In the decade or longer transition to IPv6, NAT is inescapable. This is a direct consequence of the design of a new protocol which is 100% incompatible on the wire, there is not the slightest compatibility mode.
We may not like this, and I certainly do not, but NATs are inevitable, get over it.
Alain Durand (Comcast) and Miyakawa Shin (NTT) have a common problem. They say that their networks’ customer edges are so large that, even giving each CPE a small bit of IPv4 space for the ‘front’ of a NAT, they need two to five /8s of IPv4 space. They are in a terrible trade-off space. They either request many public IPv4 /8s from the internet registries (not likely with the exhaustion of the IPv4 IANA free pool on the horizon) or do something more complex.
The approach they are testing is being called Carrier Class NAT. It is essentially one or more IPv4 NATs in the core of their networks and various tunneling and translation techniques. If the CPE has dual stack, traffic where source and destination is IPv6 would not have to me NATted.
We can contrast this to, for example, NAT-PT on the CPE, which would probably scale to the needs of even a large non-consumer backbone. But, as we noted above, Alain and Shin would need way too much IPv4 space just to front the NAT-PT front ends for their large consumer networks.
I and a few other researchers have taken up a desperate search for alternatives. The reasons are simple.
‘Carrier class’ is a euphemism for centralized. More semantics move to the core of the network. This is bad in and of itself. Net-heads call it ‘telco-think’ because it is the telco model of smarts in the core as opposed to the internet model of a simple, just forward packets, core and smart edges.
With the smarts at the edges, e.g. NAT-PT, I can easily field new protocols between consenting end-points by just tweaking the NATs at the consenting CPEs, even adding ALGs if needed.
With NAT in the core, then if a customer wants to field a new application protocol which requires cooperation from the NAT, they get to beg help from Comcast and NTT and all other users of carrier class NATs. This is the ultimate horror the NAT-haters fear, and they are not all that wrong.
You don’t build an internet walled garden at the edges, you build it by restricting the core. Comcast has recently received a lot of bad press for just this, though I know that Alain is very far from the those responsible. But be assured that the developer/deployer of new applications will be talking to Comcast’s walled garden loving lawyers not Alain.
It means that all new application protocols have to go through the carrier lawyers to be allowed to be handled by the NATs in their core. So, if someone wants to deploy a new application, they can talk to Comcast’s and NTT’s lawyers or do it over HTTP, pick your poison.
And remember that, as IPv6 deploys, and we want to have one internet, i.e. IPv4 nodes talking freely with IPv6 nodes, then translation must be done somewhere. The challenge is whether someone can figure out a scheme where it is done for these large networks at the customer edge, not in the core.