[arin-ppml] inevitability of NAT?

[Owen DeLong]

On Feb 10, 2011, at 7:42 AM, Benson Schliesser wrote:

> 
> On Feb 10, 2011, at 8: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.
> 
> CGN is a NAT, and is essentially just a higher-scale implementation of the NAT that we all know and "love".  I think you're right to challenge the oft-repeated belief that CGN is somehow fundamentally different.  That being said, the deployment model of CGN is significantly different from CPE-based NAT, and that fact does results in some differences in how it can be used.  The two fundamental differences are fairly obvious: 1) CGN is run by a carrier, and so the subscriber doesn't necessarily have the same degree of control.  2) CGN allows for greater oversubscription of public IP addresses, and so there is potentially a many-to-one relationship between subscribers and public addresses.
> 
You left out 3) Most CGN implementations will be a second layer in front of an existing consumer CPE NAT solution.

> The implications of #1 are the things you described above.  Static port forwarding is a problem unless the subscriber is given a tool to configure it.  And even then, it's something that doesn't scale very well - e.g. static entries for every subscriber rule, managed across a number of redundant CGN nodes, which may each have different public address pools, etc.  My personal opinion is that static port forwarding (for running servers at home, let's say) is better served by paying for a static public IP address from the ISP.  (Conversely, ISPs should offer static public addresses in order to support "server" users.)  In terms of dynamic port forwarding for apps that require that kind of functionality, CGN generally doesn't support UPNP for obvious reasons.  But there is work in the IETF to develop a protocol called PCP, that improves on UPNP (and similar protocols) in a number of ways.  Generally speaking, PCP will be much better suited for dynamic control of a CGN by clients.
>   In the meantime, until PCP is available, users should consider turning off UPNP support in their gateway to make sure apps don't rely on it when they're behind a CGN.
> 
> The implications of #2 are typically related to things like dynamic DNS entries.  Of course, this is mostly relevant for people doing static port forwarding, which has other complications per my comment above.  But to be specific: if you're sharing an IP address, and that address is registered in DNS, then it's possible the DNS entry will actually point to a number of completely different server resources (depending on port number, of course).  E.g. webcam.myhouse.whatever might point to an IP address, and listening on port 8080 might be my webcam while listening on port 8081 might be my neighbor's webcam; webcam.neighborshouse.whatever in the DNS might point to the same IP address.
> 
The implications of #3 are that most of the current NAT traversal technologies cannot and will not function.

> By the way, these implications are true for essentially any form of CGN, because the deployment model is the same (deployed in the carrier's network).  Arguments about DS-lite versus NAT444 are a bit misleading.  And in any case, the right conclusion is to deploy IPv6 (via 6rd if one must, native as soon as one can) to avoid this whole mess.*
> 
Not quite. DS-Lite avoids the issues associated with #3 and has the additional advantage that native IPv6 comes along for the ride.

> Cheers,
> -Benson
> 
> 
> * - Full Disclosure:  I am employed by Cisco Systems, which I assume is happy to sell NAT hardware as well as IPv6-capable routers.  However, my statements and opinions are my own and do not represent my employer, fellow employees, friends, family, or any other entity.
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.