[arin-ppml] IPv6 adoption, map-encap for IPv4?

[Paul Vixie]

> > furthermore, what i mean by "fixed return" is that it's
> > economically damned: the more effort we put into it the more
> > expensive that effort will turn out to have been.  ...
> 
> Naturally, the more effort the more cost.  ...

no, and that's pivotal.  if ipv4 had legs, had a long life ahead of it, then
effort spent on ipv4 would have a variable return, in which case one could
conceptually speaking amortize the effort over an unknown period, which
economists love (it's the miracle of capital without depreciation.)

when i say "has a fixed return" you need to hear darth vader's breath and
see him standing over there with a light sabre all ready to go.  fixed return
on a variable investment means "don't go there" and "don't do that."

> The best place to debate Tony's proposal is the RRG list.

i'm not qualified to debate any of tony's proposals, which is undoubtedly why
i am here on PPML talking about economics and policy, rather than over on RRG
talking about ones and zeroes.

> > alain durand's current plan is to native V6 to their customer edge and
> > backbone, and use native V6 to carry NAT'd V4, and thus get provide stack
> > to the comcast customer base. apple and microsoft, as well as every
> > IP-capable device designed or manufactured in japan, as well as most
> > f/l/oss software, will all use native V6 if it's present.
> > 
> > there's a very real deployment scenario involving islands of this kind of
> > dual-stack, followed by address space shortages and/or explosive routing
> > table deaggregation, followed by heightened, agitated capital investment
> > in more dual-stack because it's a way to avoid the worst pain of the
> > shortages/explosions.

> OK, but I think this falls a long way short of what end-users want and need
> in the next few years.

there is no direct path between what end-users want or need, and what we make
available.  it's an indirect path, and all i intend to show with the above is
that there will be a way for the earliest people who have nothing to sell and
therefore feel pain, to avoid that pain.  ljcamp's s-curve shows that the
period during which people feel pain will be long.  my example shows that
they will have choices less painful than going out of business or bootlegging
IPv4 address space or paying speculators for IPv4 address space or living with
explosive IPv4 routing table deaggregation.  human history shows that with
those choices available, we will see pressure on the IPv6 routing table soon
enough that working on anything else than locator-id split for IPv6 is an
irresponsible and dangerous waste of time.

> I think this optimism about early migration to IPv6-only is based on an
> unrealistically bleak notion of how difficult it will be to make much better
> use of IPv4 space in the next decade or two and on an unrealistically rosy
> view of how many end-users won't be troubled by apps and various Internet
> services, not least most web-sites, not working via an IPv6-only service.

i don't call it optimism.  there will be a lot of pain for a lot of people,
since human history shows that everybody does their homework at 1AM the night
before it's due, and the network effect says that everybody is everybody
else's hostage when it comes to IPv6 adoption.

however, people will have choices.  and if you think my notions of the IPv4
endgame are bleak, you should come to los angeles in october and put a couple
of beers into john curran and ask him why explosive deaggregation is
absolutely inevitable.  then you'll start calling me "mr. sunshine".

> If someone got a bunch of ordinary home users this year, and put them on an
> IPv6-only service with state of the art NAT-PT or whatever, and then found
> that 90% of them or more didn't notice much difference, and didn't make more
> than one or two support calls, then I would modify my views.

"oh i hope and pray that they will..." (schoolhouse rock)

> However, many DSL modems support uPnP, and this already provides an
> automated and robust method by which applications on PCs can punch holes in
> the modem's NAT and so have a reasonably stable publicly accessible UDP or
> TCP port.  This means they can accept incoming communications, run a web
> server, game server, fully functional P2P client/server etc.  Various
> dynamic DNS services makes these servers etc. easily accessible and
> apparently stable to other end-users.  So it is not as if this IPv6 approach
> is the only way of getting a stable public IP address for most users who are
> on single IP address DSL services with NAT in the modem.

when i wrote the software described by http://sa.vix.com/~vixie/proxynet.pdf
in ~1995, i knew that i was making all kinds of cool things possible and thus
opening alternatives.  but i also knew it wouldn't scale, wouldn't last, was
not the desireable way forward as would be measured through the lens of
history.  that's how uPnP's above-described feature set looks to me right now.

if you're having a conflict of vision having to do with ALG/NAT vs end-to-end
then i don't want to be involved.  ALG/NAT feels too much like minitel, 
compuserve, old-AOL, old-MSN, none of which have inspired internet growth,
and all of which were swept aside by internet growth.