[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on unmaneval-00
On Wed, 19 Nov 2003, Chirayu Patel wrote:
> 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.
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 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.
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).
> 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?
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