Fresh off my recent fame from my NAT66 articles (older and newer), I decided first thing Monday morning that a little experiment was in order. I wanted to express my displeasure for sullying something like IPv6 with something I consider to be at best a bad idea. The only thing I could come up with was this:
The response was interesting to say the least. Questions were raised. Some asked if I was playing a late April Fools joke. Others rounded up the pitchforks and torches and threatened to burn down my house if I didn’t recant on the spot. Mostly though, people made sure to express their displeasure by educating me to the fact that I should use something else to do what I wanted rather than rely on the tried-and-true metaphor of a Start Menu.
Now do you see what I’m talking about with NAT66? Some people think that NAT is needed not because it’s a technological necessity. Not because it’s solving fifteen problems that IPv6 has right now. They want NAT because they really don’t understand how things work in IPv6. It’s the same as bolting a Start Menu on to OS X. When I started using my new MacBook a few months ago, I took the time to figure out how to use things like Spotlight and Alfred. They weren’t my Start Menu, but they worked almost the same way (in many cases better). I didn’t protest the lack of a metaphor I clearly didn’t need. I adapted and overcame. And in the end I found myself happier because I found something that worked better than I had hoped.
In much the same way, people that crave NAT on IPv6 are just looking for familiar metaphors for addressing. I’m going to cast aside the multihoming argument right now because we’ve done that one to death. Yes, it exists. Yes, it needs to be addressed. Yes, NPT is the best solution we’ve got right now. However, when I started going through all the comments on my NAT66 blog post after the link from the Register article, I noticed that some of the commenters weren’t entirely sure how IPv6 worked. They did understand that the addresses being assigned to the adapters were globally routable. But some seemed to believe that a globally routable address meant that every device was going to need a firewall along with DDoS protection and ruleset monitoring. Besides the fact that every OS has had a firewall since 2002, let me ask one question. Are you tearing out your WAN firewall when you move to IPv6? Because as far as I know, you still one have one (maybe two) WAN connections that are terminated on some device. That could be a router or a firewall. In the IPv4 world, that device is doing NAT in addition to controlling which devices on the outside can talk to the inside. Configuring a service to traverse the firewall is generally a two-stage process today. You must configure a static NAT entry for the device in question and then allow one or more ports to pass through the firewall. It’s not too difficult, but it is time consuming. In IPv6, with the same firewall and no NAT, there isn’t a need to create a static NAT entry. You just permit the ports to access the devices on the inside. No NAT required. If you don’t want anyone to talk to the devices on the inside, you don’t configure any inbound rules. Simple as that. When you need to poke holes in the firewall for things like web servers, email servers, and so on, all you need to do is poke the hole and be done.
Perhaps what we really need to end this NAT issue is wildcard masking for IPv6 addresses in firewalls. I have no doubt that eventually any simple home network device that support DHCPv4 today will eventually support DHCPv6 or SLAAC in the near future. As fast as new chipsets are created to increase the processing power we install into small office/home office devices, it’s inevitable that support will come. But to support the “easy” argument, what we likely need to do is create a field in the firewall that says “Network Address”. That would be the higher ordered 48 bits of the IPv6 address. Once it’s plugged in, the hosts will use DHCPv6 or SLAAC to address themselves. Then, we select the devices from a list based on DNS name and click a couple of checkboxes to allow ports to open for inbound and outbound traffic. If a customer is forced to change their address allocation, all they need to do is change the “Network Address” field. Then, software on the backend would script changes to DHCPv6/SLAAC and all the firewall rules. DNS would update automatically and all would work again. Perhaps this idea is too far fetched right now and the scripting necessary would be difficult to write at the present time. But if it answers the “easy” outcry about IPv6 addressing without the need to add NAT to the protocol, I’m all for it. Who knows? Maybe Apple will come up with something just this easy.
For the record, I really don’t think there needs to be a Start Menu in OS X. I think Spotlight is a perfectly fine way to launch programs not located on the dock and find files on your computer. Even alternatives like Alfred and Quicksilver are fine for me. The point of my tweet and subsequent replies wasn’t meant to advocate for screwing up the UI of OS X. It was meant to show that while some people think that my distaste for NAT is silly, all it takes is the right combination of silliness to get people up in arms. To all of you that were quick to jump and offer alternatives and education for my apparent lack of vision, I say that we need to focus effort like that into educating people about how IPv6 works or spend our time figuring out how to remove the roadblocks standing in the way of adoption. If that means time writing scripting for low-end devices or figuring out easy UI options, so be it. After all, someone else has already figured out how to create a Start Menu on a Mac: