|
|
|
@ -231,17 +231,33 @@ entries for translating from IPv4 to IPv6. Our P4/BMV2 offers the
|
|
|
|
|
highest degree of flexibility, as it provides support for invidual
|
|
|
|
|
entries based on table entries and LPM table entries.
|
|
|
|
|
% ----------------------------------------------------------------------
|
|
|
|
|
\section{\label{design:statefulnat64}Stateful NAT64 - FIXME: write}
|
|
|
|
|
- controller selects "outgoing" IPv4 address range => base for sessions
|
|
|
|
|
- IPv4 addresses can be "random" (in our test case), but need
|
|
|
|
|
to be unique
|
|
|
|
|
- switch does not need to know about the "range", only about
|
|
|
|
|
sessions
|
|
|
|
|
- on session create, controller selects "random" ip (ring?)
|
|
|
|
|
- on session create, controller selects "random port" (next in range?)
|
|
|
|
|
- on session create controller adds choice into 2 tables:
|
|
|
|
|
incoming, outgoing
|
|
|
|
|
|
|
|
|
|
\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
|
|
|
|
|
\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}BMV2}
|
|
|
|
|
Development of the thesis took place on a software emulated switch
|
|
|
|
|