Browse Source

cleanup + dns64 figure

master
Nico Schottelius 3 years ago
parent
commit
fdb32a8c94
  1. 185
      doc/Background.tex
  2. 9
      doc/Conclusion.tex
  3. 30
      doc/Design.tex
  4. 36
      doc/Introduction.tex
  5. 41
      doc/Results.tex
  6. BIN
      doc/Thesis.pdf
  7. 41
      doc/graphviz/dns64.dot
  8. BIN
      doc/graphviz/dns64.png
  9. 9
      doc/plan.org
  10. 7
      doc/refs/refs.bib
  11. 2
      doc/samples.tex

185
doc/Background.tex

@ -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

9
doc/Conclusion.tex

@ -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

30
doc/Design.tex

@ -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

36
doc/Introduction.tex

@ -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.

41
doc/Results.tex

@ -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

Binary file not shown.

41
doc/graphviz/dns64.dot

@ -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" ];
}

BIN
doc/graphviz/dns64.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 45 KiB

9
doc/plan.org

@ -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

7
doc/refs/refs.bib

@ -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},

2
doc/samples.tex

@ -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…
Cancel
Save