nico
/
master-thesis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
master-thesis/doc/plan.org

8.2 KiB
Raw Blame History

Time table / log

2019-02-21 Kick-Off
Finish all admin points
Know when/how to coordinate
2019-02-21 Clarifications Ueli Maurer (Mentor)
Write mail / phone
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
Will need some switch local ip addresses
2019-03-29 Jool SIIT / range / offset support https://www.jool.mx/en/run-vanilla.html
Jool EAMT support https://www.jool.mx/en/run-eam.html
Bidirectional support
Will need IPv6 embedding suport https://tools.ietf.org/html/rfc6052
2019-04-05 NAT64 prefix based IPv6->IPv4 conversion [tayga]
Use case: IPv6 hosts send to specific /96
2019-04-19 NAT64 dynamic pool implementation: n:m ipv6 to ipv4 mapping
And n:1 stateful mappings https://www.jool.mx/en/run-nat64.html
Needs active controller
Needs timeout / leases
2019-05-10 Benmarking results between P4, Jool, Tayga
Real hardware of advantage
2019-08-01 Latest start writing documentation
2019-08-21 hand in thesis

Topics / Tasks

Admin

DONE Clarify PDF / form with Denise Spicher: free form description

TODO Create task description to be handed in mystudies

DONE Create list of tasks / initial brainstorming

TODO Get OK from Ueli Maurer that thesis is valid in Information Security Area

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

DONE Setup test VM for P4: 2a0a:e5c0:2:12:400:f0ff:fea9:c3e3

DONE Get feature list of jool

DONE Get feature list of tayga

TODO Setup P4 base / structure

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
See time table above

Additional features queue (to be discussed)

TODO Offset based translation (v4->v6) -> same as range (?)

**

Thesis documentation

Motivation

TBD

Translation mechanisms

  • v4 to v6 / vice versa
  • Stateful / stateless
  • static / dynamic
Explicit Address Mappings Table (EAMT)

Range based mapping tables See https://www.jool.mx/en/eamt.html, https://tools.ietf.org/html/rfc7757

Current state of the art tayga/jool

TBD

Tayga
  • Single threaded
  • Multi threaded work started due to initiative of ungleich / Chrisrock [IPv6.chat]
Jool
  • EAMT bidirectional only (!)

IPtables interaction

```

user@T:~# # Create a Jool iptables instance named "example." user@T:~# # Also, establish that the IPv6 representation of any IPv4 address should be user@T:~# # `2001:db8::<IPv4 address>`. (See sections below for examples.) user@T:~# jool_siit instance add "example" –iptables –pool6 2001:db8::/96 user@T:~# user@T:~# # Tell iptables which traffic should be handled by our newly-created instance: user@T:~# user@T:~# # IPv6: only packets from 2001:db8::198.51.100.8/125 to 2001:db8::192.0.2 user@T:~# ip6tables -t mangle -A PREROUTING \ > -s 2001:db8::198.51.100.8/125 -d 2001:db8::192.0.2.0/120 \ > -j JOOL_SIIT –instance "example" user@T:~# # IPv4: Only packets from 192.0.2 to 198.51.100.8/29 user@T:~# iptables -t mangle -A PREROUTING \ > -s 192.0.2.0/24 -d 198.51.100.8/29 \ > -j JOOL_SIIT –instance "example" ``` 5656

Cisco (?)

P4 based implementation

TBD

Requirements

Performance comparison

Feature/Functionality difference / overview

Not included
  • DNS64 - has already been solved in a different domain

References / Follow up

RFC 6052: https://tools.ietf.org/html/rfc6052 IPv6 Addressing of IPv4/IPv6 Translators
RFC 6586 for deployment experiences using Stateful NAT64.
RFC 7757 Explicit Address Mappings for Stateless IP/ICMP Translation
EAMT/Jool: https://www.jool.mx/en/eamt.html

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).