General IPv6 quirks on Windows

[nathana]

So I've got a tunnel set up with HE and have spent the past several days playing with v6 on as many platforms as possible, and have run into a few frustrating issues with some of them.  On this thread, I hope to document the problems I've run into on Windows, and see if anyone else has run into these issues and/or if I'm just being stupid.

I'm not running the tunnel directly TO a Windows machine; the tunnel is being terminated on a a MikroTik RouterOS box.  Windows is getting IPv6 via the router either via direct ethernet or via a PPTP connection (I've tried both).  So far I only have experience with Windows 7, but I assume because of its close heritage with Vista that Vista probably would display similar issues.

1) My understanding is that Windows does not currently support RDNSS-over-RA for learning about DNS servers; it only supports DHCPv6 for DNS autoconfigure.  Is this accurate?  (Sucks for me, because currently MikroTik RouterOS ONLY has support for RDNSS; the DHCPv6 server implementation in RouterOS so far supports prefix delegation ONLY.)

2) How Windows deals with DNS and IPv6 seems to depend on the exact nature of the configuration, and is frustratingly inconsistent.  Here are three scenarios:

2a) IPv6 SINGLE STACK: I noticed that if DNS server information is not statically set on an interface that ONLY has IPv6 enabled, and if it does not receive a DHCPv6 reply with DNS information, then Windows by default lists three IPv6 addresses from the (obsoleted/deprecated) site-local range for its resolvers: fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0:0:0:ffff::3.  I found that one way around the problem of not having RDNSS support in the client and not having full DHCPv6 support on the router was to add those three addresses to my cacheing DNS servers.  This actually worked, and Windows sent AAAA queries to those addresses and used the responses it got back from my DNS servers.  Perfect.

2b) IPv6 DUAL STACK, SINGLE INTERFACE: If I run Windows in a dual-stack configuration with an IPv4 address and an IPv6 address both on the same interface, with only an IPv4 DNS resolver listed (in this case, supplied by DHCP), Windows will send both A and AAAA queries to the DNS server via IPv4 and will also prefer the AAAA response when it gets one.  Also good.

2c) IPv6 DUAL STACK, DUAL INTERFACE: This is where things become problematic.  If I run a dual-stack configuration where one interface is IPv4-only and another (either a second ethernet, or a PPTP connection) is IPv6-only, there are two issues.  First, on the IPv6-only interface, Windows will again default to listing the three aforementioned site-local addresses as DNS resolver targets; however, it will not ever attempt to use them.  *All* DNS requests will be sent via IPv4 to the resolver listed on the IPv4-only interface.  ...but that's okay because Windows can get back quad-A records from that DNS server, right?  Wrong.  This is the second problem: command-line tools such as ping, tracert, and nslookup will successfully look up AAAA records and act upon them (e.g., "ping -6 ipv6.google.com" works great).  But despite this, no network-aware applications using the Winsock APIs will be able to get AAAA responses back from the Windows network stack!  So even though I can ping -6 an IPv6 host such as ipv6.google.com, trying to visit http://ipv6.google.com in ANY web browser (IE, Firefox, whatever) results in it not being able to find the site.

There is a workaround to 2c, but it is one I don't like very much: you can statically specify DNS servers on your IPv6-only interface, and at THAT point, Winsock applications will all-of-a-sudden be able to get back quad-A DNS responses.  I'm assuming that if it had received DNS information via DHCPv6 on the IPv6-only interface that that would have worked as well.  Since I have not yet taken the time to configure a DHCPv6 server anywhere, I don't know for sure.  What I don't understand, though, is why A) Windows stops sending DNS requests to its default IPv6 DNS server list when an IPv4 presence exists on another interface, B) why manually specifying the DNS would make a difference, and C) why Windows would treat Winsock applications and the network command-line tools differently in this scenario.  Clearly Windows is getting back AAAA records; it should pass that along to the client applications.

If you have any experience with IPv6 on Windows and can suggest additional workarounds for any of the above problems, I would be extremely grateful.

Thanks,

-- Nathan