|
|
|
|
@ -2,141 +2,16 @@
|
|
|
|
|
%** Design.tex: How was the problem attacked, what was the design |
|
|
|
|
% the architecture |
|
|
|
|
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} |
|
|
|
|
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} |
|
|
|
|
\section{\label{design:nat64}P4/NAT64} |
|
|
|
|
\begin{figure}[h] |
|
|
|
|
\includegraphics[scale=0.4]{switchdesign} |
|
|
|
|
\centering |
|
|
|
|
@ -189,75 +64,15 @@ segment.
|
|
|
|
|
\caption{In-network NAT64 translation} |
|
|
|
|
\label{fig:v6v4mixed} |
|
|
|
|
\end{figure} |
|
|
|
|
|
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\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: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:bmv2}P4/BMV2} |
|
|
|
|
\begin{figure}[h] |
|
|
|
|
@ -391,4 +206,203 @@ It is notable that
|
|
|
|
|
not the full headers are used, but only a ``pseudo header'' (compare figures |
|
|
|
|
\ref{fig:ipv6pseudoheader} and \ref{fig:ipv4pseudoheader}). |
|
|
|
|
% 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 |
|
|
|
|
|
Nico Schottelius
3 years ago
