4.3 KiB
- Time table
- Topics / Tasks
- Proposal / task description
Time table
| 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 |
Topics / Tasks
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?
TODO Add initial milestones
180d plan
25w
Thesis implementation
TODO Get feature list of jool
TODO Get feature list of tayga
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
Thesis documentation
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
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).