++graphs ++:oc

This commit is contained in:
Nico Schottelius 2019-08-10 17:48:31 +02:00
parent 61b65341aa
commit 41703f19e0
6 changed files with 100 additions and 32 deletions

View File

@ -29,15 +29,21 @@ are discussed in section \ref{conclusion:P4}.
As opposed to general purpose programming languages, P4 lacks some As opposed to general purpose programming languages, P4 lacks some
features, most notably loops. However within its constraints, P4 can guarantee features, most notably loops. However within its constraints, P4 can guarantee
operation at line speed, which general purpose programming languages operation at line speed, which general purpose programming languages
cannot guarantee in general and also fail to achieve in reality cannot guarantee and also fail to achieve in reality
(see section \ref{results:softwarenat64} for details). (see section \ref{results:softwarenat64} for details).
% ---------------------------------------------------------------------- % ----------------------------------------------------------------------
\section{\label{background:ipv6}IPv6} \section{\label{background:ip}IPv6, IPv4 and Ethernet}
The first IPv6 RFC \cite{rfc2460} was published in 1998. The first IPv6 RFC was published in 1998\cite{rfc2460}. Both IPv4 and
IPv4 operate on layer 3 of the OSI model. In this thesis we only
consider transmission via Ethernet, which operates at
layer 2. Inside the Ethernet frame a field named ``type'' specifies
the higher level protocol identifier (0x0800 for IPv4 \cite{rfc894}
and 0x86DD for IPv6 \cite{rfc2464}. This is important, because
Ethernet can only carry either of the two protocols.
The figures \ref{fig:ipv4header} and \ref{fig:ipv6header} show the The figures \ref{fig:ipv4header} and \ref{fig:ipv6header} show the
packet headers of IPv4 and IPv6. The most notable differences between packet headers of IPv4 and IPv6. The most notable differences between
the two protocols for this project are: the two protocols for this thesis are:
\begin{itemize} \begin{itemize}
\item Different address lengths (32 vs 128 bit) \item Different address lengths (32 vs 128 bit)
\item Lack of checksum in IPv6 \item Lack of checksum in IPv6
@ -96,35 +102,71 @@ the two protocols for this project are:
\caption{IPv4 Header, \cite{rfc791}} \caption{IPv4 Header, \cite{rfc791}}
\label{fig:ipv4header} \label{fig:ipv4header}
\end{figure} \end{figure}
++content!
% ---------------------------------------------------------------------- % ----------------------------------------------------------------------
\section{\label{background:transition}IPv6 Transition Mechanisms} \section{\label{background:transition}IPv6 Translation Mechanisms}
While in this thesis the focus was in NAT64 as a transition mechanism, While in this thesis the focus was in NAT64 as a translation mechanism,
there are a variety of different approaches, some of which we would there are a variety of different approaches, some of which we would
like to portray here. like to portray here.
% ----------------------------------------------------------------------
\subsection{\label{background:transition:staticnat64}Static NAT64}
Static NAT64 describes static mappings between IPv6 and IPv4
addresses. This can be based on longest prefix matchings (LPM),
ranges, bitmasks or individual entries.
proxying NAT64 translations as described in this thesis modify multiple layers
translations in the translation process:
\begin{itemize}
\item Ethernet (changing the type field)
\item IPv4 / IPv6 (changing the protocol, changing the fields)
\item TCP/UDP/ICMP/ICMP6 checksums
\end{itemize}
% ---------------------------------------------------------------------- % ----------------------------------------------------------------------
\subsection{\label{background:transition:nat64}Static NAT64} \subsection{\label{background:transition:statefulnat64}Stateful NAT64}
1:1 mappings Stateful NAT64 as defined in RFC6146\cite{rfc6146} defines how to
cretate 1:n mappings between IPv6 and IPv4 hosts. The motivation for
stateful NAT64 is similar to stateful NAT44\cite{/rfc3022}: it allows
translating many IPv6 addresses to one IPv4 address. While the
opposite translation is also technically possible, the differences in
address space don't justify its use in general.
% ---------------------------------------------------------------------- Stateful NAT64 in particular uses information in higher level
\subsection{\label{background:transition:nat64}Dynamic NAT64} protocols to multiplex connections: Given one IPv4 address and the tcp
1:n mappings, requesting temporary ID for connection, used for protocol, outgoing connections from IPv6 hosts can dynamically mapped
outgoing NAT64 to the range of possible tcp ports. After a session is closed, the
port can be reused again.
\begin{figure}[h]
\includegraphics[scale=0.7]{statefulnat64}
\centering
\caption{Stateful NAT64}
\label{fig:statefulnat64}
\end{figure}
The selection of mapped ports is usually based on the availability on
the IPv4 side and not related to the original port. To support
stateful NAT64, the translator needs to store the mapping in a table and
purge entries regularly.
Stateful usually NAT64 uses information found in protocols at layer 4
like TCP \cite{rfc793} or UDP \cite{rfc768}. However it can also
support ICMP \cite{rfc792} or ICMP6 \cite{rfc4443}.
% ---------------------------------------------------------------------- % ----------------------------------------------------------------------
\subsection{\label{background:transition:Protocol dependent}Protocol \subsection{\label{background:transition:Protocol dependent}Higher
dependent translation} layer Protocol Dependent Translation}
http, Further translation can be achieved by using information in higher
https, level protocols like HTTP \cite{rfc2616} or TLS
TLS sni \cite{rfc4366}. Application proxies like nginx
TLS1.3 SNI might be unreadable \cite{nginx:_nginx_high_perfor_load_balan} use layer 7 protocol
Disadvantage information to proxy towards backends. Within this proxying method,
the underlying IP protocol can be changed from IPv6 to IPv4 and vice
versa. However the requested hostname that is usually used for
selecting the backend is encrypted in TLS 1.3 \cite{rfc8446}, which
poses a challenge for implementations.
While protocol dependent translation has the highest amount of
information to choose from for translation, complex parsers or even
cryptographic methods are required for it. That reduces the
opportunities of protocol dependent translation
% ---------------------------------------------------------------------- % ----------------------------------------------------------------------
\subsection{\label{background:transition:Port based}Port based \subsection{\label{background:transition:Port based}Port based

View File

@ -74,7 +74,6 @@ 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 user. This way neither the operator nor the end user has to configure
extra devices. Figures \ref{fig:v6v4standard} shows the standard NAT64 extra devices. Figures \ref{fig:v6v4standard} shows the standard NAT64
approach and \ref{fig:v6v4innetwork} shows our solution. approach and \ref{fig:v6v4innetwork} shows our solution.
\begin{figure}[h] \begin{figure}[h]
\includegraphics[scale=0.7]{v6-v4-innetwork} \includegraphics[scale=0.7]{v6-v4-innetwork}
\centering \centering
@ -88,12 +87,17 @@ approach and \ref{fig:v6v4innetwork} shows our solution.
\caption{Standard NAT64 translation} \caption{Standard NAT64 translation}
\label{fig:v6v4standard} \label{fig:v6v4standard}
\end{figure} \end{figure}
HERE: development difference
Currently network operators have to focus on two network stacks when Currently network operators have to focus on two network stacks when
designing networks: IPv6 and IPv4. As To simplify network setups designing networks: IPv6 and IPv4. While in a small scale setup this
might not introduce significant complexity, however figure
\ref{fig:v6v4mixed} shows how the complexity quickly grows
quickly with the number of nodes.
\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 The in network solution does not only ease the installation and
deployment of IPv6, but it also allows line speed translation, because deployment of IPv6, but it also allows line speed translation, because
it is compiled into target dependent low level code that can run in it is compiled into target dependent low level code that can run in

View File

@ -9,7 +9,7 @@ to reproduce the test results. All compilations were made on Ubuntu
\item 4.15.0-55-generic (Desktop with NetFPGA \item 4.15.0-55-generic (Desktop with NetFPGA
\end{itemize} \end{itemize}
\section{\label{chapterminus1:thesis}Master Thesis} \section{\label{chapterminus1:thesis:general}Master Thesis}
The master thesis including all self developed source code is The master thesis including all self developed source code is
available by git via available by git via
@ -19,7 +19,7 @@ git clone git@gitlab.ethz.ch:nicosc/master-thesis.git
It can be browsed online on \url{https://gitlab.ethz.ch/nicosc/master-thesis}. It can be browsed online on \url{https://gitlab.ethz.ch/nicosc/master-thesis}.
% ---------------------------------------------------------------------- % ----------------------------------------------------------------------
\section{\label{chapterminus1:thesis}Xilinx Toolchain} \section{\label{chapterminus1:thesis:xilinx}Xilinx Toolchain}
A prerequisite for building the NetFGPA source code is the A prerequisite for building the NetFGPA source code is the
installation of installation of
\begin{itemize} \begin{itemize}
@ -1542,6 +1542,7 @@ Describe your task.
\abbrev{ASIC}{Application-specific integrated circuit} \abbrev{ASIC}{Application-specific integrated circuit}
\abbrev{FGPA}{Field-programmable gate array} \abbrev{FGPA}{Field-programmable gate array}
\abbrev{LPM}{Longes prefix matching}
\abbrev{NAT}{Network Address Translation} \abbrev{NAT}{Network Address Translation}
\abbrev{NAT64}{Network Address Translation from / to IPv6 to / from IPv4} \abbrev{NAT64}{Network Address Translation from / to IPv6 to / from IPv4}
\abbrev{RIR}{Regional Internet Registry} \abbrev{RIR}{Regional Internet Registry}

View File

@ -0,0 +1,16 @@
graph G {
node [ shape="box"];
v6host1 [ label="IPv6/TCP: [2001:db8::1]:2323"];
v6host2 [ label="IPv6/TCP: [2001:db8::17]:4242"];
v4host [ label="IPv4/TCP: 198.51.100.2:4323, 198.51.100.2:3345"];
nat64gw [ label="NAT64 translator", rank=max ];
v6host1--nat64gw;
v6host2--nat64gw;
nat64gw--v4host;
}

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

View File

@ -78,3 +78,8 @@
author = {ungleich}, author = {ungleich},
title = {Die IPv4, die!}, title = {Die IPv4, die!},
howpublished = {\url{https://ungleich.ch/en-us/cms/blog/2019/01/09/die-ipv4-die/}}} howpublished = {\url{https://ungleich.ch/en-us/cms/blog/2019/01/09/die-ipv4-die/}}}
@Misc{nginx:_nginx_high_perfor_load_balan,
author = {NGINX},
title = {NGINX | High Performance Load Balancer, Web Server, & Reverse Proxy},
howpublished = {\url{https://www.nginx.com/}}}