Fix for Windows 10 preferring IPv4 over IPv6
superuser.com/a/1469778/305492Posted Aug 10, 2019, 6:20 AM UTC
1714
superuser.com
Short version
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
Long Version
RFC6724 defined a change in how addresses should be preferred. With this change IPv6 is no longer the preferred address in nearly every case :(
This issue was "fixed" by an RFC from September 2012. Depending on your Windows version, you either had this new policy out of the box (Windows 8.1), or likely already delivered through an update (Windows 8, Windows 7, Windows Vista).
We're here because we want to use IPv6; we want that change undone.
How to put it back
If you get multiple IP addresses for a single host, your machine has to decide which address it will use. An example ranking might be:
- IPv6 loopback
- Native IPv6
- Unique-Local addresses (ULAs), e.g. fdxx::
- Site-local, e.g. fec0
- 6bone
- 6to4
- IPv4compat
- IPv4
- Teredo, e.g. 2001
On your Windows machine, this ranking is called the prefix policy.
Prefix policy
You can view your computer's prefix policy by running:
>netsh int ipv6 show prefixpolicies
In the olden times (originally defined by RFC 3484), the prefix policy was:
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
So you see it would pretty much always use IPv6 (yay!):
- IPv6 loopback
- Native IPv6, ULAs, site-local, 6one
- 6to4
- IPv4compat
- IPv4
- Teredo
If you went through the effort to deploy IPv6: it just worked.
New Prefix Policy
In 2012 a new preference order was defined by RFC6724. Nowadays the prefix policy pretty much ensures that you'll never use IPv6:
Precedence Prefix
---------- -------------
50 ::1/128 Localhost
40 ::/0 Native IPv6
35 ::ffff:0:0/96 IPv4
30 2002::/16 6to4
5 2001::/32 Teredo
3 fc00::/7 ULAs
1 fec0::/10 site-local
1 3ffe::/16 6bone
1 ::/96 IPv4compat
You'll see that you will never be able to use your Unique Local Addresses, or site-local address; it's perpetually broken:
- IPv6 loopback
- Native IPv6
- IPv4
- 6to4
- Teredo
- ULAs
- site-local
- 6bone
- IPv6compat
How to fix it?
What we want is to fix IPv6 so that ULAs are preferred over IPv4. At the very least we want to push the use of ULAs (fc00::/7) above that of IPv4:
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
Which is done by:
>netsh interface ipv6 set prefixpolicy prefix=fc00::/7 precedence=37 label=13 store=active
That will only keep it active until the next reboot. To make the change permanant:
>netsh interface ipv6 set prefixpolicy fc00::/7 37 13
If i:
- went through the effort to generate a ULA global prefix for my /48
- and choose a subnet id for my /64
- and deploy ULAs to every machine in the enterprise
- and update the DNS servers to return IPv6 ULA addresses in addition to IPv4 addresses
the least the computer could do is have the common courtesy to use the address.
Bonus Chatter
The fc00::/7 range is divided into two parts:
fd00::/8- GlobalID prefix generated locallyfc00::/8- ???
Nobody ever really decided was fc would be good for, and so just sits there.
The fd addresses are defined as:
fd[40-bit random GlobalID][16-bit subnet][64-bits for host assignment]
So if you generated a4d7f6dd66 as your cryptically random 40-bit GlobalID, that gives you your /48:
fda4:d7f5:dd66::/48fda4:d7f5:dd66:face::/64 (in thefacesubnet)fda4:d7f5:dd66:face::825as a host IP address
SixXS maintained a public database of Unique Local Address GlobalID prefixes in order to reduce the chance of collissions, e.g.:
fdee:e004:2208::/48: Apple Inc - Leopard OSXfdd4:43c8:ba34::/48: TekSavvy - Danny Murrayfdac:afbd:fea1::/48: IBM Rational Build Forge - Chris Fuller
But due to slowing use, and the dubious value in the first place, SixXS discontinued the service in 2018.
Bonus Reading
6
wow, thanks for the detailed reply!
3
would this be a problem at all if you used the prefix from one of the isp's for your lan, and Npt to the other global prefix on the second wan ? instead of, or in addition to ULA addresses.
5
In that case you'd be using global addresses, so no I don't think you'd have this issue.
2
This level of control also exists for linux in /etc/gai.conf
1
Or just run a small file...
Use registry key to configure IPv6
Important Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you modify it, back up the registry for restoration in case problems occur.
To configure IPv6, modify the following registry value based on the following table.
Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
Name: DisabledComponents
Type: REG_DWORD
Min Value: 0x00
Max Value: 0xFF (IPv6 disabled)
1
I saw this, but it doesn't do what I needed. In fact it doesn't help at all unless you've already disabled or depref'd ipv6, in which case you can undo that.
1
Did you check the links? They offer "all flavours", disable IPv6, but also prefer IPv6 over IPv4 (and vice versa)
1
Yes, and the value for "prefer ipv6" is the default for that registry value (i.e. 0).
1
ah ok, so the device that was prefering IPv4 over IPv6 had the flaf set to 0 (read: zero) ?
Would an other work-around/fix not be to just set it to prefer IPv4 (over IPv6), reboot and set it to prefer IPv6 over IPv4?
So far i've only have had to do some prefer IPv4 over IPv6 if that solved some connection issue's for former work collegue's reaching the citrix pool (website)
(as cross-ISP routing/switching issue's tend to take ages before the correct parties on both ends deal with the issue).
0
I ran into an issue where my Windows 10 laptop would prefer IPv4 even though I have working IPv6 at home. I eventually managed to resolve it but it wasn't easy, so I wrote it up and posted on SuperUser. Hopefully this will help someone else.
Nice. I'm a relatively-old-timer and I still forget about the power of netsh.
[deleted]