Spaß mit IPv6

Clients

Während bei IPv4 die verbreitetste Methode zur Konfiguration der Clients auf DHCP basiert, ist in IPv6 Netzen die sog. auto configuration die gängigste und einfachste Methode. Dies wird in der Regel durch den Kernel realisiert und erfordert keine weiteren Programme. Man sollte bedenken, dass bei einem Einbinden von Clients in Netze, die sowohl IPv4 als auch IPv6 betreiben, unerwartete Effekte auftreten können: Wenn Applikationen DNS Namen zu IPv6 Adressen auflösen können und eine IPv6 Anbindung besteht, versuchen diese Clients in der Regel auch die Kommunikation über IPv6 abzuwickeln. Wenn nun aber die Konnektivität bis zum Ziel gestört ist oder der angesprochene Dienst "nicht mit IPv6 Clients rechnet", kann es zu Problemen kommen, die man mit alleiniger IPv4 Anbindung nicht hatte: Verzögerungen bis zum Wechsel zu IPv4, Authentisierungsfehler, etc. Einige Applikationen kann man dazu zwingen, ausschließlich IPv6 oder IPv4 zu verwenden.

Windows und IPv6

Windows XP unterstützt IPv6 direkt. Für die Installation unter Windows XP mit SP1 oder 2 muss folgender Befehl in die Kommandozeile eingegeben werden:

netsh interface ipv6 install
    

Weitere Informationen sind hier zu finden: http://www.microsoft.com/windowsserver2003/techinfo/overview/ipv6faq.mspx

Im IBR angebundene Subnetze bzw. VLANs

Im IBR sind derzeit alle Subnetze mit IPv6 versorgt. In jedem Fall wird auto configuration benutzt, die Prefixe werden vom zentralen IBR Router verteilt. Für alle Clients - egal ob im Core-Netz, im TestLab, im "alten" IBR-WLAN oder im "neuen" TUBSWLAN - sollte durch einfaches Aktivieren von IPv6 eine IPv6 Anbindung zustandekommen.

Einige IPv6 Prefixe:

Anbindung gerouteter Netze

Die meisten Institutsnetze, Wohnheime, etc. werden ihre Anbindung sicherlich über eigene Router realisieren. Während bei IPv4 diese Router "Proxy-ARP" benutzen, um die für ihre Subnetze bestimmten Traffic "an sich zu nehmen", ist diese Methode im Falle von IPv6 teils garnicht möglich und in jedem Fall ziemlich unschön. Der richtige Weg ist es, den beteiligten Routern geeignete Routen für die vorhandenen Subnetze beizubringen. Dies könnte manuell geschehen, würde aber bei zunehmender Zahl von angeschlossenen Subnetzen jedem Subnetz-Administrator Aufwand bei Änderungen abverlangen und somit nicht skalieren. Glücklicherweise gibt es Routing-Protokolle. :-) Für IPv6 ist OSPFv3 das verbreitetste Protokoll. Dies kann auch in unserem TU Netz verwendet werden.

Eine OSPFv3 Implementierung, die im IBR seit dem 24.01.2006 eingesetzt wird, ist "quagga", ein Ableger von "zebra". Ein hiermit aufgesetzter Router kann die im TU-Netz propagierten Routen entgegennehmen und in seine Kernel Routing Table einpflanzen und umgekehrt die Zuständigkeit für seine eigenen Subnetze den angeschlossenen OSPFv3-Routern mitteilen.

Ein erstes Setup von quagga im IBR sieht so aus:

hostname XXXX.tu-bs.de
password XXXX
enable password XXXX
log syslog
! Diese eine Route wollen wir den anderen TU Routern verklickern:
ipv6 route 2001:638:602:XXXX::/XX fe80::XXXX:XXXX:XXXX:XXXX
    

hostname XXXX.tu-bs.de
password XXXX
log syslog
service advanced-vty
!
debug ospf6 neighbor state
!
interface ethX
 ipv6 ospf6 cost 1
 ipv6 ospf6 hello-interval 10
 ipv6 ospf6 dead-interval 40
 ipv6 ospf6 retransmit-interval 5
 ipv6 ospf6 priority 0
 ipv6 ospf6 transmit-delay 1
 ipv6 ospf6 instance-id 0
!
router ospf6
 router-id 134.169.XXX.XXX
 interface ethX area 0.0.0.0
! redistribute static route-map map1
 redistribute static
!
ipv6 prefix-list list1 seq 10 permit 2001:638:602::/48 ge 49
ipv6 prefix-list list1 seq 90 deny any
!
route-map map1 permit 10
 match ipv6 address prefix-list list1
!
access-list access4 permit 127.0.0.1/32
access-list access4 deny any
!
ipv6 access-list access6 permit ::1/128
ipv6 access-list access6 deny any
!
line vty
 access-class access4
 ipv6 access-class access6
 exec-timeout 0 0
    

Das ist ausdrücklich ein erster Stand meiner Halbkenntnisse. Die Dokumentation zu zebra und quagga ist leider nicht sehr ausführlich.

DNS

Das Ergänzen von AAAA RRs sollte in der Regel kein Problem darstellen. Wie es mit der Delegation für das Reverse Mapping (*.ip6.arpa.) aussieht, ist mir noch nicht klar. Offensichtlich hat derzeit die gesamte TU noch garkeine Delegation für ihre Zone 2.0.6.0.8.3.6.0.1.0.0.2.ip6.arpa.

Security

In der IPv4 Welt hat sich die Notwendigkeit von Firewalls inzwischen wohl herumgesprochen. Im Falle von IPv6 ist aber zu befürchten, dass es noch viele unzureichend oder garnicht gesicherte Netze gibt. Im IBR benutzen wir einen Linux-Rechner als Router und dessen "netfilter" zur Paketfilterung. "netfilter" unterstützt bereits IPv6, wenn auch noch nicht ganz so umfangreich und komfortabel wie IPv4.