[arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)

Fri Feb 18 14:27:12 UTC 2011

On Feb 18, 2011, at 12:24 AM, Zed Usser wrote:

> On Thu, Feb 10, 2011 at 14:17, Chris Grundemann wrote:
> 
>> In case you have not already found this: 
>> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 
> 
> There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list.
> 
> "draft-donley-nat444-impacts-01 is somewhat misleading.  It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems:
> 
>  * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network)
>  * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home)
>  * DS-Lite (which is an LSN / NAPT44 in the carrier's network)
>  * stateful NAT64"
> 

I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while
technically accurate isn't particulrarly meaningful.

> http://www.ietf.org/mail-archive/web/behave/current/msg09027.html
> 
> Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :)
> 
I guess that depends on whether you like having customers or not.

> Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but:
> - Less torrenting
> - Less Netflix watching
> - Less FTP downloads
> - Less video streaming in general (webcams, etc.)
> 
> You might take a hit on online gaming, but what else is there not to love? :)
> 
+ More support phone calls
+ More unhappy customers
+ More cancellations
+ Less revenue
+ More costs
+ CALEA joy

> Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way.
> 
An interesting theory.

> Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case?
> 
No, we need to move forward with IPv6 on all levels in order to reduce the need for these solutions.
Joining the IPv4/IPv6 domains doesn't work out all that well and a dependency on doing so is
broken in a number of ways, many of which are documented in the draft.

Owen