Finish design / stateless NAT64

This commit is contained in:
Nico Schottelius 2019-08-19 14:45:41 +02:00
parent 2a31aed74c
commit f9422a0e38
4 changed files with 130 additions and 76 deletions

View File

@ -1,7 +1,8 @@
\chapter{\label{design}Design}
%** Design.tex: How was the problem attacked, what was the design
% the architecture
In this chapter we describe the architecture of our solution.
In this chapter we describe the architecture of our solution and our
design choices.
% ----------------------------------------------------------------------
\section{\label{design:configuration}IPv6 and IPv4 configuration}
@ -12,7 +13,6 @@ for the discussion.
All IPv6 addresses are from the documentation block
\textit{2001:DB8::/32}~\cite{rfc3849}. In particular the following sub
networks and IPv6 addresses are used:
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c |}
@ -67,12 +67,78 @@ from the 10.0.0.0/8 range as follows:
\label{tab:ipv4address}
\end{center}
\end{table}
% ok
% ----------------------------------------------------------------------
\section{\label{design:nat64}NAT64 with P4 - FIXME: elaborate}
\section{\label{design:tests}NAT64 Verification}
We use socat~\cite{rieger:_multip} to verify basic operation of the
NAT64 gateway and iperf~\cite{dugan:_tcp_udp_sctp} to test stability
of the implementation and measure bandwidth.
In particular we use
the commands listed in table \ref{tab:nat64verification}. The socat
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).
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c | c |}
\hline
\textbf{Command} & \textbf{Example} & \textbf{Description} \\
\hline
\texttt{socat - TCP6:HOST:PORT} & socat -
TCP6:[2001:db8:42::a00:2a]:2345 & Connect via IPv6/TCP\\
& & to IPv4 host\\
%\hline
\texttt{socat - UDP6:HOST:PORT} & socat -
UDP6:[2001:db8:42::a00:2a]:2345 & Connect via IPv6/UDP \\ & & to IPv4 host\\
%\hline
\texttt{socat - TCP:HOST:PORT} & socat -
TCP:10.0.1.42:2345 & Connect via IPv4/TCP \\ & & to IPv6 host \\
%\hline
\texttt{socat - UDP:HOST:PORT} & socat -
UDP:10.0.1.42:2345 & Connect via IPv4/UDP \\ & & to IPv6 host \\
\hline
\texttt{socat - UDP6-LISTEN:PORT} & socat -
UDP6-LISTEN:2345 & Listen on IPv6/UDP \\
%\hline
\texttt{socat - TCP6-LISTEN:PORT} & socat -
TCP6-LISTEN:2345 & Listen on IPv6/TCP \\
%\hline
\texttt{socat - UDP-LISTEN:PORT} & socat -
UDP-LISTEN:2345 & Listen on IPv4/UDP \\
%\hline
\texttt{socat - TCP-LISTEN:PORT} & socat -
TCP-LISTEN:2345 & Listen on IPv4/TCP \\
\hline
\texttt{iperf3 -PROTO -p PORT} & iperf3 -4 -p 2345 & IPv4 iperf server\\
\texttt{-B IP -s} & -B 10.0.0.42 -s &\\
& iperf3 -6 -p 2345 & IPv6 iperf server\\
& -B 2001:db8:42::42 -s & \\
\hline
\texttt{iperf3 -PROTO -p PORT } & iperf3 -6 -p 2345& Connect to iperf server\\
\texttt{-O IGNORETIME -t RUNTIME} & -O 10 -t 190 &
Run for 190 seconds, \\
& & skip first 10 seconds\\
\texttt{-P PARALLEL -c IP} & -P20 -c 2001:db8:23::2a &
with 20 sessions\\
& & connecting to\\
& & 2001:db8:23::2a\\
\texttt{iperf3 -PROTO -p PORT} & & Same as above,\\
\texttt{-O IGNORETIME -t RUNTIME} & & but connect via UDP\\
\texttt{-P PARALLEL -c IP} & & \\
\texttt{-u -b0} & & \\
\hline
\end{tabular}
\end{minipage}
\caption{NAT64 verification commands}
\label{tab:nat64verification}
\end{center}
\end{table}
% ----------------------------------------------------------------------
\section{\label{design:nat64}NAT64 with P4}
\begin{figure}[h]
\includegraphics[scale=0.5]{switchdesign}
\includegraphics[scale=0.4]{switchdesign}
\centering
\caption{P4 Switch Architecture}
\label{fig:switchdesign}
@ -83,7 +149,7 @@ the translation mechansims stateless and stateful NAT64. While higher
layer protocol dependent translations are more flexible, this topic
has already been addressed in
\cite{nico18:_implem_layer_ipv4_ipv6_rever_proxy} and the focus in
this thesis is on the practicability of high speed NAT64.
this thesis is on the practicability of high speed NAT64 with P4.
The high level design can be seen in figure \ref{fig:switchdesign}: a
P4 capable switch is running our code to provide NAT64
functionality. A P4 switch cannot manage its tables on it own and
@ -107,17 +173,16 @@ port.
\end{figure}
Software NAT64 solutions typically require routing to be applied to
transport the packet to the NAT64 translator as shown in
transport the packet to the NAT64 translator as shown in figure
\ref{fig:v6v4standard}.
Our design differs here: while routing could be used like described
above, NAT64 with P4 does not require any routing to be setup. Figure
\ref{fig:v6v4mixed} shows a network design that can be realised using
\ref{fig:v6v4mixed} shows the network design that we realise using
P4. This design has multiple advantages: first it reduces the number
of devices to pass and thus directly reduces the RTT. Secondly it
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]
\includegraphics[scale=0.4]{v6-v4-mixed}
\centering
@ -125,72 +190,46 @@ segment.
\label{fig:v6v4mixed}
\end{figure}
allows our solution to be used as a standard NAT64
translation method or as an in network NAT64 translation (compare
figures \ref{fig:v6v4innetwork} and \ref{fig:v6v4standard}). The
controller is implemented in python, the NAT64 solution is implemented
in P4. The network
\begin{figure}[h]
\includegraphics[scale=0.5]{networkdesignnat64}
\centering
\caption{Network design}
\label{fig:switchdesign}
\end{figure}
from intro:
Figures \ref{fig:v6v4standard} shows the standard NAT64
approach and \ref{fig:v6v4innetwork} shows our solution.
%% \begin{figure}[h]
%% \includegraphics[scale=0.6]{v6-v4-innetwork}
%% \centering
%% \caption{In Network NAT64 translation}
%% \label{fig:v6v4innetwork}
%% \end{figure}
Describe network layouts
\begin{verbatim}
- IPv6 subnet 2001:db8::/32
- IPv6 hosts are in 2001:db8:6::/64
- IPv6 default router (::/0) is 2001:db8:6::42/64
- IPv4 mapped Internet "NAT64 prefix" 2001:db8:4444::/96 (should
go into a table)
- IPv4 hosts are in 10.0.4.0/24
- IPv6 in IPv4 mapped hosts are in 10.0.6.0/24
- IPv4 default router = 10.0.0.42
\end{verbatim}
Describe testing methods
\begin{verbatim}
def test_v4_udp_to_v6(self):
print('mx h3 "echo V4-OK | socat - UDP:10.1.1.1:2342"')
print('mx h1 "echo V6-OK | socat - UDP-LISTEN:2342"')
return
p4@ubuntu:~$ mx h1 "echo V6-OK | socat - UDP6-LISTEN:2342"
p4@ubuntu:~/master-thesis/bin$ mx h3 "echo V4-OK | socat - UDP:10.1.1.1:2342"
while true; do mx h3 "echo V4-OK | socat - TCP-LISTEN:2343"; sleep 2;
done
while true; do mx h1 "echo V6-OK | socat -
TCP6:[2001:db8:1::a00:1]:2343"; sleep 2; done
mx h1 "echo V6-OK | socat - TCP6:[2001:db8:1::a00:1]:2343"
\end{verbatim}
% ----------------------------------------------------------------------
% ----------------------------------------------------------------------
\section{\label{design:statelessnat64}Stateless NAT64 - FIXME: write}
Only using /96. Using addition.
\section{\label{design:statelessnat64}Stateless NAT64}
As seen in section \ref{background:transition:stateless}, stateless
NAT64 can be implemented using various factors. Our design for the
stateless depends on the capabilities of the environment and is
summarised in table \ref{tab:statelessnat64factors}.
\begin{table}[htbp]
\begin{center}\begin{minipage}{\textwidth}
\begin{tabular}{| c | c |}
\hline
\textbf{Implementation} & \textbf{NAT64 match}\\
\hline
P4/BMV2 & LPM (both directions)\\
& and individual entries (both directions)\\
\hline
P4/NetPFGA & Individual entries\\
\hline
Tayga & LPM (IPv6 to IPv4) and individual entries (IPv4 to IPv6)\\
\hline
Jool & LPM (both directions)\\
\hline
\end{tabular}
\end{minipage}
\caption{NAT64 match factors}
\label{tab:statelessnat64factors}
\end{center}
\end{table}
When using LPM for translating from IPv6 to IPv4, a /96 IPv6 network
is configured for covering the whole IPv4 Internet and the individual
IPv4 address is appended to the prefix (compare section
\ref{design:configuration}). We also use LPM to match on an IPv4 sub
network that translates to an IPv6 sub network. Individual
entries are configured differently depending on the implementation:
Limitations in the P4/NetFPGA environment require to use table
entries. Jool supports individual entries as a special case of LPM,
with a network mask matching only one IP address. Tayga
support LPM for translation from IPv6 to IPv4, but requires invidiual
entries for translating from IPv4 to IPv6. Our P4/BMV2 offers the
highest degree of flexibility, as it provides support for invidual
entries based on table entries and LPM table entries.
% ----------------------------------------------------------------------
\section{\label{design:statefulnat64}Stateful NAT64 - FIXME: write}
- controller selects "outgoing" IPv4 address range => base for sessions

View File

@ -19,6 +19,9 @@ P4 software implementation.
- Does not / never signal end
- Needs timeout for cleaning up
P4/BMV2 thus
allows us to closest resemble any other translation implementation.
Only supporting /96, not other embeddings as described in
section \ref{background:transition:prefixnat}.

Binary file not shown.

View File

@ -163,3 +163,15 @@
title = {IPv4 Address Report},
howpublished = {\url{https://ipv4.potaroo.net/}},
note = {Requested on 2019-08-18}}
@Misc{rieger:_multip,
author = {Gerhard Rieger},
title = {socat - Multipurpose relay},
howpublished = {\url{http://www.dest-unreach.org/socat/}},
note = {Requested on 2019-08-19}}
@Misc{dugan:_tcp_udp_sctp,
author = {Jon Dugan and Seth Elliott and Bruce A. Mah and Jeff Poskanzer and Kaustubh Prabhu},
title = {iPerf - The ultimate speed test tool for TCP, UDP and SCTP},
howpublished = {\url{https://iperf.fr/}},
note = {Requested on 2019-08-19}}