[arin-ppml] inevitability of NAT?

[Owen DeLong]

On Feb 10, 2011, at 8:30 AM, Benson Schliesser wrote:

> 
> On Feb 10, 2011, at 10:05 AM, Jack Bates wrote:
> 
>> On 2/10/2011 9:42 AM, Benson Schliesser wrote:
>>> 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.
>> 
>> User got a faulty DSL modem a few months back. uPNP wasn't enabled per the norm. User was unable to use some xbox functionality.
>> 
>> The degree at which things are depending on uPNP has grown to making it almost mandatory. Turning it off is likely to lead to things breaking. In addition, no protocol is going to fix LSN well. I don't think any studies have really been done to see at what scale applications are currently using uPNP to (port forward, open firewall). This places practical limits on the number of people doing a certain thing while behind a single IP.
> 
> My opinion, to some extent, is that in the coming years: clients that require IPv4 but don't work well with NAT should expect to break.  On the other hand, clients with IPv6 support should experience an improved experience.
> 
While I agree, that's very different from saying that "clients that work well with IPv4 NAT today should expect to break tomorrow."

> That said, UPNP (and NAT-PMP etc) just don't scale to the carrier scope.  PCP is coming, and clients should expect to migrate if they need IPv4 NAT support.  PCP will also support IPv6 pinholes (i.e. control of security in IPv6-enabled CPE), so clients should migrate regardless.
> 
Why would anyone bother porting application code to PCP instead of just adding IPv6 capabilities? It seems to me that adding IPv6 is usually much simpler than adding PCP support and yields a much longer lifetime.

The point is that we need to continue to support some applications that will not see upgrades. Telling application vendors to add support for two future paths (or worse, having them randomly choose between them) is completely the wrong direction for this. If we're going to attempt to make multi-layer NAT support for legacy applications, we should do what we can to make that support cope with what exists today.

Diverting effort from IPv6 porting to backport more hacks to deal with an expanding complexity of the IPv4 NAT environment reminds me of the old joke that starts out "Doctor! Doctor! It hurts when I do this!"



Owen