\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.}