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?

2 comments:

  1. 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. 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