[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on unmaneval-00



See below.

CP

On Wed, 19 Nov 2003 10:32:24 +0200 (EET), "Pekka Savola"
<pekkas@netcore.fi> 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