Monday, January 3, 2011

Windows 7 source address selection and unique local addresses

I set up IPv6 on my Linux router, and everything works great, except my Windows 7 box cannot connect to ipv6.google.com, because it uses my unique-local address (ULA) instead of my 6to4 address as the source. Since ULAs are not globally routable, why would Windows even consider using it when connecting to a public address?

The same problem is described here, and the workaround of modifying the prefix policy table does fix it for me, but I too feel it is a hacked/broken solution. (It is however, definitely the correct fix for making Windows prefer IPv6 over IPv4 when connecting to dual stack hosts.)

A "better" workaround I think would be to add a prefix policy of fc00::/7 with its own label and a lower priority. I think that would make it prefer my 6to4 address. Unfortunately, when I run 
netsh interface ipv6 add prefixpolicy fc00::/7 4 6
it doesn't add it right :( It shows up as just ::/7, which is the same problem as described here.

So although I believe Windows is using the correct policy table as per RFC 3484, I think it is a bug for Windows to use a ULA as the source when connecting to a public address, and I think it is a bug that it will not let me add a prefix policy for fc00::/7.

Thoughts?

Update (2018-Nov):

Interestingly, in Sep 2012 (about 2 years after this blog post), RFC 6724 came out (replaces RFC 3484), and it does include a policy for fc00::/7 with its own label.  Since current versions of Windows use the policy table defined in RFC 6724, this bug no longer exists.

Wow, I must be prophetic! :)
Posted by at

2 comments:

  1. AnonymousMarch 22, 2011 at 3:01 PM

    It's not really a bug that ULA is selected as the source. The default policy table (as per RFC 3484) does not mention fc00::/7 addresses, so those are treated equally to any other. This is quite annoying, but not incorrect. Although Microsoft could have added fc00::/7 to the default policy table (considering that RFC 4193 was published much later than RFC 3484). The inability to add fc00::/7 is probably a bug, but you can add fd00::/8 instead, because fc00::/8 is reserved and should not be used anyway.

    ReplyDelete
  2. UnknownMarch 7, 2013 at 11:29 AM

    I would say: it is a bug, or an omission.

    Modifying the prefix policy shouldn't even be necessary, because in RFC 3484, Rule 8 defines a "longest match" policy.

    I run a 6RD derived address from my ISPs 2a02:1200::/28, alongside my ULA /48 from fd::/8.

    When talking to hosts outside my ULA address space, such as ipv6.google.com (2a00:1450:4016:803::1013), I am strongly lead to believe that the 6RD prefix *does* have the longer match than the ULA prefix.

    Still, Windows7 insists on selecting the ULA address. Linuces in the same subnet have no problem to follow Rule 8 of RFC3484.

    Rule 8 may be omitted according to RFC3484, allright, but this leaves the rest of Window's implementation of RFC3484 broken for some scenarios.

    ReplyDelete

Subscribe to: Post Comments (Atom)