master-thesis/doc/Introduction.tex

112 lines
4.6 KiB
TeX
Raw Normal View History

2019-07-29 17:13:47 +00:00
%** Introduction.tex: Contains an introduction to
% the topic and motivates the work.
% State what the reader can find where.
2019-08-09 09:49:41 +00:00
%** 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}
2019-08-08 12:08:07 +00:00
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.
2019-08-08 12:08:07 +00:00
% ----------------------------------------------------------------------
2019-08-09 08:38:54 +00:00
\section{\label{introduction:ipv4ipv6}IPv4 exhaustion and IPv6 adoption}
2019-08-08 12:08:07 +00:00
The Internet has almost completely run out of public IPv4 space. The
2019-08-08 12:45:16 +00:00
5 Regional Internet Registries (RIRs) report IPv4 exhaustion world wide
2019-08-08 12:08:07 +00:00
(\cite{ripe_exhaustion},
\cite{apnic_exhaustion},
2019-08-08 12:45:16 +00:00
\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,
2019-08-18 12:24:22 +00:00
~\cite{lacnic:_ipv4_deplet_phases}}
2019-08-08 12:45:16 +00:00
\label{fig:lacnicexhaust}
\end{figure}
On the other hand IPv6 adoption grows significantly, with at least
2019-08-18 12:24:22 +00:00
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}.
2019-08-08 12:45:16 +00:00
\begin{figure}[h]
\includegraphics[scale=0.2]{googlev6}
\centering
\caption{Google IPv6 Statistics,
2019-08-18 12:24:22 +00:00
~\cite{google:_ipv6_googl}}
2019-08-08 12:45:16 +00:00
\label{fig:googlev6}
\end{figure}
2019-08-09 09:49:41 +00:00
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.
2019-08-08 12:08:07 +00:00
2019-08-09 08:38:54 +00:00
% ----------------------------------------------------------------------
\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,
2019-08-18 12:24:22 +00:00
several transition mechanism have been
proposed (\cite{wikipedia:_ipv6}, \cite{rfc4213}).
2019-08-09 08:38:54 +00:00
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.
2019-08-18 12:24:22 +00:00
In this thesis we show an in-network transition method based on
NAT64~\cite{rfc6146}. Compared to traditional NAT64 methods which require an
2019-08-09 08:38:54 +00:00
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
2019-08-09 09:49:41 +00:00
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}
2019-08-09 12:25:18 +00:00
Currently network operators have to focus on two network stacks when
2019-08-10 15:48:31 +00:00
designing networks: IPv6 and IPv4. While in a small scale setup this
2019-08-12 10:13:59 +00:00
might not introduce significant complexity, figure
2019-08-10 15:48:31 +00:00
\ref{fig:v6v4mixed} shows how the complexity quickly grows
2019-08-12 10:13:59 +00:00
with the number of hosts.
2019-08-10 15:48:31 +00:00
\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}
2019-08-09 09:49:41 +00:00
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
2019-08-18 12:24:22 +00:00
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
2019-08-09 12:25:18 +00:00
not capabale of translating protocols at line speed.