diff --git a/doc/Background.tex b/doc/Background.tex index 16c8869..5cc9aec 100644 --- a/doc/Background.tex +++ b/doc/Background.tex @@ -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} diff --git a/doc/Design.tex b/doc/Design.tex index 0b075db..c6f3b87 100644 --- a/doc/Design.tex +++ b/doc/Design.tex @@ -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} diff --git a/doc/Introduction.tex b/doc/Introduction.tex index defac49..ad63dcd 100644 --- a/doc/Introduction.tex +++ b/doc/Introduction.tex @@ -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 diff --git a/doc/Results.tex b/doc/Results.tex index d15fef4..058022d 100644 --- a/doc/Results.tex +++ b/doc/Results.tex @@ -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 diff --git a/doc/Thesis.pdf b/doc/Thesis.pdf index 6732fc8..a3b38be 100644 Binary files a/doc/Thesis.pdf and b/doc/Thesis.pdf differ diff --git a/doc/appendix.tex b/doc/appendix.tex index 225d6f3..fb7a24a 100644 --- a/doc/appendix.tex +++ b/doc/appendix.tex @@ -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} diff --git a/doc/graphviz/p4switch-stateful.dot b/doc/graphviz/p4switch-stateful.dot index 5dbec72..c17e988 100644 --- a/doc/graphviz/p4switch-stateful.dot +++ b/doc/graphviz/p4switch-stateful.dot @@ -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"];