First brainstorm of tasks
This commit is contained in:
parent
b02baff565
commit
e1a6e8c6ed
1 changed files with 72 additions and 3 deletions
75
doc/plan.org
75
doc/plan.org
|
@ -3,6 +3,75 @@
|
|||
| 2019-02-22 | have all papers handed in |
|
||||
| 2019-08-21 | hand in |
|
||||
* Topics / Tasks
|
||||
** TODO Create task description to be handed in mystudies
|
||||
** TODO Get OK from Ueli Maurer that thesis is valid in Information Security Area
|
||||
**
|
||||
** 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?
|
||||
** 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).
|
||||
|
|
Loading…
Reference in a new issue