|
|
|
@ -3,31 +3,130 @@
|
|
|
|
|
% the architecture |
|
|
|
|
In this chapter we describe the architecture of our solution. |
|
|
|
|
|
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\section{\label{design:configuration}IPv6 and IPv4 configuration} |
|
|
|
|
The following sections refer to host and network configurations. In |
|
|
|
|
this section we describe the IPv6 and IPv4 configurations as a basis |
|
|
|
|
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 |} |
|
|
|
|
\hline |
|
|
|
|
\textbf{Address} & \textbf{Description} \\ |
|
|
|
|
\hline |
|
|
|
|
2001:db8:42::/64 & IPv6 host network \\ |
|
|
|
|
\hline |
|
|
|
|
2001:db8:23::/96 & IPv6 mapping to the IPv4 Internet \\ |
|
|
|
|
\hline |
|
|
|
|
2001:db8:42::42 & IPv6 host address \\ |
|
|
|
|
\hline |
|
|
|
|
2001:db8:42::77 & IPv6 router address \\ |
|
|
|
|
\hline |
|
|
|
|
2001:db8:42::a00:2a & In-network IPv6 address mapped to 10.0.0.42 (p4)\\ |
|
|
|
|
\hline |
|
|
|
|
2001:db8:23::a00:2a & IPv6 address mapped to 10.0.0.42 (tayga) \\ |
|
|
|
|
\hline |
|
|
|
|
2001:db8:23::2a & IPv6 address mapped to 10.0.0.42 (jool)\\ |
|
|
|
|
\hline |
|
|
|
|
\end{tabular} |
|
|
|
|
\end{minipage} |
|
|
|
|
\caption{IPv6 address and network overview} |
|
|
|
|
\label{tab:ipv6address} |
|
|
|
|
\end{center} |
|
|
|
|
\end{table} |
|
|
|
|
|
|
|
|
|
We use private IPv4 addresses as specified by RFC1918~\cite{rfc1918} |
|
|
|
|
from the 10.0.0.0/8 range as follows: |
|
|
|
|
|
|
|
|
|
\begin{table}[htbp] |
|
|
|
|
\begin{center}\begin{minipage}{\textwidth} |
|
|
|
|
\begin{tabular}{| c | c |} |
|
|
|
|
\hline |
|
|
|
|
\textbf{Address} & \textbf{Description} \\ |
|
|
|
|
\hline |
|
|
|
|
10.0.0.0/24 & IPv4 host network \\ |
|
|
|
|
\hline |
|
|
|
|
10.0.1.0/24 & IPv4 network mapping to IPv6\\ |
|
|
|
|
\hline |
|
|
|
|
10.0.0.77 & IPv4 router address\\ |
|
|
|
|
\hline |
|
|
|
|
10.0.0.66 & In-network IPv4 address mapped to 2001:db8:42::42 (p4)\\ |
|
|
|
|
\hline |
|
|
|
|
10.0.1.42 & IPv4 address mapped to 2001:db8:42::42 (tayga)\\ |
|
|
|
|
\hline |
|
|
|
|
10.0.1.66 & IPv4 address mapped to 2001:db8:42::42 (jool)\\ |
|
|
|
|
\hline |
|
|
|
|
\end{tabular} |
|
|
|
|
\end{minipage} |
|
|
|
|
\caption{IPv4 address and network overview} |
|
|
|
|
\label{tab:ipv4address} |
|
|
|
|
\end{center} |
|
|
|
|
\end{table} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\section{\label{design:nat64}NAT64 with P4 - FIXME: elaborate} |
|
|
|
|
\begin{figure}[h] |
|
|
|
|
\includegraphics[scale=0.5]{switchdesign} |
|
|
|
|
\centering |
|
|
|
|
\caption{P4 Switch Architecture} |
|
|
|
|
\label{fig:switchdesign} |
|
|
|
|
\end{figure} |
|
|
|
|
In section \ref{background:transition} we discussed different |
|
|
|
|
translation mechanisms for IPv6 and IPv4. In this thesis we focus on |
|
|
|
|
the translation mechansims stateless and stateful NAT64. While higher |
|
|
|
|
layer protocol dependent translations are more flexible, this topic |
|
|
|
|
has already addressed in |
|
|
|
|
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. |
|
|
|
|
The high level design can be seen in figure \ref{fig:switchdesign}: a |
|
|
|
|
P4 capable switch is running our code to provide NAT64 |
|
|
|
|
functionality. The P4 switch cannot manage its tables on it own and |
|
|
|
|
needs support for this from a controller. If only static table entries |
|
|
|
|
are required, the controller can also be omitted. However stateful |
|
|
|
|
NAT64 requires the use of a control to create session entries in the |
|
|
|
|
functionality. A P4 switch cannot manage its tables on it own and |
|
|
|
|
needs support for this from a controller. The controller also has the |
|
|
|
|
role to handle unknown packets and can modify the runtime |
|
|
|
|
configuration of the switch. This is especially useful in the case of |
|
|
|
|
stateful NAT64. |
|
|
|
|
If only static table entries |
|
|
|
|
are required, they can usually be added at the start of a P4 switch |
|
|
|
|
and the controller can also be omitted. However stateful |
|
|
|
|
NAT64 requires the use of a controller to create session entries in the |
|
|
|
|
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] |
|
|
|
|
\includegraphics[scale=0.5]{switchdesign} |
|
|
|
|
\includegraphics[scale=0.4]{v6-v4-standard} |
|
|
|
|
\centering |
|
|
|
|
\caption{P4 Switch Architecture} |
|
|
|
|
\label{fig:switchdesign} |
|
|
|
|
\caption{Standard NAT64 translation} |
|
|
|
|
\label{fig:v6v4standard} |
|
|
|
|
\end{figure} |
|
|
|
|
The P4 switch can use any protocol to communicate with controller, as |
|
|
|
|
the connection to the controller is implemented as a separate ethernet |
|
|
|
|
port. The design allows our solution to be used as a standard NAT64 |
|
|
|
|
|
|
|
|
|
Software NAT64 solutions typically require routing to be applied to |
|
|
|
|
transport the packet to the NAT64 translator as shown in |
|
|
|
|
\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 |
|
|
|
|
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] |
|
|
|
|
\includegraphics[scale=0.4]{v6-v4-mixed} |
|
|
|
|
\centering |
|
|
|
|
\caption{In-network NAT64 translation} |
|
|
|
|
\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 |
|
|
|
@ -40,31 +139,19 @@ in P4. The network
|
|
|
|
|
\end{figure} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
from intro: |
|
|
|
|
|
|
|
|
|
\begin{figure}[h] |
|
|
|
|
\includegraphics[scale=0.4]{v6-v4-mixed} |
|
|
|
|
\centering |
|
|
|
|
\caption{Different network design with in network NAT64 translation} |
|
|
|
|
\label{fig:v6v4mixed} |
|
|
|
|
\end{figure} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figures \ref{fig:v6v4standard} shows the standard NAT64 |
|
|
|
|
approach and \ref{fig:v6v4innetwork} shows our solution. |
|
|
|
|
\begin{figure}[h] |
|
|
|
|
\includegraphics[scale=0.7]{v6-v4-innetwork} |
|
|
|
|
\centering |
|
|
|
|
\caption{In Network NAT64 translation} |
|
|
|
|
\label{fig:v6v4innetwork} |
|
|
|
|
\end{figure} |
|
|
|
|
\begin{figure}[h] |
|
|
|
|
\includegraphics[scale=0.7]{v6-v4-standard} |
|
|
|
|
\centering |
|
|
|
|
\caption{Standard NAT64 translation} |
|
|
|
|
\label{fig:v6v4standard} |
|
|
|
|
\end{figure} |
|
|
|
|
%% \begin{figure}[h] |
|
|
|
|
%% \includegraphics[scale=0.6]{v6-v4-innetwork} |
|
|
|
|
%% \centering |
|
|
|
|
%% \caption{In Network NAT64 translation} |
|
|
|
|
%% \label{fig:v6v4innetwork} |
|
|
|
|
%% \end{figure} |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Describe network layouts |
|
|
|
|