++doc

doc/Background.tex

@@ -103,6 +103,11 @@ the two protocols for this thesis are:
   \label{fig:ipv4header}
 \end{figure}
 % ----------------------------------------------------------------------
+\section{\label{background:arpndp}ARP and NDP - FIXME}
+Required for finding host.
+ARP who has
+NDP similar -- add traces here
+% ----------------------------------------------------------------------
 \section{\label{background:transition}IPv6 Translation Mechanisms}
 While in this thesis the focus was in NAT64 as a translation mechanism,
 there are a variety of different approaches, some of which we would
@@ -304,6 +309,5 @@ IPv6 only networks are in our opinion the best choice for long term
 deployments. The reasons for this are as follows: First of all hosts
 eventually will need to support IPv6 and secondly
 IPv6 hosts can address the whole 32 bit IPv4 Internet mapped in
-a single /96 IPv6 network, whithout the need for address extension or
-higher protocol dependent translations\footnote{Higher level protocols
-  like TCP, UDP, ICMP6/ICMP.}
+a single /96 IPv6 network. IPv6 only networks also allow the operators
+to focus on one IP stack.

doc/Conclusion.tex

@@ -9,20 +9,89 @@ Sum up what you have done and recapitulate your key findings.
 
 \section{\label{conclusion:softwarenat64}Software based NAT64}
 
+\section{\label{conclusion:general}General}
+Many misleading
+
+
 \section{\label{conclusion:bmv2}BMV2}
 maybe remove
 
 \section{\label{conclusion:P4}P4}
+
+checksumming a frequent problem and helper
+
 Many possibilities
 Protocol independent
 Easy architecture
 
 Limitations in
 
+if in action limitations
 
-\section{\label{conclusion:netpfga}NetFGPA}
+Limits if in actions
+
+python2 only - unicode errors
+
+IPv6: NDP: not easy to parse, as unknown number of following fields
+
+No support for multiple LPM keys in a table, can be solved with
+ternary matching.
+
+switch cannot be used in actions
+
+\begin{verbatim}
+ipaddress.ip_network("2001:db8:61::/64")
+IPv6Network(u'3230:3031:3a64:6238:3a36:313a:3a2f:3634/128')
+
+Fix:
+from __future__ import unicode_literals
+
+\end{verbatim}
+
+The tooling around P4 is still fragile, encountered many bugs
+in the development.\cite{schottelius:github1675}
+
+or missing features (\cite{schottelius:github745},
+\cite{theojepsen:_get})
+
+Hitting expression bug
+
+\section{\label{conclusion:netpfga}NetFGPA - all HERE}
 personal note here
 
+
+long compile process
+error prone compile process
+many dependencies
+lpm not supported!
+Netpfga live,
+Vivado
+SDNET
+xx k lines of supporting code
+
+no payload accessq
+
+Many workarounds
+
+Table size 63, table size 64,
+
+Table entries require arguments of all possible actions, not only used
+one.
+
+Compile time hours
+
+Silent errors
+
+Unclear errors: broken board
+
+Due to the very fragile nature of the build framework from the
+NetFPGA-Live repository,
+
+Renaming VARIABLES in the definition of
+
+Reproducibility:
+
+
 \section{\label{conclusion:realworld}Real world applications}
 Can be deployed using the netpfga. Or Barefoot or Arista.
 

doc/Design.tex

@@ -2,29 +2,148 @@
 Description of the theory/software/hardware that you designed.
 %** Design.tex: How was the problem attacked, what was the design
 %               the architecture
+In this chapter we describe the architecture of our solution.
 
-Maybe figures here? controller,
-
+% ----------------------------------------------------------------------
 \section{\label{Design:General}General}
-There are a variety of possible network layouts for realising
-NAT64. In this thesis two different layouts where taken into account:
-routed translation and transparent in network translation.
-
+The high level design can be seen in figure \ref{fig:switchdesign}: a
+P4 capable switch is running our code to provide NAT64
+functionality. The P4 switch cannot manage its tables on it own and
+needs support for this from a controller. If only static table entries
+are required, the controller can also be omitted. However stateful
+NAT64 requires the use of a control to create session entries in the
+switch tables.
+\begin{figure}[h]
+  \includegraphics[scale=0.5]{switchdesign}
+  \centering
+  \caption{General Design}
+  \label{fig:switchdesign}
+\end{figure}
+The P4 switch can use any protocol to communicate with controller, as
+the connection to the controller is implemented as a separate ethernet
+port. The design allows our solution to be used as a standard NAT64
+translation method or as an in network NAT64 translation (compare
+figures \ref{fig:v6v4innetwork} and \ref{fig:v6v4standard}). The
+controller is implemented in python, the NAT64 solution is implemented
+in P4.
+% ----------------------------------------------------------------------
 \section{\label{Design:BMV2}BMV2}
