2001:7b8:3cd:200::1
2001:7b8:3cd:200::1 - was soll das sein? Es ist eine IPv6 Adresse! Und zwar nur eine meiner gewaltigen 1 208 925 819 614 629 174 706 176 (2^80) statischen IP Adressen aus dem neuen Internet der neuen Generation.
Lange hat mich IPv6 überhaupt nicht interessiert aber im Jänner hab ich es dann doch gewagt und mir einen Tunnel bei http://www.sixxs.net bestellt.
Nach der Überprüfung meiner Daten war der Tunnel sofort eingerichtet. Zum Glück habe ich ebenfalls eine statische IPv4 Adresse, so kann ich bequem das Protokoll "6in4" (IP Protokoll 41) verwenden und muss nicht lästige Lösungen zurückgreifen die meine IP Adresse überwachen und den Tunnel umschreiben. Weiters hatte ich das Glück, dass ich es auf Anhieb geschafft habe bei meinem Speedtouch 546i das IP Protokoll 41 weiterzuleiten. So brauchte ich mich auch nicht mit irgendwelchen "windigen" UDP-Tunnel-"Lösungen" herumschlagen. Meine Installation beschreibe ich in diesem Artikel
Konfiguration Speedtouch für IPv6
Die Konfiguration des ST hatte ich auf Anhieb geschafft:
:nat tmpladd group=wan type=nat outside_addr=0.0.0.1 inside_addr=10.7.99.10 protocol=41 mode=inbound
Damit wird das Protokoll von der externen IP (0.0.0.1) an die interne IP 10.7.99.10 geNATet.
Die Maplist am Speedtouch sieht daraufhin so aus:
:nat maplist expand=enabled
[...]
34 NAT Internet 193.154.229.55 10.7.99.10 0
Access List................... 10.7.99.10
Foreign Address............... any
Protocol...................... 6to4
Flags......................... Instance
Weight........................ 10
Description................... Inbound Two-way NAT
Creator Data.................. 0
[...]
Am besten kontrolliert man das indem man tcpdump auf 10.7.99.10 verwendet:
tcpdump -i vlan3 'proto 41'
Auf einem anderen Rechner im Internet generiert man ein passendes Paket:
hping2 -0 --ipproto 41 -E /etc/apt/sources.list -d 5 gate.nobaq.net
Aber Achtung, unbedingt eine Länge und Daten angeben sonst kommen die Pakete nicht durch und werden mit folgender Meldung vom ST verworfen:
IDS proto parser : ip zero payload (1 of 61) : 62.99.247.88 193.154.229.55 0020 41
(siehe Post von mir: http://www.speedtouchforum.de/viewtopic.php?t=2617)
Konfguration Tunnel auf Debian
Nun kann man am Debianrechner den Tunnel einrichten. Alle relevanten Daten erhält man in "home"-Bereich von sixxs. Meine /etc/networking/interfaces sieht so aus:
iface sixxs inet6 v4tunnel
address 2001:7b8:2ff:196::2
netmask 64
local 10.7.99.10
endpoint 193.109.122.244
ttl 64
up ip link set mtu 1280 dev sixxs
up ip route add default via 2001:7b8:2ff:196::1 dev sixxs
Achtung! "local" sollte (muss aber nicht) angegeben werden, denn sonst werden dem Interface automatisch alle IPv4 Adressen als linklokale IPv6 Adressen zugewiesen was ich als lästig empfinde. Das ist auch in der Anleitung bei Sixxs nicht beschrieben.
Test
Und schon kann der Test losgehen:
# ping6 noc.sixxs.net -n PING noc.sixxs.net(2001:838:1:1:210:dcff:fe20:7c7c) 56 data bytes 64 bytes from 2001:838:1:1:210:dcff:fe20:7c7c: icmp_seq=1 ttl=58 time=47.8 ms 64 bytes from 2001:838:1:1:210:dcff:fe20:7c7c: icmp_seq=2 ttl=58 time=47.3 ms 64 bytes from 2001:838:1:1:210:dcff:fe20:7c7c: icmp_seq=3 ttl=58 time=47.9 ms --- noc.sixxs.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2007ms rtt min/avg/max/mdev = 47.379/47.736/47.947/0.310 ms # ping6 www.kame.net -n PING www.kame.net(2001:200:0:8002:203:47ff:fea5:3085) 56 data bytes 64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: icmp_seq=1 ttl=47 time=337 ms 64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: icmp_seq=2 ttl=47 time=337 ms 64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: icmp_seq=3 ttl=47 time=321 ms --- www.kame.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 321.493/331.911/337.180/7.366 ms
Juhuu, die Verbindung steht! :-)
Das Subnet
Wo kommt jetzt aber 2001:7b8:3cd:200::1 her? Nach einer Woche Wartezeit (in der ich meinen Tunnel 24*7 Stunden aufrecht erhalten musste) hat mir sixxs dann ein ganzes /48 Netz durchgeschaltet. Beeindruckend, jetzt habe ich mehr statische IP Adressen zu Verfügung als das ganze IPv4 Internet!
Als eigenes Subnet habe ich nun bekommen: 2001:7b8:3cd::/48. Meine Tunnel IP Adresse werde ich nur für den Tunnel verwenden und keine Services darauf lassen, ich hab ja jetzt ein ganzes Subnet, das mir sixxs durch meinen Tunnel routet.
Als erstes erweitere ich nun in /etc/network/interfaces den Eintrag für sixxs:
iface sixxs inet6 v4tunnel
address 2001:7b8:2ff:196::2
netmask 64
# local 193.154.229.55
local 10.7.99.10
endpoint 193.109.122.244
ttl 64
up ip link set mtu 1280 dev sixxs
up ip route add default via 2001:7b8:2ff:196::1 dev sixxs
up ip route add blackhole 2001:7b8:3cd::/48 dev lo metric 65535
down ip route del blackhole 2001:7b8:3cd::/48 dev lo
Die Einträge sorgen dafür, dass mein komplettes Subnet nach /dev/null geroutet wird. Das wird gebraucht wenn von aussen jemand ein Subnet von mir erreichen will dass es bei mir nicht gibt. Normalerweise würde das Paket durch den Tunnel zurückgeschickt werden, dann wieder zu mir unsw. Es tritt ein ping-pong Effekt auf (Die Pakete werden dann erst verworfen wenn die TTL abgelauten ist). Um das zu vermeiden wird eben diese Blackhole geschaffen.
Als nächstes möchte ich die neuen Adressen gerne verwenden. Aufgrund von VServern habe ich sowieso einige IPv4 Aliase. Für alle VServer, die von aussen erreichbar sein sollen hab ich nun die entsprechenden IPv6 Adressen zugewiesen. Weiters habe ich als Subnet 2001:7b8:3cd:200::/64 auserchoren - zur "Kompatibilität" zu 192.168.200.0/24. Dieses Netz befindet sich jetzt auf vlan2, d.h. es muss eine route-Anweisung hinzugefügt werden, der dieses Netz nach vlan2 routet. Der komplette Eintrag für vlan2 in /etc/network/interfaces sieht entsprechend so aus:
iface vlan2 inet static
vlan-raw-device eth0
address 192.168.200.1
netmask 255.255.255.0
up ip route add 2001:7b8:3cd:200::/64 dev vlan2
down ip route del 2001:7b8:3cd:200::/64 dev vlan2
up ip addr add 192.168.200.121/32 scope global dev vlan2
up ip addr add 192.168.200.117/32 scope global dev vlan2
up ip addr add 192.168.200.116/32 scope global dev vlan2
up ip addr add 192.168.200.114/32 scope global dev vlan2
up ip addr add 192.168.200.113/32 scope global dev vlan2
up ip addr add 192.168.200.112/32 scope global dev vlan2
up ip -6 addr add 2001:7b8:3cd:200::1/128 scope global dev vlan2
up ip -6 addr add 2001:7b8:3cd:200::113/128 scope global dev vlan2
up ip -6 addr add 2001:7b8:3cd:200::116/128 scope global dev vlan2
up ip -6 addr add 2001:7b8:3cd:200::117/128 scope global dev vlan2
up ip -6 addr add 2001:7b8:3cd:200::121/128 scope global dev vlan2
down ip addr del 192.168.200.117/32 scope global dev vlan2
down ip addr del 192.168.200.116/32 scope global dev vlan2
down ip addr del 192.168.200.114/32 scope global dev vlan2
down ip addr del 192.168.200.113/32 scope global dev vlan2
down ip addr del 192.168.200.112/32 scope global dev vlan2
down ip addr del 192.168.200.121/32 scope global dev vlan2
down ip -6 addr del 2001:7b8:3cd:200::1/128 scope global dev vlan2
down ip -6 addr del 2001:7b8:3cd:200::113/128 scope global dev vlan2
down ip -6 addr del 2001:7b8:3cd:200::116/128 scope global dev vlan2
down ip -6 addr del 2001:7b8:3cd:200::117/128 scope global dev vlan2
down ip -6 addr del 2001:7b8:3cd:200::121/128 scope global dev vlan2
Weiters muss das Routing eingeschaltet werden. Das erledigt bei mir folgender Eintrag in der /etc/sysctl.conf:
net.ipv6.conf.default.forwarding=1
Am besten den Rechner neu starten.
Ein Test von aussen mit http://www.berkom.blazing.de/tools/traceroute.cgi zeigt den Erfolg:
1 eileen.bbg.blazing.de (2a01:30:1000::1) 1.517 ms 1.347 ms 0.986 ms 2 bbcr02-fra4-decixii-a.six-de.net (2001:4b88:0:4:15:2::) 17.364 ms 33.952 ms 39.842 ms 3 bbcr01-ams-a26a.six-de.net (2001:4b88:0:4:2:1:11:10) 44.947 ms 60.963 ms 75.813 ms 4 amsix-501.xe-0-0-0.jun1.kelvin.network.bit.nl (2001:7f8:1::a501:2859:2) 47.454 ms 47.911 ms 33.961 ms 5 700.xe-0-0-0.jun1.galilei.network.bit.nl (2001:7b8:0:2bc::2) 68.064 ms 87.636 ms 68.359 ms 6 jun1.kelvin.ipv6.network.bit.nl (2001:7b8::290:6900:1cc6:d800) 54.443 ms 55.959 ms 48.701 ms 7 nlede01.sixxs.net (2001:7b8:3:4f:202:b3ff:fe46:bec) 35.709 ms 67.959 ms 40.831 ms 8 nobaq.ip6.nobaq.net (2001:7b8:3cd:200::121) 103.558 ms * 72.143 ms
Über die Aufteilung des Netzes
Hier ein paar Worte über die Aufteilung meines Subnets da ich mir anfangs über die Konventionen auch nicht ganz im Klaren war. Eine IPv6 Adresse hat bekanntlich 128 Bit, ich bekomme ein /48er Netz zugewiesen, d.h. 48 Bits dieser Adresse dienen dem Routing vom Internet zu mir und ich kann davon 80 Bits verwenden.
Wie sieht es aber nun mit der Aufteilung von Hostteil/Netzteil aus? Prinzipiell ist alles möglich, z.B. auch eine /126er Adresse was bedeuten würde: 126 Bits zeigen das Netzwerk an und nur 2 Bit die Hosts, d.h. ich könnte in meinem Netz nur 2^2=4 Computer verwenden. Es hat sich jedoch die Konvention (vor allem auch in Bezug auf Autokonfiguration von IPv6) eingebürgert, dass immer 64 Bits Hostteil sein sollen und 64 Bits Netzteil. Das bedeutet dass mir von den 80 Bits "nur" mehr 64 Bits für meine Subnetze übrig bleiben. D.h. ich könnte dann immer noch 2^16=65536 verschiedene Netzwerke mit jeweils 18 446 744 073 709 551 616 Hosts adressieren.
Nachdem ich vermutlich sowieso nur eine Routingebene bei mir haben werde habe ich mein /64er Netz durch 200h bestimmt (also die 16 Bits die mir bleiben sind 200hex).
WindowsXP Client im Netz
WindowsXP ins IPv6 zu bekommen ist relativ einfach. In den Netzwerkeinstellungen muss man einfach auf "Protokoll hinzufügen" klicken und das IPv6 Protokoll hinzufügen.
Durch die IPv6 Autokonfiguration sind prinzipiell keine weiteren Schritte mehr nötig - Windows- und Linuxrechner können bereits miteinander kommunizieren (aber nur link-local!).
Damit Windows auch ins Internet kommt (mit IPv6) muss auf dem Router (Linuxmaschine) ein Routing Advertising Daemon installiert werden: radvd. Auch das ist ganz schnell erledigt:
aptitude install radvd
In der /etc/radvd.conf steht bei mir nicht viel mehr als:
interface vlan2
{
AdvSendAdvert on;
prefix 2001:7b8:3cd:200::/64
{
};
};
Und schon erhält Windows die Adresse des Routers. Ein Test zeigt den Erfolg:
U:\>ping www.kame.net
Ping www.kame.net [2001:200:0:8002:203:47ff:fea5:3085] mit 32 Bytes Daten:
Antwort von 2001:200:0:8002:203:47ff:fea5:3085: Zeit=337ms
Antwort von 2001:200:0:8002:203:47ff:fea5:3085: Zeit=336ms
Antwort von 2001:200:0:8002:203:47ff:fea5:3085: Zeit=317ms
Antwort von 2001:200:0:8002:203:47ff:fea5:3085: Zeit=342ms
Ping-Statistik für 2001:200:0:8002:203:47ff:fea5:3085:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 317ms, Maximum = 342ms, Mittelwert = 333ms
U:\>
