Spell check #1

doc/Abstract.tex

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

doc/Background.tex

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

doc/Conclusion.tex

@@ -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
+programming. While this thesis focused on NAT64, the accompanying
-technologie DNS64~\cite{rfc6147} could also be implemented in P4, thus
+technology DNS64~\cite{rfc6147} could also be implemented in P4, thus
 completing the translation mechanism.
 
 Proxies / higher level protocols could be next level

doc/Design.tex

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

doc/Introduction.tex

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

doc/Results.tex

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