111 lines
4.6 KiB
TeX
111 lines
4.6 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 problemes that we address. We explain the
|
|
current state of IPv4 exhaustion and IPv6 adoption and describe how
|
|
it motivates our work to support 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 world wide
|
|
(\cite{ripe_exhaustion},
|
|
\cite{apnic_exhaustion},
|
|
\cite{lacnic:_ipv4_deplet_phases},
|
|
\cite{afrinic:_afrin_ipv4_exhaus},
|
|
\cite{arin:_ipv4_addres_option}) and LACNIC project complete
|
|
exhaustion for 2020 (see figure \ref{fig:lacnicexhaust}).
|
|
|
|
\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}.
|
|
\begin{figure}[h]
|
|
\includegraphics[scale=0.2]{googlev6}
|
|
\centering
|
|
\caption{Google IPv6 Statistics,
|
|
~\cite{google:_ipv6_googl}}
|
|
\label{fig:googlev6}
|
|
\end{figure}
|
|
We conclude that IPv6 is a technology strongly gaining importance with
|
|
the IPv4 depletion that is estimated to be world wide happening in the
|
|
next years. Thus more devices will be using IPv6, while communication
|
|
to legacy IPv4 devices still needs to be provided.
|
|
|
|
% ----------------------------------------------------------------------
|
|
\section{\label{introduction:motivation}Motivation}
|
|
IPv6 nodes and IPv4 nodes cannot directly connect to each other,
|
|
because the protocols are incompatible to each other.
|
|
To allow communication between different protocol nodes,
|
|
several transition mechanism have been
|
|
proposed (\cite{wikipedia:_ipv6}, \cite{rfc4213}).
|
|
|
|
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 an
|
|
extra device in the network, our proposed method is transparent to the
|
|
user. This way neither the operator nor the end user has to configure
|
|
extra devices. Figures \ref{fig:v6v4standard} shows the standard NAT64
|
|
approach and \ref{fig:v6v4innetwork} shows our solution.
|
|
\begin{figure}[h]
|
|
\includegraphics[scale=0.7]{v6-v4-innetwork}
|
|
\centering
|
|
\caption{In Network NAT64 translation}
|
|
\label{fig:v6v4innetwork}
|
|
\end{figure}
|
|
\begin{figure}[h]
|
|
\includegraphics[scale=0.7]{v6-v4-standard}
|
|
\centering
|
|
\caption{Standard NAT64 translation}
|
|
\label{fig:v6v4standard}
|
|
\end{figure}
|
|
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:v6v4mixed} shows how the complexity quickly grows
|
|
with the number of hosts.
|
|
\begin{figure}[h]
|
|
\includegraphics[scale=0.4]{v6-v4-mixed}
|
|
\centering
|
|
\caption{Differenent network design with in network NAT64 translation}
|
|
\label{fig:v6v4mixed}
|
|
\end{figure}
|
|
The 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}.
|
|
Even on fast CPUs, software solutions like
|
|
tayga~\cite{lutchansky:_tayga_simpl_nat64_linux}
|
|
can be CPU bound and are
|
|
not capabale of translating protocols at line speed.
|