IPv4 - einfach mal abschalten

oder

NAT64 mit dem Raspberry Pi


Vorwort


Es gibt viele Wege IPv4 Lebewohl zu sagen. Einer der einfachsten ist es, sich an einem Netzwerk anzumelden, in dem kein IPv4 mehr vorhanden ist.Das geht beispielsweise bei einigen Mobilfunkanbietern in den USA aber auch beim WLAN im Einzugsbereich des LRZ. (ssid: eduroam-IPv6only)

Alternativ kann man sich durch Nutzung von öffentlichen DNS64/NAT64-Gateways in die neue Welt versetzen.

z.B.
http://ipv6.lt/nat64_en.php
nameserver 2001:778::37

http://www.trex.fi/2011/dns64.html
nameserver 2001:67c:2b0::4
nameserver 2001:67c:2b0::6

http://aa.net.uk/kb-broadband-ipv6-nat64.html

nameserver 2001:8b0:6464::1
nameserver 2001:8b0:6464::2


Eine Ergänzung vom 24.August 2016

https://go6lab.si/current-ipv6-tests/nat64dns64-public-test/

nameserver 2001:67c:27e4:15::6411

nameserver 2001:67c:27e4::64

nameserver 2001:67c:27e4:15::64

nameserver 2001:67c:27e4::60


Ende der Ergänzung vom 24.August 2016.



Wenn man seine Daten nicht kreuz und quer durch die Welt schicken will, sollte man DNS64/NAT64 selber machen. (sofern es der ISP noch nicht anbietet).
Eine ausführliche Beschreibung von NAT64 und DNS64 findet man auch bei Apple, allerdings mit einem abweichenden Testszenario.


Mein Testfeld ist einfach beschrieben: Sowohl PC als auch der Raspberry Pi, der als Sondergateway dient, sind direkt an der Fritzbox angeschlossen. NAT64 besteht eigentlich aus einem stateless NAT64(tayga) und einem stateful NAT(4). Um doppeltes NAT bei IPv4 zu vermeiden, überlasse ich das stateful NAT(4) allein der Fritzbox.

Insgesamt entstehen vier verschiedene Adressbereiche bzw Subnetze.

64:ff9b::/96 - der reservierte Adressbereich für NAT64

2003:63:2444:b200:ba27:ebff:feb6:f293/64 - der vom ISP bzw. von der Fritzbox verteilte Adressbereich, (sollte vielleicht später durch die Dokumentationsadressen 2001:db8:: ersetzt werden)

192.168.178.1/24 - der üblicherweise bei der Fritzbox verwendete Adressbereich nach RCF1918

192.168.178.64/26 - ein Subnetz davon, welches via proxy arp zu tayga geleitet wird.


Zu NAT64 gehört in der Regel auch DNS64. Hier spare ich mich mir die eigene DNS-Konfiguration und verweise auf google.

Vorbereitung


Lauffähiger Raspberry Pi mit Opensuse Tumbleweed (natürlich geht auch jedes andere Linux) mit radvd, ip6tables, NetworkManager und in meinem Fall manuell compiliertem tayga.

Durchführung

Verbreiten der Route 64:ff9b::/96  via radvd mit folgender radvd.conf:

interface eth0
{
        AdvSendAdvert on;

        # life time zero means we don't actually advertise a
        # router but only our ULA address. Remove if you want this
        # host to be advertised as router.
        AdvDefaultLifetime 0;

        route 64:ff9b::/96
        {
        };
};



Danach folgende Systemaufrufe:

sysctl net.ipv6.conf.all.forwarding=1
sysctl net.ipv4.conf.all.forwarding=1 
systemctl start radvd





Damit der Raspberry Pi nicht versehentlich seine von ihm propagierte Route lernt, ist folgender ip6tables-Eintrag notwendig.

ip6tables -A INPUT -s fe80::ba27:ebff:feb6:f293/128 -d ff02::1/128 -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j DROP
ip6tables -A FORWARD -s fe80::ba27:ebff:feb6:f293/128 -d ff02::1/128 -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j DROP


(anderenfalls müsste man ständig löschen: ip -6 route del 64:ff9b::/96 via fe80::ba27:ebff:feb6:f293 dev eth0 )

Die erste Adresse ist die Link-Local-Adresse des Ethernetinterfaces des Raspberry Pi, die zweite die Multicastadresse zum Erlernen der Route. Die Routen von der Fritzbox hingegen sollen noch gelernt werden. Deshalb habe ich das Akzeptieren von Router Advertisements nicht gänzlich abgeschaltet.

Leider ist auf dem Linux-PC auch eine Änderung notwendig.

sysctl net.ipv6.conf.eth0.accept_ra_rt_info_max_plen=128

Sonst lernt der PC nur die Defaultroute von der Fritzbox. (Windows 7 war da nicht so zimperlich)


Nun zum eigentlich NAT64-Teil, der Einrichtung von Tayga. Hierzu die Daten aus der Konfigurationsdatei /usr/local/etc/tayga.conf


tun-device nat64

ipv4-addr 192.168.178.64

prefix 64:ff9b::/96

dynamic-pool 192.168.178.64/26