-
-
-\section{\label{Design:NetPFGA}NetFPGA}
-
-Netpfga live,
-Vivado
-SDNET
-xx k lines of supporting code
-
-\section{todo}
-
+Development of the thesis took place on a software emulated switch
+that is implemented using Open vSwitch \cite{openvswitch}
+and the behavioral model
+\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:
+\begin{itemize}
+\item Recalculating the checksum by inspecting headers and payload
+\item Calculating the difference between the translated headers
+\end{itemize}
+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}
+that include payload checksums.
+A typical code to create the checksum can be found in figure
+\ref{fig:checksum}.
+\begin{figure}[h]
 \begin{verbatim}
-***** Verschiedene design Möglichkeiten
-***** Proxy und co.
-***** Generell vs. spefizisch
+/* checksumming for icmp6_na_ns_option */
+update_checksum_with_payload(meta.chk_icmp6_na_ns == 1,
+	{
+        hdr.ipv6.src_addr,         /* 128 */
+        hdr.ipv6.dst_addr,         /* 128 */
+        meta.cast_length,          /* 32 */
+        24w0,                      /* 24 0's */
+        PROTO_ICMP6,               /* 8 */
+        hdr.icmp6.type,            /* 8 */
+        hdr.icmp6.code,            /* 8 */
+
+        hdr.icmp6_na_ns.router,
+        hdr.icmp6_na_ns.solicitated,
+        hdr.icmp6_na_ns.override,
+        hdr.icmp6_na_ns.reserved,
+        hdr.icmp6_na_ns.target_addr,
+
+        hdr.icmp6_option_link_layer_addr.type,
+        hdr.icmp6_option_link_layer_addr.ll_length,
+        hdr.icmp6_option_link_layer_addr.mac_addr
+    },
+    hdr.icmp6.checksum,
+    HashAlgorithm.csum16
+);
+\end{verbatim}
+  \centering
+  \caption{IPv4 Pseudo Header}
+  \label{fig:checksum}
+\end{figure}
+
+% ----------------------------------------------------------------------
+\section{\label{Design:NetPFGA}NetFPGA}
+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
+creating the checksum based on the payload.
+To support checksum modifications in NAT64 on the NetFPGA, the
+checksum was calculated on the netpfga using differences between
+the IPv6 and IPv4 headers. Figure \ref{fig:checksumbydiff} shows an
+excerpt of the code used for calculating checksums in the netpfga.
+\begin{figure}[h]
+\begin{verbatim}
+action v4sum() {
+    bit<16> tmp = 0;
+
+    tmp = tmp + (bit<16>) hdr.ipv4.src_addr[15:0];              // 16 bit
+    tmp = tmp + (bit<16>) hdr.ipv4.src_addr[31:16];             // 16 bit
+    tmp = tmp + (bit<16>) hdr.ipv4.dst_addr[15:0];              // 16 bit
+    tmp = tmp + (bit<16>) hdr.ipv4.dst_addr[31:16];             // 16 bit
+
+    tmp = tmp + (bit<16>) hdr.ipv4.totalLen -20;                // 16 bit
+    tmp = tmp + (bit<16>) hdr.ipv4.protocol;                    // 8 bit
+
+    meta.v4sum = ~tmp;
+}
+
+/* analogue code for v6sum skipped */
+
+action delta_tcp_from_v6_to_v4()
+{
+    v6sum();
+    v4sum();
+
+    bit<17> tmp = (bit<17>) hdr.tcp.checksum + (bit<17>) meta.v4sum;
+    if (tmp[16:16] == 1) {
+        tmp = tmp + 1;
+        tmp[16:16] = 0;
+    }
+    tmp = tmp + (bit<17>) (0xffff - meta.v6sum);
+    if (tmp[16:16] == 1) {
+        tmp = tmp + 1;
+        tmp[16:16] = 0;
+    }
+
+    hdr.tcp.checksum = (bit<16>) tmp;
+}
 
 \end{verbatim}
