Kurzversion
Before September 2012 After September 2012
Precedence Prefix Precedence Prefix
---------- ------------- ---------- -------------
50 ::1/128 IPv6 loopback 50 ::1/128 IPv6 loopback
40 ::/0 Native IPv6 40 ::/0 Native IPv6
40 fc00::/7 ULAs 35 ::ffff:0:0/96 IPv4
40 fec0::/10 site-local 30 2002::/16 6to4
40 3ffe::/16 6bone 5 2001::/32 Teredo
30 2002::/16 6to4 3 fc00::/7 ULAs
20 ::/96 IPv4compat 1 fec0::/10 site-local
10 ::ffff:0:0/96 IPv4 1 3ffe::/16 6bone
5 2001::/32 Teredo 1 ::/96 IPv4compat
Langversion
RFC6724 definierte eine Änderung, wie Adressen bevorzugt werden sollten. Mit dieser Änderung ist IPv6 nicht mehr in fast allen Fällen die bevorzugte Adresse :(
Diese Frage, die im Juni 2012 gestellt wurde, wurde durch einen RFC vom September 2012 “behoben”. Je nach Windows-Version hatten Sie diese neue Richtlinie entweder von Haus aus (Windows 8.1), oder sie wurde wahrscheinlich bereits durch ein Update bereitgestellt (Windows 8, Windows 7, Windows Vista).
Wir sind hier, weil wir IPv6 verwenden wollen; wir wollen diese Änderung rückgängig machen.
So machen Sie es wieder rückgängig
Wenn Sie mehrere IP-Adressen für einen einzelnen Host erhalten, muss Ihr Rechner entscheiden, welche Adresse er verwenden will. Eine Beispielreihenfolge könnte sein:
- IPv6-Loopback
- Natives IPv6
- Unique-Local-Adressen (ULAs), z. B. fdxx::
- Site-local, z. B. fec0
- 6bone
- 6to4
- IPv4compat
- IPv4
- Teredo, z. B. 2001
Auf Ihrem Windows-Rechner wird diese Rangfolge Prefix-Richtlinie genannt.
Präfix-Richtlinie
Sie können die Präfix-Richtlinie Ihres Computers anzeigen, indem Sie Folgendes ausführen:
>netsh int ipv6 show prefixpolicies
In den alten Zeiten (ursprünglich definiert durch RFC 3484 ) lautete die Präfix-Richtlinie:
Precedence Prefix
---------- -------------
50 ::1/128 IPv6 loopback
40 ::/0 Native IPv6
40 fc00::/7 ULAs
40 fec0::/10 site-local
40 3ffe::/16 6bone
30 2002::/16 6to4
20 ::/96 IPv4compat
10 ::ffff:0:0/96 IPv4
5 2001::/32 Teredo
Sie sehen also, dass so gut wie immer IPv6 verwendet wird (juhu!):
- IPv6 Loopback
- Natives IPv6, ULAs, Site-Local, 6one
- 6to4
- IPv4compat
- IPv4
- Teredo
Wenn Sie sich die Mühe gemacht haben, IPv6 zu implementieren: Es hat gerade funktioniert.
Neue Präfix-Policy
Im Jahr 2012 wurde eine neue Präferenzordnung durch RFC6724 definiert. Heutzutage stellt die Präfix-Policy so ziemlich sicher, dass Sie IPv6 niemals benutzen werden:
Precedence Prefix
---------- -------------
50 ::1/128
40 ::/0 Native IPv6
35 ::ffff:0:0/96 IPv4
30 2002::/16
5 2001::/32
3 fc00::/7 ULAs
1 fec0::/10 site-local
1 3ffe::/16
1 ::/96
Sie werden sehen, dass Sie niemals in der Lage sein werden, Ihre Unique Local Addresses oder site-local address zu benutzen; sie ist für immer kaputt:
- IPv6 loopback
- Natives IPv6
- IPv4
- 6to4
- Teredo
- ULAs
- site-local
- 6bone
- IPv6compat
Wie kann man das beheben?
Was wir wollen, ist, IPv6 so zu reparieren, dass ULAs gegenüber IPv4 bevorzugt werden. Zumindest wollen wir die Verwendung von ULAs (fc00::/7
) über die von IPv4 schieben:
Precedence Prefix
---------- -------------
50 ::1/128
40 ::/0 Native IPv6
37 fc00::/7 ULAs <---------- from 3 up to 37
35 ::ffff:0:0/96 IPv4
30 2002::/16
5 2001::/32
1 fec0::/10 site-local
1 3ffe::/16
1 ::/96
& Das wird erreicht durch:
>netsh interface ipv6 set prefixpolicy prefix=fc00::/7 precedence=37 label=13 store=active
Das hält die Änderung nur bis zum nächsten Neustart aktiv. Um die Änderung dauerhaft zu machen:
>netsh interface ipv6 set prefixpolicy fc00::/7 37 13
Wenn ich:
- mir die Mühe mache, ein globales ULA-Präfix für mein /48 zu generieren
- und eine Subnetz-ID für mein /64 auswähle
- und ULAs an jeden Rechner im Unternehmen verteile
und die DNS-Server aktualisiere, damit sie neben IPv4-Adressen auch IPv6-ULA-Adressen zurückgeben
dann könnte der Rechner wenigstens die Höflichkeit haben, die Adresse zu verwenden.
Bonus Chatter
Der fc00::/7
-Bereich ist in zwei Teile unterteilt:
fd00::/8
- GlobalID-Präfix, das lokal erzeugt wird
fc00::/8
- ???
Niemand hat jemals wirklich entschieden, wofür fc
gut sein soll, und so sitzt es einfach da.
Die fd
-Adressen sind definiert als:
fd
[40-bit random GlobalID]
[16-bit subnet]
Wenn Sie also [64-bits for host assignment]
als Ihre kryptografisch zufällige 40-Bit-“_GlobalID” generiert haben, ergibt das Ihre /48:
a4d7f6dd66
/48
fda4:d7f5:dd66::
/64 (im fda4:d7f5:dd66:face::
-Subnetz)
face
als Host-IP-Adresse
SixXS unterhält eine öffentliche Datenbank mit eindeutigen lokalen Adress-GlobalID-Präfixen, um die Wahrscheinlichkeit von Kollisionen zu verringern, z. z. B.:
fda4:d7f5:dd66:face::825
: Apple Inc - Leopard OSX
fdee:e004:2208::/48
: TekSavvy - Danny Murray
fdd4:43c8:ba34::/48
: IBM Rational Build Forge - Chris Fuller
Aber aufgrund der schleppenden Nutzung und des zweifelhaften Nutzens hat SixXS den Dienst im Jahr 2018 eingestellt.
Bonus Reading