IPv6 in VirtualisierungsumgebungenHeiko 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-routingiface "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?