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

[Owen DeLong]

On Feb 22, 2011, at 12:29 AM, Benson Schliesser wrote:

> 
> On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote:
> 
>> On Mon, Feb 21, 2011 at 19:08, Dan Wing <dwing at cisco.com> wrote:
>> 
>>> Its title, filename, abstract, and introduction all say the problems
>>> are specific to NAT444.  Which is untrue.
>> 
>> I just re-read the filename, abstract and introduction, and I disagree
>> that any of those say that the problems are specific to NAT444. They
>> all do state that these problems are present in NAT444, but not that
>> it's the only technology/scenario/configuration where you might find
>> them.
> 
> Let's at least agree that the text isn't precise.  I've had a large number of conversations in which relatively intelligent people advocated other (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is broken and draft-donley-nat444-impacts is evidence.  Either the draft is perfectly clear and all of these people are stupid, or the draft is misleading (intentionally or unintentionally).
> 
I would point out to them that the fact that their technology choice isn't
NAT 444 does not mean that they don't have the same problems, merely
that their technology wasn't part of the testing documented in the
draft.

I think the draft is perfectly clear and that humans, even intelligent
humans often have problems with this level of logic.

If A is a subset of B, it does not mean that A is not a subset of C.

Therefore, a draft that states that technology B has problem A
is not and cannot be logically construed as a statement that
technology C does not have problem A, no matter how common
it is for seemingly intelligent humans to make the mistake
of doing so.

>> More importantly, I am unsure the point of this argument. Are you
>> trying to say that the items listed as broken in the draft are not
>> actually broken? Because in my experience they are. IMHO, the fact
>> that they are also broken in other (similar) scenarios is not evidence
>> that they are not broken in this one. On the contrary, this scenario
>> seems to be evidence to the brokenness in the others (until we get a
>> chance to test and document them all - are you volunteering? ;).
> 
> There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters.  Interestingly, this position seems to be most pronounced from people not involved in operating production networks.  But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading.
> 
I don't think anyone has said that IPv6 is the only address family
that matters. What I think people, myself included, have been saying
is that IPv6 is the only way forward that does not involve many of these
problems. (See my earlier Titanic post).

As to whether or not it matters that people misinterpred draft-donly...,
I'm not sure whether it actually does or not. There is no flavor of NAT
that is particularly desirable. It's a matter of choosing the one that is
least damaging to your environment where least damage may
boil down to a choice between 5% and 3% remaining functionality.

> On the contrary: While I emphatically agree that IPv6 is the path forward, I don't accept the notion that IPv4 no longer matters.  IPv4 is the present-day Internet, and IPv4 connectivity is demanded by present-day paying customers - you don't burn the bridge until *after* you've crossed it.  Further, given that IPv4 does matter yet has an exhausted address supply, there exists a need for IPv4 address sharing technology.  Fundamentally, this means that we need to discuss and engineer the best possible address sharing technology.  It may never be as good as native end-to-end IPv6, but sub-optimal is not the same thing as "broken" as others have claimed, and sub-optimal might be acceptable if it's the only alternative.
> 
I don't think anyone is saying IPv4 no longer matters. I think we are
saying that effort spent attempting to make the deteriorating IPv4
situation deteriorate less is both futile and better spent on making
the IPv6 deployment situation better.

> Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users).  But that's a different conversation.
> 
Only if you expect that you can rely on a supply side in such a market.
I am unconvinced that such will be reliable, especially after about 6
months of trading. This also presumes that more sensitive users can
be defined in terms of what those users are willing (or able) to pay.


Owen
(who is very glad he has provider-independent addresses in
both families as we approach this iceberg)