From 82782cf8fd697a3c61d8229b5e8e69968d0c0b0d Mon Sep 17 00:00:00 2001 From: Nico Schottelius Date: Tue, 20 Aug 2019 10:19:01 +0200 Subject: [PATCH] Spell check #1 --- doc/Abstract.tex | 6 +++--- doc/Background.tex | 18 +++++++++--------- doc/Conclusion.tex | 6 +++--- doc/Design.tex | 10 +++++----- doc/Introduction.tex | 12 ++++++------ doc/Results.tex | 20 ++++++++++---------- 6 files changed, 36 insertions(+), 36 deletions(-) diff --git a/doc/Abstract.tex b/doc/Abstract.tex index 1198032..7105547 100644 --- a/doc/Abstract.tex +++ b/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. diff --git a/doc/Background.tex b/doc/Background.tex index dd182a2..570acb2 100644 --- a/doc/Background.tex +++ b/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 diff --git a/doc/Conclusion.tex b/doc/Conclusion.tex index 47e89cb..7586b30 100644 --- a/doc/Conclusion.tex +++ b/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 -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 diff --git a/doc/Design.tex b/doc/Design.tex index 15707cd..4aa89ee 100644 --- a/doc/Design.tex +++ b/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. diff --git a/doc/Introduction.tex b/doc/Introduction.tex index aae7751..415200f 100644 --- a/doc/Introduction.tex +++ b/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. diff --git a/doc/Results.tex b/doc/Results.tex index 6a8b6fd..da61410 100644 --- a/doc/Results.tex +++ b/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