+  \centering
+  \caption{Calculating checksum based on header differences}
+  \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
+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}.}.
+\end{quote}
+As the calculation mainly depends on on (1-complement) sums, the
+checksums after translating the protocol can be corrected by
+subtracting the differences of the relevant fields. It is notable that
+not the full headers are used, but the pseudo headers (compare figures
+\ref{fig:ipv6pseudoheader} and \ref{fig:ipv4pseudoheader}).
+To compensate the carry bit, our code uses 17 bit integers for
+correcting the carry.

doc/Introduction.tex

@@ -80,7 +80,6 @@ approach and \ref{fig:v6v4innetwork} shows our solution.
   \caption{In Network NAT64 translation}
   \label{fig:v6v4innetwork}
 \end{figure}
-
 \begin{figure}[h]
   \includegraphics[scale=0.7]{v6-v4-standard}
   \centering
@@ -89,9 +88,9 @@ approach and \ref{fig:v6v4innetwork} shows our solution.
 \end{figure}
 Currently network operators have to focus on two network stacks when
 designing networks: IPv6 and IPv4. While in a small scale setup this
-might not introduce significant complexity, however figure
+might not introduce significant complexity, figure
 \ref{fig:v6v4mixed} shows how the complexity quickly grows
-quickly with the number of nodes.
+with the number of hosts.
 \begin{figure}[h]
   \includegraphics[scale=0.4]{v6-v4-mixed}
   \centering

doc/Makefile

@@ -9,7 +9,7 @@ all: all-graphviz
 	pdflatex $(FILE)
 
 clean:
