nico/master-thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

++doc

Browse source
This commit is contained in:
Nico Schottelius 2019-08-09 14:25:18 +02:00
parent 1c217817c4
commit bbada059b5
13 changed files with 357 additions and 53 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

217
doc/Background.tex
View file

@ -1,15 +1,220 @@
\chapter{\label{background}Background}
In this chapter we describe the key technologies involved.
\section{\label{background:P4}P4}
P4 is a programming language designed to program inside network
equipment. It's main features are protocol and target independence.
The \textit{protocol independence} refers to the separation of concerns in
terms of language and protocols: P4 generally speaking operates on
bits that are parsed and then accessible in the (self) defined
structures, also called headers. The general flow can be seen in
figure \ref{fig:p4fromnsg}: a parser parses the incoming packet and
prepares it for processing in the switching logic. Afterwards the
packets is output and deparsing of the parsed data might follow.
In the context of NAT64 this is a very important feature: while the
parser will read and parse in the ingress pipeline one protocol
(f.i. IPv6), the deparser will output a different protocol (f.i. IPv4).
\begin{figure}[h]
\includegraphics[scale=0.9]{p4-from-nsg}
\centering
\caption{P4 protocol independence, \cite{vanbever:_progr_networ_data_planes}}
\label{fig:p4fromnsg}
\end{figure}
The \textit{target independence} is the second very powerful feature
of P4: it allows code to be compiled to different targets. While in
theory the P4 code should be completely target independent, in reality
there are some modifications needed on a per-target basis and each
target faces different restrictions. The challenges arising from this
are discussed in section \ref{conclusion:P4}.
As opposed to general purpose programming languages, P4 lacks some
features, most notably loops. However within its constraints, P4 can guarantee
operation at line speed, which general purpose programming languages
cannot guarantee in general and also fail to achieve in reality
(see section \ref{results:softwarenat64} for details).
% ----------------------------------------------------------------------
\section{\label{background:ipv6}IPv6}
The first IPv6 RFC \cite{rfc2460} was published in 1998.
The figures \ref{fig:ipv4header} and \ref{fig:ipv6header} show the
packet headers of IPv4 and IPv6. The most notable differences between
the two protocols for this project are:
\begin{itemize}
\item Different address lengths (32 vs 128 bit)
\item Lack of checksum in IPv6
\item Format of Pseudo headers (see section \ref{background:checksums})
\end{itemize}
\begin{figure}[h]
\begin{verbatim}
***** Für IPv6, NAT64, transitation mechanism
***** RFC hinzufügen
***** P4 kurz erwähnen
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\end{verbatim}
\centering
\caption{IPv6 Header, \cite{rfc2460}}
\label{fig:ipv6header}
\end{figure}
growth
\begin{figure}[h]
\begin{verbatim}
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\end{verbatim}
\caption{IPv4 Header, \cite{rfc791}}
\label{fig:ipv4header}
\end{figure}
++content!
% ----------------------------------------------------------------------
\section{\label{background:transition}IPv6 Transition Mechanisms}
While in this thesis the focus was in NAT64 as a transition mechanism,
there are a variety of different approaches, some of which we would
like to portray here.
\section{\label{background:transition}Transition Mechanisms}
proxying
translations
\section{\label{background:ipv6}IPv6}
% ----------------------------------------------------------------------
\subsection{\label{background:transition:nat64}Static NAT64}
1:1 mappings
% ----------------------------------------------------------------------
\subsection{\label{background:transition:nat64}Dynamic NAT64}
1:n mappings, requesting temporary ID for connection, used for
outgoing NAT64
% ----------------------------------------------------------------------
\subsection{\label{background:transition:Protocol dependent}Protocol
dependent translation}
http,
https,
TLS sni
TLS1.3 SNI might be unreadable
Disadvantage
% ----------------------------------------------------------------------
\subsection{\label{background:transition:Port based}Port based
translation}
tcp/udp
icmp: ?? maybe ID field
% ----------------------------------------------------------------------
\section{\label{background:checksums}Protocol Checksums}
% ----------------------------------------------------------------------
\section{\label{background:networkdesign}Network Designs}
\begin{figure}[h]
\includegraphics[scale=0.5]{v4only}
\centering
\caption{IPv4 only network}
\label{fig:v4onlynet}
\end{figure}
In relation to IPv6 and IPv4, there are in general three different
network designs possible:
The oldest form are IPv4 only networks (see figure
\ref{fig:v4onlynet}.
These networks consist of
hosts that are either not configured for IPv6 or are even technically
incapable of enabling the IPv6 protocol. These nodes are connected to
an IPv4 router that is connected to the Internet. That router might be
capable of translating IPv4 to IPv6 and vice versa.
\begin{figure}[h]
\includegraphics[scale=0.5]{dualstack}
\centering
\caption{Dualstack network}
\label{fig:dualstacknet}
\end{figure}
With the introduction of IPv6, hosts can have a separate IP stack
active and in that configuration hosts are called ``dualstack hosts''
(see figure \ref{fig:dualstacknet}).
Dualstack hosts are capabale of reaching both IPv6 and IPv4 hosts
directly without the need of any translation mechanism.
The last possible network design is based on IPv6 only hosts, as shown
in figure \ref{fig:v6onlynet}. While it is technically easy to disable IPv4, it
seems that completely removing the IPv4 stack in current operating
systems is not an easy task \cite{ungleich:_ipv4}.
\begin{figure}[h]
\includegraphics[scale=0.5]{v6only}
\centering
\caption{IPv6 only network}
\label{fig:v6onlynet}
\end{figure}
While the three network designs look similar, there are significant
differences in operating them and limitations that are not easy to
circumvent. In the following sections we describe the limitations and
reason how a translation mechanism like our NAT64 implementation
should be deployed.
% ----------------------------------------------------------------------
\subsection{\label{background:networkdesign:ipv4}IPv4 only network limitations}
As shown in figures \ref{fig:ipv4header} and \ref{fig:ipv6header}
the IPv4 address size is 32 bit, while the IPv6 address size is 128
bit.
Without an extension to the address space, there is no protocol independent
mapping of IPv4 address to IPv6 (see section
\ref{background:transition:nat64})
that can cover the whole IPv6 address space. Thus IPv4 only hosts can
never address every host in the IPv6 Internet. While protocol
dependent translations can try to minimise the impact, accessing all
IPv6 addresses independent of the protcol is not possible.
% ----------------------------------------------------------------------
\subsection{\label{background:networkdesign:dualstack}Dualstack network
maintenance}
While dualstack hosts can address any host in either IPv6 or IPv4
networks, the deployment of dualstack hosts comes with a major
disadvantage: all network configuration double. The required routing
tables double, the firewall rules roughly double\footnote{The rulesets
even for identical policies in IPv6 and IPv4 networks are not
identical, but similar. For this reason we state that roughly double
the amount of firewall rules are required for the same policy to be
applied.} and the number of network supporting systems (like DHCPv4,
DHCPv6, router advertisement daemons, etc.) also roughly double.
Additionally services that run on either IPv6 or IPv4 might need to be
configured to run in dualstack mode as well and not every software
might be capable of that.
So while there is the instant benefit of not requiring any transition mechanism
or translation method, we argue that the added complexity (and thus
operational cost) of running dual stack networks can be significant.
% ----------------------------------------------------------------------
\subsection{\label{background:networkdesign:v6only}IPv6 only networks}
IPv6 only networks are our opinion the best choice for long term
deployments. The reasons for this are as follows:
IPv6 hosts can address the whole 32 bit IPv4 Internet mapped in
a single /96 IPv6 network, whithout the need for address extension or
higher protocol dependent translations\footnote{Lower level protocols
like TCP, UDP, ICMP6/ICMP.}

3
doc/Conclusion.tex
View file

@ -7,6 +7,8 @@ Sum up what you have done and recapitulate your key findings.
%\section{\label{conclusion:overall}Overall}
\section{\label{conclusion:softwarenat64}Software based NAT64}
\section{\label{conclusion:bmv2}BMV2}
maybe remove
@ -17,6 +19,7 @@ Easy architecture
Limitations in
\section{\label{conclusion:netpfga}NetFGPA}
personal note here

57
doc/Introduction.tex
View file

@ -89,55 +89,18 @@ approach and \ref{fig:v6v4innetwork} shows our solution.
\label{fig:v6v4standard}
\end{figure}
HERE: development difference
Currently network operators have to focus on two network stacks when
designing networks: IPv6 and IPv4. As To simplify network setups
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}.
\section{\label{introduction:taskdescription}The Task}
- Milestone 1: Stateless NAT64/NAT46 translations in P4
- Milestone 2: Stateful (dynamic) NAT64/NAT46 translations
- Milestone 3: Hardware adaption
This thesis is
into 3 milestone
P4 environment
a lot of potential
Programming language in the network
Not only faster, but also more convienient.
**** High speed NAT64 with P4
Currently there are two main open source NAT64 solution available:
tayga and jool. The former is a single threaded, cpu bound user
space solution, the latter a custom Linux kernel module.
This thesis challenges this status quo by developing a P4 based
solution supporting all features of jool/tayga and comparing the
performance, security and adaptivity of the solutions.
Describe your task.
\section{\label{chapter2:linespeed}Line Speed NAT64}
NAT64 in software is CPU bound. Hardware can potentially do this at
line speed.
\section{\label{chapter2:transitition}Simplify IPv6 deployments}
Currently network operators have to focus on two network stacks when
designing networks: IPv6 and IPv4. As To simplify network setups
\section{todo}
\begin{verbatim}
***** Motivation zeigen
***** IPv6, NetPFGA mehr Möglichketien
***** P4 erwähnen
***** Task gut zu zeigen, alles erreicht
use cases / sample applications
\end{verbatim}
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.

