Proof read #2

doc/Background.tex

@@ -4,7 +4,7 @@ relation to our work.
 % ----------------------------------------------------------------------
 \section{\label{background:p4}P4}
 P4 is a programming language designed to program inside network
-equipment. It's main features are protocol and target independence.
+equipment. Its main features are protocol and target independence.
 The \textit{protocol independence} refers to the separation of concerns in
 terms of language and protocols: P4, generally speaking, operates on
 bits that are parsed and then accessible in the self defined
@@ -23,7 +23,7 @@ parser will read and parse in the ingress pipeline one protocol
 \end{figure}
 The \textit{target independence} is the second very powerful feature
 of P4: it allows code to be compiled to different targets. While in
-theory the P4 code should be completely target independent, in reality
+theory the P4 code should be completely target independent, in reality,
 there are some modifications needed on a per-target basis and each
 target faces different restrictions. The challenges arising from this
 are discussed in section \ref{results:p4}.
@@ -44,7 +44,7 @@ consider transmission via Ethernet, which operates at
 layer 2. Inside the Ethernet frame a field named ``type'' specifies
 the higher level protocol identifier.\footnote{
   0x0800 for IPv4~\cite{rfc894} and 0x86DD for IPv6~\cite{rfc2464}.}
-This is important, because
+This is important because
 Ethernet can only reference one protocol, which makes IPv4 and IPv6
 mutually exclusive.
 The figures \ref{fig:ipv4header} and \ref{fig:ipv6header} show the
@@ -81,7 +81,7 @@ The major difference between ARP and NDP in relation to P4 are
 \item ARP is a separate protocol on the same layer as IPv6 and IPv4,
 \item NDP operates below ICMP6 which operates below IPv6,
 \item NDP contains checksums over payload,
-\item and NDP in ICMP6 contains optional, non referenced option fields
+\item and NDP in ICMP6 contains optional, non-referenced option fields
   (specifically: ICMP6 link layer address option).
 \end{itemize}
 ARP is required to be a separate protocol, because IPv4 hosts don't
@@ -99,8 +99,7 @@ collision domain is significantly reduced in IPv6, compared to IPv4.
 As seen later in this document (compare
 section \ref{results:netpfga:features}), the requirement to generate checksums
 over payload poses difficult problems for some hardware targets. Even
-more difficult is the use of options within ICMP6. Figure shows a
-typical layout of a neighbor advertisement messages.
+more difficult is the use of options within ICMP6.
 \begin{figure}[h]
   \includegraphics[scale=0.3]{icmp6ndp}
   \centering
@@ -230,7 +229,7 @@ stateful NAT64, the translator needs to store the mapping in a table and
 purge entries regularly.
 
 Stateful NAT64 usually uses information found in protocols at layer 4
-like TCP~\cite{rfc793} or UDP~\cite{rfc768}. However it can also
+like TCP~\cite{rfc793} or UDP~\cite{rfc768}. However, it can also
 support ICMP~\cite{rfc792} and ICMP6~\cite{rfc4443}.
 % ----------------------------------------------------------------------
 \subsection{\label{background:transition:Protocol dependent}Higher
@@ -242,14 +241,14 @@ nginx~\cite{nginx:_nginx_high_perfor_load_balan}
 use layer 7 protocol
 information to proxy towards backends. Within this proxying method,
 the underlying IP protocol can be changed from IPv6 to IPv4 and vice
-versa. However the requested hostname that is usually used for
+versa. However, the requested hostname that is usually used for
 selecting the backend is encrypted in TLS 1.3~\cite{rfc8446}, which
 poses a challenge for implementations.
 
 While protocol dependent translation has the highest amount of
 information to choose from for translation, complex parsers or even
 cryptographic methods are required for it. That reduces the
-opportunities of protocol dependent translation
+opportunities of protocol dependent translation.
 % ----------------------------------------------------------------------
 \subsection{\label{background:transition:prefixnat}Mapping IPv4
 Addresses in IPv6}
@@ -260,8 +259,8 @@ practice to assign an IPv6 prefix for IPv6 hosts that represents a
 mapping to the IPv4 Internet. In RFC6052~\cite{rfc6502} the well
 known prefix \textit{64:ff9b::/96} is defined. One possibility to map
 an IPv4 address into the prefix is by adding its integer value to the
-prefix, treating it like an offset. In figure \ref{fig:ipv4embed}
-we show an example python code of how this can be done.
+prefix, treating it as an offset. In figure \ref{fig:ipv4embed}
+we show example python code of how this can be done.
 \begin{figure}[h]
 \begin{verbatim}
 >>> import ipaddress
@@ -328,7 +327,7 @@ figure \ref{fig:dns64}.
   \caption{Illustration of DNS64}
   \label{fig:dns64}
 \end{figure}
-The DNS64 DNS server will query the authorative DNS server for an AAAA
+The DNS64 DNS server will query the authoritative DNS server for an AAAA
 record. However as the host \textit{ipv4onlyhost.example.com} is only
 reachable by IPv4, it also only has an A entry. After receiving the
 answer that there is no AAAA record, the DNS64 server will ask for an
@@ -337,7 +336,7 @@ A record and gets an answer that the name
 \textit{192.0.2.0}. The DNS64 server then embeds the IPv4 address in
 the configured IPv6 prefix (\textit{64:ff9b::/96} in this case) and
 returns a fake AAAA record to the IPv6 only host. The IPv6 only host
-then will use address to connect to. The NAT64 translator recognises
+then will use the address to connect to. The NAT64 translator recognises
 either that the address is part of a configured prefix or that it has
 a dedicated table entry for mapping this IPv6 address to an IPv4
 address and translates it accordingly.
@@ -380,7 +379,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 NetFPGA) 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}
@@ -447,7 +446,7 @@ systems is not an easy task~\cite{ungleich:_ipv4}.
 %% \end{figure}
 While the three network designs look similar, there are significant
 differences in operating them and limitations that are not easy to
-circumvent. In the following sections we describe the limitations and
+circumvent. In the following sections, we describe the limitations and
 reason how a translation mechanism like our NAT64 implementation
 should be deployed.
 % ----------------------------------------------------------------------
@@ -473,7 +472,7 @@ 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
-  applied.} and the number of network supporting systems (like DHCPv4,
+  applied.} and the number of network supporting systems, (like DHCPv4,
 DHCPv6, router advertisement daemons, etc.) also roughly double.
 Additionally services that run on either IPv6 or IPv4 might need to be
 configured to run in dualstack mode as well and not every software