How to prevent delays associated with IPv6 AAAA records?
Solution 1:
This question is pretty interesting and I must admit that I've never seen this behavior. In doing some fiddling around to try and understand it better, I took a snippet of nslookup querying for one of my W2K8R2 RDS servers from another W2K8R2 server and I also captured a snippet of an RDP session to the same RDS server from the same test server. Nslookup showed no delay in returning the IPv6 record and the nslookup showed my test server querying for the IPv4 record before querying for the IPv6 record. The time delta in the capture shows no appreciable delay (that I can ascertain) in either query.
EDIT
Now you're on to something.
Make sure you're capturing traffic for the Microsoft 6To4 adapter, otherwise you won't see IPv6:
Here's the nslookup result for my RDS server. Make note of the IPv6 addresses:
Now here's a snippet of my capture:
And finally, here's a snippet from netstat showing the connection:
So clearly, as you've confirmed, DNS resolution isn't the problem. The problem is that the RDP connection prefers IPv6 over IPv4 (which is the default for Windows - Windows prefers IPv6 over IPv4) and because IPv6 isn't functioning properly it's causing the delay (as you've stated) when falling back from IPv6 to IPv4. You could fix this by configuring the clients to prefer IPv4 over IPv6, but I think that would merely be masking the problem. The better solution would be to figure out why IPv6 isn't working and fix that. I don't know enough about IPv6 to help but my guess is that the IPv6 records being returned by DNS are "local" addresses valid only on the subnet where the RDS hosts exist and since the clients are in a different subnet, they can't reach those IPv6 addresses.
Solution 2:
The IPv6 transition technology called 6to4 is infamous for causing problems like this one. There are several factors at work. Individually they are harmless, but the combined effect is that end users can experience connection delays.
A list of enabling factors and thoughts on their mitigation is presented below.
Windows enables 6to4 by default
If your hosts are running a recent version of Windows (Vista or later), Windows will opportunistically enable 6to4 tunnelling when a publicly routable IPv4 address is available. Critically, this applies to both servers and clients.
To find out whether a system is using 6to4, run ipconfig and look for an IPv6 address that starts with the 6to4 prefix 2002:. It would look something like this.
C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222
- If your endpoints are connected to Active Directory, you can use Group Policy to disable transition protocols like 6to4 and Teredo. This is well-documented in KB929852. (Applying this to either your clients or servers would be sufficient, but if you're taking this step it probably makes sense to disable it everywhere, on both clients and servers.)
- If you only manage a few hosts, you can disable 6to4 on a case by case basis. This is much better than disabling IPv6 entirely.
netsh int ipv6 6to4 set state disabled - Use a different client operating system. For example, Mac OS X does not have 6to4 enabled by default.
Publicly routable IPv4 addresses are being used
6to4 only works on hosts that have publicly routable IPv4 addresses so this problem never affects hosts behind a NAT firewall.
- You can move clients and/or servers behind a NAT firewall and start using RFC1918 addressing. But in some cases, publicly routable addresses are actually preferred. Changing the addressing of an entire network might also be an unrealistic choice.
6to4 is not functioning correctly on the network
It is infamously difficult to troubleshoot 6to4 in anycast mode. It is so troublesome that there was a formal request to the IETF that 6to4 should be reclassified as historic. In the opinion of this author, 6to4 has been deprecated.
In brief, 6to4 works by encapsulating IPv6 packets into IPv4 packets using a protocol called 6in4 (IP protocol=41). The IPv4 packets are addressed to anycast address 192.88.99.1 in hopes that it will arrive at a working 6to4 relay somewhere on the internet. It might even be geographically nearby, if you're lucky.
In practice, some 6to4 relays are set up incorrectly, and a lot of networks don't even allow 6in4 traffic to cross the firewall. Typically this happens when a firewall allows all outbound traffic, but doesn’t explicitly allow IP protocol 41 packets to return through the firewall. (TODO note the relevant RFC for troubleshooting.) This failure ("inbound black hole") and many others are described in RFC 6343.
- Set up your firewall to loudly reject IP protocol 41 (with TCP resets) when sent from hosts internal to your network. This should result in a "fail fast" behaviour that makes more sense than non-deterministic connection delays. This has been demonstrated to work in limited test environments.
- Ask your ISP or first-hop transit provider to set up a working 6to4 relay. If this is done right, it will result in the best experience for end users. Any end user with a publicly routable IPv4 address would be able to participate in the IPv6 internet.
Dynamic DNS registration
In a typical Active Directory environment, every computer is permitted to register its own addresses with the DNS server. When a host is multihomed, it will register all of its addresses, even from a 6to4 tunnel.
Most internet services don't use dynamic DNS, so this problem is typically restricted to enterprise sites where the clients and servers are all "internal" to the same network.
- You may choose to disable dynamic DNS updates. Then if you don't put any AAAA resource records into the zone file, they will never be served. However, dynamic DNS is often desirable for internal DNS servers. (If you do this, make sure to also delete any AAAA records that might already be present.)
- Set up the DNS server to not provide answers for AAAA resource records. But don't do this, because it will really give you trouble when you want to start implementing IPv6. (Does anybody know of a free/open source DNS firewall?)
Client application does not fail gracefully
Microsoft's RDP client is one example of a client application that does not gracefully deal with IPv6 routing problems. Most web browsers are better at dealing with IPv6 edge cases like this one, so they don’t tend to show this behaviour.
- Try using a different client. Maybe you'll get lucky.
Solution 3:
I realize it's not very helpful for this situation, but for implementors facing a similar dilemma, there is an implementation technique known as "Happy Eyeballs" (RFC 6555) that specifies a technique for connecting to ipv4 and ipv6 simultaneously and choosing whichever connects first.