master-thesis/doc/Introduction.tex

%** Introduction.tex: Contains an introduction to
%                     the topic and motivates the work.
%                     State what the reader can find where.

%** Problem.tex: Documentation in own words of the problem to
%                be addressed in this document:
%                What is the challenge, why is it useful what you
%                plan to do.


%% In \ref{introduction} we start with our introduction to the problem that we
%% are going to address.  Since we do not want to waste the readers time we
%% go and show the essential issues of latex in section
%% \ref{chapter2:essentials}.


\chapter{\label{introduction}Introduction}
In this chapter we give an introduction about the topic of the master
thesis, the motivation, and problems that we address. We explain the
current state of IPv4 exhaustion and IPv6 adoption and describe how
it motivates our work to support to ease transition to IPv6 networks.

% ----------------------------------------------------------------------
\section{\label{introduction:ipv4ipv6}IPv4 Exhaustion and IPv6 Adoption}
The Internet has almost completely run out of public IPv4 space. The
5 Regional Internet Registries (RIRs) report IPv4 exhaustion worldwide
\cite{ripe_exhaustion},
\cite{apnic_exhaustion},
\cite{lacnic:_ipv4_deplet_phases},
\cite{afrinic:_afrin_ipv4_exhaus},
\cite{arin:_ipv4_addres_option}.
Figure \ref{fig:riripv4rundown} contains summarised data from all RIRs
and projects complete IPv4 addresses depletion by 2021.
The LACNIC project even predicts complete exhaustion for 2020 as shown
in figure \ref{fig:lacnicexhaust}.
\begin{figure}[h]
  \includegraphics[scale=0.5]{rir-ipv4-rundown}
  \centering
  \caption{RIR IPv4 Rundown Projection~\cite{huston:_ipv4_addres_repor}}
  \label{fig:riripv4rundown}
\end{figure}
\begin{figure}[h]
  \includegraphics[scale=0.7]{lacnicdepletion}
  \centering
  \caption{LACNIC Exhaustion Projection~\cite{lacnic:_ipv4_deplet_phases}}
  \label{fig:lacnicexhaust}
\end{figure}

On the other hand, IPv6 adoption grows significantly, with at least
three countries (India, US, Belgium) surpassing 50\%
adoption~\cite{akamai:_ipv6_adopt_visual},
\cite{vyncke:_ipv6_deploy_aggreg_status},
\cite{cisco:_ipv6}. Traffic from Google users reaches almost 30\% as
of 2019-08-08~\cite{google:_ipv6_googl}, see figure \ref{fig:googlev6}.

We conclude that IPv6 is a technology strongly gaining importance.
IPv4 depletion is estimated to be happening worldwide in the
next years. Thus more devices will be using IPv6, while communication
with legacy IPv4 devices still needs to be provided.
% ok
% ----------------------------------------------------------------------
\section{\label{introduction:motivation}Motivation}
\begin{figure}[h]
  \includegraphics[scale=0.2]{googlev6}
  \centering
  \caption{Google IPv6 Statistics~\cite{google:_ipv6_googl}}
  \label{fig:googlev6}
\end{figure}
IPv6 hosts and IPv4 hosts cannot directly connect to each other,
because the protocols are incompatible to each other.
To allow communication between different protocol hosts,
several transition mechanisms have been
proposed~\cite{wikipedia:_ipv6},~\cite{rfc4213}.
\begin{figure}[h]
  \includegraphics[scale=0.4]{v6-v6-separated}
  \centering
  \caption{Separated IPv6 and IPv4 Network Segments}
  \label{fig:v6v4separated}
\end{figure}
However installation and configuration of the transition mechanism
usually require in-depth knowledge about both protocols and require
additional hardware to be added in the network.
In this thesis we show an in-network transition method based on
NAT64~\cite{rfc6146}. Compared to traditional NAT64 methods which
require hosts to explicitly use an extra device in the
network,\footnote{Usually the default router will take this role.}
our proposed method is transparent to the hosts.
This way the routing and network configuration does not need to be
changed to support NAT64 within a network.
Currently network operators have to focus on two network stacks when
designing networks: IPv6 and IPv4. While in a small scale setup this
might not introduce significant complexity, figure
\ref{fig:v6v4separated} shows how the complexity quickly grows
even with a small number of hosts.
The proposed in-network solution does not only ease the installation and
deployment of IPv6, but it also allows line speed translation, because
it is compiled into target dependent low level code that can run in
ASICs~\cite{networks:_tofin},
FPGAs~\cite{netfpga:_p4_netpf_public_github}
or even in
software~\cite{_implem_your_switc_target_with_bmv2}. Figure
\ref{fig:v6v4mixed} shows how the design differs for an in-network
solution.
Even on fast CPUs, software solutions like
Tayga~\cite{lutchansky:_Tayga_simpl_nat64_linux}
can be CPU bound (see section \ref{results:softwarenat64}) and are
incapable of translating protocols at line speed.