[ppml] IPv6>>32

> So Verizon has a revenue stream of $40/month for supplying a static
> address.
>
Verizon gets away with this in IPv4 because there is a perceived
scarcity of addresses, and, people will let them get away with it
as a result.

Verizon will face competition in IPv6 that will gladly give end users
a /64 or /48 because they don't really have to do much to justify that
they have done so and they don't have to worry about having such assignments
questioned by their RIR.

That will create market pressure on Verizon to stop charging $40 for
a reasonable sized network.  My current provider, for example, charges
me $59/month and is routing PI addresses for me on DSL.  Technically,
I have 768 static addresses for only $14 more than Verizon is charging
for a single dynamic, so, it's already economically feasible.

Do you really think than in the V6 world where RIR audit becomes much less
of an issue that providers will stonewall instead of undercutting Verizon
by offering more address space for the same price?

Once that happens, applications that require more than one address per user
will begin to gain acceptance.  As they gain acceptance, Verizon will face
customers that ask "Why won't your network let me run blah, when it works
fine for my friend on XYZ provider's network?"

> Now, I can't predict the future, but I can already see the arguments
> being made by sales, marketing, and the like that in an IPv6 world
> you should get a single address, and if you want more (1? 5?, are
> we really going to hope for a /64?) it will be $40/month.  I've
> never met a sales, marking, or board member who would give up
> $40/month per subscriber "because the protocol designers say it's
> a good idea".
>
I can see that argument being made.  Heck, I've seen sales people invent
all kinds of crazy things.  However, when they're faced with competition
offering something better for the same price, they're kind of stuck.
This is the one good thing about capitalism.  We should at least count
on it working.

> All of which is why I'm extremely cynical that:
>
Which crumbles when that one assumption falls.

Owen


-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.arin.net/pipermail/ppml/attachments/20050512/21d33982/attachment.bin