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!