IPv6 in Virtualisierungsumgebungen Heiko Wundram | Gehrkens.IT

Warum IPv6 jetzt? IPv4-Adressraum läuft aus, (nur) noch 20 /8-er verfügbar! Kunden wollen IPv6 ausprobieren Hostinganbieter müssen IPv6 ausprobieren! Umstellung jetzt sichert die Zukunftsfähigkeit!

Anbindung (1. Tunneling) Transport von IPv6 in IPv4 (RFC 3053, Teredo-Protokoll) Vergleichsweise unkomplizierte Möglichkeit, geroutete IPv6-Adressen/Netze zu bekommen: SixXS (www.sixxs.net), Hurricane Electric (www.he.net) Teredo, Anycast 6in4 Keine Verfügbarkeitszusagen, teilweise kein echtes Adress“eigentum“, keine SLAs, da diese Angebote üblicherweise unentgeltlich von Tunnel Brokern bereitgestellt werden Teilweise Abhängigkeit von der aktuellen (mglw. dynamischen) IPv4-Adresse, „dynamische“ IPv6-Adressen (Deutlich) reduzierte MTU durch den Tunnel Deutlich erhöhte Ping-Zeiten

Anbindung (2. nativ) Transport von IPv6 als gleichberechtigtes Protokoll neben IPv4 Provider- oder Uplinkabhängig, Netze/Adressen z.B. als PA über die RIPE: IPv6 über Ethernet, zusammen oder separat von IPv4 IPv6 über PPP (RFC 5072) Verfügbarkeitszusagen, Adresseigentum, SLAs natürlich möglich, je nach vertraglicher Bindung an Provider Aktuell schon bei vielen Colocationprovidern verfügbar IPv6 über PPP immer noch kaum verfügbar in Deutschland Übliche reduzierte MTU bei PPP-Uplink

Exkurs: SixXS Anmeldung bei SixXS erfolgt per Webformular Nach erfolgreicher Anmeldung: Anbindung eigener Router an PoP über zu installierende Tunnel (6to4) Delegation eines Netzes durch den PoP an den eigenen Tunnelendpunkt SixXS unterstützt zusätzlich bei Anfragen nach PI Adressraum z.B. über die RIPE

Infrastruktur Unabhängig von der Anbindung müssen folgende Komponenten lokal mglw. aktualisiert werden: IPv6-fähige Router für Anbindung des lokalen Netzes über den gewählten Uplink und zum Router-Advertisement für das lokale Netz Bei „intelligenten“ Switchen, solche, die IPv6-Traffic switchen (z.B. filtern ältere Extreme Networks Pakete mit „defektem“ Ethernet-Typ) DNS-Resolver, die mit AAAA-Records umgehen können Bei Bedarf Sicherheitsinfrastruktur (IDS, IPS, etc.), die mit IPv6 umgehen kann

Verteilung (1. separates „LAN“) Logische/physikalische Trennung von IPv6- und IPv4-Transport Benötigt entweder VLAN-fähige oder mehrere Netzwerkkarten in allen Endgeräten Konfigurationsmehraufwand, da zwei interne Netzwerke konfiguriert und verwaltet werden müssen Sicherheitsvorteil, da keine öffentlich gerouteten Adressen „zufällig“ verteilt werden

Verteilung (2. Dual-Stack) Transport von IPv4 und IPv6 über das selbe (Ethernet-)Netzwerk Benötigt Dual-Stack-fähige Endgeräte Konfigurationsaufwand geringer, wenn öffentlich geroutetes IPv6-Netz dem öffentlich gerouteten IPv4-Netz „entspricht“ Durch IPv6-Autokonfiguration kann es zu „zufällig“ verteilten öffentlichen IPv6-Adressen kommen!

Konfiguration (1. Autokonfiguration) Netzmaske <= /64 des internen Netzes erlaubt Autokonfiguration durch Router-Advertisement Durch Autokonfiguration kann in den meisten Fällen eine gesonderte IP-Konfiguration der Endgeräte entfallen Linux ab 2.4.x, FreeBSD ab 4.x Windows ab XP Verteilung von DNS-Servern, bzw. „pushen“ von gerouteten Netzen jedoch nicht möglich!