-	rm -f *.dvi *.log *.aux *.bbl *.blg *.toc *.lof *.lot *.cb *.~
+	rm -f *.dvi *.log *.aux *.bbl *.blg *.toc *.lof *.lot *.cb *.~ *.ilg *.nlo *.nls *.out *.glo
 
 all-graphviz:
 	for dot in graphviz/*.dot; do make $${dot%%.dot}.png; done

doc/Results.tex

@@ -2,53 +2,41 @@
 %** Results.tex: What were the results achieved including an evaluation
 %
 
-The results from your evaluations.
+\section{\label{results:general}General}
+Parser for all protocols (udp,tcp,icmp,icmp6)
+
+BMV2: more feature rich, but software only solution
+NetFPGA: capabale of line speed Nat64, focused port on nat64
 
-\begin{itemize}
-\item Solution in P4/BMV2
-\item Solution in P4/NetFPGA
-\end{itemize}
 
 \section{\label{Results:BMV2}BMV2}
+
+Responds to icmp, icmp6
 ndp
 arp
 
 test framework openvswitch
 
+Fully functional host
+Can compute checksums on its own.
+
+\section{\label{results:tayga}Tayga}
+
+3gbit
+
+\section{\label{results:jool}Jool}
 
 
 \section{\label{Results:NetPFGA}NetFPGA}
 General result: limited NAT64 is working, however
 
-\subsection{\label{Results:NetPFGA:challenge-checksum}No Payload
-  checksumming}
+  No Payload
+  checksumming - requires controller
 
-Hash funktion in Arbeit
+  Hash funktion in Arbeit
 
-\subsection{\label{Results:NetPFGA:challenges}Other Challenges}
-Many workarounds
-
-Table size 63, table size 64,
-
-Table entries require arguments of all possible actions, not only used
-one.
-
-Compile time hours
-
-Silent errors
-
-Unclear errors: broken board
-
-Due to the very fragile nature of the build framework from the
-NetFPGA-Live repository,
-
-Renaming VARIABLES in the definition of
-
-Reproducibility:
-
-\section{\label{Results:P4}P4}
-
-Limits if in actions
+  No NDP, no ARP - focused on key factors of NAT64 translation,
+  other features can be supported by controller
 
 \section{\label{results:softwarenat64}NAT64 in Software}
 Tayga, Jool

doc/graphviz/netpfgadesign.dot

@@ -0,0 +1,36 @@
+graph G {
+    node [ shape="box"];
+    rankdir="LR";
+
+    x520_1 [ label="X520: IPv4" ];
+    x520_2 [ label="X520: IPv6" ];
+    x520_nsg [ label="X520: Controller" ];
+
+    netpfga1 [ label="NetFPGA Port 1" ];
+    netpfga2 [ label="NetFPGA Port 2" ];
+    netpfga3 [ label="NetFPGA Port 3" ];
+
+
+
+    subgraph cluster_esprimo {
+        label="Load generator";
+
+        x520_1;
+        x520_2;
+    }
+
+    subgraph cluster_nsg {
+        label="NetFPGA Host";
+
+        netpfga1;
+        netpfga2;
+
+        netpfga3--x520_nsg;
+    }
+
+    x520_1--netpfga1;
+    x520_2--netpfga2;
+
+
+
+}

doc/graphviz/switchdesign.dot

@@ -0,0 +1,19 @@
+graph G {
+    node [ shape="box"];
+
+    v4host [ label="IPv4 hosts" ]
+    v6host [ label="IPv6 hosts" ]
+
+    nat64gw [ label="P4 switch: NAT64" ];
+    controller [ label="P4 Controller" ];
+
+    nat64gw--v4host;
+
+    v6host--nat64gw;
+
+    nat64gw--controller [ label="custom protocol" ];
+
+    { rank="same" nat64gw, controller };
+
+
+}

doc/plan.org

@@ -9286,15 +9286,15 @@ nico@nsg-System:~/projects/P4-NetFPGA/contrib-projects/sume-sdnet-switch/project
 *** TODO Add comparison with other solutions (Results?)
 *** TODO Show / create graph of a bigger network
 *** Rough time table / effort
-|               |          | Status  |
-| Abstract      | 1 day    | okayish |
-| Introduction  | 1 day    |         |
-| Background    | 1 day    |         |
-| Design        | 1-2 days |         |
-| Results       | 2-3 days |         |
-| Conclusion    | 1 day    |         |
-| Proof reading | 2-3 days |         |
-| SUM(max)      | 12d      |         |
+|               |          | Status     |
+| Abstract      | 1 day    | okayish    |
+| Introduction  | 1 day    | okayish    |
+| Background    | 1 day    | okayish    |
+| Design        | 1-2 days | 2019-08-12 |
+| Results       | 2-3 days | 2019-08-13 |
+| Conclusion    | 1 day    |            |
+| Proof reading | 2-3 days |            |
+| SUM(max)      | 12d      |            |
 * DONE Initial administration
 ** DONE Clarify PDF / form with Denise Spicher: free form description
 ** DONE Create task description to be handed in mystudies

doc/refs/refs.bib

@@ -83,3 +83,29 @@
   author =    {NGINX},
   title =     {NGINX | High Performance Load Balancer, Web Server, \& Reverse Proxy},
   howpublished = {\url{https://www.nginx.com/}}}
+
+@Misc{openvswitch,
+  author =    {Linux Foundation},
+  title =     {Open vSwitch},
+  howpublished = {\url{https://www.openvswitch.org/}}}
+
+@Misc{wikipedia:_ipv4,
+  author =    {Wikipedia},
+  title =     {IPv4 header checksum},
+  howpublished = {\url{https://en.wikipedia.org/wiki/IPv4_header_checksum}},
+  note =      {Requested on 2019-08-12}}
+
+@Misc{schottelius:github1675,
+  author =    {Nico Schottelius},
+  title =     {Casting bit<16> to bit<32> in checksum causes incorrect json to be generated},
+  howpublished = {\url{https://github.com/p4lang/p4c/issues/1765}}}
+
+@Misc{schottelius:github745,
+  author =    {Nico Schottelius},
+  title =     {Add access to table keys},
+  howpublished = {\url{https://github.com/p4lang/p4-spec/issues/745}}}
+
+@Misc{theojepsen:_get,
+  author =    {theojepsen},
+  title =     {Get size of header},
+  howpublished = {\url{https://github.com/p4lang/p4-spec/issues/660}}}

p4src/actions_nat64_generic.p4

@@ -1,4 +1,4 @@
-#ifndef NICO_NAT64_GENERIC
+xf#ifndef NICO_NAT64_GENERIC
 #define NICO_NAT64_GENERIC
 
 #include "actions_egress.p4"