107 lines
4.7 KiB
TeX
107 lines
4.7 KiB
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 from~\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.
|