Nico Schottelius
4 years ago
13 changed files with 357 additions and 53 deletions
@ -1,15 +1,220 @@
|
||||
\chapter{\label{background}Background} |
||||
In this chapter we describe the key technologies involved. |
||||
\section{\label{background:P4}P4} |
||||
P4 is a programming language designed to program inside network |
||||
equipment. It's main features are protocol and target independence. |
||||
The \textit{protocol independence} refers to the separation of concerns in |
||||
terms of language and protocols: P4 generally speaking operates on |
||||
bits that are parsed and then accessible in the (self) defined |
||||
structures, also called headers. The general flow can be seen in |
||||
figure \ref{fig:p4fromnsg}: a parser parses the incoming packet and |
||||
prepares it for processing in the switching logic. Afterwards the |
||||
packets is output and deparsing of the parsed data might follow. |
||||
In the context of NAT64 this is a very important feature: while the |
||||
parser will read and parse in the ingress pipeline one protocol |
||||
(f.i. IPv6), the deparser will output a different protocol (f.i. IPv4). |
||||
\begin{figure}[h] |
||||
\includegraphics[scale=0.9]{p4-from-nsg} |
||||
\centering |
||||
\caption{P4 protocol independence, \cite{vanbever:_progr_networ_data_planes}} |
||||
\label{fig:p4fromnsg} |
||||
\end{figure} |
||||
The \textit{target independence} is the second very powerful feature |
||||
of P4: it allows code to be compiled to different targets. While in |
||||
theory the P4 code should be completely target independent, in reality |
||||
there are some modifications needed on a per-target basis and each |
||||
target faces different restrictions. The challenges arising from this |
||||
are discussed in section \ref{conclusion:P4}. |
||||
|
||||
As opposed to general purpose programming languages, P4 lacks some |
||||
features, most notably loops. However within its constraints, P4 can guarantee |
||||
operation at line speed, which general purpose programming languages |
||||
cannot guarantee in general and also fail to achieve in reality |
||||
(see section \ref{results:softwarenat64} for details). |
||||
|
||||
% ---------------------------------------------------------------------- |
||||
\section{\label{background:ipv6}IPv6} |
||||
The first IPv6 RFC \cite{rfc2460} was published in 1998. |
||||
The figures \ref{fig:ipv4header} and \ref{fig:ipv6header} show the |
||||
packet headers of IPv4 and IPv6. The most notable differences between |
||||
the two protocols for this project are: |
||||
\begin{itemize} |
||||
\item Different address lengths (32 vs 128 bit) |
||||
\item Lack of checksum in IPv6 |
||||
\item Format of Pseudo headers (see section \ref{background:checksums}) |
||||
\end{itemize} |
||||
\begin{figure}[h] |
||||
\begin{verbatim} |
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
|Version| Traffic Class | Flow Label | |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
| Payload Length | Next Header | Hop Limit | |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
| | |
||||
+ + |
||||
| | |
||||
+ Source Address + |
||||
| | |
||||
+ + |
||||
| | |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
| | |
||||
+ + |
||||
| | |
||||
+ Destination Address + |
||||
| | |
||||
+ + |
||||
| | |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
\end{verbatim} |
||||
\centering |
||||
\caption{IPv6 Header, \cite{rfc2460}} |
||||
\label{fig:ipv6header} |
||||
\end{figure} |
||||
|
||||
\begin{figure}[h] |
||||
\begin{verbatim} |
||||
|
||||
***** Für IPv6, NAT64, transitation mechanism |
||||
***** RFC hinzufügen |
||||
***** P4 kurz erwähnen |
||||
0 1 2 3 |
||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
|Version| IHL |Type of Service| Total Length | |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
| Identification |Flags| Fragment Offset | |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
| Time to Live | Protocol | Header Checksum | |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
| Source Address | |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
| Destination Address | |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
| Options | Padding | |
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
||||
|
||||
growth |
||||
\end{verbatim} |
||||
\caption{IPv4 Header, \cite{rfc791}} |
||||
\label{fig:ipv4header} |
||||
\end{figure} |
||||
|
||||
++content! |
||||
|
||||
% ---------------------------------------------------------------------- |
||||
\section{\label{background:transition}IPv6 Transition Mechanisms} |
||||
While in this thesis the focus was in NAT64 as a transition mechanism, |
||||
there are a variety of different approaches, some of which we would |
||||
like to portray here. |
||||
|
||||
\section{\label{background:transition}Transition Mechanisms} |
||||
proxying |
||||
translations |
||||
|
||||
\section{\label{background:ipv6}IPv6} |
||||
% ---------------------------------------------------------------------- |
||||
\subsection{\label{background:transition:nat64}Static NAT64} |
||||
1:1 mappings |
||||
|
||||
% ---------------------------------------------------------------------- |
||||
\subsection{\label{background:transition:nat64}Dynamic NAT64} |
||||
1:n mappings, requesting temporary ID for connection, used for |
||||
outgoing NAT64 |
||||
|
||||
% ---------------------------------------------------------------------- |
||||
\subsection{\label{background:transition:Protocol dependent}Protocol |
||||
dependent translation} |
||||
http, |
||||
https, |
||||
TLS sni |
||||
TLS1.3 SNI might be unreadable |
||||
Disadvantage |
||||
|
||||
% ---------------------------------------------------------------------- |
||||
\subsection{\label{background:transition:Port based}Port based |
||||
translation} |
||||
tcp/udp |
||||
icmp: ?? maybe ID field |
||||
|
||||
|
||||
% ---------------------------------------------------------------------- |
||||
\section{\label{background:checksums}Protocol Checksums} |
||||
|
||||
% ---------------------------------------------------------------------- |
||||
\section{\label{background:networkdesign}Network Designs} |
||||
\begin{figure}[h] |
||||
\includegraphics[scale=0.5]{v4only} |
||||
\centering |
||||
\caption{IPv4 only network} |
||||
\label{fig:v4onlynet} |
||||
\end{figure} |
||||
In relation to IPv6 and IPv4, there are in general three different |
||||
network designs possible: |
||||
The oldest form are IPv4 only networks (see figure |
||||
\ref{fig:v4onlynet}. |
||||
These networks consist of |
||||
hosts that are either not configured for IPv6 or are even technically |
||||
incapable of enabling the IPv6 protocol. These nodes are connected to |
||||
an IPv4 router that is connected to the Internet. That router might be |
||||
capable of translating IPv4 to IPv6 and vice versa. |
||||
\begin{figure}[h] |
||||
\includegraphics[scale=0.5]{dualstack} |
||||
\centering |
||||
\caption{Dualstack network} |
||||
\label{fig:dualstacknet} |
||||
\end{figure} |
||||
With the introduction of IPv6, hosts can have a separate IP stack |
||||
active and in that configuration hosts are called ``dualstack hosts'' |
||||
(see figure \ref{fig:dualstacknet}). |
||||
Dualstack hosts are capabale of reaching both IPv6 and IPv4 hosts |
||||
directly without the need of any translation mechanism. |
||||
|
||||
The last possible network design is based on IPv6 only hosts, as shown |
||||
in figure \ref{fig:v6onlynet}. While it is technically easy to disable IPv4, it |
||||
seems that completely removing the IPv4 stack in current operating |
||||
systems is not an easy task \cite{ungleich:_ipv4}. |
||||
\begin{figure}[h] |
||||
\includegraphics[scale=0.5]{v6only} |
||||
\centering |
||||
\caption{IPv6 only network} |
||||
\label{fig:v6onlynet} |
||||
\end{figure} |
||||
While the three network designs look similar, there are significant |
||||
differences in operating them and limitations that are not easy to |
||||
circumvent. In the following sections we describe the limitations and |
||||
reason how a translation mechanism like our NAT64 implementation |
||||
should be deployed. |
||||
% ---------------------------------------------------------------------- |
||||
\subsection{\label{background:networkdesign:ipv4}IPv4 only network limitations} |
||||
As shown in figures \ref{fig:ipv4header} and \ref{fig:ipv6header} |
||||
the IPv4 address size is 32 bit, while the IPv6 address size is 128 |
||||
bit. |
||||
Without an extension to the address space, there is no protocol independent |
||||
mapping of IPv4 address to IPv6 (see section |
||||
\ref{background:transition:nat64}) |
||||
that can cover the whole IPv6 address space. Thus IPv4 only hosts can |
||||
never address every host in the IPv6 Internet. While protocol |
||||
dependent translations can try to minimise the impact, accessing all |
||||
IPv6 addresses independent of the protcol is not possible. |
||||
% ---------------------------------------------------------------------- |
||||
\subsection{\label{background:networkdesign:dualstack}Dualstack network |
||||
maintenance} |
||||
While dualstack hosts can address any host in either IPv6 or IPv4 |
||||
networks, the deployment of dualstack hosts comes with a major |
||||
disadvantage: all network configuration double. The required routing |
||||
tables double, the firewall rules roughly double\footnote{The rulesets |
||||
even for identical policies in IPv6 and IPv4 networks are not |
||||
identical, but similar. For this reason we state that roughly double |
||||
the amount of firewall rules are required for the same policy to be |
||||
applied.} and the number of network supporting systems (like DHCPv4, |
||||
DHCPv6, router advertisement daemons, etc.) also roughly double. |
||||
Additionally services that run on either IPv6 or IPv4 might need to be |
||||
configured to run in dualstack mode as well and not every software |
||||
might be capable of that. |
||||
So while there is the instant benefit of not requiring any transition mechanism |
||||
or translation method, we argue that the added complexity (and thus |
||||
operational cost) of running dual stack networks can be significant. |
||||
% ---------------------------------------------------------------------- |
||||
\subsection{\label{background:networkdesign:v6only}IPv6 only networks} |
||||
IPv6 only networks are our opinion the best choice for long term |
||||
deployments. The reasons for this are as follows: |
||||
IPv6 hosts can address the whole 32 bit IPv4 Internet mapped in |
||||
a single /96 IPv6 network, whithout the need for address extension or |
||||
higher protocol dependent translations\footnote{Lower level protocols |
||||
like TCP, UDP, ICMP6/ICMP.} |
||||
|
||||
@ -0,0 +1,22 @@
|
||||
graph G { |
||||
node [ shape="box"]; |
||||
|
||||
host1 [ label="Dualstack host"]; |
||||
host2 [ label="Dualstack host"]; |
||||
host3 [ label="Dualstack host"]; |
||||
router [ label="IPv6 & IPv4 router"]; |
||||
|
||||
v4internet [ label="IPv4 Internet", shape="egg" ]; |
||||
v6internet [ label="IPv6 Internet", shape="egg" ]; |
||||
|
||||
switch1 [ label="Network Switch", shape="oval" ]; |
||||
|
||||
host1--switch1; |
||||
host2--switch1; |
||||
host3--switch1; |
||||
|
||||
switch1--router; |
||||
router--v4internet; |
||||
router--v6internet; |
||||
|
||||
} |
||||
|
After Width: | Height: | Size: 24 KiB |
@ -0,0 +1,25 @@
|
||||
graph G { |
||||
node [ shape="box"]; |
||||
|
||||
|
||||
v4host1 [ label="IPv4 only host"]; |
||||
v4host2 [ label="IPv4 only host"]; |
||||
v4host3 [ label="IPv4 only host"]; |
||||
v4router [ label="IPv4 router"]; |
||||
|
||||
v4internet [ label="IPv4 Internet", shape="egg" ]; |
||||
v6internet [ label="IPv6 Internet", shape="egg" ]; |
||||
|
||||
|
||||
switch1 [ label="Network Switch", shape="oval" ]; |
||||
|
||||
v4host1--switch1; |
||||
v4host2--switch1; |
||||
v4host3--switch1; |
||||
|
||||
switch1--v4router; |
||||
|
||||
v4router--v4internet; |
||||
v4router--v6internet; |
||||
|
||||
} |
||||
|
After Width: | Height: | Size: 22 KiB |
@ -0,0 +1,23 @@
|
||||
graph G { |
||||
node [ shape="box"]; |
||||
|
||||
|
||||
v6host1 [ label="IPv6 only host"]; |
||||
v6host2 [ label="IPv6 only host"]; |
||||
v6host3 [ label="IPv6 only host"]; |
||||
v6router [ label="IPv6 router"]; |
||||
|
||||
v4internet [ label="IPv4 Internet", shape="egg" ]; |
||||
v6internet [ label="IPv6 Internet", shape="egg" ]; |
||||
|
||||
switch1 [ label="Network Switch", shape="oval" ]; |
||||
|
||||
v6host1--switch1; |
||||
v6host2--switch1; |
||||
v6host3--switch1; |
||||
|
||||
switch1--v6router; |
||||
v6router--v4internet; |
||||
v6router--v6internet; |
||||
|
||||
} |
||||
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 85 KiB |
Loading…
Reference in new issue