Exkurs: Router-Advertisement Bei Linux-Routern kommt üblicherweise radvd zum Einsatz: radvd (www.litech.org/radvd/) Konfigurationsbeispiel (im Einsatz bei x|encon): interface eth0 { AdvSendAdvert on; AdvManagedFlag on; AdvOtherConfigFlag on; AdvDefaultPreference high; prefix 2a02:790:1:6::/96 { AdvAutonomous off; };

Konfiguration (2. DHCPv6) Bei Netzmaske > /64 des internen Netzes zwingend für automatische Konfiguration benötigt Konfiguration ähnlich wie DHCP für IPv4: dynamische Leases, statische Leases (z.B. MAC-basiert), Push-Optionen Linux/FreeBSD benötigen spezielles Client-Programm Windows-Client ab Vista integriert Verteilung von DNS-Servern/NTP-Servern, pushen von gerouteten Netzen möglich Ersetzt jedoch nicht das Router-Advertisement!

Exkurs: DHCPv6-Implementierungen Mehrere Client/Server-Implementierungen für Linux/FreeBSD/Windows verfügbar: Wide-Projekt (wide-dhcpv6.sf.net) (Linux, *BSD) Dibbler (klub.com.pl/dhcpv6/) (Linux, Windows) Konfiguration von Dibbler, sowohl Client als auch Server, deutlich einfacher als die von Wide Gängige Optionen werden von beiden interpretiert und umgesetzt Andere Betriebssysteme (OpenSolaris) bringen eigene Clients mit

Exkurs: Dibbler-Server Konfigurationsbeispiel (im Einsatz bei x|encon): iface "eth0" { t1 1800 t2 3600 option dns-server 2a02:790:1:6::1 class { accept-only fe80::0216:3eff:fe00:1234 pool 2a02:790:1:6::1000 }

Exkurs: Dibbler-Client Dibbler-Client kommt mit fast allen Linux-Distributionen im Paketmanagement mit Einfache Konfiguration für Endbenutzer Konfigurationsbeispiel (im Einsatz bei x|encon): strict-rfc-no-routing iface "eth0" { ia option dns-server }

Xen und IPv6 Xen selbst ist „nur“ ein Hypervisor, dementsprechend IPv6-agnostisch Virtuelle (Ethernet-)Netzwerkinterfaces von Xen unterstützen IPv6 „out of the box“ Aktueller Xen-Kernel ist noch immer auf dem Stand von Linux 2.6.18, dementsprechend stehen einige IPv6-Funktionen noch nicht zur Verfügung Aktuelle Xen-Tools sind rudimentär IPv6 Management-fähig

Virtuozzo (OpenVZ) und IPv6 Erst kommerziell ab Virtuozzo 4.0 verfügbar, OpenVZ-Unterstützung ab 3.x Einbindung von IPv6 in Gast-Jails nur über virtuelle (Ethernet-)Netzwerkinterfaces (veth) möglich, nicht über venet Aktueller Kernel von OpenVZ ist 2.6.32, volle Unterstützung für IPv6 + Erweiterungen Aktuelle Virtuozzo/OpenVZ-Tools sind rudimentär IPv6 Management-fähig

VMWare und IPv6 VMWare selbst ist „nur“ eine Art Hypervisor, dementsprechend IPv6-agnostisch Virtuelle (Ethernet-)Netzwerkinterfaces von VMWare unterstützen IPv6 „out of the box“ VMWare ist Kernel unabhängig Aktuelle VMWare-Tools sind fast vollständig IPv6 Management-fähig

Sicherheit (1. IPv6) Jedes Gerät mit IPv6-Unterstützung hat mindestens eine (lokale) IPv6-Adresse auf jedem Interface! Unvermittelte Router-Advertisements können den Netzbetrieb empfindlich stören Router-Advertisements auf mehreren LANs können Routing-Chaos verursache Viele (TCP-/UDP-)Dienste lauschen selbst ohne eingerichtetes IPv6 auf allen IPv6-Adressen, sind also über die lokale(n) Adresse(n) lokal erreichbar!

Sicherheit (2. Linux) Linux behandelt IPv4 und IPv6 durch unterschiedliche Firewall-Backends; Standardfirewall für IPv6 ist leer! Standardmäßig lauscht Linux auf allen Interfaces nach Router-Advertisements, mehrere Default-Routen möglich Stateful Matching für IPv6 unter Linux ist erst ab 2.6.25 funktional

Sicherheit (3. Xen) Xen-Tools besitzen eingebaute Funktionalität um (rudimentäres) IPv4-Firewalling in den Start-Scripten zu erledigen; dergleichen fehlt vollständig für IPv6! Die Xen-Tools-Dienste (Migration, externes Management, etc.) hören standardmäßig auch auf IPv6-Adressen, sind also offen zugängig über die link-lokale Adresse Alle Interfaces für virtuelle Maschinen müssen auf der Host-Maschine verfügbar sein, sind also dort auch mit einer link-lokalen Adresse verfügbar!

Fragen?