3
doc/Results.tex
View file

@ -50,6 +50,9 @@ Reproducibility:
Limits if in actions
\section{\label{results:softwarenat64}NAT64 in Software}
Tayga, Jool
\section{todo}
\begin{verbatim}

45
doc/appendix.tex
View file

@ -1492,6 +1492,51 @@ root@ESPRIMO-P956:~#
%If you are using TeXniCenter, specify:
%"%bm.nlo" -s nomencl.ist -o "%bm.nls"
%as beeing the argument list for makeindex.
%---------------------------------------------------------------------------------------------------------
\chapter{\label{bufferssssss}Buffer}
Stuff that needs to be cleaned up
\section{Introduction}
\subsection{\label{introduction:taskdescription}The Task}
- Milestone 1: Stateless NAT64/NAT46 translations in P4
- Milestone 2: Stateful (dynamic) NAT64/NAT46 translations
- Milestone 3: Hardware adaption
This thesis is
into 3 milestone
P4 environment
a lot of potential
Programming language in the network
Not only faster, but also more convienient.
**** High speed NAT64 with P4
Currently there are two main open source NAT64 solution available:
tayga and jool. The former is a single threaded, cpu bound user
space solution, the latter a custom Linux kernel module.
This thesis challenges this status quo by developing a P4 based
solution supporting all features of jool/tayga and comparing the
performance, security and adaptivity of the solutions.
Describe your task.
\begin{verbatim}
***** Motivation zeigen
***** IPv6, NetPFGA mehr Möglichketien
***** P4 erwähnen
***** Task gut zu zeigen, alles erreicht
use cases / sample applications
\end{verbatim}
%---------------------------------------------------------------------------------------------------------
\printnomenclature

