187 lines
8.8 KiB
Org Mode
187 lines
8.8 KiB
Org Mode
* Time table / log
|
|
| When? | What? | Notes |
|
|
| 2019-02-21 | Kick-Off | x |
|
|
| | Finish all admin points | x |
|
|
| | Know when/how to coordinate | x |
|
|
| 2019-02-21 | Clarifications Ueli Maurer (Mentor) | x |
|
|
| | Write mail / phone | x |
|
|
| 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
|
|
***** TODO TCP
|
|
***** TODO UDP
|
|
***** TODO 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
|
|
**** Static mappings
|
|
- need table
|
|
- need tcp & udp translation
|
|
|
|
**** 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.
|
|
|
|
- Milestone 1: Stateless NAT64/NAT46 translations in P4
|
|
- Milestone 2: Stateful (dynamic) NAT64/NAT46 translations
|
|
- Milestone 3: Hardware adaption
|
|
|
|
|
|
** 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).
|