IPv6 in Virtualisierungsumgebungen

1. IPv6 in Virtualisierungsumgebungen Heiko Wundram | Gehrkens.IT

2. 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!

3. 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), HurricaneElectric (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

4. 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

5. 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

6. 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

7. 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

8. 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!

9. 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!

10. 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; AdvDefaultPreferencehigh; prefix 2a02:790:1:6::/96 { AdvAutonomous off; }; };

11. 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!

12. 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

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

14. 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 }

15. 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

16. 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

17. 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

18. 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!

19. 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

20. 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!

21. Fragen?