[arin-ppml] inevitability of NAT?

[Owen DeLong]

On Feb 10, 2011, at 6:41 AM, Scott Helms wrote:

> 
>> They work through CONSUMER NAT because consumer NAT has nat traversal facilities like uPNP.
>> 
>> LSN/CGNAT is a whole different ballgame.
>> 
> 
> Lets step back a moment.  Why is LSN/CGNAT different from consumer NAT?  Is it only because of a perceived lack of knobs?
> 
> If I am going to explain to a CFO that "CGNAT is bad" I have to articulate exactly why its bad.  While I don't know if this is the case or not there is no reason that the CGNAT vendors can't expose to end users the ability create forwarding rules based on user profiles (could be stored in TR-069, RADIUS, DHCP, LDAP, or even DDNS).  I may be naive here because I haven't actually verified with Cisco and the others that they are planning this but if their product managers missed something that obvious I will be greatly surprised.  While UPnP will not  be part of that solution for obvious reasons building a web page that works with some sort of storage directory is trivial.
> 

It's not just perception. The knobs aren't there, and, even if they were, as you pointed out, they can't/won't be the same knobs that exist in consumer NAT boxes. The problem with this is that many applications depend on the ones that exist and updating them to support different ones is probably at least as much effort as updating them to support IPv6.

Further, most LSN/CGN implementations will not be single-layer. Most NAT solutions depend on a Private->Public or Private->Public->Private
structure with a rendezvous host in the Public zone to coordinate knowledge of both sides of the translator. In the LSN/CGN scenario,
you have Private->Private2->Public- or worse Private->Private2->Public->Private or worse still Private->Private2->Public->Private2->Private.

There is no ability to have Rendezvous hosts in all of the Private2 sectors.

This makes a huge difference in the way applications currently operate and means that porting to IPv6 is, in most cases, simpler than
incorporating sufficient workarounds to cope with LSN/CGN.

Owen