First brainstorm of tasks

This commit is contained in:
Nico Schottelius 2019-02-20 13:01:57 +01:00
parent b02baff565
commit e1a6e8c6ed

View file

@ -3,6 +3,75 @@
| 2019-02-22 | have all papers handed in | | 2019-02-22 | have all papers handed in |
| 2019-08-21 | hand in | | 2019-08-21 | hand in |
* Topics / Tasks * Topics / Tasks
** TODO Create task description to be handed in mystudies ** Admin
** TODO Get OK from Ueli Maurer that thesis is valid in Information Security Area *** 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?
** Thesis implementation
*** TODO Get feature list of jool
*** TODO Get feature list of tayga
*** TODO Setup P4 base
*** DONE Setup test VM: 2a0a:e5c0:2:12:400:f0ff:fea9:c3e3
** Thesis documentation
* 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).