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:
The Networking Nerd 
Yes, please solve the small-site multi-homing issue with IPv6. Oh, and you need to do it without changing all the host IPv6 stacks, or polluting the global table with a /48 for every small office in the world. Thanks.
We want to roll out IPv6 everywhere, we really do. But getting PI address space and BGP from multiple providers for a 30-person sales office is a non-starter. They need multi-homing, because they are dead in the water without VPN connectivity back to HQ, But they don’t need a $2500/month telecomms bill and $25000 worth of routers in their small office. Right now we do that multi-homing with some inexpensive firewalls, NAT, and cheap connectivity for under $400/month recurring.
Small-site multi-homing is NOT a “corner case,” especially with a lot of functionality moving from locally-hosted servers to the cloud. In addition to the small-office-of-a-larger-enterprise case, in the USA: Small businesses create more than 50 percent of the non-farm gross domestic product (GDP). Small businesses employ about 50 percent of all private sector workers. Small businesses create 75 percent of the net new jobs.
As an architect, when introducing IPv6 to people the first time, I often say that the only thing IPv4 and IPv6 have in common are the letters “I, P, and V”. They are that different. I tell engineers that they must think differently. All of that NAT, RFC1918, and VLSM stuff was WORKAROUNDS to deal with the exhaustion of IPv4 address space. These workarounds create numerous problems. Engineers must stop thinking in terms of those workarounds for IPv4. I often equate running IPv6 and IPv4 in a dual-stack arrangement to running IPv4 and IPX/SPX or AppleTalk at the same time like days gone by.
What do people think about IRON for multihoming? Technically you’d be single-homed to your virtual ISP, but they should be redundant enough that the result is still reliable. Or your HQ could act as an IRON server for your branch sites.
NPT66 is the answer to multihoming for small sites .
http://tools.ietf.org/html/rfc6296
LISP was invented to solve the small site multi-homing issue.
curious to how many people get the keep calm reference. Chive on!
Wow, yeah…the reference to Chive…
Or perhaps the reference to the real thing?
http://en.wikipedia.org/wiki/Keep_Calm_and_Carry_On
Actually, RFC 6106 describes sending DNS server information in Router Advertisements using SLAAC. I just wish Cisco’s IOS would support it!
In the meantime we are stuck with using the other stateful configuration flag and DHCPv6 to supply the information?
Another relevant use case is centralized corporate internet gateways… How do you make sure a spoke’s traffic passes through the same firewall symmetrically just by using BGP?
Re: “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.”
I am not that long to work with other protocols and dual stacks on daily basis, but wasn’t the same situation around adoption of today’s stuff, too? Think of VLSM that still causes headaches for CCNAs, or maybe IP protocol itself when it was introduced to established existence of ISO stack or IPX. Some vets here could chime in.
Youu’ll think differently when service providers start to abuse the lack of NAT.
“Why would you need more than one IPv6 address routed to your mobile device? This is … strange, you’re not in the tethering contract after all! Oh, you can upgrade to tethering contract for only $10 per month. Even includes one additional IPv6 address!”
There have been cases of VPS providers trying to charge for each IPv6 address already: http://www.webhostingtalk.com/showthread.php?t=1209774
It WILL happen, especially in countries with an unregulated market that tend to generate localized monopolies.
NAT is not a purely technical issue. It’s also about power. The lack of NAT would shift power away from the end user to the network provider.
Pingback: The Five Stages of IPv6 and NAT | The Networking Nerd | IPv6 deployment in the Asia Pacific | Scoop.it
Any progress with your quest? I volunteer as a tester.
Pingback: Cisco Borderless Idol | The Networking Nerd
The chariot is ready and parked in the box. I am reharsing every wednsday evening with the angels to prepare the choir for singing. No luck for the unicorn, but I plan to stick a Christmas tree topping on a donkey. When will Gabriel the Archangel ring my doorbell?
More seriously, if you are still in this project, I would appreciate to hear what’s going on.
NAPT66 can be an answer, but there is much to do for a working implementation that quickly and correctly adapts to changes in prefix delegation, tests connectivity with something more intelligent than “ping 2001:4860:4860::8888”, etc.
So, do we have an answer yet? Say I have a bunch of PCs on my LAN, and a router with two WAN connections – ISP1 and ISP2, both providing IPv6. I want to load-balance. I want each local user to visit a web site of his choosing and the router decides which WAN connection to use. The PC doesn’t know which it’ll be so surely we HAVE to use NPT? Multihoming on the PC doesn’t help as I don’t want the PC to decide which interface to use (it wouldn’t know how to balance).
Okay, so let me ask something here:
You don’t want to overload the PC with this decision making. Why the router? Why not use a load balancer/ADC inline? That’s what it’s designed for.
I think the real issue comes back down to cost. People don’t like deploying solutions that cost something other than time. They want a protocol to support every possible transmutation of scenario they could possibly encounter. This is a slightly different argument than the BGP/multihoming issues that were previously brought up. Multihoming means failing over to another link when the primary dies. In this case, you want deterministic and efficient link utilization from and edge device with very little decision making capability.
Why not create a simple split in the routing table? 0.0.0.0/1 goes out WAN A and 128.0.0.0/1 goes out WAN B? That effectively accomplishes the same thing. It’s not deterministic, but why does it need to be? Are you wanting the PCs to use the most efficient link? Or just the one that’s got the least amount of traffic? If the intelligence doesn’t need to be at the host level, why should it be at the edge? Unless the WAN circuits are terminated on one router instead of being on two separate devices.
Your case isn’t the first time that a challenge has appeared to IPv6 and the design decisions made 20 years ago. Rather than looking at ways to modify the underlying protocol to support every possible use case, I think it would be better to design a robust protocol and take each edge use case as they come and design higher order intelligence into the network to handle it.
Thanks for the prompt comment… helps me reply while the topic is still in my brain’s RAM 🙂
>> Why the router? Why not use a load balancer/ADC
>> inline? That’s what it’s designed for.
Okay, well, when I said router, I mean anything at the border, or basically beyond the PC. We want the PC to send out the HTTP request (say) and some other device, which has knowledge of current traffic levels on each WAN connection to make the decision. Routers do this for IPv4; it’s not processor intensive.
>> Multihoming means failing over to another link when the primary dies.
I may have misread the context, but surely multihoming just means having
multiple IP addresses, as every IPv6 host does.
>> you want deterministic and efficient link utilization from
>> and edge device with very little decision making capability.
The edge device knows everything it needs to. It can fire the request
out on WAN-A or WAN-B on a round-robin basis or by looking at
which connection currently has the lowest throughput. IT works,
I’m doing it right now (from 192.168.1.10 on IPv4 🙂 ).
>> Why not create a simple split in the routing table?
>> 0.0.0.0/1 goes out WAN A and 128.0.0.0/1 goes out WAN B?
Because when the guy at the next desk in the same group decides
to download CSI New York on a Torrent and I need to access
my company Intranet, I’ll not be able to, despite a completely
clear and unused other WAN connection.
>> Are you wanting the PCs to use the most efficient link?
>> Or just the one that’s got the least amount of traffic?
The latter (not sure what you mean by ‘efficient’ – hopwise
or latency, maybe) but no, based either on current traffic on
each connection, or round-robin when not known/equal.
>> If the intelligence doesn’t need to be at the host level,
>> why should it be at the edge?
Because the edge has the information to know which is
the best WAN connection to use. The doorman at your
nightclub knows how many people went in each door;
the guy at the bar doesn’t (okay, the analogy doesn’t
quite work…)
>> Unless the WAN circuits are terminated on one
>> router instead of being on two separate devices.
Oh! I was assuming they were !
>> Your case isn’t the first time that a challenge has
>> appeared to IPv6 and the design decisions made 20 years ago.
Oh no… this isn’t the answer I wanted. Right now, no-one seems to
have an answer…. IPv4 users with any sort of business
dependency on the Internet routinely have multiple WAN feeds.
They’re not going to move to IPv6 if they can’t have contingency
(failover) or load balancing….
Okay, yes, for the pedants out there, I meant Extranet… 🙂
Tom, any further response?… I wasn’t looking to disagree…but noone seems to know the answer to this, hence I am assuming that NPT is the only way to load-balance.
It seems that the NAT debate has become moot lately. Standardized or not, many vendors have implemented it. I know of Fortinet, OpenDNS and the latest version of VMWare. I just wish it had been done through a proper RFC, instead of having a bunch of different – and potentially incompatible – implementations.