Subject: Re: Comments on unmaneval-00

From: "Chirayu Patel" <[email-masked]>
Date: Wed, 19 Nov 2003 15:57:13 +0530

See below.

CP

On Wed, 19 Nov 2003 10:32:24 +0200 (EET), "Pekka Savola"
<[email-masked]> said:
>
> On Wed, 19 Nov 2003, Chirayu Patel wrote:
> > ,----[ text from unmaneval-00 ]
> > |    During the transition phase from IPv4 to IPv6 there will be IPv4
> > |    only, dual stack or IPv6 only nodes. In this document, we make
> > |    the hypothesis that the IPv6 only nodes do not need to
> > |    communicate with IPv4 only nodes; devices that want to
> > |    communicate with both IPv4 and IPv6 nodes are expected to
> > |    implement both IPv4 and IPv6, i.e. be dual stack.
> > `----
> >
> > I don't agree with such an hypothesis. As long as IPv6-only devices
> > are not barred, it is just a matter of time when some IPv6
> > application proves to be too sexy (for IPv4-only devices) to resist.
> >
> > From the perspective of this document, mechanisms that can be used to
> > bridge IPv4-only and IPv6-only devices should be evaluated.
> >
> > The same comment applies to the text in section 3.2.
>
> This has been discussed in the past, and I believe should not be
> substantially changed.
>
> The point is, if we don't require something like this, we'll end up in
> scenarios where you deploy NAT-PT or something similar internal to an
> unmanaged network.  Moreover, if there are some "too sexy" new IPv6
> applications aout there, I'd suppose they're ones that work even work
> through NAT or NAT-PT. And that's not something we'll want.
>
> So, I think it's very reasonable to recommend deploying dual-stack at
> least as long as you don't have v4 nodes to talk to any more.

I agree with the recommendation, and it will be followed initially...but
somewhere down the line maintaining IPv4 stack (in dual stack networks)
might prove to a burden. (ISP's might not want to support IPv4 as the
traffic is too less, global IPv4 addresses are not available, and all the
relevant services are accessible over IPv6) This will probably happen
when the IPv6 Internet will be much bigger than the IPv4- only Internet.

It is then that application translators or NAT-PT solutions will be
developed to either access IPv6 application from IPv4 or viceversa. The
former seems to be more likely.

> The other point here is that if some v6 app just proves too sexy to
> resist, such users/nodes will have an incentive to deploy v6
> themselves, not just translation -- and that's what we want.

Deploying IPv6 may not be simple in case the ISP does not support IPv6,
and the "supporting infrastructure" is not free or efficient. Moreover,
the IPv6-only app developers might not want to wait for the potential
IPv4 users to deploy IPv6..but rather deploy proxies to attract them. On
the surface it might seem that the app developers should probably modify
the app to support IPv4...but you never know the logistics.

From the unmaneval document perspective, this is the case where an IPv4-
only network wants to access IPv6-only applications. The document should
mention that the only way to access IPv6 applications would be through
external translators (if available). However, the user experience might
not be good as certain features of the application might not be
available, and it may be slow. (If both the assumptions are false there
is not much incentive to deploy IPv6). The document should list the
translation services, and give a recommendation (if possible).

What do you say?

CP

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2003 12:53:56 +0200 (EET)

> former seems to be more likely.

There are undoubtedly scenarios in the "end-game" case, maybe in 10 
years (if we're lucky!) or more, which are difficult to estimate at 
this point.  I don't think they should be considered at too much 
depth.

> the app to support IPv4...but you never know the logistics.

I think we have to ensure that IPv6 is easy enough to obtain for the 
users so that app developers can develop IPv6-only apps.  The other 
approach here is that we don't ensure the "easiness" of IPv6, but 
recommend that app developers do dual-stack apps, not IPv6-only.

Nonetheless, the potential IPv6-only apps (peer-to-peer, etc.) are
typically those that do NOT work properly through proxies, translators
and such... so it certainly would seem to make sense to either deploy 
them dual-stack (if generic enough to be useful), or v6-only (uses 
features of IPv6 which would be munged by the translators anyway).
 
> translation services, and give a recommendation (if possible).

I'll just have to say I fundamentally disagree with this model.  I do 
not think we must be catering for the case where IPv4 nodes must be 
able perform functions provided on purpose for IPv6 only; that's where 
we can assume that the node gets updated.

Certainly, this clearly seems to need more justification/text to make
the point across better..

On the other hand, the end-game case you mentioned first, going from 
v6-only to legacy v4 (for e.g. some very special business application 
coded in the 1970's) may be something we have to consider .. but 
that's the other way around, and not an urgent matter to consider.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Suresh Satapati <[email-masked]>
Date: Wed, 19 Nov 2003 09:32:54 -0800 (PST)

Chirayu,

We captured this scenario in NAT-PT Applicability.
http://www.ietf.org/internet-drafts/draft-satapati-v6ops-natpt-applicability-00.txt

The same discussion did take place within "unman" design team, and the
initial versions had some text to that effect. Later on, that text was
removed for obvious reasons (that you see on this list) ;-)

--
Suresh