You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

108 lines
4.7 KiB

%** 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}
3 years ago
In this chapter we give an introduction about the topic of the master
3 years ago
thesis, the motivation, and problems that we address. We explain the
current state of IPv4 exhaustion and IPv6 adoption and describe how
3 years ago
it motivates our work to support to ease transition to IPv6 networks.
3 years ago
% ----------------------------------------------------------------------
\section{\label{introduction:ipv4ipv6}IPv4 Exhaustion and IPv6 Adoption}
3 years ago
The Internet has almost completely run out of public IPv4 space. The
3 years ago
5 Regional Internet Registries (RIRs) report IPv4 exhaustion worldwide
\cite{ripe_exhaustion},
3 years ago
\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}
3 years ago
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,
3 years ago
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}
3 years ago
However installation and configuration of the transition mechanism
3 years ago
usually require in-depth knowledge about both protocols and require
3 years ago
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.
3 years ago
Currently network operators have to focus on two network stacks when
3 years ago
designing networks: IPv6 and IPv4. While in a small scale setup this
3 years ago
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
3 years ago
incapable of translating protocols at line speed.