22
doc/graphviz/dualstack.dot Normal file
View file

@ -0,0 +1,22 @@
graph G {
node [ shape="box"];
host1 [ label="Dualstack host"];
host2 [ label="Dualstack host"];
host3 [ label="Dualstack host"];
router [ label="IPv6 & IPv4 router"];
v4internet [ label="IPv4 Internet", shape="egg" ];
v6internet [ label="IPv6 Internet", shape="egg" ];
switch1 [ label="Network Switch", shape="oval" ];
host1--switch1;
host2--switch1;
host3--switch1;
switch1--router;
router--v4internet;
router--v6internet;
}

BIN
doc/graphviz/dualstack.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 24 KiB

25
doc/graphviz/v4only.dot Normal file
View file

@ -0,0 +1,25 @@
graph G {
node [ shape="box"];
v4host1 [ label="IPv4 only host"];
v4host2 [ label="IPv4 only host"];
v4host3 [ label="IPv4 only host"];
v4router [ label="IPv4 router"];
v4internet [ label="IPv4 Internet", shape="egg" ];
v6internet [ label="IPv6 Internet", shape="egg" ];
switch1 [ label="Network Switch", shape="oval" ];
v4host1--switch1;
v4host2--switch1;
v4host3--switch1;
switch1--v4router;
v4router--v4internet;
v4router--v6internet;
}

BIN
doc/graphviz/v4only.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 22 KiB

23
doc/graphviz/v6only.dot Normal file
View file

@ -0,0 +1,23 @@
graph G {
node [ shape="box"];
v6host1 [ label="IPv6 only host"];
v6host2 [ label="IPv6 only host"];
v6host3 [ label="IPv6 only host"];
v6router [ label="IPv6 router"];
v4internet [ label="IPv4 Internet", shape="egg" ];
v6internet [ label="IPv6 Internet", shape="egg" ];
switch1 [ label="Network Switch", shape="oval" ];
v6host1--switch1;
v6host2--switch1;
v6host3--switch1;
switch1--v6router;
v6router--v4internet;
v6router--v6internet;
}

BIN
doc/graphviz/v6only.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
doc/images/p4-from-nsg.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 85 KiB

15
doc/refs/refs.bib
View file

@ -63,3 +63,18 @@
author = {Barefoot Networks},
title = {Tofino2},
howpublished = {\url{https://barefootnetworks.com/products/brief-tofino-2/}}}
@Misc{lutchansky:_tayga_simpl_nat64_linux,
author = {Nathan Lutchansky},
title = {TAYGA - Simple, no-fuss NAT64 for Linux},
howpublished = {\url{http://www.litech.org/tayga/}}}
@Misc{vanbever:_progr_networ_data_planes,
author = {Laurent Vanbever},
title = {Programming Network Data Planes},
howpublished = {\url{https://github.com/nsg-ethz/p4-learning/blob/master/slides/02_p4_env.pdf}}}
@Misc{ungleich:_ipv4,
author = {ungleich},
title = {Die IPv4, die!},
howpublished = {\url{https://ungleich.ch/en-us/cms/blog/2019/01/09/die-ipv4-die/}}}