include pdfs instead of png
Signed-off-by: Nico Schottelius <nico@nico-notebook.schottelius.org>
|
@ -10,3 +10,4 @@ plan.tex
|
||||||
Thesis.bbl
|
Thesis.bbl
|
||||||
Thesis.blg
|
Thesis.blg
|
||||||
Thesis.blg
|
Thesis.blg
|
||||||
|
abc.dot
|
||||||
|
|
|
@ -7,21 +7,22 @@
|
||||||
\begin{center}\textbf{Abstract}\end{center}
|
\begin{center}\textbf{Abstract}\end{center}
|
||||||
Due to the lack of IPv4 addresses, IPv6 deployments have recently
|
Due to the lack of IPv4 addresses, IPv6 deployments have recently
|
||||||
gained in importance in the Internet.
|
gained in importance in the Internet.
|
||||||
Several transition mechanisms exist that allow translating IPv6
|
Several transition mechanisms exist that include
|
||||||
packets into IPv4 packets, thus enabling the coexistence
|
translating IPv6 packets into IPv4 packets,
|
||||||
and interoperability of both protocols.
|
thus enabling the coexistence and interoperability of both protocols.
|
||||||
|
|
||||||
This thesis describes an implementation of the transition mechanism
|
This thesis describes an implementation of the translation mechanism
|
||||||
NAT64 implemented in P4. Using the P4 programming language
|
NAT64, implemented in P4. Using the P4 programming language
|
||||||
a software emulated switch was created that translates IPv4 to IPv6 and vice versa.
|
a software emulated switch was created that translates IPv4 to IPv6 and vice versa.
|
||||||
Due to the target independence of P4 the same code can be compiled
|
Due to the target independence of P4 the same code can be compiled
|
||||||
for and deployed to on the FPGA hardware platform ``NetFPGA''.
|
for and deployed to the FPGA hardware platform ``NetFPGA''.
|
||||||
|
|
||||||
Within the NetFPGA the NAT64 implementation achieves a stable throughput of
|
Within the NetFPGA the NAT64 implementation achieves a stable throughput of
|
||||||
9.29 Gigabit/s and allows in-network translations without a
|
9.28 Gigabit/s. Our solution allows in-network translations without a
|
||||||
router. Due to the nature of P4, the implementation runs at line speed
|
router or client configurations. Due to the nature of P4, the
|
||||||
and thus with different hardware the same code can run potentially at
|
implementation runs at line speed and thus with different hardware
|
||||||
much higher speeds, for instance on 100 Gbit/s switches.
|
the same code can run potentially at much higher speeds,
|
||||||
|
for instance on 100 Gbit/s switches.
|
||||||
|
|
||||||
%% P4. P4 is protocol and target independent and allo
|
%% P4. P4 is protocol and target independent and allo
|
||||||
%% P4 is a protocol independent programming language that allows programming network
|
%% P4 is a protocol independent programming language that allows programming network
|
||||||
|
|
|
@ -21,7 +21,7 @@ parser will read and parse in the ingress pipeline one protocol
|
||||||
\caption{P4 protocol independence~\cite{vanbever:_progr_networ_data_planes}}
|
\caption{P4 protocol independence~\cite{vanbever:_progr_networ_data_planes}}
|
||||||
\label{fig:p4fromnsg}
|
\label{fig:p4fromnsg}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
The \textit{target independence} is the second very powerful feature
|
The \textit{target independence} is the second strong feature
|
||||||
of P4: it allows code to be compiled to different targets. While in
|
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
|
there are some modifications needed on a per-target basis and each
|
||||||
|
|
416
doc/Design.tex
|
@ -2,141 +2,16 @@
|
||||||
%** Design.tex: How was the problem attacked, what was the design
|
%** Design.tex: How was the problem attacked, what was the design
|
||||||
% the architecture
|
% the architecture
|
||||||
In this chapter we describe the architecture of our solution and our
|
In this chapter we describe the architecture of our solution and our
|
||||||
design choices.
|
design choices. We first introduce the general design of NAT64 in the
|
||||||
|
P4 architecture. Afterwards we describe the design differences
|
||||||
|
for the BMV2 and NetFPGA P4 architectures. Afterwards we discuss the
|
||||||
|
design of stateless and stateful NAT64 in relation to P4 an well as
|
||||||
|
two existing software NAT64 solutions.
|
||||||
|
|
||||||
|
Lastly we discuss how we verify NAT64 functionality present
|
||||||
|
the network configurations that we use.
|
||||||
% ----------------------------------------------------------------------
|
% ----------------------------------------------------------------------
|
||||||
\section{\label{design:configuration}IPv6 and IPv4 configuration}
|
\section{\label{design:nat64}P4/NAT64}
|
||||||
The following sections refer to host and network configurations. In
|
|
||||||
this section we describe the IPv6 and IPv4 configurations as a basis
|
|
||||||
for the discussion.
|
|
||||||
|
|
||||||
All IPv6 addresses are from the documentation block
|
|
||||||
\textit{2001:DB8::/32}~\cite{rfc3849}. In particular the following sub
|
|
||||||
networks and IPv6 addresses are used:
|
|
||||||
\begin{table}[htbp]
|
|
||||||
\begin{center}\begin{minipage}{\textwidth}
|
|
||||||
\begin{tabular}{| c | c |}
|
|
||||||
\hline
|
|
||||||
\textbf{Address} & \textbf{Description} \\
|
|
||||||
\hline
|
|
||||||
2001:db8:42::/64 & IPv6 host network \\
|
|
||||||
\hline
|
|
||||||
2001:db8:23::/96 & IPv6 mapping to the IPv4 Internet \\
|
|
||||||
\hline
|
|
||||||
2001:db8:42::42 & IPv6 host address \\
|
|
||||||
\hline
|
|
||||||
2001:db8:42::77 & IPv6 router address \\
|
|
||||||
\hline
|
|
||||||
2001:db8:42::a00:2a & In-network IPv6 address mapped to 10.0.0.42 (p4)\\
|
|
||||||
\hline
|
|
||||||
2001:db8:23::a00:2a & IPv6 address mapped to 10.0.0.42 (tayga) \\
|
|
||||||
\hline
|
|
||||||
2001:db8:23::2a & IPv6 address mapped to 10.0.0.42 (jool)\\
|
|
||||||
\hline
|
|
||||||
\end{tabular}
|
|
||||||
\end{minipage}
|
|
||||||
\caption{IPv6 address and network overview}
|
|
||||||
\label{tab:ipv6address}
|
|
||||||
\end{center}
|
|
||||||
\end{table}
|
|
||||||
|
|
||||||
We use private IPv4 addresses as specified by RFC1918~\cite{rfc1918}
|
|
||||||
from the 10.0.0.0/8 range as follows:
|
|
||||||
|
|
||||||
\begin{table}[htbp]
|
|
||||||
\begin{center}\begin{minipage}{\textwidth}
|
|
||||||
\begin{tabular}{| c | c |}
|
|
||||||
\hline
|
|
||||||
\textbf{Address} & \textbf{Description} \\
|
|
||||||
\hline
|
|
||||||
10.0.0.0/24 & IPv4 host network \\
|
|
||||||
\hline
|
|
||||||
10.0.1.0/24 & IPv4 network mapping to IPv6\\
|
|
||||||
\hline
|
|
||||||
10.0.0.77 & IPv4 router address\\
|
|
||||||
\hline
|
|
||||||
10.0.0.66 & In-network IPv4 address mapped to 2001:db8:42::42 (p4)\\
|
|
||||||
\hline
|
|
||||||
10.0.1.42 & IPv4 address mapped to 2001:db8:42::42 (tayga)\\
|
|
||||||
\hline
|
|
||||||
10.0.1.66 & IPv4 address mapped to 2001:db8:42::42 (jool)\\
|
|
||||||
\hline
|
|
||||||
\end{tabular}
|
|
||||||
\end{minipage}
|
|
||||||
\caption{IPv4 address and network overview}
|
|
||||||
\label{tab:ipv4address}
|
|
||||||
\end{center}
|
|
||||||
\end{table}
|
|
||||||
% ok
|
|
||||||
% ----------------------------------------------------------------------
|
|
||||||
\section{\label{design:tests}NAT64 Verification}
|
|
||||||
We use socat~\cite{rieger:_multip} to verify basic operation of the
|
|
||||||
NAT64 gateway and iperf~\cite{dugan:_tcp_udp_sctp} to test stability
|
|
||||||
of the implementation and measure bandwidth.
|
|
||||||
In particular we use
|
|
||||||
the commands listed in table \ref{tab:nat64verification}. The socat
|
|
||||||
commands allow interactive testing on TCP and UDP connections, while
|
|
||||||
the iperf commands fully utilise the available bandwidth with test
|
|
||||||
data.
|
|
||||||
The socat and iperf commands are used to verify all three NAT64
|
|
||||||
implementations (p4, tayga, jool).
|
|
||||||
\begin{table}[htbp]
|
|
||||||
\begin{center}\begin{minipage}{\textwidth}
|
|
||||||
\begin{tabular}{| c | c | c |}
|
|
||||||
\hline
|
|
||||||
\textbf{Command} & \textbf{Example} & \textbf{Description} \\
|
|
||||||
\hline
|
|
||||||
\texttt{socat - TCP6:HOST:PORT} & socat -
|
|
||||||
TCP6:[2001:db8:42::a00:2a]:2345 & Connect via IPv6/TCP\\
|
|
||||||
& & to IPv4 host\\
|
|
||||||
%\hline
|
|
||||||
\texttt{socat - UDP6:HOST:PORT} & socat -
|
|
||||||
UDP6:[2001:db8:42::a00:2a]:2345 & Connect via IPv6/UDP \\ & & to IPv4 host\\
|
|
||||||
%\hline
|
|
||||||
\texttt{socat - TCP:HOST:PORT} & socat -
|
|
||||||
TCP:10.0.1.42:2345 & Connect via IPv4/TCP \\ & & to IPv6 host \\
|
|
||||||
%\hline
|
|
||||||
\texttt{socat - UDP:HOST:PORT} & socat -
|
|
||||||
UDP:10.0.1.42:2345 & Connect via IPv4/UDP \\ & & to IPv6 host \\
|
|
||||||
\hline
|
|
||||||
\texttt{socat - UDP6-LISTEN:PORT} & socat -
|
|
||||||
UDP6-LISTEN:2345 & Listen on IPv6/UDP \\
|
|
||||||
%\hline
|
|
||||||
\texttt{socat - TCP6-LISTEN:PORT} & socat -
|
|
||||||
TCP6-LISTEN:2345 & Listen on IPv6/TCP \\
|
|
||||||
%\hline
|
|
||||||
\texttt{socat - UDP-LISTEN:PORT} & socat -
|
|
||||||
UDP-LISTEN:2345 & Listen on IPv4/UDP \\
|
|
||||||
%\hline
|
|
||||||
\texttt{socat - TCP-LISTEN:PORT} & socat -
|
|
||||||
TCP-LISTEN:2345 & Listen on IPv4/TCP \\
|
|
||||||
\hline
|
|
||||||
\texttt{iperf3 -PROTO -p PORT} & iperf3 -4 -p 2345 & IPv4 iperf server\\
|
|
||||||
\texttt{-B IP -s} & -B 10.0.0.42 -s &\\
|
|
||||||
& iperf3 -6 -p 2345 & IPv6 iperf server\\
|
|
||||||
& -B 2001:db8:42::42 -s & \\
|
|
||||||
\hline
|
|
||||||
\texttt{iperf3 -PROTO -p PORT } & iperf3 -6 -p 2345& Connect to iperf server\\
|
|
||||||
\texttt{-O IGNORETIME -t RUNTIME} & -O 10 -t 190 &
|
|
||||||
Run for 190 seconds, \\
|
|
||||||
& & skip first 10 seconds\\
|
|
||||||
\texttt{-P PARALLEL -c IP} & -P20 -c 2001:db8:23::2a &
|
|
||||||
with 20 sessions\\
|
|
||||||
& & connecting to\\
|
|
||||||
& & 2001:db8:23::2a\\
|
|
||||||
\texttt{iperf3 -PROTO -p PORT} & & Same as above,\\
|
|
||||||
\texttt{-O IGNORETIME -t RUNTIME} & & but connect via UDP\\
|
|
||||||
\texttt{-P PARALLEL -c IP} & & \\
|
|
||||||
\texttt{-u -b0} & & \\
|
|
||||||
\hline
|
|
||||||
\end{tabular}
|
|
||||||
\end{minipage}
|
|
||||||
\caption{NAT64 verification commands}
|
|
||||||
\label{tab:nat64verification}
|
|
||||||
\end{center}
|
|
||||||
\end{table}
|
|
||||||
% ----------------------------------------------------------------------
|
|
||||||
\section{\label{design:nat64}NAT64 with P4}
|
|
||||||
\begin{figure}[h]
|
\begin{figure}[h]
|
||||||
\includegraphics[scale=0.4]{switchdesign}
|
\includegraphics[scale=0.4]{switchdesign}
|
||||||
\centering
|
\centering
|
||||||
|
@ -189,75 +64,15 @@ segment.
|
||||||
\caption{In-network NAT64 translation}
|
\caption{In-network NAT64 translation}
|
||||||
\label{fig:v6v4mixed}
|
\label{fig:v6v4mixed}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
% ----------------------------------------------------------------------
|
||||||
|
\section{\label{design:nat64:indepth}P4/NAT64}
|
||||||
|
P4 switches in general look very similar to regular switches, however
|
||||||
|
support executing logic while the packet passes through the switch.
|
||||||
|
|
||||||
|
When a packet enters the switch,
|
||||||
|
|
||||||
|
\digraph[scale=0.5]{abc}{rankdir=LR; a->b->c;}
|
||||||
|
|
||||||
% ----------------------------------------------------------------------
|
|
||||||
\section{\label{design:statelessnat64}Stateless NAT64}
|
|
||||||
As seen in section \ref{background:transition:stateless}, stateless
|
|
||||||
NAT64 can be implemented using various factors. Our design for the
|
|
||||||
stateless depends on the capabilities of the environment and is
|
|
||||||
summarised in table \ref{tab:statelessnat64factors}.
|
|
||||||
\begin{table}[htbp]
|
|
||||||
\begin{center}\begin{minipage}{\textwidth}
|
|
||||||
\begin{tabular}{| c | c |}
|
|
||||||
\hline
|
|
||||||
\textbf{Implementation} & \textbf{NAT64 match}\\
|
|
||||||
\hline
|
|
||||||
P4/BMV2 & LPM (both directions)\\
|
|
||||||
& and individual entries (both directions)\\
|
|
||||||
\hline
|
|
||||||
P4/NetPFGA & Individual entries\\
|
|
||||||
\hline
|
|
||||||
Tayga & LPM (IPv6 to IPv4) and individual entries (IPv4 to IPv6)\\
|
|
||||||
\hline
|
|
||||||
Jool & LPM (both directions)\\
|
|
||||||
\hline
|
|
||||||
\end{tabular}
|
|
||||||
\end{minipage}
|
|
||||||
\caption{NAT64 match factors}
|
|
||||||
\label{tab:statelessnat64factors}
|
|
||||||
\end{center}
|
|
||||||
\end{table}
|
|
||||||
When using LPM for translating from IPv6 to IPv4, a /96 IPv6 network
|
|
||||||
is configured for covering the whole IPv4 Internet and the individual
|
|
||||||
IPv4 address is appended to the prefix (compare section
|
|
||||||
\ref{design:configuration}). We also use LPM to match on an IPv4 sub
|
|
||||||
network that translates to an IPv6 sub network. Individual
|
|
||||||
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 individual
|
|
||||||
entries for translating from IPv4 to IPv6. Our P4/BMV2 offers the
|
|
||||||
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 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.
|
|
||||||
We use different approaches within the implementations
|
|
||||||
to solve this problem:
|
|
||||||
\begin{itemize}
|
|
||||||
\item For P4/BMV2 and P4/NetPFGA a python controller handles packets
|
|
||||||
that don't have a table entry, sets the table entry in the P4 switch
|
|
||||||
and inserts the original packet afterwards back into the switch.
|
|
||||||
\item With tayga we rely on the Linux kernel NAT44 capabilities
|
|
||||||
\item Jool implements its own stateful mechanism based on a port
|
|
||||||
ranges
|
|
||||||
\end{itemize}
|
|
||||||
All methods though operate in a very similar fashion: A ``controller''
|
|
||||||
inspects the IPv6 packet and depending on the source address,
|
|
||||||
destination address, protocol (TCP, UDP,
|
|
||||||
ICMP, ICMP6, etc.) and the protocol ID (source / destination TCP/UDP
|
|
||||||
port, ICMP identifier) it selects an outgoing IPv4 address, and source
|
|
||||||
port or ICMP identifier.
|
|
||||||
In case of Jool and Tayga this decision is based on a session table
|
|
||||||
inside the Linux kernel, in case of P4 this decision is based on a
|
|
||||||
session table inside the python controller. While the Jool and Tayga
|
|
||||||
both support cleaning up old session entries,
|
|
||||||
our P4 based solution does not support this feature at the moment.
|
|
||||||
% ----------------------------------------------------------------------
|
% ----------------------------------------------------------------------
|
||||||
\section{\label{design:bmv2}P4/BMV2}
|
\section{\label{design:bmv2}P4/BMV2}
|
||||||
\begin{figure}[h]
|
\begin{figure}[h]
|
||||||
|
@ -391,4 +206,203 @@ It is notable that
|
||||||
not the full headers are used, but only a ``pseudo header'' (compare figures
|
not the full headers are used, but only a ``pseudo header'' (compare figures
|
||||||
\ref{fig:ipv6pseudoheader} and \ref{fig:ipv4pseudoheader}).
|
\ref{fig:ipv6pseudoheader} and \ref{fig:ipv4pseudoheader}).
|
||||||
% ok
|
% ok
|
||||||
|
|
||||||
% ----------------------------------------------------------------------
|
% ----------------------------------------------------------------------
|
||||||
|
\section{\label{design:statelessnat64}Stateless NAT64}
|
||||||
|
As seen in section \ref{background:transition:stateless}, stateless
|
||||||
|
NAT64 can be implemented using various factors. Our design for the
|
||||||
|
stateless depends on the capabilities of the environment and is
|
||||||
|
summarised in table \ref{tab:statelessnat64factors}.
|
||||||
|
\begin{table}[htbp]
|
||||||
|
\begin{center}\begin{minipage}{\textwidth}
|
||||||
|
\begin{tabular}{| c | c |}
|
||||||
|
\hline
|
||||||
|
\textbf{Implementation} & \textbf{NAT64 match}\\
|
||||||
|
\hline
|
||||||
|
P4/BMV2 & LPM (both directions)\\
|
||||||
|
& and individual entries (both directions)\\
|
||||||
|
\hline
|
||||||
|
P4/NetPFGA & Individual entries\\
|
||||||
|
\hline
|
||||||
|
Tayga & LPM (IPv6 to IPv4) and individual entries (IPv4 to IPv6)\\
|
||||||
|
\hline
|
||||||
|
Jool & LPM (both directions)\\
|
||||||
|
\hline
|
||||||
|
\end{tabular}
|
||||||
|
\end{minipage}
|
||||||
|
\caption{NAT64 match factors}
|
||||||
|
\label{tab:statelessnat64factors}
|
||||||
|
\end{center}
|
||||||
|
\end{table}
|
||||||
|
When using LPM for translating from IPv6 to IPv4, a /96 IPv6 network
|
||||||
|
is configured for covering the whole IPv4 Internet and the individual
|
||||||
|
IPv4 address is appended to the prefix (compare section
|
||||||
|
\ref{design:configuration}). We also use LPM to match on an IPv4 sub
|
||||||
|
network that translates to an IPv6 sub network. Individual
|
||||||
|
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 individual
|
||||||
|
entries for translating from IPv4 to IPv6. Our P4/BMV2 offers the
|
||||||
|
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 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.
|
||||||
|
We use different approaches within the implementations
|
||||||
|
to solve this problem:
|
||||||
|
\begin{itemize}
|
||||||
|
\item For P4/BMV2 and P4/NetPFGA a python controller handles packets
|
||||||
|
that don't have a table entry, sets the table entry in the P4 switch
|
||||||
|
and inserts the original packet afterwards back into the switch.
|
||||||
|
\item With tayga we rely on the Linux kernel NAT44 capabilities
|
||||||
|
\item Jool implements its own stateful mechanism based on a port
|
||||||
|
ranges
|
||||||
|
\end{itemize}
|
||||||
|
All methods though operate in a very similar fashion: A ``controller''
|
||||||
|
inspects the IPv6 packet and depending on the source address,
|
||||||
|
destination address, protocol (TCP, UDP,
|
||||||
|
ICMP, ICMP6, etc.) and the protocol ID (source / destination TCP/UDP
|
||||||
|
port, ICMP identifier) it selects an outgoing IPv4 address, and source
|
||||||
|
port or ICMP identifier.
|
||||||
|
In case of Jool and Tayga this decision is based on a session table
|
||||||
|
inside the Linux kernel, in case of P4 this decision is based on a
|
||||||
|
session table inside the python controller. While the Jool and Tayga
|
||||||
|
both support cleaning up old session entries,
|
||||||
|
our P4 based solution does not support this feature at the moment.
|
||||||
|
% ----------------------------------------------------------------------
|
||||||
|
\section{\label{design:tests}NAT64 Verification}
|
||||||
|
We use socat~\cite{rieger:_multip} to verify basic operation of the
|
||||||
|
NAT64 gateway and iperf~\cite{dugan:_tcp_udp_sctp} to test stability
|
||||||
|
of the implementation and measure bandwidth.
|
||||||
|
In particular we use
|
||||||
|
the commands listed in table \ref{tab:nat64verification}. The socat
|
||||||
|
commands allow interactive testing on TCP and UDP connections, while
|
||||||
|
the iperf commands fully utilise the available bandwidth with test
|
||||||
|
data.
|
||||||
|
The socat and iperf commands are used to verify all three NAT64
|
||||||
|
implementations (p4, tayga, jool).
|
||||||
|
\begin{table}[htbp]
|
||||||
|
\begin{center}\begin{minipage}{\textwidth}
|
||||||
|
\begin{tabular}{| c | c | c |}
|
||||||
|
\hline
|
||||||
|
\textbf{Command} & \textbf{Example} & \textbf{Description} \\
|
||||||
|
\hline
|
||||||
|
\texttt{socat - TCP6:HOST:PORT} & socat -
|
||||||
|
TCP6:[2001:db8:42::a00:2a]:2345 & Connect via IPv6/TCP\\
|
||||||
|
& & to IPv4 host\\
|
||||||
|
%\hline
|
||||||
|
\texttt{socat - UDP6:HOST:PORT} & socat -
|
||||||
|
UDP6:[2001:db8:42::a00:2a]:2345 & Connect via IPv6/UDP \\ & & to IPv4 host\\
|
||||||
|
%\hline
|
||||||
|
\texttt{socat - TCP:HOST:PORT} & socat -
|
||||||
|
TCP:10.0.1.42:2345 & Connect via IPv4/TCP \\ & & to IPv6 host \\
|
||||||
|
%\hline
|
||||||
|
\texttt{socat - UDP:HOST:PORT} & socat -
|
||||||
|
UDP:10.0.1.42:2345 & Connect via IPv4/UDP \\ & & to IPv6 host \\
|
||||||
|
\hline
|
||||||
|
\texttt{socat - UDP6-LISTEN:PORT} & socat -
|
||||||
|
UDP6-LISTEN:2345 & Listen on IPv6/UDP \\
|
||||||
|
%\hline
|
||||||
|
\texttt{socat - TCP6-LISTEN:PORT} & socat -
|
||||||
|
TCP6-LISTEN:2345 & Listen on IPv6/TCP \\
|
||||||
|
%\hline
|
||||||
|
\texttt{socat - UDP-LISTEN:PORT} & socat -
|
||||||
|
UDP-LISTEN:2345 & Listen on IPv4/UDP \\
|
||||||
|
%\hline
|
||||||
|
\texttt{socat - TCP-LISTEN:PORT} & socat -
|
||||||
|
TCP-LISTEN:2345 & Listen on IPv4/TCP \\
|
||||||
|
\hline
|
||||||
|
\texttt{iperf3 -PROTO -p PORT} & iperf3 -4 -p 2345 & IPv4 iperf server\\
|
||||||
|
\texttt{-B IP -s} & -B 10.0.0.42 -s &\\
|
||||||
|
& iperf3 -6 -p 2345 & IPv6 iperf server\\
|
||||||
|
& -B 2001:db8:42::42 -s & \\
|
||||||
|
\hline
|
||||||
|
\texttt{iperf3 -PROTO -p PORT } & iperf3 -6 -p 2345& Connect to iperf server\\
|
||||||
|
\texttt{-O IGNORETIME -t RUNTIME} & -O 10 -t 190 &
|
||||||
|
Run for 190 seconds, \\
|
||||||
|
& & skip first 10 seconds\\
|
||||||
|
\texttt{-P PARALLEL -c IP} & -P20 -c 2001:db8:23::2a &
|
||||||
|
with 20 sessions\\
|
||||||
|
& & connecting to\\
|
||||||
|
& & 2001:db8:23::2a\\
|
||||||
|
\texttt{iperf3 -PROTO -p PORT} & & Same as above,\\
|
||||||
|
\texttt{-O IGNORETIME -t RUNTIME} & & but connect via UDP\\
|
||||||
|
\texttt{-P PARALLEL -c IP} & & \\
|
||||||
|
\texttt{-u -b0} & & \\
|
||||||
|
\hline
|
||||||
|
\end{tabular}
|
||||||
|
\end{minipage}
|
||||||
|
\caption{NAT64 verification commands}
|
||||||
|
\label{tab:nat64verification}
|
||||||
|
\end{center}
|
||||||
|
\end{table}
|
||||||
|
% ----------------------------------------------------------------------
|
||||||
|
\section{\label{design:configuration}IPv6 and IPv4 configuration}
|
||||||
|
The following sections refer to host and network configurations. In
|
||||||
|
this section we describe the IPv6 and IPv4 configurations as a basis
|
||||||
|
for the discussion.
|
||||||
|
|
||||||
|
All IPv6 addresses are from the documentation block
|
||||||
|
\textit{2001:DB8::/32}~\cite{rfc3849}. In particular the following sub
|
||||||
|
networks and IPv6 addresses are used:
|
||||||
|
\begin{table}[htbp]
|
||||||
|
\begin{center}\begin{minipage}{\textwidth}
|
||||||
|
\begin{tabular}{| c | c |}
|
||||||
|
\hline
|
||||||
|
\textbf{Address} & \textbf{Description} \\
|
||||||
|
\hline
|
||||||
|
2001:db8:42::/64 & IPv6 host network \\
|
||||||
|
\hline
|
||||||
|
2001:db8:23::/96 & IPv6 mapping to the IPv4 Internet \\
|
||||||
|
\hline
|
||||||
|
2001:db8:42::42 & IPv6 host address \\
|
||||||
|
\hline
|
||||||
|
2001:db8:42::77 & IPv6 router address \\
|
||||||
|
\hline
|
||||||
|
2001:db8:42::a00:2a & In-network IPv6 address mapped to 10.0.0.42 (p4)\\
|
||||||
|
\hline
|
||||||
|
2001:db8:23::a00:2a & IPv6 address mapped to 10.0.0.42 (tayga) \\
|
||||||
|
\hline
|
||||||
|
2001:db8:23::2a & IPv6 address mapped to 10.0.0.42 (jool)\\
|
||||||
|
\hline
|
||||||
|
\end{tabular}
|
||||||
|
\end{minipage}
|
||||||
|
\caption{IPv6 address and network overview}
|
||||||
|
\label{tab:ipv6address}
|
||||||
|
\end{center}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
We use private IPv4 addresses as specified by RFC1918~\cite{rfc1918}
|
||||||
|
from the 10.0.0.0/8 range as follows:
|
||||||
|
|
||||||
|
\begin{table}[htbp]
|
||||||
|
\begin{center}\begin{minipage}{\textwidth}
|
||||||
|
\begin{tabular}{| c | c |}
|
||||||
|
\hline
|
||||||
|
\textbf{Address} & \textbf{Description} \\
|
||||||
|
\hline
|
||||||
|
10.0.0.0/24 & IPv4 host network \\
|
||||||
|
\hline
|
||||||
|
10.0.1.0/24 & IPv4 network mapping to IPv6\\
|
||||||
|
\hline
|
||||||
|
10.0.0.77 & IPv4 router address\\
|
||||||
|
\hline
|
||||||
|
10.0.0.66 & In-network IPv4 address mapped to 2001:db8:42::42 (p4)\\
|
||||||
|
\hline
|
||||||
|
10.0.1.42 & IPv4 address mapped to 2001:db8:42::42 (tayga)\\
|
||||||
|
\hline
|
||||||
|
10.0.1.66 & IPv4 address mapped to 2001:db8:42::42 (jool)\\
|
||||||
|
\hline
|
||||||
|
\end{tabular}
|
||||||
|
\end{minipage}
|
||||||
|
\caption{IPv4 address and network overview}
|
||||||
|
\label{tab:ipv4address}
|
||||||
|
\end{center}
|
||||||
|
\end{table}
|
||||||
|
% ok
|
||||||
|
|
|
@ -3,16 +3,21 @@ FILE = Thesis
|
||||||
|
|
||||||
all: all-graphviz
|
all: all-graphviz
|
||||||
pdflatex $(FILE)
|
pdflatex $(FILE)
|
||||||
|
dot -Tpdf -o abc.pdf abc.dot
|
||||||
bibtex $(FILE)
|
bibtex $(FILE)
|
||||||
makeindex Thesis.nlo -s nomencl.ist -o Thesis.nls
|
makeindex Thesis.nlo -s nomencl.ist -o Thesis.nls
|
||||||
pdflatex $(FILE)
|
pdflatex $(FILE)
|
||||||
pdflatex $(FILE)
|
pdflatex $(FILE)
|
||||||
|
|
||||||
clean:
|
clean:
|
||||||
rm -f *.dvi *.log *.aux *.bbl *.blg *.toc *.lof *.lot *.cb *.~ *.ilg *.nlo *.nls *.out *.glo
|
rm -f *.dvi *.log *.aux *.bbl *.blg *.toc *.lof *.lot *.cb *.~ *.ilg *.nlo *.nls *.out *.glo graphviz/*.png graphiz/*.pdf
|
||||||
|
|
||||||
all-graphviz:
|
all-graphviz:
|
||||||
for dot in graphviz/*.dot; do make $${dot%%.dot}.png; done
|
#for dot in graphviz/*.dot; do make $${dot%%.dot}.png; done
|
||||||
|
for dot in graphviz/*.dot; do make $${dot%%.dot}.pdf; done
|
||||||
|
|
||||||
graphviz/%.png: graphviz/%.dot
|
graphviz/%.png: graphviz/%.dot
|
||||||
dot -Tpng < $< > $@
|
dot -Tpng < $< > $@
|
||||||
|
|
||||||
|
graphviz/%.pdf: graphviz/%.dot
|
||||||
|
dot -Tpdf < $< > $@
|
||||||
|
|
BIN
doc/Thesis.pdf
|
@ -36,6 +36,7 @@
|
||||||
\listoffigures
|
\listoffigures
|
||||||
\listoftables
|
\listoftables
|
||||||
|
|
||||||
|
\includepdf[pages=-]{declaration-of-orginality.pdf}
|
||||||
\include{Introduction}
|
\include{Introduction}
|
||||||
\include{Background}
|
\include{Background}
|
||||||
\include{Design}
|
\include{Design}
|
||||||
|
|
Before Width: | Height: | Size: 37 KiB |
Before Width: | Height: | Size: 69 KiB |
Before Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 9.4 KiB |
Before Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 8.2 KiB |
Before Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 8.8 KiB |
Before Width: | Height: | Size: 22 KiB |
Before Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 19 KiB |
Before Width: | Height: | Size: 37 KiB |
Before Width: | Height: | Size: 22 KiB |
|
@ -137,4 +137,6 @@
|
||||||
\makeatother
|
\makeatother
|
||||||
\fi
|
\fi
|
||||||
|
|
||||||
%\usepackage[pdf]{graphviz}
|
|
||||||
|
\usepackage[pdf]{graphviz}
|
||||||
|
\usepackage{pdfpages}
|
||||||
|
|