[137767] in North American Network Operators' Group
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6
daemon@ATHENA.MIT.EDU (Benson Schliesser)
Fri Feb 18 17:27:13 2011
From: Benson Schliesser <bensons@queuefull.net>
Date: Fri, 18 Feb 2011 16:26:57 -0600
In-Reply-To: <FE8D9D35-42C7-45B0-90E7-1FCAF177EC04@delong.com>
To: Owen DeLong <owen@delong.com>, Zed Usser <zzuser@yahoo.com>,
nanog@merit.edu
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote:
> 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.
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.
>> 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.
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).
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.
Cheers,
-Benson
