Allgemein sagt man das IPv6 immer vor IPv4 geht. IPv6 Verbindungen sollten also immer gegenüber IPv4 Verbindungen bevorzugt werden. Ich war also etwas erstaunt als ein Windows System mit konfiguriertem IPv6 ULA Netzwerk dauerhaft seine alte IPv4 Verbindung bevorzugte…
Alle Linux Systeme verhalten sich dagegen wie gewünscht. Eine kurze Suche förderte erst RFC 3484 und dann der ersetzende RFC 6724 zutage. Hier wird eine Tabelle definiert in welcher die Verschiedenen IPv6 Prefixe sowie das umgerechnete IPv4 Prefix ::ffff:0:0/96 sowie deren Priorisierung gegenübergestellt werden. Spannend ist dabei das in RFC 3484 die prefix policy wie folgt war:
1. IPv6 loopback
2. Native IPv6, ULAs, site-local, 6one
3. 6to4
4. IPv4compat
5. IPv5
6. Teredo
Dieses hat sich aber mit RFC 6724 in 2012 geändert zu:
1. IPv6 loopback
2. Native IPv6
3. IPv4
4. 6to4
5. Teredo
6. ULAs
7. site-local
8. 6bone
9. IPv6Combat
Früher war also alles besser? Naja… Wie man sehen kann wird inzwischen IPv4 for IPv6 ULA priorisiert. Öhm… Ich habe da jetzt Leute im Kopf die fragen wie man IPv6 bei seinem System abschalten kann, weil es ja nur Probleme macht *kopfschüttel*.
Wie ändert man nun also die Priorisierung?
Auf einem Windows lässt sich diese Liste wie folgt bewundern:
netsh int ipv6 show prefixpolicies
Auf einem Linux steht alles in: /etc/gai.conf und man kann es bewundern mit:
ip -f inet6 addrlabel show
Bei einem FreeBSD bekommt man die Liste wie folgt:
# ip6addrctl Prefix Prec Label Use ::1/128 50 0 0 ::/0 40 1 5580865 ::ffff:0.0.0.0/96 35 4 0 2002::/16 30 2 0 2001::/32 5 5 0 fc00::/7 3 13 0 ::/96 1 3 300 fec0::/10 1 11 0 3ffe::/16 1 12 0
Apple… Bei Apple ist es etwas spezieller! Daher erstmal zur Frage: „Wie gebe ich ULA eine höhere Prio als IPv4, damit mein schön konfiguriertes IPv6 ULA Netzwerk auf benutzt wird?“.
Ganz einfach für Windows:
netsh interface ipv6 set prefixpolicy fc00::/7 37 13
Bei den anderen Systemen (bis auf Apple) klappt das sehr ähnlich. Das finden diese User auch ohne das es copy&paste fertig ist, hm?
Apple…. Die Jungs nutzen RFC 6555 (Happy Eyeballs). Puhhh Joar die Idee dahinter ist nicht schlecht. Grob gesehen ist es so: Bei den meisten anderen RFCs wird nach einem AAAA RR geschaut und im Zusammenspiel mit der Prefix Policy geschaut ob man eine IPv6 Verbindung aufbauen kann. Klappt dieses nicht gibt es einen Fallback auf IPv4. Dieses setzt also voraus, dass eine IPv6 Verbindung nicht zustande kommt. Es kann also mal passieren, dass es dauert! Happy Eyeballs (was eine Name für ein RFC?!?!?) baut die IPv4 und IPv6 Verbindung gleichzeitig auf wenn es einen AAAA RR gibt. Klappt dieses „gut“ bleibt es bei IPv6 sonst hat man ja direkt schon die IPv4 Verbindung offen. Damit werden Wartezeiten minimiert. Eine ULA Verbindung wird dabei leider nicht gegen IPv4 priorisiert 🙁
Fragen? Dann fragen!
