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

Cleanup caps, write text for stateful NAT64 diagram

Browse source
This commit is contained in:
Nico Schottelius 2019-08-22 13:43:33 +02:00
parent ec050a11ae
commit 33963bc681
7 changed files with 71 additions and 53 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
doc/Background.tex
View file

@ -15,10 +15,10 @@ packets are 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]
\begin{figure}[htbp]
\includegraphics[scale=0.9]{p4-from-nsg}
\centering
\caption{P4 protocol independence~\cite{vanbever:_progr_networ_data_planes}}
\caption{P4 Protocol Independence~\cite{vanbever:_progr_networ_data_planes}}
\label{fig:p4fromnsg}
\end{figure}
The \textit{target independence} is the second major feature
@ -72,7 +72,7 @@ used prior to establishing a connection and their results are
cached, their availability is crucial for operating a switch, because
without ARP or NDP no connection will every be established.
Figure \ref{fig:arpndp} illustrates a typical address resolution process.
\begin{figure}[h]
\begin{figure}[htbp]
\includegraphics[scale=0.4]{arp-ndp}
\centering
\caption{ARP and NDP}
@ -103,10 +103,10 @@ As seen later in this document (compare
section \ref{results:netpfga:features}), the requirement to generate checksums
over payload poses difficult problems for some hardware targets. Even
more difficult is the use of options within ICMP6.
\begin{figure}[h]
\begin{figure}[htbp]
\includegraphics[scale=0.4]{icmp6ndp}
\centering
\caption{ICMP6 option fields}
\caption{ICMP6 Option Fields}
\label{fig:icmp6ndp}
\end{figure}
The problem arises from the layout of the options, as seen
@ -151,7 +151,7 @@ addresses of different size, but fields have also been changed or
removed when the version changed. Depending on the NAT64
translation direction, a translator will need to re-arrange fields to
a different position, remove fields and add fields.
\begin{figure}[h]
\begin{figure}[htbp]
\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
@ -194,7 +194,7 @@ NAT64 allows translating many IPv6 addresses to one IPv4 address.
While the opposite stateful translation, mapping many IPv4 addresses
to one IPv6 address, is also technically possible,
the differences in address space size don't justify its use in general.
\begin{figure}[h]
\begin{figure}[htbp]
\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
@ -222,7 +222,7 @@ protocols to multiplex connections: Given one IPv4 address and the TCP
protocol, outgoing connections from IPv6 hosts can dynamically mapped
to the range of possible TCP ports. After a session is closed, the
port can be reused again.
\begin{figure}[h]
\begin{figure}[htbp]
\includegraphics[scale=0.5]{statefulnat64}
\centering
\caption{Stateful NAT64}
@ -270,7 +270,7 @@ this purpose. One possibility to map
an IPv4 address into the prefix is by adding its integer value to the
prefix, treating it as an offset. In figure \ref{fig:ipv4embed}
we show example python code of how this can be done.
\begin{figure}[h]
\begin{figure}[htbp]
\begin{verbatim}
>>> import ipaddress
>>> prefix=ipaddress.IPv6Network("64:ff9b::/96")
@ -283,7 +283,7 @@ we show example python code of how this can be done.
IPv6Address('64:ff9b::c000:200')
\end{verbatim}
\centering
\caption{Representing an IPv4 address in an IPv6 prefix}
\caption{Representing an IPv4 address in an IPv6 Prefix}
\label{fig:ipv4embed}
\end{figure}
Network administrators can choose to use either the well known prefix
@ -293,7 +293,7 @@ Internet.\footnote{For instance
While a /96 prefix seems a natural selection (it provides exactly 32 bit),
other prefix lengths are defined in RFC6052 (see figure
\ref{fig:prefixlen}) that allow flexible embedding of the IPv4 address.
\begin{figure}[h]
\begin{figure}[htbp]
\begin{verbatim}
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
@ -312,7 +312,7 @@ other prefix lengths are defined in RFC6052 (see figure
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
\end{verbatim}
\centering
\caption{IPv4 embedding depending on the prefix length}
\caption{IPv4 Embedding Depending on the Prefix Length}
\label{fig:prefixlen}
\end{figure}
RFC6146, which describes stateful NAT64, states that
@ -359,7 +359,7 @@ level protocols. The pseudo header for upper layer protocols for
IPv6 is defined in RFC2460~\cite{rfc2460} and shown in figure
\ref{fig:ipv6pseudoheader}, the IPv4 pseudo header for TCP and UDP are
defined in RFC768 and RFC793 and are shown in \ref{fig:ipv4pseudoheader}.
\begin{figure}[h]
\begin{figure}[htbp]
\begin{verbatim}
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
@ -392,7 +392,7 @@ adjusted. The checksums for TCP and UDP are calculated not only over the pseudo
headers, but also contain the payload of the packet. This is
important because some targets (like the NetFPGA) do not allow
accessing the payload (see section \ref{design:netpfga}).
\begin{figure}[h]
\begin{figure}[htbp]
\begin{verbatim}
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
@ -490,10 +490,10 @@ a single /96 IPv6 network. IPv6 only networks also allow the operators
to focus on one IP stack.
% ----------------------------------------------------------------------
\section{\label{background:netfpga}NetFPGA}
\begin{figure}[h]
\begin{figure}[htbp]
\includegraphics[scale=0.4]{sumeboard}
\centering
\caption{NetFPGA Board, \cite{zilberman:_netfp_sume}}
\caption{NetFPGA Board~\cite{zilberman:_netfp_sume}}
\label{fig:netfpga}
\end{figure}
The NetFPGA~\cite{zilberman:_netfp_sume}

52
doc/Design.tex
View file

@ -12,7 +12,7 @@ Lastly we discuss how we verify NAT64 functionality and
present the network configurations that we use.
% ----------------------------------------------------------------------
\section{\label{design:nat64}P4/NAT64}
\begin{figure}[h]
\begin{figure}[htbp]
\includegraphics[scale=0.5]{switchdesign}
\centering
\caption{P4 Switch Architecture}
@ -40,10 +40,10 @@ switch tables.
The P4 switch can use any protocol to communicate with the controller, as
the connection to the controller is implemented as a separate Ethernet
port.
\begin{figure}[h]
\begin{figure}[htbp]
\includegraphics[scale=0.4]{v6-v4-standard}
\centering
\caption{Standard NAT64 translation}
\caption{Standard NAT64 Translation}
\label{fig:v6v4standard}
\end{figure}
@ -59,10 +59,10 @@ P4. This design has multiple advantages: first it reduces the number
of devices to pass and thus directly reduces the RTT, secondly it
allows translation of IP addresses within the same logic network
segment.
\begin{figure}[h]
\begin{figure}[htbp]
\includegraphics[scale=0.4]{v6-v4-mixed}
\centering
\caption{In-network NAT64 translation}
\caption{In-network NAT64 Translation}
\label{fig:v6v4mixed}
\end{figure}
P4 switches in general look very similar to regular switches, however
@ -77,7 +77,7 @@ implemented and translates packets.
\end{figure}
% ----------------------------------------------------------------------
\section{\label{design:bmv2}P4/BMV2}
\begin{figure}[h]
\begin{figure}[htbp]
\begin{verbatim}
/* checksumming for icmp6_na_ns_option */
update_checksum_with_payload(meta.chk_icmp6_na_ns == 1,
@ -105,7 +105,7 @@ update_checksum_with_payload(meta.chk_icmp6_na_ns == 1,
);
\end{verbatim}
\centering
\caption{P4/BMV2 checksumming}
\caption{P4/BMV2 Checksumming}
\label{fig:bmv2checksum}
\end{figure}
The software emulated switch that is implemented using
@ -138,7 +138,7 @@ second option of using the differences is described in section
% ok
% ----------------------------------------------------------------------
\section{\label{design:netpfga}P4/NetFPGA}
\begin{figure}[h]
\begin{figure}[htbp]
\begin{verbatim}
action v4sum() {
bit<16> tmp = 0;
@ -176,7 +176,7 @@ action delta_tcp_from_v6_to_v4()
}
\end{verbatim}
\centering
\caption{Calculating checksum based on header differences}
\caption{Calculating Checksum based on Header Differences}
\label{fig:checksumbydiff}
\end{figure}
While the P4-NetFPGA project~\cite{netfpga:_p4_netpf_public_github}
@ -232,7 +232,7 @@ Jool & LPM (both directions)\\
\hline
\end{tabular}
\end{minipage}
\caption{NAT64 match factors}
\caption{NAT64 Match Factors}
\label{tab:statelessnat64factors}
\end{center}
\end{table}
@ -251,7 +251,7 @@ highest degree of flexibility, as it provides support for individual
entries based on table entries and LPM table entries.
% ----------------------------------------------------------------------
\section{\label{design:statefulnat64}Stateful NAT64}
\begin{figure}[h]
\begin{figure}[htbp]
\includegraphics[scale=0.5]{p4switch-stateful}
\centering
\caption{Stateful NAT64 with P4}
@ -268,8 +268,7 @@ to solve this problem:
\item For P4/BMV2 and P4/NetPFGA a python controller handles packets
that don't have a table entry, sets the table entry in the P4 switch
and inserts the original packet afterwards back into the
switch. Figure \ref{fig:p4switchstateful} shows the flow of a packet
with stateful translation in detail.
switch.
\item With Tayga we rely on the Linux kernel NAT44 capabilities
\item Jool implements its own stateful mechanism based on port
ranges
@ -285,6 +284,25 @@ inside the Linux kernel, in case of P4 this decision is based on a
session table inside the python controller. While the Jool and Tayga
both support cleaning up old session entries,
our P4 based solution does not support this feature at the moment.
In figure \ref{fig:p4switchstateful} we show the flow of a packet for
stateful translation in a P4 switch in detail. As can be seen an IPv6
host emits a packet that should be translated to IPv4. On a new
connection there will be no table entry in the P4 switch to
match. Thus the table mismatch causes the P4 switch to forward the
packet to the controller. The controller then inspects the packet,
creates a table entry for the session and reinjects the packet into
the P4 switch. The P4 switch then processes the packet again, however
this time it finds a matching table entry. This entry causes
translation to happen to a specific IPv4 address, including higher
level protocol changes. After processing the IPv6 packet is output as
a translated IPv4 packet. A second packet of the same session will
directly take the second path via table match, as the session ID will
stay the same.\footnote{We use the quintuple (source address,
destination address, source port, destination port, protocol) to
generate a unique ID.} This is an important feature, because if the
controller was involved into processing every packet, the P4
controller would become the bottleneck.
% ----------------------------------------------------------------------
\section{\label{design:tests}NAT64 Verification}
We use socat~\cite{rieger:_multip} to verify basic operation of the
@ -296,7 +314,7 @@ commands allow interactive testing on TCP and UDP connections, while
the iperf commands fully utilise the available bandwidth with test
data.
The socat and iperf commands are used to verify all three NAT64
implementations (p4, Tayga, Jool).
implementations (P4, Tayga, Jool).
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c | c |}
@ -348,7 +366,7 @@ with 20 sessions\\
\hline
\end{tabular}
\end{minipage}
\caption{NAT64 verification commands}
\caption{NAT64 Verification Commands}
\label{tab:nat64verification}
\end{center}
\end{table}
@ -383,7 +401,7 @@ networks and IPv6 addresses are used:
\hline
\end{tabular}
\end{minipage}
\caption{IPv6 address and network overview}
\caption{IPv6 Address and Network Overview}
\label{tab:ipv6address}
\end{center}
\end{table}
@ -411,7 +429,7 @@ from the 10.0.0.0/8 range as follows:
\hline
\end{tabular}
\end{minipage}
\caption{IPv4 address and network overview}
\caption{IPv4 Address and Network Overview}
\label{tab:ipv4address}
\end{center}
\end{table}

8
doc/Introduction.tex
View file

@ -36,13 +36,13 @@ 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}}
\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}}
\caption{LACNIC Exhaustion Projection~\cite{lacnic:_ipv4_deplet_phases}}
\label{fig:lacnicexhaust}
\end{figure}
@ -63,7 +63,7 @@ with legacy IPv4 devices still needs to be provided.
\begin{figure}[h]
\includegraphics[scale=0.2]{googlev6}
\centering
\caption{Google IPv6 Statistics from~\cite{google:_ipv6_googl}}
\caption{Google IPv6 Statistics~\cite{google:_ipv6_googl}}
\label{fig:googlev6}
\end{figure}
IPv6 hosts and IPv4 hosts cannot directly connect to each other,
@ -74,7 +74,7 @@ proposed~\cite{wikipedia:_ipv6},~\cite{rfc4213}.
\begin{figure}[h]
\includegraphics[scale=0.4]{v6-v6-separated}
\centering
\caption{Separated IPv6 and IPv4 network segments}
\caption{Separated IPv6 and IPv4 Network Segments}
\label{fig:v6v4separated}
\end{figure}
However installation and configuration of the transition mechanism

