2019-02-20 11:37:39 +00:00
|
|
|
* Time table
|
2019-02-20 12:31:21 +00:00
|
|
|
| 2019-02-22 | kick-off |
|
|
|
|
|
| 2019-02-22 | have all papers handed in |
|
|
|
|
|
| 2019-02-22 | Have rough definition of tasks |
|
|
|
|
|
| 2019-03-01 | Feature list / priority list / roadmap clear |
|
|
|
|
|
| 2019-03-08 | NAT46 1:1 table TCP/UDP working |
|
|
|
|
|
| 2019-03-15 | NAT46 1:1 table ICMP, ICMPv6 working |
|
|
|
|
|
| | |
|
|
|
|
|
| 2019-08-05 | Latest start writing documentation |
|
|
|
|
|
| 2019-08-21 | hand in thesis |
|
2019-02-20 11:37:39 +00:00
|
|
|
* Topics / Tasks
|
2019-02-20 12:01:57 +00:00
|
|
|
** Admin
|
|
|
|
|
*** TODO Create task description to be handed in mystudies
|
|
|
|
|
*** TODO Get OK from Ueli Maurer that thesis is valid in Information Security Area
|
|
|
|
|
*** TODO Create list of tasks / initial brainstorming
|
|
|
|
|
*** TODO Find out how-when-whom-where to meet / define schedule
|
|
|
|
|
*** TODO Latex and/or org-mode for the thesis?
|
2019-02-20 12:31:21 +00:00
|
|
|
*** TODO Add initial milestones
|
|
|
|
|
**** 180d plan
|
|
|
|
|
**** 25w
|
2019-02-20 12:01:57 +00:00
|
|
|
** Thesis implementation
|
|
|
|
|
*** TODO Get feature list of jool
|
|
|
|
|
*** TODO Get feature list of tayga
|
2019-02-20 12:31:21 +00:00
|
|
|
*** TODO Setup P4 base / structure
|
|
|
|
|
*** DONE Setup test VM for P4: 2a0a:e5c0:2:12:400:f0ff:fea9:c3e3
|
|
|
|
|
*** TODO Setup test VM [dual stack] for Jool:
|
|
|
|
|
*** TODO Setup test VM [dual stack] for tayga:
|
|
|
|
|
*** NAT64/NAT46 Features in jool and tayga
|
|
|
|
|
**** TODO Static 1:1 NAT46: translate from IPv4 to IPv6 with a table
|
|
|
|
|
***** TCP, UDP
|
|
|
|
|
***** ICMP <-> ICMPv6
|
|
|
|
|
**** TODO Stateless Prefix based NAT64: IPv6 to IPv4 translation prefix based
|
|
|
|
|
***** Allows IPv6 hosts to reach the IPv4 Internet
|
2019-02-20 12:01:57 +00:00
|
|
|
** Thesis documentation
|
2019-02-20 12:31:21 +00:00
|
|
|
*** Motivation
|
|
|
|
|
TBD
|
|
|
|
|
*** Current state of the art tayga/jool
|
|
|
|
|
TBD
|
|
|
|
|
*** P4 based implementation
|
|
|
|
|
TBD
|
|
|
|
|
*** Performance comparison
|
|
|
|
|
*** Feature/Functionality difference / overview
|
|
|
|
|
**** Not included
|
|
|
|
|
- DNS64 - has already been solved in a different domain
|
|
|
|
|
*** References / Follow up
|
|
|
|
|
**** RFC 6052
|
2019-02-20 12:01:57 +00:00
|
|
|
* Proposal / task description
|
|
|
|
|
** Task description for mystudies
|
|
|
|
|
*** High speed NAT64 with P4
|
|
|
|
|
Currently there are two main open source NAT64 solution available:
|
|
|
|
|
tayga and jool. The former is a single threaded, cpu bound user
|
|
|
|
|
space solution, the latter a custom Linux kernel module.
|
|
|
|
|
|
|
|
|
|
This thesis challenges this status quo by developing a P4 based
|
|
|
|
|
solution supporting all features of jool/tayga and comparing the
|
|
|
|
|
performance, security and adaptivity of the solutions.
|
|
|
|
|
** Original ideas
|
|
|
|
|
Proposal 1: Automating NAT64 with P4
|
|
|
|
|
|
|
|
|
|
In IPv6 only data centers IPv4 connectivity is still a business
|
|
|
|
|
requirement. Current state of the art methods include layer 7 proxying
|
|
|
|
|
or static assignments. both featuring static assignments.
|
|
|
|
|
|
|
|
|
|
A flexible, dynamic assignment of IPv4 addresses to IPv6 hosts, similar
|
|
|
|
|
to lease times in DHCPv4 and prefix delegations in DHCPv6 could reduce
|
|
|
|
|
the pressure on IPv4 addresses.
|
|
|
|
|
|
|
|
|
|
I would suggest the develop of a new protocol (likely UDP embedded) that
|
|
|
|
|
allows hosts to request on-network support for IPv4 addresses. As IPv4
|
|
|
|
|
addresses have to be treated as "expensive", an accounting metric has to
|
|
|
|
|
be introduced. While in the business world this is usually related to
|
|
|
|
|
money, in the network world IPv4 users could be paying the network by
|
|
|
|
|
(reduced) bandwidth.
|
|
|
|
|
|
|
|
|
|
If such a metric existed, devices attached to the network could also try
|
|
|
|
|
to negotiate and wait for using IPv4, when the price / penality for IPv4
|
|
|
|
|
is low (this might be very suitable for mail exchangers for instance).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Proposal 2: High speed NAT64 with P4
|
|
|
|
|
|
|
|
|
|
Currently there are two main open source NAT64 solution available:
|
|
|
|
|
tayga[0] and jool[1]. The former is a single threaded, cpu bound user
|
|
|
|
|
space solution, the latter a custom Linux kernel module.
|
|
|
|
|
|
|
|
|
|
I would like to challenge this status quo and develop a P4 based
|
|
|
|
|
solution supporting all features of jool/tayga and comparing the
|
|
|
|
|
performance and adaptivity of the solutions.
|
|
|
|
|
|
|
|
|
|
[0] http://www.litech.org/tayga/
|
|
|
|
|
[1] https://www.jool.mx/en/index.html
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Proposal 3: Challenging the status quo with IPv10
|
|
|
|
|
|
|
|
|
|
The de facto standard in networking is to treat IPv4
|
|
|
|
|
and IPv6 as "impossible to combine". This proposal is
|
|
|
|
|
to challenge this notion with three different methods:
|
|
|
|
|
|
|
|
|
|
- Extensions to IPv4 to request remote IPv6 transport
|
|
|
|
|
- Extensions to IPv6 to request remote IPv4 transport
|
|
|
|
|
- Support in network equipment to handle the extensions
|
|
|
|
|
|
|
|
|
|
As the IPv4 header does not allow embedding IPv6 addresses due to size
|
|
|
|
|
limitations, embedding the destination address in a secondary header
|
|
|
|
|
might be necessary (possibly encapsulated in UDP).
|
