cleanup + dns64 figure

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

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

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

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.

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
 

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

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

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

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