IPv6 Privacy Extensions bei Ubuntu 12.04 LTS

Theorie und Wirklichkeit

Auch wenn die Privacy Extensions bei Ubuntu voreingestellt sind, heißt das nicht, dass sie in jedem Fall angewendet werden. Vielmehr kommt es auf die Kombination von Parametern bei Ubuntu und der Konfiguration des DHCPv6 Servers an, welche Art von IPv6 Adresse genutzt wird. Es kann sogar passieren, dass gar keine IPv6 Adresse vom Client gebildet / akzeptiert wird.

IPv6 Defaults bei Ubuntu 12.04 LTS

Gemäß dem deutschen Ubuntu Wiki sind bei Unbuntu die Privacy Extensions ab 12.04 LTS von IPv6 aktiviert. Dabei gelten folgende beiden Defaults:

Aktive Nutzungsperiode: 3600 Sekunden / 1 Stunde

Passive Nutzungspersiode: 7200 Sekunden / 2 Stunden

Das würde bedeuten, dass jede Stunde eine neue IPv6 Adresse generiert würde und diese eine Stunde lang für den Verbindungsaufbau benutzt würde. Darüber hinaus ist diese IP Adresse eine weitere Stunde lang zu erreichen bzw. kann für bereits bestehende Verbindungen genutzt werden.

Praxis

Soweit die Theorie, stellt sich jedoch die Frage, warum ich nach der Installation eine Ubuntu Servers jedoch folgende Ausgabe habe:

schaub@mysqlserver:~$ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
 inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
 inet6 2001:4dd0:f90c:0:20c:29ff:fe36:e29d/64 scope global
 valid_lft forever preferred_lft forever
 inet6 fe80::20c:29ff:fe36:e29d/64 scope link
 valid_lft forever preferred_lft forever

Wie leicht am ff:fe zu erkennen, wurde der Hostanteil der IPv6 Adresse nicht zufällig sondern gemäß EUI-64 gebildet. Stellt sich die Frage, warum? Stimmen die Defaults etwas nicht oder ist die Doku wirklich falsch?

Lösung des Rätsels

Der Grund steckt im Detail: es stimmt zwar, dass in der Datei /etc/sysctl.d/10-ipv6-privacy.conf  folgende Zeilen stehen:

net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2

Richtig ist auch die gesetzte Option „2“:

0 = Privacy Extensions nicht aktiv
1 = temporäre Adresse bereitstellen
2 = temporäre Adresse bereitstellen und aktiv nutzen

Quelle: Deutsches Ubuntu Wiki

Jedoch wird dieser Default an einer anderen Stelle übersteuert und zwar durch die Bootoptionen in der Datei /etc/network/interfaces. Diese steuert, mit welchen Optionen die Interface gestartet werden. Dort ist nach der Installation sowohl für IPv4 als auch IPv6 DHCP eingetragen:

# The primary network interface
auto eth0
iface eth0 inet dhcp
iface eth0 inet6 dhcp

Das bedeutet aber nicht nur, dass DHCPv6 die Default des Betriebssystems überschreiben darf, sondern sogar, dass nur vom DHCP-Server zugewiesene Adressen akzeptiert werden.

Weist der DHCP Server aber nur ein Präfix zu, wird das Interface gar nicht aktiv. Denn es wird eben bei IPv6 vom Server kein Präfix an Endgeräte vergeben, sondern nur komplette IP Adressen. Die Präfixzuweisung ist vielmehr eine Präfix-Delegation mittels derer ein DHCP Server Präfixe an Router weitergeben kann, die diese dann verteilen. Denn die Präfix-Zuweisung erfolgt immer per Router Advertisement und niemals per DHCPv6:

Der Eintrag in der Datei /etc/network/interfaces übersteuert somit nicht nur alle anderen internen Defaults sondern sorgt auch dafür, dass vom DHCPv6 Server ein bestimmtes Verhalten erwartet wird. In diesem Fall, dass er – der DHCP Client – eine komplette IP Adresse zugewiesen bekommt und nicht nur ein Präfix, da das gar nicht möglich ist. Damit wird aber die Privacy Extension sinnlos, da der DHCP Client keine eigene IP Adresse mehr bilden (soll).

Man kann dieses Verhalten natürlich ändern. Statt „dhcp“ sind auch Optionen „static“ und „auto“ möglich:

# The primary network interface
auto eth0
iface eth0 inet dhcp
iface eth0 inet6 auto

Diese kleine Änderung sorgt dafür, dass SLAAC zur Anwendung kommt. Das Resultat sieht dann so aus:

schaub@mysqlserver:~$ ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
 inet6 ::1/128 scope host
 valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
 inet6 2001:4dd0:f90c:0:3:36f3:e3e4:99d3/64 scope global temporary dynamic
 valid_lft 7008sec preferred_lft 3408sec
 inet6 2001:4dd0:f90c:0:20c:29ff:fe36:e29d/64 scope global dynamic
 valid_lft 7008sec preferred_lft 3408sec
 inet6 fe80::20c:29ff:fe36:e29d/64 scope link
 valid_lft forever preferred_lft forever

Das System nutzt nun eine temporäre IPv6 Adresse, die in diesem Fall noch 7008 Sekunden (valid_lft) gültig ist und weitere 3408 Sekunden (preferred_lft) aktiv genutzt wird.

Zu beachten ist, dass auch eine EUI-64 Adresse gebildet wurde und an das Interface gebunden ist. Das System reagiert auch auf diese IPv6 Adresse, soll heißen man kann sie durchaus anpingen oder für andere Dienste nutzen. Es benutzt sie lediglich für ausgehende Verbindungen nicht.

Fazit

Das Zusammenspiel zwischen Router, DHCPv6 Server und Client ist diffiziler als es zunächst den Anschein hat: nicht jede Kombination von Default-Werten und Konfigurationsparametern führt zu einem funktionierenden Ergebnis. Was überrascht ist, dass Ubuntu (Server?) den Default auf „dhcp“ setzen, statt auf „auto“. Das mag durchaus  der Installationsroutine geschuldet sein, die bei der Installation des Systems einen DHCPv6 Server „erkannte“.

Andere Systeme verhalten sich übrigens anders: ein Mac mit OSX 12.4 in derselben Testumgebung akzeptierte durchaus die vom DHCP Server zugewiesene Adresse, generierte aber trotzdem noch eine temporäre Adresse, die er auch fleissig aktiv nutzt. Also genau das umgekehrte Verhalten des Linux Systems.

Zusammenfassend lässt sich also feststellen, dass bei der Adressvergabe bei IPv6 noch einiges im Argen liegt, so lange unterschiedliche Betriebssysteme unterschiedlich reagieren. Hier sollte dringend ein verbindlicher Standard geschaffen und flächendeckend implementiert werden.

« Teil 3: IPv6 Konfiguration bei Windows 7Teil 5: Troubleshooting IPv6 »