Design: add network documentation
This commit is contained in:
parent
d7d38ad820
commit
2a31aed74c
3 changed files with 123 additions and 35 deletions
157
doc/Design.tex
157
doc/Design.tex
|
@ -3,31 +3,130 @@
|
||||||
% the architecture
|
% the architecture
|
||||||
In this chapter we describe the architecture of our solution.
|
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}
|
\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]
|
\begin{figure}[h]
|
||||||
\includegraphics[scale=0.5]{switchdesign}
|
\includegraphics[scale=0.5]{switchdesign}
|
||||||
\centering
|
\centering
|
||||||
\caption{P4 Switch Architecture}
|
\caption{P4 Switch Architecture}
|
||||||
\label{fig:switchdesign}
|
\label{fig:switchdesign}
|
||||||
\end{figure}
|
\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
|
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
|
translation method or as an in network NAT64 translation (compare
|
||||||
figures \ref{fig:v6v4innetwork} and \ref{fig:v6v4standard}). The
|
figures \ref{fig:v6v4innetwork} and \ref{fig:v6v4standard}). The
|
||||||
controller is implemented in python, the NAT64 solution is implemented
|
controller is implemented in python, the NAT64 solution is implemented
|
||||||
|
@ -40,31 +139,19 @@ in P4. The network
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
from intro:
|
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
|
Figures \ref{fig:v6v4standard} shows the standard NAT64
|
||||||
approach and \ref{fig:v6v4innetwork} shows our solution.
|
approach and \ref{fig:v6v4innetwork} shows our solution.
|
||||||
\begin{figure}[h]
|
%% \begin{figure}[h]
|
||||||
\includegraphics[scale=0.7]{v6-v4-innetwork}
|
%% \includegraphics[scale=0.6]{v6-v4-innetwork}
|
||||||
\centering
|
%% \centering
|
||||||
\caption{In Network NAT64 translation}
|
%% \caption{In Network NAT64 translation}
|
||||||
\label{fig:v6v4innetwork}
|
%% \label{fig:v6v4innetwork}
|
||||||
\end{figure}
|
%% \end{figure}
|
||||||
\begin{figure}[h]
|
|
||||||
\includegraphics[scale=0.7]{v6-v4-standard}
|
|
||||||
\centering
|
|
||||||
\caption{Standard NAT64 translation}
|
|
||||||
\label{fig:v6v4standard}
|
|
||||||
\end{figure}
|
|
||||||
|
|
||||||
|
|
||||||
Describe network layouts
|
Describe network layouts
|
||||||
|
|
BIN
doc/Thesis.pdf
BIN
doc/Thesis.pdf
Binary file not shown.
|
@ -2587,3 +2587,4 @@ Linux package management, handling updates, etc.
|
||||||
\abbrev{NAT}{Network Address Translation}
|
\abbrev{NAT}{Network Address Translation}
|
||||||
\abbrev{NAT64}{Network Address Translation from / to IPv6 to / from IPv4}
|
\abbrev{NAT64}{Network Address Translation from / to IPv6 to / from IPv4}
|
||||||
\abbrev{RIR}{Regional Internet Registry}
|
\abbrev{RIR}{Regional Internet Registry}
|
||||||
|
\abbrev{RTT}{Round Trip Time}
|
||||||
|
|
Loading…
Reference in a new issue