multiple prefixes

[Lorenzo Colitti]

On Wed, Feb 13, 2013 at 3:00 AM, Matthew Huff <mhuff at ox.com> wrote:

> IMHO, the push to force end-to-end connectivity (no-nat) that pervades the
> IPv6 community has slowed the growth of IPv6 considerably.


Personally I don't have an issue with that.

The way I see it, regardless of this issue, it was always going to be
unrealistic to suppose that enterprises (which have may more resources than
consumers) would be substantial early adopters of a new networking protocol
whose main reason for existence is to solve a global resource shortage. The
incentives aren't there. And if you look at history, enterprises weren't at
the forefront of IPv4 adoption either. I wasn't there, but I bet that at
the time, there were plenty of enterprise network managers who scoffed at
this IP stuff, saying "We'll never connect our networks to the Internet,
and so it doesn't make sense to use this IP stuff. We're way happier with
frame relay".

IPv6 adoption may be happening a bit more slowly as a result, but it's
happening nonetheless (growth is ~3x year over year) and the architectures
that are being deployed are cleaner, which at the end of the day will lead
to a lower network cost for everyone, including enterprises.

Enterprise networks are very complex, routinely employing stuff like double
/ triple NAT, captive portals, MAC-address based authentication, etc. etc.
Personally I would hate that complexity to be a model for residential or
mobile Internet access, because complexity has capex, opex, and reliability
costs, and I think those just aren't the right tradeoffs for the majority
of Internet users, who are residential or mobile.

The way I see it, if the price of adopting a simpler, lower-cost
architecture is that enterprise adoption happens later on (because make no
mistake, if IPv6 is widely deployed in residential and mobile networks, it
*will* happen in enterprise networks sooner or later), then that's an
acceptable tradeoff. Others of course will disagree.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130213/86488c4d/attachment.htm>