nico/master-thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Design: add network documentation

Browse source
This commit is contained in:
Nico Schottelius 2019-08-19 11:59:37 +02:00
parent d7d38ad820
commit 2a31aed74c
3 changed files with 123 additions and 35 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

157
doc/Design.tex
View file

@ -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}
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
\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
switch tables.
\begin{figure}[h]
\includegraphics[scale=0.5]{switchdesign}
\centering
\caption{P4 Switch Architecture}
\label{fig:switchdesign}
\end{figure}
The P4 switch can use any protocol to communicate with controller, as
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 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. 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. The design allows our solution to be used as a standard NAT64
port.
\begin{figure}[h]
\includegraphics[scale=0.4]{v6-v4-standard}
\centering
\caption{Standard NAT64 translation}
\label{fig:v6v4standard}
\end{figure}
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

BIN
doc/Thesis.pdf
View file

Binary file not shown.

1
doc/appendix.tex
View file

@ -2587,3 +2587,4 @@ Linux package management, handling updates, etc.
\abbrev{NAT}{Network Address Translation}
\abbrev{NAT64}{Network Address Translation from / to IPv6 to / from IPv4}
\abbrev{RIR}{Regional Internet Registry}
\abbrev{RTT}{Round Trip Time}