data-dir /var/db/tayga

ipv6-addr 2003:63:2444:b200:ba27:ebff:feb6:f293


Kurz zu Erläuterung:

nat64 ist das Interface zwischen Kernel und Tayga. Die Adressübersetzung findet im "Userspace" von Tayga statt.
64:ff9b::/96 ist das IPv6-Präfix, in das die weltweiten IPv4-Adressen hinein gemappt werden
192.168.178.64/26 ist das Präfix, welches Tayga ausgehend nutzt, Tayga reserviert für jeden IPv6-Host im lokalen Netz eine Adresse aus diesem Pool
2003:63:2444:b200:ba27:ebff:feb6:f293 braucht Tayga der Vollständigkeit halber.


Damit nicht zweimal NAT bei IPv4 betrieben wird, eignet sich der Raspberry-Pi bzw. Tayga den Adressbereich via proxy arp an.

sysctl net.ipv4.conf.eth0.proxy_arp=1


Der große Moment:

tayga --mktun


ip addr add 192.168.178.64/26 dev nat64
ip -6 route add 64:ff9b::/96 dev nat64
ip -6 addr add 2003:63:2444:b200:ba27:ebff:feb6:f293 dev nat64
ip link set nat64 up

tayga -d
starting TAYGA 0.9.2
Using tun device nat64 with MTU 1500
TAYGA's IPv4 address: 192.168.178.64
TAYGA's IPv6 address: 2003:63:2444:b200:ba27:ebff:feb6:f293
NAT64 prefix: 64:ff9b::/96
Note: traffic between IPv6 hosts and private IPv4 addresses (i.e. to/from 64:ff9b::10.0.0.0/104, 64:ff9b::192.168.0.0/112, etc) will be dropped.  Use a translation prefix within your organization's IPv6 address space instead of 64:ff9b::/96 if you need your IPv6 hosts to communicate with private IPv4 addresses.
Dynamic pool: 192.168.178.64/26
Loaded 1 dynamic map from /var/db/tayga/dynamic.map
reactivated dormant pool address 192.168.178.84 (2003:63:2444:b200:beae:c5ff:feb5:2088)


Auf dem PC in der Zwischenzeit:

/etc/resolv.conf

nameserver 2001:4860:4860::64




traceroute6 www.tagesschau.de
traceroute to www.tagesschau.de (64:ff9b::17d9:1d3), 30 hops max, 80 byte packets
 1  p200300632444B200BA27EBFFFEB6F293.dip0.t-ipconnect.de (2003:63:2444:b200:ba27:ebff:feb6:f293)  1.100 ms  1.612 ms  1.578 ms
 2  p200300632444B200BA27EBFFFEB6F293.dip0.t-ipconnect.de (2003:63:2444:b200:ba27:ebff:feb6:f293)  1.905 ms  1.873 ms  1.837 ms
 3  p200300632444B200BA27EBFFFEB6F293.dip0.t-ipconnect.de (2003:63:2444:b200:ba27:ebff:feb6:f293)  3.171 ms  3.407 ms  3.387 ms
 4  * * *
 5  64:ff9b::57ba:e003 (64:ff9b::57ba:e003)  19.781 ms  20.444 ms  22.221 ms
 6  64:ff9b::57ba:c29e (64:ff9b::57ba:c29e)  26.469 ms  25.917 ms  25.603 ms
 7  64:ff9b::3e9a:ebe (64:ff9b::3e9a:ebe)  28.083 ms  28.622 ms  28.693 ms
 8  * * *
 9  64:ff9b::81fa:6f8 (64:ff9b::81fa:6f8)  30.481 ms  24.244 ms  25.483 ms
10  64:ff9b::81fa:3b3 (64:ff9b::81fa:3b3)  39.531 ms  32.221 ms  33.903 ms
11  * * *
12  * * *
13  64:ff9b::17d9:1d3 (64:ff9b::17d9:1d3)  33.894 ms  34.317 ms  34.853 ms



ping -6  www.tagesschau.de
PING www.tagesschau.de(64:ff9b::17d9:1d3 (64:ff9b::17d9:1d3)) 56 data bytes
64 bytes from 64:ff9b::17d9:1d3 (64:ff9b::17d9:1d3): icmp_seq=1 ttl=55 time=30.8 ms
64 bytes from 64:ff9b::17d9:1d3 (64:ff9b::17d9:1d3): icmp_seq=2 ttl=55 time=31.6 ms
64 bytes from 64:ff9b::17d9:1d3 (64:ff9b::17d9:1d3): icmp_seq=3 ttl=55 time=30.1 ms
^C
--- www.tagesschau.de ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 30.109/30.869/31.632/0.638 ms



Nachwort



Man sollte keine großen Wunder erwarten. Diese Methode stellt  eher einen schnellen Hack dar als eine solide Netzwerkkonfiguration. Ich empfehle keine Nachahmung außerhalb von privaten Anschlüssen oder in extra als (Netz)Labor ausgewiesenen Räumen.

Diese Anleitung entstand auf Anregung dieses Videos vom Meeting der RIPE und der Ankündigung Googles neuer public DNS64-Resolver zur gleichen Zeit.









11.Juni 2016