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
|
highest degree of flexibility, as it provides support for invidual
|
||||||
entries based on table entries and LPM table entries.
|
entries based on table entries and LPM table entries.
|
||||||
% ----------------------------------------------------------------------
|
% ----------------------------------------------------------------------
|
||||||
\section{\label{design:statefulnat64}Stateful NAT64 - FIXME: write}
|
\section{\label{design:statefulnat64}Stateful NAT64}
|
||||||
- controller selects "outgoing" IPv4 address range => base for sessions
|
Similar to stateless NAT64, the design of stateful NAT64 depends on
|
||||||
- IPv4 addresses can be "random" (in our test case), but need
|
the features of the invidual implementation. As pointed out in section
|
||||||
to be unique
|
\ref{background:transition:statefulnat64}, stateful NAT64 is very
|
||||||
- switch does not need to know about the "range", only about
|
similar to stateless NAT64, with the main difference being an
|
||||||
sessions
|
additional stateful table that helps to create 1:n mappings.
|
||||||
- on session create, controller selects "random" ip (ring?)
|
We use different approaches within the implementations
|
||||||
- on session create, controller selects "random port" (next in range?)
|
to solve this problem:
|
||||||
- on session create controller adds choice into 2 tables:
|
\begin{itemize}
|
||||||
incoming, outgoing
|
\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}
|
\section{\label{Design:BMV2}BMV2}
|
||||||
Development of the thesis took place on a software emulated switch
|
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