[ppml] dual-stack (was Re: Expand timeframe of Additional Requests )
Paul Vixie
paul at vix.com
Thu Aug 16 11:54:25 EDT 2007
> I see IPv6 in the same boat, trying to compete with IPv4 10 years (okay,
> probably like 25 years) later with essentially the same feature set.
> That's a hard sell.
this analogy also falls apart (like all analogies) since there's no way that
the entertainment industry could have "run out" of betamax and offered VHS as
a way to keep doing what they'd been doing without "hitting the wall". we all
want continued growth, enabled rather than fettered by technology.
> And folks. Please don't forget. The only migration strategy towards IPv6
> is dual-stack. Folks are going to need both v6 and v4 addresses for a
> long time, this isn't going to relieve pressure for v4 addresses.
this seems to argue that we should have been deploying dual-stack for some
years now, and that david conrad's soft landing proposal doesn't go far
enough since it doesn't REQUIRE dual stack, merely asks to hear a plan for it.
if we're going to need new V4 addresses for a long time, but we only have a
supply that will last a short time, then the pressures toward NAT, toward
black marketeering and piracy, toward deaggregation and routing table bloat,
and toward RIR shopping and IP address globalization, give me a serious case
of the heebee jeebees.
can we talk about ways to use our last years of new IPv4 to get dual stack
running everywhere, or at least running in enough places that a V6-only client
in the post-V4-depletion era will have services they can talk to? should the
conrad "soft landing" proposal require dual-stack for V4 allocations starting
years before projected depletion? or maybe just for access-side or content-
side?
(separately and in other forums more technical, the industry ought to work on
ways to make a V4-only pee cee able to get V4-like services from a local proxy
that looks like a default gateway but actually does some kind of V6 tunnelling
thing -- like NAT-PT except deployable. dual-stack as our only option, sucks.)
More information about the ARIN-PPML
mailing list