You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
309 lines
18 KiB
309 lines
18 KiB
\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 and also fail to achieve in reality |
|
(see section \ref{results:softwarenat64} for details). |
|
|
|
% ---------------------------------------------------------------------- |
|
\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. |
|
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 thesis 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} |
|
% ---------------------------------------------------------------------- |
|
\section{\label{background:transition}IPv6 Translation Mechanisms} |
|
While in this thesis the focus was in NAT64 as a translation mechanism, |
|
there are a variety of different approaches, some of which we would |
|
like to portray here. |
|
% ---------------------------------------------------------------------- |
|
\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. |
|
|
|
NAT64 translations as described in this thesis modify multiple layers |
|
in the translation process: |
|
|
|
\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} |
|
|
|
% ---------------------------------------------------------------------- |
|
\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] |
|
\includegraphics[scale=0.5]{statefulnat64} |
|
\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}. |
|
% ---------------------------------------------------------------------- |
|
\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 |
|
% ---------------------------------------------------------------------- |
|
\section{\label{background:checksums}Protocol Checksums} |
|
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 | |
|
+--------+--------+--------+--------+ |
|
|
|
\end{verbatim} |
|
\centering |
|
\caption{IPv4 Pseudo Header} |
|
\label{fig:ipv4pseudoheader} |
|
\end{figure} |
|
% ---------------------------------------------------------------------- |
|
\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 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 |
|
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{Higher level protocols |
|
like TCP, UDP, ICMP6/ICMP.}
|
|
|