[137772] in North American Network Operators' Group
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Feb 18 17:49:48 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <813D8351-9884-4820-A10E-BD3B2FB632CE@queuefull.net>
Date: Fri, 18 Feb 2011 14:46:23 -0800
To: Benson Schliesser <bensons@queuefull.net>
Cc: nanog@merit.edu, Zed Usser <zzuser@yahoo.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote:
>=20
> On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote:
>=20
>> On Feb 18, 2011, at 12:24 AM, Zed Usser wrote:
>>>=20
>>> There's a bit of critique on the NAT444 document on the BEHAVE IETF =
WG list.
>>>=20
>>> "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:
>>>=20
>>> * 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"
>>>=20
>>=20
>> 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.
>=20
> 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.
>=20
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.
>=20
>>> http://www.ietf.org/mail-archive/web/behave/current/msg09027.html
>>>=20
>>> 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? :)
>>>=20
>> I guess that depends on whether you like having customers or not.
>=20
> 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).
>=20
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.
>=20
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