12
doc/Results.tex
View file

@ -131,7 +131,7 @@ fully implemented\footnote{Source code: \texttt{checksum\_bmv2.p4}}\\
\hline
\end{tabular}
\end{minipage}
\caption{P4/BMV2 feature list}
\caption{P4/BMV2 Feature List}
\label{tab:p4bmv2features}
\end{center}
\end{table}
@ -226,7 +226,7 @@ unsupported\footnote{To support creating payload checksums, either an
\hline
\end{tabular}
\end{minipage}
\caption{P4/NetFPGA feature list}
\caption{P4/NetFPGA Feature List}
\label{tab:p4netpfgafeatures}
\end{center}
\end{table}
@ -244,13 +244,13 @@ on the first NetFPGA card.
\begin{figure}[h]
\includegraphics[scale=1.4]{hwtestnico}
\centering
\caption{Hardware Test NetPFGA card 1}
\caption{Hardware Test NetPFGA Card 1}
\label{fig:hwtestnico}
\end{figure}
\begin{figure}[h]
\includegraphics[scale=0.2]{hwtesthendrik}
\centering
\caption{Hardware Test NetPFGA card 2, ~\cite{hendrik:_p4_progr_fpga_semes_thesis_sa}}
\caption{Hardware Test NetPFGA Card 2~\cite{hendrik:_p4_progr_fpga_semes_thesis_sa}}
\label{fig:hwtesthendrik}
\end{figure}
During the development and benchmarking, the second NetFPGA card stopped to
@ -402,7 +402,7 @@ and summarise the benchmarking results.
\begin{figure}[h]
\includegraphics[scale=0.6]{softwarenat64design}
\centering
\caption{Benchmark design for NAT64 in software implementations}
\caption{Benchmark Design for NAT64 in Software Implementations}
\label{fig:softwarenat64design}
\end{figure}
We use two hosts for performing benchmarks: a load generator and a
@ -423,7 +423,7 @@ warm up phase.\footnote{iperf -O 10 parameter, see section \ref{design:tests}.}
\begin{figure}[h]
\includegraphics[scale=0.5]{netpfgadesign}
\centering
\caption{NAT64 with NetFPGA benchmark}
\caption{NAT64 with NetFPGA Benchmark}
\label{fig:netpfgadesign}
\end{figure}
% ok

BIN
doc/Thesis.pdf
View file

Binary file not shown.

12
doc/appendix.tex
View file

@ -1462,12 +1462,12 @@ nico@ESPRIMO-P956:~/master-thesis/iperf$
\end{verbatim}
%---------------------------------------------------------------------------------------------------------
\abbrev{ARP}{Address resolution protocol}
\abbrev{ASIC}{Application-specific integrated circuit}
\abbrev{DAC}{Direct attach cable}
\abbrev{FGPA}{Field-programmable gate array}
\abbrev{LPM}{Longes prefix matching}
\abbrev{MTU}{Maximum transfer unit}
\abbrev{ARP}{Address Resolution Protocol}
\abbrev{ASIC}{Application-Specific Integrated Circuit}
\abbrev{DAC}{Direct Attach Cable}
\abbrev{FGPA}{Field-Programmable Gate Array}
\abbrev{LPM}{Longes Prefix Matching}
\abbrev{MTU}{Maximum Transfer Unit}
\abbrev{NDP}{Neighbor Discovery Protocol}
\abbrev{NAT}{Network Address Translation}
\abbrev{NAT64}{Network Address Translation from / to IPv6 to / from IPv4}

8
doc/graphviz/p4switch-stateful.dot
View file

@ -9,15 +9,15 @@ digraph G {
parser [ label="Parser"];
deparser [ label="Deparser"];
translation [ label="Translation"];
mismatch [ label="Table mismatch"];
mismatch [ label="Table Mismatch"];
v4packet [ label="IPv6 Packet"];
v4packet2 [ label="IPv4 Packet"];
v6packet [ label="IPv6 Packet"];
tableentry [ label="Create table entry" ];
tablematch [ label="Table match" ];
tableentry [ label="Create Table Entry" ];
tablematch [ label="Table Match" ];
reinject [ label="Reinject packet" ];
controller [ label="Controller reads packet" ]
controller [ label="Controller Reads Packet" ]
deparser [ label="Deparser"];
deparser2 [ label="Deparser"];