220 lines
11 KiB
TeX
220 lines
11 KiB
TeX
\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}
|
|
|
|
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 |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
\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.
|
|
|
|
proxying
|
|
translations
|
|
|
|
% ----------------------------------------------------------------------
|
|
\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.}
|