This commit is contained in:
Nico Schottelius 2019-08-10 18:11:42 +02:00
parent 41703f19e0
commit 6485e26417
2 changed files with 60 additions and 13 deletions

View file

@ -137,7 +137,7 @@ 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. port can be reused again.
\begin{figure}[h] \begin{figure}[h]
\includegraphics[scale=0.7]{statefulnat64} \includegraphics[scale=0.5]{statefulnat64}
\centering \centering
\caption{Stateful NAT64} \caption{Stateful NAT64}
\label{fig:statefulnat64} \label{fig:statefulnat64}
@ -167,17 +167,63 @@ While protocol dependent translation has the highest amount of
information to choose from for translation, complex parsers or even information to choose from for translation, complex parsers or even
cryptographic methods are required for it. That reduces the cryptographic methods are required for it. That reduces the
opportunities of protocol dependent translation opportunities of protocol dependent translation
% ----------------------------------------------------------------------
\subsection{\label{background:transition:Port based}Port based
translation}
tcp/udp
icmp: ?? maybe ID field
% ---------------------------------------------------------------------- % ----------------------------------------------------------------------
\section{\label{background:checksums}Protocol Checksums} \section{\label{background:checksums}Protocol Checksums}
One challenge for translating IPv6-IPv4 are checksums of higher level
protocols like TCP and UDP that incorporate information from the lower
level protocols. The pseudo header for upper layer protocols for
IPv6 is defined in RFC2460 \cite{rfc2460} and shown in figure
\ref{fig:ipv6pseudoheader}, the IPv4 pseudo header for TCP and UDP are
defined in RFC768 and RFC793 and are shown in \ref{fig:ipv4pseudoheader}.
\begin{figure}[h]
\begin{verbatim}
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upper-Layer Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\end{verbatim}
\centering
\caption{IPv6 Pseudo Header}
\label{fig:ipv6pseudoheader}
\end{figure}
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
access the payload.
\begin{figure}[h]
\begin{verbatim}
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| source address |
+--------+--------+--------+--------+
| destination address |
+--------+--------+--------+--------+
| zero |protocol| UDP length |
+--------+--------+--------+--------+
\end{verbatim}
\centering
\caption{IPv4 Pseudo Header}
\label{fig:ipv4pseudoheader}
\end{figure}
% ---------------------------------------------------------------------- % ----------------------------------------------------------------------
\section{\label{background:networkdesign}Network Designs} \section{\label{background:networkdesign}Network Designs}
\begin{figure}[h] \begin{figure}[h]
@ -254,9 +300,10 @@ or translation method, we argue that the added complexity (and thus
operational cost) of running dual stack networks can be significant. operational cost) of running dual stack networks can be significant.
% ---------------------------------------------------------------------- % ----------------------------------------------------------------------
\subsection{\label{background:networkdesign:v6only}IPv6 only networks} \subsection{\label{background:networkdesign:v6only}IPv6 only networks}
IPv6 only networks are our opinion the best choice for long term IPv6 only networks are in our opinion the best choice for long term
deployments. The reasons for this are as follows: deployments. The reasons for this are as follows: First of all hosts
eventually will need to support IPv6 and secondly
IPv6 hosts can address the whole 32 bit IPv4 Internet mapped in IPv6 hosts can address the whole 32 bit IPv4 Internet mapped in
a single /96 IPv6 network, whithout the need for address extension or a single /96 IPv6 network, whithout the need for address extension or
higher protocol dependent translations\footnote{Lower level protocols higher protocol dependent translations\footnote{Higher level protocols
like TCP, UDP, ICMP6/ICMP.} like TCP, UDP, ICMP6/ICMP.}

View file

@ -81,5 +81,5 @@
@Misc{nginx:_nginx_high_perfor_load_balan, @Misc{nginx:_nginx_high_perfor_load_balan,
author = {NGINX}, author = {NGINX},
title = {NGINX | High Performance Load Balancer, Web Server, & Reverse Proxy}, title = {NGINX | High Performance Load Balancer, Web Server, \& Reverse Proxy},
howpublished = {\url{https://www.nginx.com/}}} howpublished = {\url{https://www.nginx.com/}}}