Browse Source

Cleanups, update bib

master
Nico Schottelius 3 years ago
parent
commit
9eff2bf045
  1. 4
      doc/Background.tex
  2. 17
      doc/Conclusion.tex
  3. 32
      doc/Results.tex
  4. BIN
      doc/Thesis.pdf
  5. 89
      doc/refs/refs.bib

4
doc/Background.tex

@ -264,7 +264,7 @@ 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 whole IPv4 Internet. In RFC6052~\cite{rfc6502} the well
mapping to the whole IPv4 Internet. In RFC6052~\cite{rfc6052} the well
known prefix \textit{64:ff9b::/96} is defined that can be used for
this purpose. One possibility to map
an IPv4 address into the prefix is by adding its integer value to the
@ -326,7 +326,7 @@ 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
DNS64~\cite{rfc6147}. 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}.

17
doc/Conclusion.tex

@ -12,23 +12,24 @@ Our implementation has been shown to be portable
between 2 different P4 targets and we expect it to be portable
to other P4 targets, potentially at much higher speeds.
Our in-network solution allows novel translations
without involving external routers, without involving
external routers.\footnote{Compare
without involving external routers.\footnote{Compare
figures \ref{fig:v6v4standard} and \ref{fig:v6v4mixed}.}
We expect this to support migration to IPv6 only networks.
% P4
P4 has been proven to us as a suitable programming language for
network equipment with great potential. However in the current state
network equipment and we think it has great potential for solving new
and existing problems at line rates.
However, in the current state
the tooling and frameworks are still immature and need significant
work to become usable for solving day-to-day challenges or supporting
large scale projects. Even with the current state drawbacks, P4 is a
very convincing language that has wide range of applications due to
its protocol independence and easy to understand architecture.
The availability of protocol independent programmable network
equipment opens up many possibilities in network
equipment opens up many possibilities for in-network
programming. While this thesis focused on NAT64, the accompanying
technology DNS64~\cite{rfc6147} could also be implemented in P4, thus
technology DNS64 could also be implemented in P4, thus
completing the translation mechanism.
% NetPFGA
@ -41,13 +42,13 @@ render productive deployments difficult.
% ----------------------------------------------------------------------
% Outlook
While the project concluded successfully, there are a variety of
While the project concluded successfully, we see
possible improvements to our work as well to the used toolchains.
% Implementation
The implementation of our algorithm uses the IPv4-Compatible
IPv6 Address~\cite{rfc4291} to embed IPv4 addresses.
However RFC6052~\cite{rfc6052} defines different
IPv6 Address defined in RFC4291 to embed IPv4 addresses.
However RFC6052 defines different
embeddings depending on the prefix size. A future version should
not only support more flexible embeddings, but also consider more in
depth translation like ICMP/ICMP6 specifics.

32
doc/Results.tex

@ -364,17 +364,17 @@ NetPFGA mailing list, the NetFPGA only supports 1500 byte frames at
the moment and additional work is required to implement support for
bigger frames.
Our P4 source code required contains Xilinx
Our P4 source code requires to contains Xilinx
annotations\footnote{F.i. ``@Xilinx\_MaxPacketRegion(1024)''} that define
the maximum packet size in bits. We observed two different errors on
the output packet, if the incoming packets exceed the specified size:
the output packet, if the incoming packets exceed the maximum packet size:
\begin{itemize}
\item The output packet is longer than the original packet.
\item The output packet is corrupted.
\end{itemize}
While most of the P4 language is supported on the netpfga, some key
techniques are missing or not supported.
While most of the P4 language is supported on the NetFPGA, some key
techniques are currently missing or not supported.
\begin{itemize}
\item Analysing / accessing payload is not supported
\item Checksum computation over payload is not supported
@ -382,7 +382,7 @@ techniques are missing or not supported.
\item Depending on the match type, only certain table sizes are allowed
\end{itemize}
Renaming variables in the declaration of the parser or deparser lead
to compilation errors. Function syntax is not supported. For this
to compilation errors. The P4 function syntax is not supported. For this
reason our implementation uses \texttt{\#define} statements instead of functions.
%ok
% ----------------------------------------------------------------------
@ -400,7 +400,7 @@ and summarise the benchmarking results.
% ----------------------------------------------------------------------
\subsection{\label{results:benchmark:design}Benchmark Design}
\begin{figure}[h]
\includegraphics[scale=0.5]{softwarenat64design}
\includegraphics[scale=0.6]{softwarenat64design}
\centering
\caption{Benchmark design for NAT64 in software implementations}
\label{fig:softwarenat64design}
@ -449,30 +449,34 @@ recorded by iperf for UDP based benchmarks, as TCP packets are confirmed and
resent if necessary.
Tayga has the highest variation of results, which might be due to
being fully CPU bound even in the simplest benchmark. Jool has less
being fully CPU bound, even in the non-parallel benchmark. Jool has less
variation and in general the P4/NetFPGA solution behaves almost
identical in different benchmark runs.
The CPU load for TCP based benchmarks with Jool was almost negligible,
however for UDP based benchmarks one core was almost 100\%
utilised. In all benchmarks with tayga, one CPU was fully
utilised. And as the translation for P4/NetFPGA happens within the
utilised. When the translation for P4/NetFPGA happens within the
NetFPGA card, there was no CPU utilisation visible on the NAT64 host.
We see lower bandwidth for translating IPv4 to IPv6 in all solutions.
We suspect that this might be due to slighty increasing packet sizes that
occur during this direction of translation. Not only does this vary
the IPv4 versus IPv6 bandwidth, but it might also cause fragmentation
to slowdown the process.
that slows down.
During the benchmark with 1 and 10 parallel connections, no
During the benchmarks with up to 10 parallel connections, no
significant CPU load was registered on the load generator. However
with 20 parallel connections, each of the two iperf
processes\footnote{One for sending, one for receiving.} partially
spiked to 100\% cpu usage, which with 50 parallel connections the cpu
load of each process hit 100\% often.
processes\footnote{The client process for sending, the server process for receiving.} partially
spiked to 100\% cpu usage. With 50 parallel connections the cpu
load of each process hit 100\% often. For this reason we argue that
the benchmark results of the benchmarks with 20 or more parallel
connections might be affected by the load generator limits. While
there is no visible evidence in our results, this problem might become
more significant with higher speed links.
While tayga's performance seems to reduce with the growing number of
While tayga's performance is reduced with the growing number of
parallel connections, both Jool and our P4/NetFPGA implementations
vary only slighty.

BIN
doc/Thesis.pdf

Binary file not shown.

89
doc/refs/refs.bib

@ -1,73 +1,87 @@
@Misc{ripe_exhaustion,
author = {RIPE},
title = {IPv4 Exhaustion},
howpublished = {\url{https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion}}}
howpublished = {\url{https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion}},
note = {Requested on 2019-08-22}}
@Misc{apnic_exhaustion,
author = {APNIC},
title = {APNIC’s IPv4 pool status},
howpublished = {\url{https://www.apnic.net/community/ipv4-exhaustion/graphical-information/}}}
howpublished = {\url{https://www.apnic.net/community/ipv4-exhaustion/graphical-information/}},
note = {Requested on 2019-08-22}}
@Misc{google:_ipv6_googl,
author = {Google},
title = {IPv6 - Google},
howpublished = {\url{https://www.google.com/intl/en/ipv6/statistics.html}}}
howpublished = {\url{https://www.google.com/intl/en/ipv6/statistics.html}},
note = {Requested on 2019-08-22}}
@Misc{lacnic:_ipv4_deplet_phases,
author = {LACNIC},
title = {IPv4 Depletion Phases},
howpublished = {\url{https://www.lacnic.net/1039/1/lacnic/ipv4-depletion-phases}}}
howpublished = {\url{https://www.lacnic.net/1039/1/lacnic/ipv4-depletion-phases}},
note = {Requested on 2019-08-22}}
@Misc{afrinic:_afrin_ipv4_exhaus,
author = {AFRINIC},
title = {AFRINIC IPv4 Exhaustion},
howpublished = {\url{https://afrinic.net/exhaustion}}}
howpublished = {\url{https://afrinic.net/exhaustion}},
note = {Requested on 2019-08-22}}
@Misc{arin:_ipv4_addres_option,
author = {ARIN},
title = {IPv4 Addressing Options},
howpublished = {\url{https://www.arin.net/resources/guide/ipv4/}}}
howpublished = {\url{https://www.arin.net/resources/guide/ipv4/}},
note = {Requested on 2019-08-22}}
@Misc{vyncke:_ipv6_deploy_aggreg_status,
author = {Eric Vyncke},
title = {IPv6 Deployment Aggregated Status},
howpublished = {\url{https://www.vyncke.org/ipv6status/}}}
howpublished = {\url{https://www.vyncke.org/ipv6status/}},
note = {Requested on 2019-08-22}}
@Misc{cisco:_ipv6,
author = {CISCO},
title = {6lab - The place to monitor IPv6 adoption},
howpublished = {\url{https://6lab.cisco.com/stats/}}}
howpublished = {\url{https://6lab.cisco.com/stats/}},
note = {Requested on 2019-08-22}}
@Misc{akamai:_ipv6_adopt_visual,
author = {Akamai},
title = {IPv6 Adoption Visualization},
howpublished = {\url{https://www.akamai.com/us/en/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp#countries}}}
howpublished = {\url{https://www.akamai.com/us/en/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp#countries}},
note = {Requested on 2019-08-22}}
@Misc{wikipedia:_ipv6,
author = {Wikipedia},
title = {IPv6 transition mechanism},
howpublished = {\url{https://en.wikipedia.org/wiki/IPv6_transition_mechanism}},
note = {As requested on 2019-08-08}}
note = {Requested on 2019-08-08}}
@Misc{_implem_your_switc_target_with_bmv2,
author = {BMV2},
title = {IMPLEMENTING YOUR SWITCH TARGET WITH BMv2},
howpublished = {\url{http://www.bmv2.org/}}}
howpublished = {\url{http://www.bmv2.org/}},
note = {Requested on 2019-08-22}}
@Misc{netfpga:_p4_netpf_public_github,
author = {NetFPGA},
title = {P4-NetPFGA-Public repository at Github},
howpublished = {\url{https://github.com/NetFPGA/P4-NetFPGA-public}}}
howpublished = {\url{https://github.com/NetFPGA/P4-NetFPGA-public}},
note = {Requested on 2019-08-22}}
@Misc{networks:_tofin,
author = {Barefoot Networks},
title = {Barefoot Tofino2},
howpublished = {\url{https://barefootnetworks.com/products/brief-tofino-2/}}}
howpublished = {\url{https://barefootnetworks.com/products/brief-tofino-2/}},
note = {Requested on 2019-08-22}}
@Misc{networks:_tofin1,
author = {Barefoot Networks},
title = {Barefoot Tofino},
howpublished = {\url{https://www.barefootnetworks.com/products/brief-tofino/}}}
howpublished = {\url{https://www.barefootnetworks.com/products/brief-tofino/}},
note = {Requested on 2019-08-22}}
@Misc{networks:_arist_series,
author = {Arista Networks},
@ -78,22 +92,29 @@
@Misc{lutchansky:_tayga_simpl_nat64_linux,
author = {Nathan Lutchansky},
title = {TAYGA - Simple, no-fuss NAT64 for Linux},
howpublished = {\url{http://www.litech.org/tayga/}}}
howpublished = {\url{http://www.litech.org/tayga/}}
note = {Requested on 2019-08-22}}
@Misc{mexico:_jool_open_sourc_siit_nat64_linux,
author = {NIC Mexico},
title = {Jool an Open Source SIIT and NAT64 for Linux.},
howpublished = {\url{https://www.jool.mx/en/index.html}}}
howpublished = {\url{https://www.jool.mx/en/index.html}},
note = {Requested on 2019-08-22}}
@Misc{vanbever:_progr_networ_data_planes,
author = {Laurent Vanbever},
title = {Programming Network Data Planes},
howpublished = {\url{https://github.com/nsg-ethz/p4-learning/blob/master/slides/02_p4_env.pdf}}}
howpublished = {\url{https://github.com/nsg-ethz/p4-learning/blob/master/slides/02_p4_env.pdf}},
note = {Requested on 2019-08-22}}
@Misc{ungleich:_ipv4,
author = {ungleich},
title = {Die IPv4, die!},
howpublished = {\url{https://ungleich.ch/en-us/cms/blog/2019/01/09/die-ipv4-die/}}}
howpublished = {\url{https://ungleich.ch/en-us/cms/blog/2019/01/09/die-ipv4-die/}},
note = {Requested on 2019-08-22}}
@Misc{ungleich:networkinfrastructure,
@ -105,12 +126,17 @@
@Misc{nginx:_nginx_high_perfor_load_balan,
author = {NGINX},
title = {NGINX | High Performance Load Balancer, Web Server, \& Reverse Proxy},
howpublished = {\url{https://www.nginx.com/}}}
howpublished = {\url{https://www.nginx.com/}},
note = {Requested on 2019-08-22}}
@Misc{openvswitch,
author = {Linux Foundation},
title = {Open vSwitch},
howpublished = {\url{https://www.openvswitch.org/}}}
howpublished = {\url{https://www.openvswitch.org/}},
note = {Requested on 2019-08-22}}
@Misc{wikipedia:_ipv4,
author = {Wikipedia},
@ -121,17 +147,22 @@
@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}}}
howpublished = {\url{https://github.com/p4lang/p4c/issues/1765}},
note = {Requested on 2019-08-22}}
@Misc{schottelius:github745,
author = {Nico Schottelius},
title = {Add access to table keys},
howpublished = {\url{https://github.com/p4lang/p4-spec/issues/745}}}
howpublished = {\url{https://github.com/p4lang/p4-spec/issues/745}},
note = {Requested on 2019-08-22}}
@Misc{theojepsen:_get,
author = {theojepsen},
title = {Get size of header},
howpublished = {\url{https://github.com/p4lang/p4-spec/issues/660}}}
howpublished = {\url{https://github.com/p4lang/p4-spec/issues/660}},
note = {Requested on 2019-08-22}}
@Misc{wikipedia:_solic,
author = {Wikipedia},
@ -142,8 +173,8 @@
@Misc{schottelius:thesisrepo,
author = {Nico Schottelius},
title = {High speed NAT64 in P4 (git repository)},
howpublished = {\url{https://gitlab.ethz.ch/nsg/student-projects/ma-2019-19_high_speed_nat64_with_p4}}}
howpublished = {\url{https://gitlab.ethz.ch/nsg/student-projects/ma-2019-19_high_speed_nat64_with_p4}},
note = {Requested on 2019-08-22}}
@Misc{nico18:_implem_layer_ipv4_ipv6_rever_proxy,
@ -155,12 +186,16 @@
@Misc{schottelius:_exter_p4_netpf,
author = {Nico Schottelius},
title = {Extern for checksum'ing payload (P4-NetPFGA-public)},
howpublished = {\url{https://github.com/NetFPGA/P4-NetFPGA-public/issues/13}}}
howpublished = {\url{https://github.com/NetFPGA/P4-NetFPGA-public/issues/13}},
note = {Requested on 2019-08-22}}
@Misc{hendrik:_p4_progr_fpga_semes_thesis_sa,
author = {Hendrik Züllig, Supervisor; Prof. Dr. Laurent Vanbever; Tutor: Tobias Bühler},
title = {P4-Programming on an FPGA, Semester Thesis SA-2019-02},
howpublished = {\url{https://gitlab.ethz.ch/nsg/student-projects/sa-2019-02_p4_programming_sume_netfpga/blob/master/SA-2019-02.pdf}}}
howpublished = {\url{https://gitlab.ethz.ch/nsg/student-projects/sa-2019-02_p4_programming_sume_netfpga/blob/master/SA-2019-02.pdf}},
note = {Requested on 2019-08-22}}
@Misc{wikipedia:_jumbo,
author = {Wikipedia},

Loading…
Cancel
Save