|
|
|
|
@ -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} |
|
|
|
|
|
Nico Schottelius
3 years ago