Bei  RFC 4941 handelt es sich um Erweiterungen von IPv6 für den Schutz der Privatsphäre (IPv6 Privacy Extensions). Zweck dieser Erweiterung ist es, die Identifizierbarkeit eines IPv6-Geräts zu verschleiern, indem der 64-bittige Host-Anteil der IPv6-Adresse nicht mehr mittels EUI-64 aus der MAC der Netzwerkkarte, sondern zufällig gewählt wird. Unter Linux wird dies konfiguriert, indem man das Kernel-Flag "use_tempaddr" auf den Wert 2 setzt. Es gibt diverse Anleitungen dazu, wie dies erfolgen soll, teilweise wird dort die Empfehlung gegeben, dies mittels systcl zu tun und gleichzeitig noch die Werte "temp_valid_lft" sowie "temp_preferred_lft" zu setzen, etwa so: net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.all.temp_valid_lft = 86400 net.ipv6.conf.all.temp_prefered_lft = 7200 net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.default.temp_valid_lft = 86400 net.ipv6.conf.default.temp_prefered_lft = 7200 net.ipv6.conf.eth0.use_tempaddr = 2 net.ipv6.conf.eth0.temp_valid_lft = 86400 net.ipv6.conf.eth0.temp_prefered_lft = 7200 Die Vorgaben für "temp_valid_lft" und "temp_prefered_lft" lauten im RFC 4941 und im Linux-Kernel übrigens 604800 (1 Woche) respektive 86400 (1 Tag). Teilweise wird in solchen Anleitungen sogar 1h (3600s) als "preferred lifetime" gewählt. Die meisten dieser schlauen Empfehlungen führen fast zwangsläufig zu Problemen, wie gleich gezeigt wird. Die Problematik liegt darin, dass in vielen Heimnetzen folgende Bedingungen vorliegen:

• Der Internet-Service-Provider vergibt keine statischen IPv6-Präfixe (Beispiel: Telekom).
• Eventuell wird nicht nur der routbare Präfix, sondern auch noch ein ULA-Präfix (z.B. fd00::) per Router-Advertisement verteilt (Beispiel: Fritzbox).

Bedingt dadurch könnte es nach einiger Zeit z.B. zu folgender IPv6-Konfiguration des Interfaces kommen: 10: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2003::1047:514e:3875:6f81/64 global temporary dyn valid_lft 72869sec preferred_lft 269sec inet6 2003::8e80:9f41:985b:fd1f/64 global temporary deprecated dyn valid_lft 59071sec preferred_lft 0sec inet6 2003::e179:c522:a34a:d41c/64 global temporary deprecated dyn valid_lft 45273sec preferred_lft 0sec inet6 2003::80d1:e7c0:cb43:8cce/64 global temporary deprecated dyn valid_lft 42275sec preferred_lft 0sec inet6 2003::4216:7eff:fe37:dd55/64 global mngtmpaddr dyn valid_lft 86173sec preferred_lft 14173sec inet6 fd00::1047:514e:3875:6f81/64 global temporary dyn valid_lft 72869sec preferred_lft 269sec inet6 fd00::8e80:9f41:985b:fd1f/64 global temporary deprecated dyn valid_lft 59071sec preferred_lft 0sec inet6 fd00::e179:c522:a34a:d41c/64 global temporary deprecated dyn valid_lft 45273sec preferred_lft 0sec inet6 fd00::80d1:e7c0:cb43:8cce/64 global temporary deprecated dyn valid_lft 42275sec preferred_lft 0sec inet6 fd00::4216:7eff:fe37:dd55/64 global mngtmpaddr dyn valid_lft 86173sec preferred_lft 14173sec inet6 fe80::4216:7eff:fe37:dd55/64 link valid_lft forever preferred_lft forever Ignoriert man die letzte Zeile mit der Link-Local-Adresse (Präfix fe80::), sowie die per SLAAC zugewiesenen EUI-64-Adressen ("global mngtmpaddr dyn"), dann sieht man jeweils eine gültige, präferierte temporäre IPv6 für den routbaren Präfix 2003:: und den ULA-Präfix fd00:: ("global temporary dyn") und jeweils drei "deprecated" IPs für jeden der beiden Präfixe. Die "deprecated"-IPs sind jene, deren "preferred lifetime" nach 7200 Sekunden bereits abgelaufen ist. Genau hier liegt das Problem, denn: Aufgrund der längeren "valid lifetime" ergibt sich zwangsläufig später, dass nach dem ersten Tag (86400s) pro Präfix bis zu 86400/7200 = 12 gültige IPs pro Präfix existieren. Hinzu kommen noch die EUI-64 pro Präfix sowie die Link-Local-IP, also bei zwei Präfixen 12 * 2 + 2 + 1 = 27 IPs - was an und für sich kein Problem wäre. Dumm nur, dass in der Default-Konfiguration des Kernels der Wert für "max_addresses" bei 16 liegt! Noch problematischer wird die Sache, wenn die Internetverbindung gekappt und neu aufgebaut wird - oftmals werden dann die alten Präfixe nicht per Router Advertisement für ungültig erklärt. Somit entsteht für die routbaren Adressen ein neues Präfix, während die alten IPs weiter erhalten bleiben. Nachdem die maximale Anzahl von IPv6-Adressen belegt ist, werden keine weiteren Adressen vergeben, was zum vollkommenen vorübergehenden Verlust der routbaren IPv6-Konnektivität führt. Man sollte also das Verhältnis von "temp_prefered_lft" und "temp_valid_lft" so wählen, dass einerseits nicht zu viele "deprecated" IPs entstehen, andererseits aber auch die "valid lifetime" nicht zu kurz ausfällt (z.B. für lang laufende Verbindungen bei Backups usw.). Als guter Kompromiss bietet sich daher z.B. folgende Konfiguration an: net.ipv6.conf.all.use_tempaddr = 2 net.ipv6.conf.all.temp_valid_lft = 86400 net.ipv6.conf.all.temp_prefered_lft = 14000 net.ipv6.conf.all.max_addresses = 64 net.ipv6.conf.default.use_tempaddr = 2 net.ipv6.conf.default.temp_valid_lft = 86400 net.ipv6.conf.default.temp_prefered_lft = 14400 net.ipv6.conf.default.max_addresses = 64 net.ipv6.conf.eth0.use_tempaddr = 2 net.ipv6.conf.eth0.temp_valid_lft = 86400 net.ipv6.conf.eth0.temp_prefered_lft = 14400 net.ipv6.conf.eth0.max_addresses = 64 Damit ergeben sich 86400s/14400s = 8 Adressen pro Präfix, in unserem Beispiel also bereits 2 * 8 + 2 + 1 = 19. Um noch ausreichend Reserven für neue routbare Präfixe zu haben, wird "max_addresses" sicherheitshalber auf 64 erhöht. Man könnte theoretisch auch die Default-Werte für "valid lifetime" und "preferred lifetime" verwenden (604800s = 7 Tage bzw. 86400s = 1 Tag), dies ergibt ganz ähnliche Zahlen, aber es löst nicht das Problem des Adressmangels bei wechselnden Präfixen.