[arin-ppml] IPv6 Allocation Planning

[Ted Mittelstaedt]

On 8/10/2010 9:05 AM, Chris Engel wrote:
>
>> The current "slow start" philosophy of keeping IPv6 addresses away
>> from entrepreneurs, small businesses, individuals, etc, seems to
>> have been highly effective.
>>

What good is the RIR handing a small business an IPv6 block when
there's nobody that that small business can plug into that will
route it?

Tunnelling and 6to4 are not answers.  They were kludges and it is
a good thing that not a lot of folks implemented them.  If
they had it would have set back native dual-stacking on the Internet
by decades because most ISP's would have had end users tunnelling
over their IPv4 networks to IPv6 gateways.

>> - It has kept IPv6 from being deployed in any sizable way until we
>> now face the wall with the end of IPv4 allocations probably next
>> year.
>>
>> - We now face a forced rollout of IPv6 without enough experience in
>> it, especially in large scale IPv6 network operations and
>> security.
>>

This is Chicken Little talk.  IPv6 is like complaining about the
US Post Office going to a new form of alphanumeric zip codes.  A
letter is still a letter it just has a different zip code on it,
it's still carried and delivered the same way.  If you have experience
in IPv4 networks then most of that will carry over to IPv6 networks.

Frankly i feel talk like this hinders IPv6 deployments because
it gives the false impression to people with no IPv6 experience
that IPv6 is more difficult than it really is, and is a disincentive
to those folks to spend the time to learn about IPv6.

>> - We avoided fixing or replacing a conceptually broken protocol
>> like BGP for twenty years.
>>
>> - And every day more IPv4 based apps have come online which
>> inevitably increases the conversion costs for the end user.
>>
>> Excellent long range planning!
>>
>> Take care Terry
>
>> From my perspective, I don't see that lack of adoption has very
>> much to do with the inability to get address space. The
>> cost/ability to get sufficient IPv6 address space is so far down
>> the list of factors that weigh against deploying it that it doesn't
>> even register on the scale.
>
> It's the protocol itself, how different it is from the existing
> protocol and the lack of support for the tools I need to use on a
> daily basis that are major factors.
>

I agree.

> If the designers had just stuck 4 more octets on IPv4...kept
> everything else the same....and called it a day...we'd probably be
> done and not having this conversation by now......
>

I kind of doubt that.

IMHO the two biggest impediments to earlier IPv6 deployment in the
corporate enterprise sphere have been Cisco and Microsoft.

Cisco because Cisco did not release a usable IPv6 in IOS until IOS
12.3 - and 12.3 IOS is too large to run on just about every "edge"
router of the 1600 series and earlier.  It also is officially 
unsupported on the NPE300 and earlier 7200 series processors and
those series are also widely deployed in the enterprise as
"mini" backbone routers.

Microsoft because it did not have a usable implementation until
Vista.  Yes it was an add-on for XP but not fully functional.

If we had just tacked on more octets then both of those companies
would likely have still dragged their feet.

I realize the economics here and that both companies used IPv6 to
force their userbase to upgrade.  However while I can excuse Microsoft
barely, Cisco promised IPv6 support over 15 years ago "when the routing
standards were done" and then repeatedly claimed "they weren't done"
of course that didn't stop them from implementing many draft standards
in other areas than IPv6.

>
> At least from the end Enterprise end...can't really speak to how
> things look from the backbone/transit guys.
>

The problem is that so much of this deployment is dependent on other
people getting their work done.  The backbone/transit guys were
dependent on Juniper releasing complete IPv6 support and I kind of
suspect that wouldn't have happened until Cisco had done it and Juniper 
perceived the lack of such support as a competitive threat.  And
Cisco would undoubtedly blame the IETF for not finalizing IPv6.  The
root nameservers were dependent on the backbone/transit guys being
able to route IPv6.  And so on and so on.

In any of these large projects you always have a "key" or "single point
of failure" or some single issue that everything else piles up behind
like a logjam.  Once that issue is cleared then everything starts
happening at once.  The IPv6 deployment is like this.  We finally have
the infrastructure problems taken care of and now the next logjam are
getting the large networks to start routing it natively, when that
happens then all the rest of the networks will start routing it.  When 
that happens then the next stop point will be the large retail ISPs like
Comcast starting to offer native IPv6 to their customers, that will
force all the rest of the retail ISPs to offer it.  Then last will be
the content providers & end users.

This is just how large deployments of any project work.  If you look at
the US Interstate Highway system deployment for example, there is no
surprise that seat belts, crush bumpers, airbags and so on all came into
automobiles AFTER that system was deployed - because before that system
was deployed, vehicle speeds were low enough that most crashes were 
survivable without that safety gear.  Even though, the first seat belt 
patent was issued in 1885 - by those "small businesses and inventors"

Ted

> Christopher Engel
>
> _______________________________________________ PPML You are
> receiving this message because you are subscribed to the ARIN Public
> Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your
> mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
> info at arin.net if you experience any issues.