cleanup + dns64 figure
This commit is contained in:
Nico Schottelius
parent
df2c52a37f
commit
fdb32a8c94
|
|
@ -1,6 +1,6 @@
|
|||
\chapter{\label{background}Background}
|
||||
In this chapter we describe the key technologies involved.
|
||||
\section{\label{background:P4}P4}
|
||||
\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
|
||||
|
|
@ -36,19 +36,24 @@ cannot guarantee and also fail to achieve in reality
|
|||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{background:ip}IPv6, IPv4 and Ethernet}
|
||||
The first IPv6 RFC was published in 1998\cite{rfc2460}. Both IPv4 and
|
||||
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
|
||||
the higher level protocol identifier.\footnote{
|
||||
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 Different address lengths
|
||||
\begin{itemize}
|
||||
\item IPv4: 32 bit
|
||||
\item IPv6: 128 bit
|
||||
\end{itemize}
|
||||
\item Lack of a checksum in IPv6
|
||||
\item Format of Pseudo headers (see section \ref{background:checksums})
|
||||
\end{itemize}
|
||||
\begin{figure}[h]
|
||||
|
|
@ -77,7 +82,7 @@ the two protocols for this thesis are:
|
|||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
\end{verbatim}
|
||||
\centering
|
||||
\caption{IPv6 Header, \cite{rfc2460}}
|
||||
\caption{IPv6 Header~\cite{rfc2460}}
|
||||
\label{fig:ipv6header}
|
||||
\end{figure}
|
||||
|
||||
|
|
@ -101,15 +106,15 @@ the two protocols for this thesis are:
|
|||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
\end{verbatim}
|
||||
\caption{IPv4 Header, \cite{rfc791}}
|
||||
\caption{IPv4 Header~\cite{rfc791}}
|
||||
\label{fig:ipv4header}
|
||||
\end{figure}
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{background:arpndp}ARP and NDP, ICMP and ICMP6}
|
||||
While IPv6 and IPv4 are primarily used as a ``shell'' to support
|
||||
addressing for protocols that have no or limited addressing support
|
||||
(like TCP or UDP), protocols like ARP \cite{rfc826} and NDP
|
||||
\cite{rfc4861} provide support for resolving IPv6 and IPv4
|
||||
(like TCP or UDP), protocols like ARP~\cite{rfc826} and
|
||||
NDP~\cite{rfc4861} provide support for resolving IPv6 and IPv4
|
||||
addresses to hardware (MAC) addresses. While both ARP and NDP are only
|
||||
used prior to establishing a connection on and their results are
|
||||
cached, their availability is crucial for operating a switch.
|
||||
|
|
@ -134,14 +139,14 @@ way to communicate to the target IPv4 address (``The chicken and the
|
|||
egg problem'').
|
||||
NDP on the other hand already works within IPv6, as every IPv6 host is
|
||||
required to have a self-assigned link local IPv6 address from the
|
||||
range \texttt{fe80::/10} (compare RFC4291\cite{rfc4291}). NDP also
|
||||
range \texttt{fe80::/10} (compare RFC4291~\cite{rfc4291}). NDP also
|
||||
does not require broadcast communication, because hosts automatically
|
||||
join multicast groups that embed parts of their
|
||||
IPv6 addresses (\cite{rfc2710}, \cite{wikipedia:_solic}). This way the
|
||||
IPv6 addresses~\cite{rfc2710},~\cite{wikipedia:_solic}. This way the
|
||||
collision domain is significantly reduced in IPv6, compared to IPv4.
|
||||
|
||||
As seen later in this document (compare
|
||||
\ref{results:netpfga:checksum}), the requirement to generate checksums
|
||||
section \ref{results:netpfga:features}), the requirement to generate checksums
|
||||
over payload poses difficult problems for some hardware targets. Even
|
||||
more difficult is the use of options within ICMP6. Figure shows a
|
||||
typical layout of a neighbor advertisement messages.
|
||||
|
|
@ -154,10 +159,10 @@ typical layout of a neighbor advertisement messages.
|
|||
The problem arises from the layout of the options, as seen in the
|
||||
following quote:
|
||||
\begin{quote}
|
||||
Neighbor Discovery messages include zero or more options, some of
|
||||
``Neighbor Discovery messages include zero or more options, some of
|
||||
which may appear multiple times in the same message. Options should
|
||||
be padded when necessary to ensure that they end on their natural
|
||||
64-bit boundaries.\footnote{From RFC4861.}
|
||||
64-bit boundaries''.\footnote{Quote from \cite{rfc4861}.}
|
||||
\end{quote}
|
||||
|
||||
ICMP6 and ICMP are primarily used to signal errors in
|
||||
|
|
@ -165,8 +170,9 @@ communication. Specifically signalling that a packet is too big to
|
|||
pass a certain link and needs fragmentation is a common functionality
|
||||
of both protocols. For a host (or switch) to be able to emit ICMP6 and
|
||||
ICMP messages, the host requires a valid IPv6 / IPv4 address.
|
||||
Without ICMP6 / ICMP support path mtu discovery (\cite{rfc1191},
|
||||
\cite{rfc8201}) does not work and the sender needs to determine
|
||||
Without ICMP6 / ICMP support path MTU
|
||||
discovery~\cite{rfc1191},~\cite{rfc8201}
|
||||
does not work and the sender needs to determine
|
||||
different ways of finding out the maximum MTU on the path.
|
||||
% ok -- need to separate backgroun and results
|
||||
% ----------------------------------------------------------------------
|
||||
|
|
@ -191,9 +197,9 @@ in the translation process:
|
|||
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{background:transition:statefulnat64}Stateful NAT64}
|
||||
Stateful NAT64 as defined in RFC6146\cite{rfc6146} defines how to
|
||||
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
|
||||
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.
|
||||
|
|
@ -214,20 +220,21 @@ 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}.
|
||||
Stateful NAT64 usually uses information found in protocols at layer 4
|
||||
like TCP~\cite{rfc793} or UDP~\cite{rfc768}. However it can also
|
||||
support ICMP~\cite{rfc792} and 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
|
||||
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
|
||||
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
|
||||
|
|
@ -235,22 +242,41 @@ information to choose from for translation, complex parsers or even
|
|||
cryptographic methods are required for it. That reduces the
|
||||
opportunities of protocol dependent translation
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{background:transition:dns64}DNS64 - FIXME}
|
||||
|
||||
DNS64 \cite{rfc6174}
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{background:transition:prefixnat}Prefix based NAT -
|
||||
FIXME}
|
||||
Explain how it works in general
|
||||
**** RFC6052
|
||||
- Defining well known prefix 64:ff9b::/96
|
||||
- Defining embedding depending on prefix: /32../104 in 8 bit
|
||||
steps
|
||||
- Longer than /96: suffix support
|
||||
|
||||
|
||||
- v4 to v6 / vice versa
|
||||
|
||||
\subsection{\label{background:transition:prefixnat}Mapping IPv4
|
||||
Addresses in IPv6}
|
||||
As described in section \ref{background:ip}, one of the major
|
||||
differences between IPv6 and IPv4 is the address length. As the whole
|
||||
IPv4 Internet can be represented in only 32 bits, it is a common
|
||||
practice to assign an IPv6 prefix for IPv6 hosts that represents a
|
||||
mapping to the IPv4 Internet. In RFC6052~\cite{rfc6502} the well
|
||||
known prefix \textit{64:ff9b::/96} is defined. One possibility to map
|
||||
an IPv4 address into the prefix is by adding its integer value to the
|
||||
prefix, treating it like an offset. In figure \ref{fig:ipv4embed}
|
||||
we show an example python code of how this can be done.
|
||||
\begin{figure}[h]
|
||||
\begin{verbatim}
|
||||
>>> import ipaddress
|
||||
>>> prefix=ipaddress.IPv6Network("64:ff9b::/96")
|
||||
>>> ipv4address=ipaddress.IPv4Address("192.0.2.0")
|
||||
>>> int(ipv4address)
|
||||
3221225984
|
||||
>>> hex(3221225984)
|
||||
'0xc0000200'
|
||||
>>> prefix[int(ipv4address)]
|
||||
IPv6Address('64:ff9b::c000:200')
|
||||
\end{verbatim}
|
||||
\centering
|
||||
\caption{Representing an IPv4 address in an IPv6 prefix}
|
||||
\label{fig:ipv4embed}
|
||||
\end{figure}
|
||||
Network administrators can choose to use either the well known prefix
|
||||
or to use a network block of their own to map the
|
||||
Internet.\footnote{For instance
|
||||
2a0a:e5c0:0:1::/96~\ref{ungleich:networkinfra}.}
|
||||
While a /96 prefix seems a natural selection (it provides exactly 32 bit),
|
||||
other prefix lengths are defined in RFC6052 (see figure
|
||||
\ref{fig:prefixlen}) that allow flexible embedding of the IPv4 address.
|
||||
\begin{figure}[h]
|
||||
\begin{verbatim}
|
||||
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
|PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
|
||||
|
|
@ -267,51 +293,48 @@ Explain how it works in general
|
|||
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
|96| prefix | v4(32) |
|
||||
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
|
||||
|
||||
***** DONE Case IPv6 initiator
|
||||
CLOSED: [2019-08-13 Tue 10:59]
|
||||
- Mapping whole IPv4 Internet in /96 prefix
|
||||
- Session information for mapping reply
|
||||
- Timeout handling in controller
|
||||
****** TODO IPv6 udp -> IPv4
|
||||
- Got 4-5 tuple ([proto], src ip, src port, dst ip, dst port)
|
||||
- Does not / never signal end
|
||||
- Needs timeout for cleaning up
|
||||
****** TODO IPv6 tcp -> IPv4
|
||||
- Similar to udp
|
||||
- react on FIN/RST (?) -- could be an addition
|
||||
****** TODO IPv6 icmp6 -> IPv4
|
||||
- usual protocol specific changes
|
||||
- Session??
|
||||
- src ip, dst ip, code ?
|
||||
***** TODO Case IPv4 initiator
|
||||
- Needs upper level protol
|
||||
|
||||
|
||||
****** Controller Logic
|
||||
- controller selects "outgoing" IPv4 address range => base for sessions
|
||||
- IPv4 addresses can be "random" (in our test case), but need
|
||||
to be unique
|
||||
- switch does not need to know about the "range", only about
|
||||
sessions
|
||||
- on session create, controller selects "random" ip (ring?)
|
||||
- on session create, controller selects "random port" (next in range?)
|
||||
- on session create controller adds choice into 2 tables:
|
||||
incoming, outgoing
|
||||
|
||||
|
||||
>>> ipaddress.IPv6Network("2001:db8:100::/96")[int(ipaddress.IPv4Address("10.0.0.1"))]
|
||||
IPv6Address('2001:db8:100::a00:1')
|
||||
\end{verbatim}
|
||||
from RFC6052
|
||||
\centering
|
||||
\caption{IPv4 embedding depending on the prefix length}
|
||||
\label{fig:prefixlen}
|
||||
\end{figure}
|
||||
RFC6146, which describes stateful NAT64, states that
|
||||
``IPv4 addresses of IPv4 hosts are algorithmically
|
||||
translated to and from IPv6 addresses by using the algorithm defined
|
||||
in [RFC6052]''~\cite{rfc6146} While this sentencen does not use the
|
||||
typical RFC keywords like SHALL, REQUIRED, etc.~\cite{rfc2119}, we
|
||||
interpret this sentence in the meaning of ``a stateful NAT64
|
||||
translator SHALL implement IPv4 address embedding as described in the
|
||||
algorithm of RFC6052''.
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{background:transition:dns64}DNS64}
|
||||
Tightly related to NAT64 is a technology known as
|
||||
DNS64~\cite{rfc6174}. DNS64 tries to solve the problem of addressing
|
||||
IPv4 only hosts from IPv6 only hosts
|
||||
by adding a ``fake'' IPv6 (AAAA) DNS resource record, as shown in
|
||||
figure \ref{fig:dns64}.
|
||||
\begin{figure}[h]
|
||||
\includegraphics[scale=0.4]{dns64}
|
||||
\centering
|
||||
\caption{Illustration of DNS64}
|
||||
\label{fig:dns64}
|
||||
\end{figure}
|
||||
The DNS64 DNS server will query the authorative DNS server for an AAAA
|
||||
record. However as the host \textit{ipv4onlyhost.example.com} is only
|
||||
reachable by IPv4, it also only has an A entry. After receiving the
|
||||
answer that there is no AAAA record, the DNS64 server will ask for an
|
||||
A record and gets an answer that the name
|
||||
\textit{ipv4onlyhost.example.com} resolves to the IPv4 address
|
||||
\textit{192.0.2.0}. The DNS64 server then embeds the IPv4 address in
|
||||
the configured IPv6 prefix (\textit{64:ff9b::/96} in this case) and
|
||||
returns a fake AAAA record to the IPv6 only host.
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\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
|
||||
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]
|
||||
|
|
@ -395,7 +418,7 @@ 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}.
|
||||
systems is not an easy task~\cite{ungleich:_ipv4}.
|
||||
\begin{figure}[h]
|
||||
\includegraphics[scale=0.5]{v6only}
|
||||
\centering
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ between 2 different P4 targets. It should be portable with minor
|
|||
target specific changes to faster hardware to support NAT64 at much
|
||||
higher line speeds, without any logic changes.
|
||||
|
||||
Our algorithm uses the IPv4-Compatible IPv6 Address\cite{rfc4291} to
|
||||
embed IPv4 addresses. However RFC6052\cite{rfc6052} defines different
|
||||
Our algorithm uses the IPv4-Compatible IPv6 Address~\cite{rfc4291} to
|
||||
embed IPv4 addresses. However RFC6052~\cite{rfc6052} defines different
|
||||
embeddings depending on the prefix size. A future version should
|
||||
support these schemes to be compatible to other implementations.
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ the learnings of the different layers were very much appreciated / liked
|
|||
The availability of protocol independent programmable network
|
||||
equipment opens up many possibilities for in network
|
||||
programming. While this thesis focused on NAT64, the accompying
|
||||
technologie DNS64\cite{rfc6147} could also be implemented in P4, thus
|
||||
technologie DNS64~\cite{rfc6147} could also be implemented in P4, thus
|
||||
completing the translation mechanism.
|
||||
|
||||
Proxies / higher level protocols could be next level
|
||||
|
|
@ -63,3 +63,6 @@ table
|
|||
|
||||
Support a meta language to define used types and/or export to popular languages.
|
||||
Long term supporting python3 would be helpful. P4OS.
|
||||
|
||||
|
||||
- react on FIN/RST (?) -- could be an addition
|
||||
|
|
|
|||
|
|
@ -63,9 +63,9 @@ TCP6:[2001:db8:1::a00:1]:2343"; sleep 2; done
|
|||
% ----------------------------------------------------------------------
|
||||
\section{\label{Design:BMV2}BMV2}
|
||||
Development of the thesis took place on a software emulated switch
|
||||
that is implemented using Open vSwitch \cite{openvswitch}
|
||||
that is implemented using Open vSwitch ~\cite{openvswitch}
|
||||
and the behavioral model
|
||||
\cite{_implem_your_switc_target_with_bmv2}. The development followed
|
||||
~\cite{_implem_your_switc_target_with_bmv2}. The development followed
|
||||
closely the general design shown in section
|
||||
\ref{Design:General}. Within the software emulation checksums can be
|
||||
computed with two different methods:
|
||||
|
|
@ -76,7 +76,7 @@ computed with two different methods:
|
|||
The BMV2 model is rather sophisticated and provides many standard
|
||||
features including checksumming over payload. This allows the BMV2
|
||||
model to operate as a full featured host, including advanced features
|
||||
like responding to ICMP6 Neighbor discovery requests \cite{rfc4861}
|
||||
like responding to ICMP6 Neighbor discovery requests ~\cite{rfc4861}
|
||||
that include payload checksums.
|
||||
A typical code to create the checksum can be found in figure
|
||||
\ref{fig:checksum}.
|
||||
|
|
@ -114,7 +114,7 @@ update_checksum_with_payload(meta.chk_icmp6_na_ns == 1,
|
|||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{Design:NetPFGA}NetFPGA}
|
||||
While the P4-NetFPGA project \cite{netfpga:_p4_netpf_public_github}
|
||||
While the P4-NetFPGA project ~\cite{netfpga:_p4_netpf_public_github}
|
||||
allows compiling P4 to the NetPFGA, the design slightly varies.
|
||||
In particular, the NetFPGA P4 compiler does not support reading
|
||||
the payload. For this reason it also does not support
|
||||
|
|
@ -166,13 +166,13 @@ action delta_tcp_from_v6_to_v4()
|
|||
\label{fig:checksumbydiff}
|
||||
\end{figure}
|
||||
The checksums for IPv4, TCP, UDP and ICMP6 are all based on the
|
||||
``Internet Checksum'' (\cite{rfc791}, \cite{rfc1071}). Its calculation
|
||||
``Internet Checksum'' (~\cite{rfc791}, ~\cite{rfc1071}). Its calculation
|
||||
can be summarised as follows:
|
||||
\begin{quote}
|
||||
The checksum field is the 16-bit one's complement of the one's
|
||||
complement sum of all 16-bit words in the header. For purposes of
|
||||
computing the checksum, the value of the checksum field
|
||||
is zero.\footnote{Quote from Wikipedia\cite{wikipedia:_ipv4}.}.
|
||||
is zero.\footnote{Quote from Wikipedia~\cite{wikipedia:_ipv4}.}.
|
||||
\end{quote}
|
||||
As the calculation mainly depends on on (1-complement) sums, the
|
||||
checksums after translating the protocol can be corrected by
|
||||
|
|
@ -182,6 +182,24 @@ not the full headers are used, but the pseudo headers (compare figures
|
|||
To compensate the carry bit, our code uses 17 bit integers for
|
||||
correcting the carry.
|
||||
% FIXME: add note to python script / checksum diffing
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{design:statefulnat64}Stateful NAT64}
|
||||
|
||||
|
||||
- controller selects "outgoing" IPv4 address range => base for sessions
|
||||
- IPv4 addresses can be "random" (in our test case), but need
|
||||
to be unique
|
||||
- switch does not need to know about the "range", only about
|
||||
sessions
|
||||
- on session create, controller selects "random" ip (ring?)
|
||||
- on session create, controller selects "random port" (next in range?)
|
||||
- on session create controller adds choice into 2 tables:
|
||||
incoming, outgoing
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{design:ipv4embed}IPv4 embedding}
|
||||
Only using /96. Using addition.
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{Design:Benchmarks}Benchmarks}
|
||||
The benchmarks were performed on two hosts, a load generator and a
|
||||
|
|
|
|||
|
|
@ -35,22 +35,21 @@ exhaustion for 2020 (see figure \ref{fig:lacnicexhaust}).
|
|||
\includegraphics[scale=0.7]{lacnicdepletion}
|
||||
\centering
|
||||
\caption{LACNIC Exhaustion projection,
|
||||
\cite{lacnic:_ipv4_deplet_phases}}
|
||||
~\cite{lacnic:_ipv4_deplet_phases}}
|
||||
\label{fig:lacnicexhaust}
|
||||
\end{figure}
|
||||
|
||||
On the other hand IPv6 adoption grows significantly, with at least
|
||||
three countries (India, US, Belgium) surpassing 50\% adoption
|
||||
(\cite{akamai:_ipv6_adopt_visual},
|
||||
\cite{vyncke:_ipv6_deploy_aggreg_status}).
|
||||
|
||||
\cite{cisco:_ipv6}). Traffic from Google users reaches almost 30\% as
|
||||
of 2019-08-08 (\cite{google:_ipv6_googl}, see figure \ref{fig:googlev6}).
|
||||
three countries (India, US, Belgium) surpassing 50\%
|
||||
adoption~\cite{akamai:_ipv6_adopt_visual},
|
||||
\cite{vyncke:_ipv6_deploy_aggreg_status},
|
||||
\cite{cisco:_ipv6}. Traffic from Google users reaches almost 30\% as
|
||||
of 2019-08-08~\cite{google:_ipv6_googl}, see figure \ref{fig:googlev6}.
|
||||
\begin{figure}[h]
|
||||
\includegraphics[scale=0.2]{googlev6}
|
||||
\centering
|
||||
\caption{Google IPv6 Statistics,
|
||||
\cite{google:_ipv6_googl}}
|
||||
~\cite{google:_ipv6_googl}}
|
||||
\label{fig:googlev6}
|
||||
\end{figure}
|
||||
We conclude that IPv6 is a technology strongly gaining importance with
|
||||
|
|
@ -63,15 +62,15 @@ to legacy IPv4 devices still needs to be provided.
|
|||
IPv6 nodes and IPv4 nodes cannot directly connect to each other,
|
||||
because the protocols are incompatible to each other.
|
||||
To allow communication between different protocol nodes,
|
||||
several transition mechanism have been proposed
|
||||
\cite{wikipedia:_ipv6}, \cite{rfc4213}.
|
||||
several transition mechanism have been
|
||||
proposed (\cite{wikipedia:_ipv6}, \cite{rfc4213}).
|
||||
|
||||
However installation and configuration of the transition mechanism
|
||||
usually require in depth knowledge about both protocols and require
|
||||
additional hardware to be added in the network.
|
||||
|
||||
In this thesis we show an in-network transition method based on NAT64
|
||||
\cite{rfc6146}. Compared to traditional NAT64 methods which require an
|
||||
In this thesis we show an in-network transition method based on
|
||||
NAT64~\cite{rfc6146}. Compared to traditional NAT64 methods which require an
|
||||
extra device in the network, our proposed method is transparent to the
|
||||
user. This way neither the operator nor the end user has to configure
|
||||
extra devices. Figures \ref{fig:v6v4standard} shows the standard NAT64
|
||||
|
|
@ -102,10 +101,11 @@ with the number of hosts.
|
|||
The in network solution does not only ease the installation and
|
||||
deployment of IPv6, but it also allows line speed translation, because
|
||||
it is compiled into target dependent low level code that can run in
|
||||
ASICs\cite{networks:_tofin},
|
||||
FPGAs\cite{netfpga:_p4_netpf_public_github}
|
||||
or even in software
|
||||
\cite{_implem_your_switc_target_with_bmv2}.
|
||||
Even on fast CPUs, software solutions like tayga
|
||||
\cite{lutchansky:_tayga_simpl_nat64_linux} can be CPU bound and are
|
||||
ASICs~\cite{networks:_tofin},
|
||||
FPGAs~\cite{netfpga:_p4_netpf_public_github}
|
||||
or even in
|
||||
software~\cite{_implem_your_switc_target_with_bmv2}.
|
||||
Even on fast CPUs, software solutions like
|
||||
tayga~\cite{lutchansky:_tayga_simpl_nat64_linux}
|
||||
can be CPU bound and are
|
||||
not capabale of translating protocols at line speed.
|
||||
|
|
|
|||
|
|
@ -12,16 +12,27 @@ objective of this thesis was to demonstrate the high speed
|
|||
capabilities of NAT64 in hardware, no benchmarks were performed on the
|
||||
P4 software implementation.
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{results:p4}NAT64 Benchmarks - FIXME: explain numbers}
|
||||
\section{\label{results:p4:implementation}P4 based implementation}
|
||||
|
||||
****** TODO IPv6 udp -> IPv4
|
||||
- Got 4-5 tuple ([proto], src ip, src port, dst ip, dst port)
|
||||
- Does not / never signal end
|
||||
- Needs timeout for cleaning up
|
||||
|
||||
Only supporting /96, not other embeddings as described in
|
||||
section \ref{background:transition:prefixnat}.
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{results:benchmark}NAT64 Benchmarks - FIXME: explain numbers}
|
||||
We successfully implemented P4 code to realise
|
||||
NAT64\cite{schottelius:thesisrepo}. It contains parsers
|
||||
NAT64~\cite{schottelius:thesisrepo}. It contains parsers
|
||||
for all related protocols (ipv6, ipv4, udp, tcp, icmp, icmp6, ndp,
|
||||
arp), supports EAMT as defined by RFC7757 \cite{rfc7757} and is
|
||||
arp), supports EAMT as defined by RFC7757 ~\cite{rfc7757} and is
|
||||
feature equivalent to the two compared software solutions
|
||||
tayga\cite{lutchansky:_tayga_simpl_nat64_linux} and
|
||||
jool\cite{mexico:_jool_open_sourc_siit_nat64_linux}.
|
||||
tayga~\cite{lutchansky:_tayga_simpl_nat64_linux} and
|
||||
jool~\cite{mexico:_jool_open_sourc_siit_nat64_linux}.
|
||||
Due to limitations in the P4 environment of the
|
||||
NetFPGA\cite{conclusion:netfpga} environment, the BMV2 implementation
|
||||
NetFPGA~\cite{conclusion:netfpga} environment, the BMV2 implementation
|
||||
is more feature rich. Table \ref{tab:benchmark} summarises the
|
||||
achieved bandwidths of the NAT64 solutions.
|
||||
|
||||
|
|
@ -151,7 +162,7 @@ as a ``proper'' participant in NDP, requires the host to calculate
|
|||
checksums over the payload.
|
||||
|
||||
|
||||
List of features BMV2 \cite{tab:p4bmv2features}
|
||||
List of features BMV2 ~\cite{tab:p4bmv2features}
|
||||
|
||||
\begin{table}[htbp]
|
||||
\begin{center}\begin{minipage}{\textwidth}
|
||||
|
|
@ -210,7 +221,7 @@ fully implemented\footnote{Source code: \texttt{checksum\_bmv2.p4}}\\
|
|||
\end{table}
|
||||
|
||||
Responds to icmp, icmp6
|
||||
ndp \cite{rfc4861}
|
||||
ndp ~\cite{rfc4861}
|
||||
arp
|
||||
|
||||
very easy to use
|
||||
|
|
@ -221,7 +232,7 @@ Can compute checksums on its own.
|
|||
focus on typical use cases of icmp, icmp6, the software implementation
|
||||
supports translating echo request and echo reply messages, but does
|
||||
not support all ICMP/ICMP6 translations that are defined in
|
||||
RFC6145\cite{rfc6145}.
|
||||
RFC6145~\cite{rfc6145}.
|
||||
|
||||
Stateful : no automatic removal
|
||||
|
||||
|
|
@ -299,7 +310,7 @@ fully implemented\footnote{Source code: \texttt{actions\_delta\_checksum.p4}}\\
|
|||
Payload Checksum & Switch can calculate checksum with payload inspection &
|
||||
unsupported\footnote{To support creating payload checksums, either an
|
||||
HDL module needs to be created or to modify the generated
|
||||
the PX program.\cite{schottelius:_exter_p4_netpf}} \\
|
||||
the PX program.~\cite{schottelius:_exter_p4_netpf}} \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{minipage}
|
||||
|
|
@ -326,7 +337,7 @@ on the first NetFPGA card.
|
|||
\begin{figure}[h]
|
||||
\includegraphics[scale=0.2]{hwtesthendrik}
|
||||
\centering
|
||||
\caption{Hardware Test NetPFGA card 2, \cite{hendrik:_p4_progr_fpga_semes_thesis_sa}}
|
||||
\caption{Hardware Test NetPFGA card 2, ~\cite{hendrik:_p4_progr_fpga_semes_thesis_sa}}
|
||||
\label{fig:hwtesthendrik}
|
||||
\end{figure}
|
||||
During the development and benchmarking, the second NetFPGA card stopped to
|
||||
|
|
@ -500,10 +511,10 @@ incorrect.
|
|||
FIXMe: IPv6: NDP: not easy to parse, as unknown number of following fields
|
||||
|
||||
The tooling around P4 is still fragile, encountered many bugs
|
||||
in the development.\cite{schottelius:github1675}
|
||||
in the development.~\cite{schottelius:github1675}
|
||||
|
||||
or missing features (\cite{schottelius:github745},
|
||||
\cite{theojepsen:_get})
|
||||
or missing features (~\cite{schottelius:github745},
|
||||
~\cite{theojepsen:_get})
|
||||
|
||||
Hitting expression bug (FIXME: source)
|
||||
|
||||
|
|
@ -519,7 +530,7 @@ No switch in actions, No conditional execution in actions
|
|||
|
||||
Not directly related to P4, but supporting scripts are usually written in python2, however python2
|
||||
handles unicode strings differently and thus effects like an IPv6
|
||||
address ``changing'' happen. \cite{appendix:p4:python2unicode}.
|
||||
address ``changing'' happen. ~\cite{appendix:p4:python2unicode}.
|
||||
|
||||
P4os - reusable code
|
||||
|
||||
|
|
|
|||
BIN
doc/Thesis.pdf
BIN
doc/Thesis.pdf
Binary file not shown.
|
|
@ -0,0 +1,41 @@
|
|||
digraph G {
|
||||
node [ shape="box"];
|
||||
|
||||
rankdir="TB";
|
||||
|
||||
# ORDER OF CREATION IS IMPORTANT FOR ORDERING!
|
||||
|
||||
v6host1 [ label="IPv6 only host" rank="source" ];
|
||||
dnsserver [ label="DNS64 DNS server" ];
|
||||
authdns [ label="DNS server\nfor example.com" ];
|
||||
|
||||
nat64 [ label="NAT64 translator" ];
|
||||
v4host1 [ label="IPv4 host: 192.0.2.0" ];
|
||||
|
||||
|
||||
subgraph sdns64 {
|
||||
label="DNS request";
|
||||
|
||||
dnsserver;
|
||||
authdns;
|
||||
}
|
||||
|
||||
subgraph snat64 {
|
||||
label="NAT64 translation";
|
||||
nat64;
|
||||
v4host1;
|
||||
}
|
||||
|
||||
|
||||
v6host1->dnsserver [ label="ipv4onlyhost.example.com:\nAAAA?" ] ;
|
||||
dnsserver->v6host1 [ label="AAAA\n64:ff9b::c000:200" ];
|
||||
dnsserver->authdns [ label="ipv4onlyhost.example.com:\nAAAA?" ];
|
||||
dnsserver->authdns [ label="ipv4onlyhost.example.com:\nA?" ];
|
||||
authdns->dnsserver [ label="NO AAAA record"];
|
||||
authdns->dnsserver [ label="A: 192.0.2.0"];
|
||||
|
||||
v6host1->nat64 [ label="Packet for\n64:ff9b::c000:200 tcp port 80" ];
|
||||
nat64->v4host1 [ label="Packet for\n192.0.2.0 tcp port 80" ];
|
||||
|
||||
|
||||
}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
|
|
@ -9368,9 +9368,12 @@ nico@nsg-System:~/projects/P4-NetFPGA/contrib-projects/sume-sdnet-switch/project
|
|||
*** TODO P 13: missing closing parentheses after [13]
|
||||
*** TODO P 14: figures 2.3 and 2.2 -> 2.2 and 2.3
|
||||
*** TODO P 14: why do you compare ARP and NDP to P4?
|
||||
*** TODO P 15: missing reference
|
||||
*** TODO P 15: the quote - perhaps put it in quotation marks. Instead of the footnote perhaps a bib entry?
|
||||
*** TODO P 15: mtu vs. MTU (I would write MTU)
|
||||
*** DONE P 15: missing reference
|
||||
CLOSED: [2019-08-18 Sun 12:59]
|
||||
*** DONE P 15: the quote - perhaps put it in quotation marks. Instead of the footnote perhaps a bib entry?
|
||||
CLOSED: [2019-08-18 Sun 12:58]
|
||||
*** DONE P 15: mtu vs. MTU (I would write MTU)
|
||||
CLOSED: [2019-08-18 Sun 12:58]
|
||||
*** TODO P 16: missing reference
|
||||
*** TODO P 16: tcp -> TCP
|
||||
*** TODO P 17: the checksums for TCP and UDP is -> are
|
||||
|
|
|
|||
|
|
@ -84,6 +84,13 @@
|
|||
title = {Die IPv4, die!},
|
||||
howpublished = {\url{https://ungleich.ch/en-us/cms/blog/2019/01/09/die-ipv4-die/}}}
|
||||
|
||||
|
||||
@Misc{ungleich:networkinfra,
|
||||
author = {ungleich},
|
||||
title = {The ungleich network infrastructure},
|
||||
howpublished = {\url{https://redmine.ungleich.ch/projects/open-infrastructure/wiki/The_ungleich_network_infrastructure}},
|
||||
note = {Requested on 2019-08-18}}
|
||||
|
||||
@Misc{nginx:_nginx_high_perfor_load_balan,
|
||||
author = {NGINX},
|
||||
title = {NGINX | High Performance Load Balancer, Web Server, \& Reverse Proxy},
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@
|
|||
%% \normalsize
|
||||
|
||||
%% \CHECK
|
||||
%% If we reference to another document, we cite the document \cite{Lamport:LaTeX}.
|
||||
%% If we reference to another document, we cite the document ~\cite{Lamport:LaTeX}.
|
||||
|
||||
%% %** landscape
|
||||
%% \NEW
|
||||
|
|
|
|||
Loading…
Reference in New Issue