- Piecemeal Deployment
- Security Issues
- The IPv6 Panopticon
- Am I Online Yet?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Am I Online Yet?
With tunneling mechanisms so easy to implement, it seems like most client machines should already have working IPv6 support. Unfortunately, this is not always the case.
One of the major problems with IPv6 deployment is that it's difficult for a client machine to determine whether it is actually online. If you are using the getaddrinfo() call to look up the correct destination address, then a modern resolver will look for both A and AAAA DNS records, indicating IPv4 and IPv6 addresses.
If you try to connect with an IPv6 address and you have no working IPv6 stack enabled, then it fails immediately, you go on to the next one, and users are completely unaware of the problem. If you have IPv6 enabled but not actually working, then you will have to wait for the timeout before trying the next one.
Unfortunately, this is a difficult problem to solve. Some authoritative DNS servers try to address this by only returning AAAA records to queries that arrive via IPv6, in violation of the spec.
The problem with this approach is that most people don't query these servers directly. They send a recursive query to their ISP's DNS cache, which then queries each server in turn. This server may send the queries over IPv4 or IPv6, depending on the preferences of the network administrator. At the moment, it will probably use IPv4 unless the start of authority (SOA) record from the previous domain only had AAAA records. This means that a query originating from someone on an IPv6 network may be relayed over IPv4.
Some ISPs or DNS cache operators take this a step further and only return AAAA records in response to queries that originate over IPv6. This has a similar problem. Pretty much any current IPv6 user will be running a dual-stack configuration, which may prefer IPv4 where available. The DNS cache address may only have been discovered via DCHP, so may only be known by the IPv4 stack. In this case, all queries will be sent via IPv4, but subsequent connections will be made by IPv6.
Worse, the DNS queries might not actually be coming from the original machine. Most home users have some kind of router, which may run a simple DNS cache that forwards queries to the ISP's cache. This may only support forwarding queries over IPv4, so even if the end user supports IPv6, the query might be being forwarded by something that doesn't.
In a more common configuration, the end user might be on a Windows system with a dual-stack Teredo and IPv4 configuration, while the router only supports IPv4. All DNS queries in this setup are likely to be sent using IPv4, even though the endpoint supports IPv6.
Google's solution to this is to only serve AAAA records to networks that have explicitly opted in as being IPv6-aware. This may work for Google, because they're big enough that ISPs will listen to complaints of Google being broken, but it's certainly not feasible for everyone to do this.
Although IPv6 has been around for a while, there are still some problems related to deploying it. We'll look at some more of these next week.