Subject: Re: avoiding pitfalls in v4/v6 NAT (was Re: About IETF communication skills)

From: [email-masked] (Noel Chiappa)
Date: Sun, 3 Aug 2008 15:17:13 -0400 (EDT)

> From: Keith Moore <[email-masked]>

    > You don't need to add it to all (or most) IPv6 implementations.

More hair-splitting...

    > The goal ... is not to magically make all boxes and apps suddenly be
    > able to communicate with both IPv4-only and IPv6-only hosts as if there
    > were no difference between the two. 

So you're willing to live with the converse of that? I.e. a situation where
communication between the two groups is spotty and unpredictable?

    > Enterprise network management will continue to evolve and they'll see
    > the benefits of using v6. 

A familiar prediction...

    >> Either this functionality is added to .. IPv6 .., or the IPv6/v4
    >> NAT boxes .. will display the same crippling problems as v4/v4 NAT...

    > No, because (a) you're not trying to impose this on all hosts or apps,
    > ... and (c) you engineer these boxes from day one in such a way as to
    > avoid the crippling problems we've experience in v4 NAT.

I see no refutation of my basic observation, here.

	Noel
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Sun, 03 Aug 2008 19:06:26 -0400

>     > You don't need to add it to all (or most) IPv6 implementations.

It's not hair-splitting if it significantly reduces the barrier to adoption.

> communication between the two groups is spotty and unpredictable?

I'm willing to live with a world where a v6-only app that needs to 
communicate with a v4 peer, or a v4-only app that needs to communicate 
with a v6 peer, has a well-defined way of doing so - even though it 
might require extra effort (in the form of extra API calls and/or 
binding to a library that does them implicitly) and infrastructure (in 
the form of a willing v4-v6 NAT).  (Particularly if this extra effort 
doesn't burden communication between v6-only peers.)

>     > the benefits of using v6. 

Again, it's a big topic.  I don't want to gloss over the problems - 
they're considerable.  But neither do I assume that enterprise network 
operators in general are not capable of leveraging advantages of IPv6.

> I see no refutation of my basic observation, here.

I see no support for your assertion that this needs to be a core part of 
IPv6.

Keith