|
|
|
@ -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 |
|
|
|
|