A Sticky Situation
You might not realize this, but every time you make a Domain Name System query, you use a little bit of Internet glue. This is one part of the Internet few think about and most users don’t even know exists. But this glue is missing for Internet Protocol Version 6 and currently prevents agencies from running all-IPv6 networks.
When we type in a URL or the name of a server into our browsers or an application, our computers need to change that name into a numeric IP address and do so by sending a query to a local DNS server. System administrators and network chiefs assign computers local DNS servers to use, and these servers do all of the hard work for us. They are responsible for tracking down the machines on the Internet that can, for instance, change www.example.net into 208.77.188.166.
How does your hardworking local DNS server know where to start? DNS servers are seeded with a file called the root zone hints file, which contains a list of 13 DNS servers that can help find the right server for the current query. The names of these servers are a.root-servers.net through m.root-servers.net. But having the name of a server isn’t very useful to a computer that only communicates with other computers via their IP addresses, so the root zone hints file also contains the IP addresses for those 13 servers. The problem is it contains only the IPv4 addresses for those servers.
A Disconnect
On an IPv6-only network, the first time you want to look up a name, the DNS server will look at the root zone hints file and not find any IPv6 root DNS servers it can use. The lookup will fail.
So the Internet is broken, right? Well, like a fine wine (and chaos theory), the Internet is improving and growing more complex every day.
In the example, the system involves an IPv6-only computer and an IPv6-only DNS server. If the DNS server is dual-stacked, running both IPv4 and IPv6, then it will use IPv4 to ascertain the proper IPv6 address for the query. This conundrum means that to run IPv6 end to end, you need IPv4 — at least for now.
But isn’t one supposed to replace the other? Yes. We should not support an Internet that relies on old systems to make new systems work. An agency should be able to throw the switch on IPv6 and turn off IPv4 right now if it so desires. The problem lies in the glue information and the task of getting it to work for IPv6.
The original DNS protocol put a 512-byte size restriction on the response sent from a server. That means 13 servers and 13 glue records for those servers fit inside of that packet and fill it almost to the maximum size. There isn’t any room to simply add IPv6 addresses for all 13 servers.
There are options to fix the problem:
- Insert opt records in the DNS query by using the Internet Engineering Task Force’s Enhanced DNS protocol.
- Make the packets bigger, and to heck with the protocol.
- Pull out some of the IPv4 servers and insert IPv6 servers.
- Add two IPv6 glue records to the query, to the full maximum 512-byte limit, and hope those two never go down.
The reason this problem has continued for so long is not because there are no possible solutions. It seems to be more tied to a fear of breaking the Internet by implementing them. But how well founded are these worries? Look around the Internet, and you will discover that each of these approaches has been partially implemented, and agencies can even conduct experiments in their own IPv6 test beds.
Options 1 and 2 suggest that agencies create bigger packets. The caution factor here is that the networking equipment between the user and a DNS server might mark packets as suspect if they do not conform to the original DNS protocol by maintaining packet sizes smaller than 512 bytes. If this happens, organizations will need to upgrade, replace or reconfigure hardware to solve the problem rather than not implement IPv6 (which is not an option for agencies given the June 2008 mandate).
Testing networks and systems to see how they will respond is easy. Plus, there are at least two real-world examples: The top-level domains for Hong Kong and the United Kingdom (.hk and .uk) have been exceeding the 512-byte limit for some time. Yet, neither Hong Kong nor the U.K. has fallen off the Internet map or sent the Internet into a fiery tailspin.
From the Top
Options 3 and 4 raise concerns about whether systems can handle the reception of IPv6 DNS records. Some systems experts suggest that by adding IPv6 records, machines that don’t have an IPv6 connection will try to access IPv6 nodes because they received an IPv6 record. Theoretically, these systems will time out and then fail. The top-level domains for .net, .com, .biz and even .museum already have IPv6 records in their glue, however.
FACT:
IPv4 supports 4.3 billion addresses. IPv6 supports 340 billion billion billion billion addresses to support the addressing needs of the world’s 6.5 billion people.
If systems were going to break, it seems they would have begun sputtering by now because IPv6 records have been available at the top-level domains for some time. If they break, it is because they are old or unable to handle the current state of the Internet and — as with options 1 and 2 — need to be replaced, upgraded or reconfigured. Although every large-scale systems change demands that an organization evaluate and justify it, it should not take years to ensure that an agency’s infrastructure can support the next generation of IP.
Option 3 also raises red flags because removing any of the 13 servers from the root zone hints file could risk the operation of the DNS process and cause reliability issues. This becomes less worrisome with the advent of “anycasting.” With anycasting, even though there is one k.root-servers.net IP address, there are multiple machines geographically located that answer to that address. So, removing a few machines from the root zone hints file doesn’t seem to be a reliability issue but a political one. Does anyone want to tell VeriSign, Cogent or NASA that they suddenly won’t be running a root-name server anymore? Of course not.
In the short term, few networks will be converted exclusively to IPv6 with no IPv4 support. Too many pieces of the Internet haven’t converted to IPv6, which makes maintaining a dual-stack connection to both IPv4 and IPv6 necessary. But, over time, public- and private-sector organizations alike must address this issue. Similarly, the Internet Assigned Numbers Authority will need to work out details for expeditiously updating the root zone hints file before the advent of numerous IPv6-only networks.
