nico/master-thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Spell check #1

Browse source
This commit is contained in:
Nico Schottelius 2019-08-20 10:19:01 +02:00
parent 60a4d08514
commit 82782cf8fd
6 changed files with 36 additions and 36 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
doc/Abstract.tex
View file

@ -5,9 +5,9 @@
\begin{center}\textbf{Abstract}\end{center}
Due to the lack of IPv4 addresses, IPv6 deployements have recently
Due to the lack of IPv4 addresses, IPv6 deployments have recently
gained in importance in the Internet.
Several transition mechanism exist that allow translating IPv6
Several transition mechanisms exist that allow translating IPv6
packets into IPv4 packets, thus enabling the coexistence
and interoperability of both protocols.
@ -18,7 +18,7 @@ Due to the target independence of P4 the same code can be compiled
for and deployed to on the FPGA hardware platform ``NetFPGA''.
Within the NetFPGA the NAT64 implementation achieves a stable throughput of
9.29 Gigabit/s and allows in network translations without a
9.29 Gigabit/s and allows in-network translations without a
router. Due to the nature of P4, the implementation runs at line speed
and thus with different hardware the same code can run potentially at
much higher speeds, for instance on 100 Gbit/s switches.

18
doc/Background.tex
View file

@ -134,7 +134,7 @@ like to portray here.
% ----------------------------------------------------------------------
\subsection{\label{background:transition:stateless}Stateless NAT64}
Stateless NAT64 describes static mappings between IPv6 and IPv4
addresses. This can be based on longest prefix matchings (LPM),
addresses. This can be based on longest prefix matching (LPM),
ranges, bitmasks or individual entries.
NAT64 translations as described in this thesis modify multiple layers
@ -182,7 +182,7 @@ a different position, remove fields and add fields.
% ----------------------------------------------------------------------
\subsection{\label{background:transition:statefulnat64}Stateful NAT64}
Stateful NAT64 as defined in RFC6146~\cite{rfc6146} defines how to
cretate 1:n mappings between IPv6 and IPv4 hosts. The motivation for
create 1:n mappings between IPv6 and IPv4 hosts. The motivation for
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
@ -214,9 +214,9 @@ address space don't justify its use in general.
Stateful NAT64 in particular uses information in higher level
protocols to multiplex connections: Given one IPv4 address and the tcp
protocols to multiplex connections: Given one IPv4 address and the TCP
protocol, outgoing connections from IPv6 hosts can dynamically mapped
to the range of possible tcp ports. After a session is closed, the
to the range of possible TCP ports. After a session is closed, the
port can be reused again.
\begin{figure}[h]
\includegraphics[scale=0.5]{statefulnat64}
@ -310,7 +310,7 @@ other prefix lengths are defined in RFC6052 (see 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
in [RFC6052]''~\cite{rfc6146} While this sentence 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
@ -380,7 +380,7 @@ defined in RFC768 and RFC793 and are shown in \ref{fig:ipv4pseudoheader}.
When translating, the checksum fields in the higher protocols need to be
adjusted. The checksums for TCP and UDP is calculated not only over the pseudo
headers, but also contain the payload of the packet. This is
important, because some targets (like the NetPFGA) do not allow to
important, because some targets (like the NetFPGA) do not allow to
access the payload (see section \ref{design:netpfga}).
\begin{figure}[h]
\begin{verbatim}
@ -432,7 +432,7 @@ capable of translating IPv4 to IPv6 and vice versa.
With the introduction of IPv6, hosts can have a separate IP stack
active and in that configuration hosts are called ``dualstack hosts''.
Dualstack hosts are capabale of reaching both IPv6 and IPv4 hosts
Dualstack hosts are capable of reaching both IPv6 and IPv4 hosts
directly without the need of any translation mechanism.
The last possible network design is based on IPv6 only hosts.
@ -461,7 +461,7 @@ mapping of IPv4 address to IPv6\footnote{See section
Thus IPv4 only hosts can
never address every host in the IPv6 Internet. While protocol
dependent translations can try to minimise the impact, accessing all
IPv6 addresses independent of the protcol is not possible.
IPv6 addresses independent of the protocol is not possible.
% ok
% ----------------------------------------------------------------------
\subsection{\label{background:networkdesign:dualstack}Dualstack network
@ -469,7 +469,7 @@ IPv6 addresses independent of the protcol is not possible.
While dualstack hosts can address any host in either IPv6 or IPv4
networks, the deployment of dualstack hosts comes with a major
disadvantage: all network configuration double. The required routing
tables double, the firewall rules roughly double\footnote{The rulesets
tables double, the firewall rules roughly double\footnote{The rule sets
even for identical policies in IPv6 and IPv4 networks are not
identical, but similar. For this reason we state that roughly double
the amount of firewall rules are required for the same policy to be

6
doc/Conclusion.tex
View file

@ -32,7 +32,7 @@ very convincing language that has wide range of applications due to
its protocol independence and easy to understand architecture.
% NetPFGA
The NetFGPA platform is a good showcase for the capabilities of
The NetFPGA platform is a good showcase for the capabilities of
P4, demonstrating almost line speed P4 programs.
However the supporting code immaturity, logging ambiguity
and enormous complexity of the development process.
@ -47,8 +47,8 @@ the learnings of the different layers were very much appreciated / liked
% Outlook OUTLOOK What are the consequences of your work for future work?
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
programming. While this thesis focused on NAT64, the accompanying
technology DNS64~\cite{rfc6147} could also be implemented in P4, thus
completing the translation mechanism.
Proxies / higher level protocols could be next level

10
doc/Design.tex
View file

@ -145,7 +145,7 @@ with 20 sessions\\
\end{figure}
In section \ref{background:transition} we discussed different
translation mechanisms for IPv6 and IPv4. In this thesis we focus on
the translation mechansims stateless and stateful NAT64. While higher
the translation mechanisms stateless and stateful NAT64. While higher
layer protocol dependent translations are more flexible, this topic
has already been addressed in
\cite{nico18:_implem_layer_ipv4_ipv6_rever_proxy} and the focus in
@ -163,7 +163,7 @@ and the controller can also be omitted. However stateful
NAT64 requires the use of a controller to create session entries in the
switch tables.
The P4 switch can use any protocol to communicate with the controller, as
the connection to the controller is implemented as a separate ethernet
the connection to the controller is implemented as a separate Ethernet
port.
\begin{figure}[h]
\includegraphics[scale=0.4]{v6-v4-standard}
@ -226,14 +226,14 @@ entries are configured differently depending on the implementation:
Limitations in the P4/NetFPGA environment require to use table
entries. Jool supports individual entries as a special case of LPM,
with a network mask matching only one IP address. Tayga
support LPM for translation from IPv6 to IPv4, but requires invidiual
support LPM for translation from IPv6 to IPv4, but requires individual
entries for translating from IPv4 to IPv6. Our P4/BMV2 offers the
highest degree of flexibility, as it provides support for invidual
highest degree of flexibility, as it provides support for individual
entries based on table entries and LPM table entries.
% ----------------------------------------------------------------------
\section{\label{design:statefulnat64}Stateful NAT64}
Similar to stateless NAT64, the design of stateful NAT64 depends on
the features of the invidual implementation. As pointed out in section
the features of the individual implementation. As pointed out in section
\ref{background:transition:statefulnat64}, stateful NAT64 is very
similar to stateless NAT64, with the main difference being an
additional stateful table that helps to create 1:n mappings.

12
doc/Introduction.tex
View file

@ -16,14 +16,14 @@
\chapter{\label{introduction}Introduction}
In this chapter we give an introduction about the topic of the master
thesis, the motivation and problemes that we address. We explain the
thesis, the motivation, and problems that we address. We explain the
current state of IPv4 exhaustion and IPv6 adoption and describe how
it motivates our work to support ease transition to IPv6 networks.
% ----------------------------------------------------------------------
\section{\label{introduction:ipv4ipv6}IPv4 exhaustion and IPv6 adoption}
The Internet has almost completely run out of public IPv4 space. The
5 Regional Internet Registries (RIRs) report IPv4 exhaustion world wide
5 Regional Internet Registries (RIRs) report IPv4 exhaustion worldwide
\cite{ripe_exhaustion},
\cite{apnic_exhaustion},
\cite{lacnic:_ipv4_deplet_phases},
@ -46,7 +46,7 @@ in figure \ref{fig:lacnicexhaust}.
\caption{RIR IPv4 rundown projection from~\cite{huston:_ipv4_addres_repor}}
\label{fig:riripv4rundown}
\end{figure}
On the other hand IPv6 adoption grows significantly, with at least
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},
@ -59,7 +59,7 @@ of 2019-08-08~\cite{google:_ipv6_googl}, see figure \ref{fig:googlev6}.
\label{fig:googlev6}
\end{figure}
We conclude that IPv6 is a technology strongly gaining importance with
the IPv4 depletion that is estimated to be world wide happening in the
the IPv4 depletion that is estimated to be worldwide happening in the
next years. Thus more devices will be using IPv6, while communication
to legacy IPv4 devices still needs to be provided.
% ok
@ -77,7 +77,7 @@ proposed~\cite{wikipedia:_ipv6},~\cite{rfc4213}.
\label{fig:v6v4separated}
\end{figure}
However installation and configuration of the transition mechanism
usually require in depth knowledge about both protocols and require
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
@ -103,4 +103,4 @@ solution.
Even on fast CPUs, software solutions like
tayga~\cite{lutchansky:_tayga_simpl_nat64_linux}
can be CPU bound (see section \ref{results:softwarenat64}) and are
incapabale of translating protocols at line speed.
incapable of translating protocols at line speed.

20
doc/Results.tex
View file

@ -90,7 +90,7 @@ Table~\ref{tab:p4bmv2features} references all implemented features.
\hline
\textbf{Feature} & \textbf{Description} & \textbf{Status} \\
\hline
Switch to controller & Switch forwards unhandeled packets to
Switch to controller & Switch forwards unhandled packets to
controller & fully implemented\footnote{Source code: \texttt{actions\_egress.p4}}\\
\hline
Controller to Switch & Controller can setup table entries &
@ -173,7 +173,7 @@ features and reasons about their implementation status.
\hline
\textbf{Feature} & \textbf{Description} & \textbf{Status} \\
\hline
Switch to controller & Switch forwards unhandeled packets to
Switch to controller & Switch forwards unhandled packets to
controller & portable\footnote{While the NetFPGA P4 implementation
does not have the clone3() extern that the BMV2 implementation offers,
communication to the controller can easily be realised by using one of
@ -188,7 +188,7 @@ portable\footnote{The p4utils suite offers an easy access to the
\hline
NDP & Switch responds to ICMP6 neighbor & \\
& solicitation request (without controller) &
portable\footnote{NetFPGA/P4 does not offer calculating the checksume
portable\footnote{NetFPGA/P4 does not offer calculating the checksum
over the payload. However delta checksumming can be used to create
the required checksum for replying.} \\
\hline
@ -263,7 +263,7 @@ forward packets anymore. Multiple reboots (up to 3)
and multiple times reflashing the bitstream to the NetFPGA usually
restored the intended behaviour. However due to this ``crashes'', it
was impossible for us run a benchmark for more than one hour.
Similariy, sometimes flashing the bitstream to the NetFPGA would fail.
Similarly, sometimes flashing the bitstream to the NetFPGA would fail.
It was required to reboot the host containing the
NetFPGA card up to 3 times to enable successful flashing.\footnote{Typical
output of the flashing process would be: ``fpga configuration
@ -271,7 +271,7 @@ failed. DONE PIN is not HIGH''}
% ok
% ----------------------------------------------------------------------
\subsubsection{\label{results:netpfga:performance}Performance}
The NetFGPA card performed at near line speed and offers
The NetFPGA card performed at near line speed and offers
NAT64 translations at 9.28 Gbit/s (see section \ref{results:benchmark}
for details).
Single and multiple streams
@ -284,7 +284,7 @@ The handling and usability of the NetFPGA card is rather difficult. In
this section we describe our findings and experiences with the card
and its toolchain.
To use the NetFGPA, the tools Vivado and SDNET provided by Xilinx need to be
To use the NetFPGA, the tools Vivado and SDNET provided by Xilinx need to be
installed. However a bug in the installer triggers an infinite loop,
if a certain shared library\footnote{The required shared library
is libncurses5.} is missing on the target operating system. The
@ -310,7 +310,7 @@ gen\_testdata.py.}
However incorrect parsing generates syntactically incorrect
scripts or scripts that generate incorrect output. The toolchain
provided by the NetFGPA-P4 repository contains more than 80000 lines
provided by the NetFPGA-P4 repository contains more than 80000 lines
of code. The supporting scripts for setting table entries require
setting the parameters for all possible actions, not only for the
selected action. Supplying only the required parameters results in a
@ -332,7 +332,7 @@ compile process.
During the compile process various informational, warning and error
messages are printed. However some informational messages constitute
critical errors, while on the other hand critical errors and syntax
errors often do not constitue a critical
errors often do not constitute a critical
error.\footnote{F.i. ``CRITICAL WARNING: [BD 41-737] Cannot set the
parameter TRANSLATION\_MODE on /axi\_interconnect\_0. It is
read-only.'' is a non critical warning.}
@ -344,7 +344,7 @@ release, use 'get\_user\_parameters' instead''.}
Programs or scripts that are called during the compile process do not
necessarily exit non zero if they encountered a critical error. Thus
finding the source of an error can be difficult due to the compile
process continuing after critical errors occured. Not only programs
process continuing after critical errors occurred. Not only programs
that have critical errors exit ``successfully'', but also python
scripts that encounter critical paths don't abort with raise(), but
print an error message to stdout and don't abort with an error.
@ -383,7 +383,7 @@ techniques are missing or not supported.
\item Analysing / accessing payload is not supported
\item Checksum computation over payload is not supported
\item Using LPM tables can lead to compilation errors
\item Depening on the match type, only certain table sizes are allowed
\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