I think it’s time to put up a new post on IPv6 and NAT. Mainly because I’m still getting comments on my old NAT66 post from last year. I figured it would be nice to create a new place for people to start telling me how necessary NAT is for the Internet of the future.
In the interim, though, I finally had a chance to attend the Texas IPv6 Task Force Winter 2012 meeting. I got to hear wonderful presentations from luminaries such as John Curran of ARIN, Owen DeLong of Hurricane Electric, and even Jeff Doyle of Routing TCP/IP book fame. There was a lot of great discussion about IPv6 and the direction that we need to be steering adoption of the new address paradigm. I also got some very interesting background about the formation of IPv6. When RFC 1550 was written to start soliciting ideas about a new version of IP, the Internet was a much different place. Tim Berners-Lee was just beginning to experiment with HTTP. The majority of computers connected to the Internet used FTP and Telnet. Protocols that we take for granted today didn’t exist. I knew IPSec was a creation of the IPv6 working group. But I didn’t know that DHCP wasn’t created yet (RFC 2131). Guess what? NAT wasn’t created yet either (RFC 1631). Granted, the IPng (IPv6) informational RFC 1669 was published after NAT was created, but NAT as we know and use it today wasn’t really formalized until RFC 2663. That’s right, folks.
The reason NAT66 doesn’t exist is because IPv6 was built at a time when NAT didn’t exist.
It’s like someone turned on a lightbulb. That’s why NAT66 has always felt so wrong to me. Because the people that created IPv6 had no need for something that didn’t exist. IPv6 was about creating a new protocol with advanced features like automatic address configuration and automatic network detection and assignment. I mean, take a look at the two IPv6 numbering methods. Stateless Automatic Autoconfiguration (SLAAC) can assign all manner of network information to a host. I can provide prefixes and gateways and even default routes. However, the one thing that I can’t provide in basic SLAAC is a DNS server entry. In fact, I can’t provide any of the commonly assigned DHCP options, such as NTP server or other vendor-specific fields. SLAAC is focused solely on helping hosts assign addresses to themselves and get basic IP connectivity to the global Internet. Now, take DHCPv6. This stateful protocol can keep track of options like DNS server or NTP server. It can also provide a database of assignments so I know which machine has which IP. But you know what critical piece of information it can’t provide? A default router. That’s right, DHCPv6 has no method of assigning a default router or gateway to an end node. I’m sure that’s due to the designers of DHCPv6 knowing that SLAAC and router advertisements (RA) handle the network portion of things. The two protocols need to work together to get hosts onto the internet. In 1995, that was some pretty advanced stuff. Today, we think auto addressing and network prefix assignment is pretty passé.
Instead of concentrating on solving the dilemma of increasing the adoption rate of IPv6 past the 1% mark where it currently resides, we’ve instead turned to the Anger and Bargaining phases of the Küber-Ross model, otherwise known as the Five Stages of Grief. The need for IPv6 can no longer be denied. The reality of running out of IPv4 addresses is upon us. Instead, we lash out against that which we don’t understand or threatens us. IPv6 isn’t ready for real networking. There are security risks. End-to-end communications aren’t important. IPv6 is too expensive to maintain. People aren’t smart enough to implement it. Any of those sound familiar? Maybe not those exact words, but I’ve heard arguments very similar to that leveled at IPv6 in just the two short years that I’ve been writing. Think about how John Curran of ARIN must feel twenty years after he started working on the protocol.
Anger is something I can handle. Getting yelled at or called expletives is all part of networking. It’s the Bargaining phase that scares me. Now, armed with a quiver of use cases that perhaps 5% of the population will ever take advantage of, we now must delay adoption or move to something entirely different to support those use cases. It’s the equivalent of being afraid to jump off a diving board because there is a possibility that the water will drain out of the pool on the way down. The most diabolical is Carrier Grade NAT. Let’s NAT our NATed networks to keep IPv4 around just a little longer. It won’t cause that many problems, really. After all, we’ve only got 65,536 ports that we can assign for any given PAT setup. So if we take that limit and extend it yet another level, we have 65,536 PATed PAT translations that we can assign per CGN gateway. That has real potential to break applications, and not just from an end-to-end connectivity point of view. To prove my point, fire up any connection manager and go to http://maps.google.com. See how many separate connection requests are spawned when those map tiles start loading. Now, imagine what would happen if you could only load ten or fifteen of them. There’s going to be a lot of blank spots on the that map.
Now, for the fun part. I’ve been accused of hating NAT. Yes, it’s true. I dislike any protocol that breaks basic connectivity and causes headaches for troubleshooting and end-to-end communications. I have to live with it in IPv4. I’d rather not see it carried forward. That’s the feeling of many IPv6 evangelists. If you think I dislike NAT, ask Owen DeLong his feelings on the subject. However, to say that I dislike NAT for no good reason is silly. People are angry at me for saying the emperor has no clothes. Every time I discuss the lack of need for NAT66, the same argument gets thrown in my face. Ivan Pepelnjak wrote an article about about using network prefix translation (NPT) in a very specific case. If you are multihoming your network to two different providers and not using BGP then a case for NPT can be made. It’s not the best solution, but it’s the easiest. Much like Godwin’s Law, as the length of any NAT66 argument increases, the probability of someone bringing up Ivan’s article approaches approaches one.
So, I’ve found a solution to the problem. I’m going to fix this one scenario. I’m going to dedicate my time to solving the multihoming without BGP issue. When I do that, I expect choirs of angels to sing and a chariot pulled by unicorns to arrive at my home to escort me to my new position of Savior of IPv6 Adoption. More realistically, I expect someone else to find a corner case rationale for why IPv6 isn’t the answer. Of course, that’s just another attempt at bargaining. By that point, I’ll have enough free time to solve the next issue. Until then, I suggest the following course of action: