Re: Comments on unmaneval-00

[Suresh Satapati <satapati@cisco.com>]

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

On Wed, 19 Nov 2003, Chirayu Patel wrote:

>
> 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
>
>