Frequent visitors to this site know of my crusade against all things Network Address Translation (NAT). Despite its few useful properties and our current reliance on it with IPv4, I consider it to be a kludge at best. However, some people see NAT as a necessity of modern networks and have begun working hard to ensure that NAT will live on with our shift to IPv6.
I realize that NAT is a necessary evil today. The IPv4 Internet would have imploded long ago without translating the meager number of prefixes available into the large number of “private” devices sitting behind NAT gateways. IPv4 is the duct tape that has held things together for the last ten years while we prep a long term solution like IPv6. Alas, some people in the community think that since NAT has done such a good job fixing things for so long that it should be the all-in-one tool in their toolbox for every network problem. Some people think it’s a great way to provide security for a network. These people often confuse NAT with what a firewall does in conjunction with NAT. NAT in and of itself provides no additional security beyond masking addresses. NAT also adds in additional complexity when troubleshooting. NAT boundaries break things like VoIP. Packets hit the gateway device and get lost headed back to the source. NAT does this for almost every form of end-to-end communication in the Internet. If you add in Port Address Translation (PAT), where you translate a whole block of private addresses to one public IP address, you push the processor on your firewall to the breaking point. I don’t have the hard numbers to prove my supposition, but I’d venture a guess that 50% of a firewall’s processor time is spent translating NAT/PAT rather than shuffling packets to their proper destinations.
IPv6 doesn’t currently have a concept of direct address translation. Nor does it need one. There isn’t a dwindling pool of global addresses than need to be extended. With the large amount of addresses available, the odds that two companies are going to have overlapping address spaces that will need to be translated in a merger are slim. Right now, the only viable use case I can see for NAT used in relation to IPv6 is for translating the IPv6 addresses on a network to something that can access the IPv4 Internet without a dual-stacked router (NAT64). Even this use case is rather dubious in my mind, but Ivan has managed to convince me that it’s useful in the short term. So why do I still hear about RFC 6296? Why does Jeff Fry point out stories like this to me? What is this world coming to? Let me make this clear:
NAT on IPv6 is pointless and a bad idea.
There is no reason to implement native IPv6-to-IPv6 NAT (NAT66) in reality. The address space is way too big to require translation in the foreseeable future of my lifetime or even that of my kids. If you are really concerned about hiding your addresses or disguising your MAC address, you can look into the idea of Temporary Addressing. In the middle of writing this post, Paul Regan asked me about using NAT to translate when you move from one provider to another. That might be a good use case, and it happens to be the one that RFC 6296 is lined up to address, but if keeping your IPv6 space is so important when you move, why not sign up for a provider-independent block from your local Regional Internet Registrar (RIR) and run BGP to advertise it yourself? If you switch ISPs often enough to keep switching IP schemes every few months, maybe you need to worry more about stability and less about chasing the lowest ISP price. If your ISP keeps forcing you to switch addressing space that often, it might be time to shop around.
I truly believe that the people out there chasing the NAT66 sasquach are looking for a new security blanket. They’ve dealt with NAT for so long in IPv4 that the idea of using IPv6 sans NAT makes them lie awake at night in a cold sweat. Why else would you take something so unnecessary and bolt it on after the fact? There’s no need to have NAT unless you take the position “it’s how we’ve always done it”. The NAT66 proponents must think that NAT is needed simply because they’re unsure how to configure a firewall otherwise. Obviously, without NAT the Internet breaks. So we must have it in IPv6 or things won’t work right. However, I think that having NAT66 will cause people to keep configuring their networks incorrectly and lead to confusion and problems down the road. If IPv6 is going to require a shift in thinking like so many people keep telling me, why not truly shift our thinking away from things like NAT? We’ve already done it once before with the concept of reserved local addresses. RFC 1884 tried to define a site local address similar to what we think of with RFC 1918 addressing. This was such a horrible idea that RFC 3879 came out and deprecated the whole idea (Yes, I know about RFC 4193. I’m not talking about it.)
If there are people out there that think we still need to cling fervently to old ideas to help ease our transition to the Internet of the Future™, then I’m going to make my own proposal. I think it’s time that we put the IP checksum field back into the IPv6 header. Yes, I know that TCP has its own checksum and that the underlying packet must be good if the TCP checksum comes out okay. Yes, I know that having a checksum in the IPv6 header is silly if there aren’t going to be any naked IP packets floating around anywhere. However, I think that since it’s always been there in IPv4 it’s comforting to have it available in case I want to double check each of the packets moving into and out of my network. Who cares if it introduces a small amount of latency to calculate? I feel better knowing it’s still there. Now, doesn’t that kind of thinking sound silly? Yes, I purposely picked something totally trivial to make my point, but that’s how I feel about NAT. If we want to move forward out of the IPv4 Dark Ages and into the realm of the IPv6 Renaissance, we need to leave behind childish things like the need to NAT IPv6 packets on IPv6 networks. Let’s spend more time making the Internet work the right way and less time trying to make it work the way we think it should.