2019-08-07 13:55:53 +00:00
|
|
|
\chapter{\label{background}Background}
|
2019-08-09 12:25:18 +00:00
|
|
|
In this chapter we describe the key technologies involved.
|
2019-08-07 13:55:53 +00:00
|
|
|
\section{\label{background:P4}P4}
|
2019-08-09 12:25:18 +00:00
|
|
|
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
|
2019-08-10 15:48:31 +00:00
|
|
|
cannot guarantee and also fail to achieve in reality
|
2019-08-09 12:25:18 +00:00
|
|
|
(see section \ref{results:softwarenat64} for details).
|
|
|
|
|
|
|
|
|
|
% ----------------------------------------------------------------------
|
2019-08-10 15:48:31 +00:00
|
|
|
\section{\label{background:ip}IPv6, IPv4 and Ethernet}
|
|
|
|
|
The first IPv6 RFC was published in 1998\cite{rfc2460}. Both IPv4 and
|
|
|
|
|
IPv4 operate on layer 3 of the OSI model. In this thesis we only
|
|
|
|
|
consider transmission via Ethernet, which operates at
|
|
|
|
|
layer 2. Inside the Ethernet frame a field named ``type'' specifies
|
|
|
|
|
the higher level protocol identifier (0x0800 for IPv4 \cite{rfc894}
|
|
|
|
|
and 0x86DD for IPv6 \cite{rfc2464}. This is important, because
|
|
|
|
|
Ethernet can only carry either of the two protocols.
|
2019-08-09 12:25:18 +00:00
|
|
|
The figures \ref{fig:ipv4header} and \ref{fig:ipv6header} show the
|
|
|
|
|
packet headers of IPv4 and IPv6. The most notable differences between
|
2019-08-10 15:48:31 +00:00
|
|
|
the two protocols for this thesis are:
|
2019-08-09 12:25:18 +00:00
|
|
|
\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}
|
2019-08-07 13:55:53 +00:00
|
|
|
|
2019-08-09 12:25:18 +00:00
|
|
|
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 |
|
|
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
2019-08-07 13:55:53 +00:00
|
|
|
|
2019-08-09 12:25:18 +00:00
|
|
|
\end{verbatim}
|
|
|
|
|
\caption{IPv4 Header, \cite{rfc791}}
|
|
|
|
|
\label{fig:ipv4header}
|
|
|
|
|
\end{figure}
|
|
|
|
|
% ----------------------------------------------------------------------
|
2019-08-12 10:13:59 +00:00
|
|
|
\section{\label{background:arpndp}ARP and NDP - FIXME}
|
|
|
|
|
Required for finding host.
|
|
|
|
|
ARP who has
|
|
|
|
|
NDP similar -- add traces here
|
|
|
|
|
% ----------------------------------------------------------------------
|
2019-08-10 15:48:31 +00:00
|
|
|
\section{\label{background:transition}IPv6 Translation Mechanisms}
|
|
|
|
|
While in this thesis the focus was in NAT64 as a translation mechanism,
|
2019-08-09 12:25:18 +00:00
|
|
|
there are a variety of different approaches, some of which we would
|
|
|
|
|
like to portray here.
|
2019-08-10 15:48:31 +00:00
|
|
|
% ----------------------------------------------------------------------
|
|
|
|
|
\subsection{\label{background:transition:staticnat64}Static NAT64}
|
|
|
|
|
Static NAT64 describes static mappings between IPv6 and IPv4
|
|
|
|
|
addresses. This can be based on longest prefix matchings (LPM),
|
|
|
|
|
ranges, bitmasks or individual entries.
|
2019-08-07 13:55:53 +00:00
|
|
|
|
2019-08-10 15:48:31 +00:00
|
|
|
NAT64 translations as described in this thesis modify multiple layers
|
|
|
|
|
in the translation process:
|
2019-08-07 13:55:53 +00:00
|
|
|
|
2019-08-10 15:48:31 +00:00
|
|
|
\begin{itemize}
|
|
|
|
|
\item Ethernet (changing the type field)
|
|
|
|
|
\item IPv4 / IPv6 (changing the protocol, changing the fields)
|
|
|
|
|
\item TCP/UDP/ICMP/ICMP6 checksums
|
|
|
|
|
\end{itemize}
|
2019-08-09 12:25:18 +00:00
|
|
|
|
|
|
|
|
% ----------------------------------------------------------------------
|
2019-08-10 15:48:31 +00:00
|
|
|
\subsection{\label{background:transition:statefulnat64}Stateful NAT64}
|
|
|
|
|
Stateful NAT64 as defined in RFC6146\cite{rfc6146} defines how to
|
|
|
|
|
cretate 1:n mappings between IPv6 and IPv4 hosts. The motivation for
|
|
|
|
|
stateful NAT64 is similar to stateful NAT44\cite{/rfc3022}: it allows
|
|
|
|
|
translating many IPv6 addresses to one IPv4 address. While the
|
|
|
|
|
opposite translation is also technically possible, the differences in
|
|
|
|
|
address space don't justify its use in general.
|
|
|
|
|
|
|
|
|
|
Stateful NAT64 in particular uses information in higher level
|
|
|
|
|
protocols to multiplex connections: Given one IPv4 address and the tcp
|
|
|
|
|
protocol, outgoing connections from IPv6 hosts can dynamically mapped
|
|
|
|
|
to the range of possible tcp ports. After a session is closed, the
|
|
|
|
|
port can be reused again.
|
|
|
|
|
\begin{figure}[h]
|
2019-08-10 16:11:42 +00:00
|
|
|
\includegraphics[scale=0.5]{statefulnat64}
|
2019-08-10 15:48:31 +00:00
|
|
|
\centering
|
|
|
|
|
\caption{Stateful NAT64}
|
|
|
|
|
\label{fig:statefulnat64}
|
|
|
|
|
\end{figure}
|
|
|
|
|
The selection of mapped ports is usually based on the availability on
|
|
|
|
|
the IPv4 side and not related to the original port. To support
|
|
|
|
|
stateful NAT64, the translator needs to store the mapping in a table and
|
|
|
|
|
purge entries regularly.
|
|
|
|
|
|
|
|
|
|
Stateful usually NAT64 uses information found in protocols at layer 4
|
|
|
|
|
like TCP \cite{rfc793} or UDP \cite{rfc768}. However it can also
|
|
|
|
|
support ICMP \cite{rfc792} or ICMP6 \cite{rfc4443}.
|
2019-08-09 12:25:18 +00:00
|
|
|
% ----------------------------------------------------------------------
|
2019-08-10 15:48:31 +00:00
|
|
|
\subsection{\label{background:transition:Protocol dependent}Higher
|
|
|
|
|
layer Protocol Dependent Translation}
|
|
|
|
|
Further translation can be achieved by using information in higher
|
|
|
|
|
level protocols like HTTP \cite{rfc2616} or TLS
|
|
|
|
|
\cite{rfc4366}. Application proxies like nginx
|
|
|
|
|
\cite{nginx:_nginx_high_perfor_load_balan} use layer 7 protocol
|
|
|
|
|
information to proxy towards backends. Within this proxying method,
|
|
|
|
|
the underlying IP protocol can be changed from IPv6 to IPv4 and vice
|
|
|
|
|
versa. However the requested hostname that is usually used for
|
|
|
|
|
selecting the backend is encrypted in TLS 1.3 \cite{rfc8446}, which
|
|
|
|
|
poses a challenge for implementations.
|
|
|
|
|
|
|
|
|
|
While protocol dependent translation has the highest amount of
|
|
|
|
|
information to choose from for translation, complex parsers or even
|
|
|
|
|
cryptographic methods are required for it. That reduces the
|
|
|
|
|
opportunities of protocol dependent translation
|
2019-08-09 12:25:18 +00:00
|
|
|
% ----------------------------------------------------------------------
|
|
|
|
|
\section{\label{background:checksums}Protocol Checksums}
|
2019-08-10 16:11:42 +00:00
|
|
|
One challenge for translating IPv6-IPv4 are checksums of higher level
|
|
|
|
|
protocols like TCP and UDP that incorporate information from the lower
|
|
|
|
|
level protocols. The pseudo header for upper layer protocols for
|
|
|
|
|
IPv6 is defined in RFC2460 \cite{rfc2460} and shown in figure
|
|
|
|
|
\ref{fig:ipv6pseudoheader}, the IPv4 pseudo header for TCP and UDP are
|
|
|
|
|
defined in RFC768 and RFC793 and are shown in \ref{fig:ipv4pseudoheader}.
|
|
|
|
|
\begin{figure}[h]
|
|
|
|
|
\begin{verbatim}
|
|
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
| |
|
|
|
|
|
+ +
|
|
|
|
|
| |
|
|
|
|
|
+ Source Address +
|
|
|
|
|
| |
|
|
|
|
|
+ +
|
|
|
|
|
| |
|
|
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
| |
|
|
|
|
|
+ +
|
|
|
|
|
| |
|
|
|
|
|
+ Destination Address +
|
|
|
|
|
| |
|
|
|
|
|
+ +
|
|
|
|
|
| |
|
|
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
| Upper-Layer Packet Length |
|
|
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
| zero | Next Header |
|
|
|
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
\end{verbatim}
|
|
|
|
|
\centering
|
|
|
|
|
\caption{IPv6 Pseudo Header}
|
|
|
|
|
\label{fig:ipv6pseudoheader}
|
|
|
|
|
\end{figure}
|
|
|
|
|
When translating, the checksum fields in the higher protocols need to be
|
|
|
|
|
adjusted. The checksums for TCP and UDP is calculated not only over the pseudo
|
|
|
|
|
headers, but also contain the payload of the packet. This is
|
|
|
|
|
important, because some targets (like the NetPFGA) do not allow to
|
|
|
|
|
access the payload.
|
|
|
|
|
\begin{figure}[h]
|
|
|
|
|
\begin{verbatim}
|
|
|
|
|
0 7 8 15 16 23 24 31
|
|
|
|
|
+--------+--------+--------+--------+
|
|
|
|
|
| source address |
|
|
|
|
|
+--------+--------+--------+--------+
|
|
|
|
|
| destination address |
|
|
|
|
|
+--------+--------+--------+--------+
|
|
|
|
|
| zero |protocol| UDP length |
|
|
|
|
|
+--------+--------+--------+--------+
|
2019-08-09 12:25:18 +00:00
|
|
|
|
2019-08-10 16:11:42 +00:00
|
|
|
\end{verbatim}
|
|
|
|
|
\centering
|
|
|
|
|
\caption{IPv4 Pseudo Header}
|
|
|
|
|
\label{fig:ipv4pseudoheader}
|
|
|
|
|
\end{figure}
|
2019-08-09 12:25:18 +00:00
|
|
|
% ----------------------------------------------------------------------
|
|
|
|
|
\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}
|
2019-08-10 16:11:42 +00:00
|
|
|
IPv6 only networks are in our opinion the best choice for long term
|
|
|
|
|
deployments. The reasons for this are as follows: First of all hosts
|
|
|
|
|
eventually will need to support IPv6 and secondly
|
2019-08-09 12:25:18 +00:00
|
|
|
IPv6 hosts can address the whole 32 bit IPv4 Internet mapped in
|
2019-08-12 10:13:59 +00:00
|
|
|
a single /96 IPv6 network. IPv6 only networks also allow the operators
|
|
|
|
|
to focus on one IP stack.
|
