IPv6 vs NAT

There are many ways to make a networking protocol, and one of the key aspects of the protocol definition is the addressing. There are many ways to address the information (typically packets).

1. You can create a system where the data has a locally relevant address which defines some channel of communications. At the next hop there is a pre-set path for that channel to go to the next hop after that via some local channel. The target address in the packet changes as it goes hop to hop to get to the destination. The channel creates an end to end path. You can have many different paths across a network.

These paths could be pre-set or could be created by some other protocol. Examples of this are protocols like ATM and even TDM (phone calls). It is a separate issue of whether the data flows continuously at a pre-defined rate (like a phone call) or has some dynamic bandwidth (as ATM can do). What I am talking of here is the addressing system being used.

2. You can create a system that has some hop by hop local addresses in the original packet. This allows each hop to work out where next to send the packet. Typically the packet changes as it goes to create a reverse path allowing a reply. This has the advantage that you do not have to establish end to end pathways in advance and can send packets ad-hoc. However, it does mean that the addressing is variable length and you have to work out the path needed to make the packet address header which depends where you start from. E.g. using some other protocol to find the path needed from where you are to where you want to get to.

3. You can create a system where packets are addressed based on a globally unique ID that identifies the target. The address stays the same at each hop. Each hop uses this target address to send the packet logically closer to the designation. Usually in this case the source globally unique address is included to allow replies. This has several advantages. Protocols to look up addresses can return the same final unique destination address regardless of where the packet starts. It is a good system and how IP works.

Another key aspect of a protocol definition is the way it works with layers. You have distinct layers that are responsible for different levels of communications. E.g. a low level that gets packets to their destination. Layers above provide session management and reliable communications with retransmission and acknowledgments. Layers above provide more complex protocols like web pages and email and so on. The principle is that you have well defined interfaces between layers and a general hiding of information between layers to some extent.

Internet Protocol uses the third type of addressing I listed. It means that every IP packet contains a globally unique final endpoint destination and source address. Internet Protocol also provides means for communications at higher levels to work (e.g. ICMP, UDP, TCP).

Some people have said that IPv6 is "throwing the baby out with the bathwater". IPv6 is indeed replacing the IPv4 layer. Everyone that looks at IPv6 can find one or other thing that IPv6 could also have done. There are many small niggles and problems that could have been fixed or improved in making IPv6 which is a shame. However it does address the problem with IPv4 running out of space. It is a big change, but gives us a chance to get rid of NAT now.

The alternatives being suggested, which are basically lots more NAT are a problem for a lot of reasons.

NAT breaks the basic principle of globally unique target addresses. It changes to a sort of ad-hoc connection based addressing one side. It also interferes with higher protocols like UDP and TCP. UDP cannot work as designed via NAT! NAT has to understand UDP and TCP and ICMP and make changes to that layer. In some cases NAT has to make changes at the layers above that even. NAT has to understand the way IP is used at various levels to work at all.

NAT breaks almost all innovation in protocol development. Nobody could make a new IP protocol (along side ICMP, UDP, TCP) as it simply would not work through any existing NAT router. You would have to change the software (maybe even the hardware too) for all existing NAT routers in the world to add a new protocol. You can't even rely on UDP and TCP working as they should and make new application level protocols without assuming NAT is in the way, which restricts what you can do or means changes NAT routers. People complaining about IPv6 seem to understand that changing every router is a bad thing, but that is what NAT is forcing when ever anyone makes a new protocol.

Also, the idea you can just NAT more and more for end user connections misses the point. For a start it creates resource issues for ISPs (processing power, memory for session tracking, and limited numbers of sessions due to port number limits). It creates huge traceability issues (history of every session needed). So it will not scale indefinitely.

But also this is not the only issue. What about when hosting companies have no IPv4's left and you want to host a new web server? You can't just NAT that side. You have to create all sorts of bodges. There are ways of doing it, but they create yet new issues.

NAT is an evil bodge that should never have taken off. Are we stuck with it? Probably for IPv4, but we can make a fresh start with IPv6. NAT and RFC1918 can continue to stretch IPv4 so that devices on local networks (printers, etc) can carry on working without change. But new applications can start to rely on proper IP functionality using IPv6.

Now, what will happen is that IPv4 and IPv6 run in parallel. Machines will dual stack with no problem. IPv6 can "just work" as IP was always intended. IPv4 can be carrier grade NAT'd and bodged and get increasingly broken. But we then have the best of both worlds.

