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-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).
|
||||||
|
|
Loading…
Reference in a new issue