Finish Design/stateful NAT64
This commit is contained in:
parent
f9422a0e38
commit
71e0e61248
2 changed files with 27 additions and 11 deletions
|
@ -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
|
||||
|
|
BIN
doc/Thesis.pdf
BIN
doc/Thesis.pdf
Binary file not shown.
Loading…
Reference in a new issue