We should be concentrating on making that happen. Making it seamless for end users when they next replace their router (typically small routers go bang after a year or two anyway). We need ISPs to handle the IPv6 side too.

We need any moves to create any sort of IPv6 NAT to be stamped on as soon as they are suggested.

Look forward, not back!


  1. Time for a little documentation or recommendations maybe? All i've ever seen on IPv6 is a page of this is why IPv6 is needed, or whacking great 300 page+ manuals with reams of RFCs included. I could explain to a home user the basics of IPv4 within an hour, including NAT and PAT to the internet, but I've not encountered anybody, any documentation or any guides that aim this at the soho user who may not be a network geek, but wants to try this IPv6 stuff in a proper and safe manner.

  2. The basic operation of IPv6 is pretty much identical in principle to IPv4, apart from not having NAT or PAT!

    But a home user trying it will only really be simple when domestic routers support it. Then it will "just work" and won't need "trying" if the ISP supports it.

    If domestic routers did not have things like DHCP then home users would find IPv4 networking complicated too. It's not special to IPv6. What is "special" at the moment is the router manufacturers not yet making it easy, and no real reason why not.

  3. Small routers go bang after a year or two? I can report that my Linksys WRT54GS running OpenWRT has been going for about 6 years now, with no signs of trouble. Yes I could configure it for IPv6, but it would take me probably a whole weekend.

  4. Funny you should write that. The pregnant plug on a year old A+A supplied Zyxel went bang yesterday. Hope the Firebricks are more reliable.

    Seriously though, the technical excellence of IPv6 is irrelevant to most organisations. The PHB won't be remotely interested until the day beancounter central can't access the bank website on IPv4. The only way to get it out there faster is to provide IPv6 out of the box. It's already there in Windoze, and some ISPs but the bit inbetween is missing and as I suggested cynically on IRC, the manufacturers are holding back so everyone has to buy new kit when it becomes a necessity.

  5. OpenWRT IPv6 support is brilliant these days. It always surprises me though that AAISP don't offer pre-configured OpenWRT boxes for home users.

    It wouldn't take too much effort to find one device and support it (possibly with customised/branded images) and would solve http://www.aaisp.net.uk/news-ipv6-routers.html in-house as well as making it much easier for average users to get a sane default setup just like the IPv4 devices that you mail out as standard.

  6. I'm sorry, but I don't agree that to the home user, the operation of IPv6 is pretty much identical to IPv4.

    IPv4. DHCP server or manually program address, subnet and gateway.

    IPv6. Do nothing and have four addresses on your computer (Win 7 does this even when you have explicitly told it not to use IPv6 at all), no obvious gateway, no obvious way of seeing how the machine was automatically allocated an address and no obvious way of saying "This is the address I want to use" (well, Win XP anyway).

    It took my some time to get my head around IPv6. I can't see any of my customers even having the vaguest of ideas.

  7. Well, it should be - if there is a router announcement on the LAN then IPv6 "just works" as far as the end user is concerned.

    No reason the PC does not tell you what issued the route announcement like it does for DHCP on IPv4.

    No reason the PC does not tell you the IP it is using. Having FE80 addresses is not any more confusing than the fact you have on IPv4.

    No reason for the PC not to tell you the gateway it is using. Bear in mind that a "gateway" on an Ethernet is in fact just a MAC address and always has been for IPv4 or IPv6. Just that typically in IPv4 it is a MAC address resolved by ARP from an IPv4 address. No reason it has to be like that on IPv4 any more than IPv6. As for "What is my IPv6 gateway IP address" as opposed to MAC, well IPv6 makes that easy. Its your IP prefix ending in zero! You don't even have to guess - that is by default anycast LAN gateway address - simples.

    For the average domestic user - they do not need to know the gateway IP or MAC or they IPv6 address that they use when accessing the internet or who allocated the gateway. They just need the internet to work - that can and will (and does) happen.

    An excellent example we had some years ago was that we had made an error in our access control lists for outgoing SMTP email servers. We had forgotten to include 2002: prefix equivalents of IPv4 range for someone using 6in4. We had a customer confused that they could not send email as not allowed. We found they were using 2002: 6in4 IPv6 access. They had no idea - someone had put something on their LAN that did it and used RA. They were accessing email and web pages and all sorts using IPv6 with no idea they were doing it. Had it not been for our stupid config mistake they would have continued to do so oblivious of the fact. That is how it should be.


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

ISO8601 is wasted

Why did we even bother? Why create ISO8601? A new API, new this year, as an industry standard, has JSON fields like this "nextAccessTim...