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

Fri Feb 18 22:46:23 UTC 2011

On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote:

> 
> On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote:
> 
>> On Feb 18, 2011, at 12:24 AM, Zed Usser wrote:
>>> 
>>> 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.
> 
> The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues.  However, it conflates NAT444 with CGN.  And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN.  This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN.
> 
NAT444 is one implementation of CGN and the issues it describes all apply to NAT444.

It does not claim that it discusses issues unique to NAT444. It claims that all of the issues it discusses
apply to NAT444. That claim is accurate.

> 
>>> 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.
> 
> Yes.  And today's customers enjoy being able to communicate with the IPv4 Internet.  CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice).
> 
I remain unconvinced of the accuracy of this statement.

> Of course, tomorrow morning's customers will enjoy communicating with the IPv6 Internet even more, so as somebody else already said: deploy IPv6 alongside any CGN solution.
> 
Absolutely. Also, I think the intent of the draft is to serve as a further heads-up to content and application
providers that their customer experience in a NAT-444 environment is going to suck and they need to
deploy IPv6. Further, it also serves to provide a guide for help-desks to deal with the consequences of
having deployed a NAT444 solution in their network.

Owen