[arin-ppml] Policy Proposal: DedicatedIPv4blocktofacilitateIPv6 deployment

[Ted Mittelstaedt]

> -----Original Message-----
> From: Hyunseog Ryu [mailto:hyunseog.ryu at norlight.com] 
> Sent: Wednesday, July 16, 2008 2:12 PM
> To: Matthew Wilder; Matteson_Mike at emc.com; tedm at ipinc.net; 
> jyy at uci.edu; michael.dillon at bt.com; arin-ppml at arin.net
> Subject: RE: [arin-ppml] Policy Proposal: 
> DedicatedIPv4blocktofacilitateIPv6 deployment
> 
> 
> I cannot help to put some feedback on this one.
> I believe that the reason why U.S. is still using lb(pound), 
> inches, miles is because of cost concern.

For some industries, that is true.  However for most it is
because you have an existing infrastructure that uses
the older measurements and there's a need to interface with
equipment using the older measurements.

Take for example the lowly 12 oz aluminum beer can and
think of everything, from store shelf heights, to the
dual-beer hats that people wear to ball games, to
automatic recycling machines, that is already designed
for that exact dimension of can.  The manufacturer cannot
shrink or expand the size of the can without having
to change all this stuff, and while the new sized cans are
coming into the market, the equipment in use already will
need to continue to work with the old size can, it cannot
just be replaced.

We are in a much better situation with IPv6 since we
can dual-stack devices.

> Long time ago the 
> federal government was trying to use meter measure instead of 
> mile/inch measure, but it turned out that it cost 4 times of 
> U.S. federal government annual budget at the time. That's 
> what I heard. I don't know it's true or not. But for IPv6 
> deployment, it might be same reason.

Which is why IPv4->IPv6 deployments are ALL envisioned as
gradual changeovers.  At the least, because Windows XP does
not completely properly handle all IPv6 cases, even though
it is dual stacked, we won't even be at the stage that we can
properly dual-stack the clients used on the Internet until
XP disappears.  And a properly dual-stacked client is what you
do at the BEGINNING of an IPv4->IPv6 changeover.

> Since U.S. has so many 
> laywers, there will be debate who's going to pay for what. 
> Other countries have more power from government/service 
> providers. But in U.S., service provider needs to invest the 
> money for existing infrastructure to support IPv6 and there 
> will be resistance coming from consumers/users for pushing 
> IPv6. So far, I tried to find IPv6 transit peering from U.S. 
> market, but for even tier-1 providers, not all of them 
> supports IPv6 for peering yet. Sometimes request for IPv6 
> peering got lost from sales people and engineering people, 
> too. So how can I expect IPv6 useable for our customers?

All you need for now is ONE of your peers to support IPv6.
Yes, it won't be redundant.  That does not matter on a
dual stack client since the client will have a redundant path
through the IPv4 network.

> Even 
> IPv6 supported tier-1 providers doesn't have native IPv6 dual 
> stack support from peering viewpoint. It turns out to be 
> tunneling method for IPv6 peering for all of cases I have 
> found so far.

So what?  I don't know your age but at one time it was common
to run IPTunnel and tunnel IPv4 over Novell Netware IPX
protocol on corporate WANS.  Tunnelling is a transition
technology and you shouldn't be afraid of it.

> Most of business from U.S. is strictly based on 
> ROI(Return on Investment). They don't want to spend the money 
> unless it is absolutely necessary. From that viewpoint, most 
> of CEOs and management still see that they have no problem to 
> run the business using IPv4 only. If they need to push IPv6, 
> they have recommended CPE to support IPv6 and etc. It will 
> cost money to customers, and big players such as Tier-1 still 
> have some ip address available from legacy allocation such as 
> /8 from pre-ARIN era. So it's not immediate need for them to 
> push IPv6 at this moment.
> 

Agreed.  However, merely standing with hands at your sides and
not participating in an IPv6 deployment is completely different than
actively campaigning against IPv6 by claiming that IPv6 will
never get off the ground, IPv4 is permanent, etc.

Like you, I have people we buy bandwidth from who at this
point only offer IPv6 tunnelling.  They don't route IPv6 natively
because of cost concerns of deploying it.  In short, they have
decided that they can make more profit allowing customers who
demand native IPv6 to disconnect and go find other bandwidth
providers, than spending the money to offer native IPv6.  However
none of them are out there telling customers that IPv6 isn't
ever going to happen.  Even the ones who refuse to provide IPv6
now, and will only give a tunnel, all say that they know they will
have to offer IPv6 eventually.

Most industry conversions happen this way, and IPv6 will be no
different.  In the beginning the customer base who is willing to
pay for IPv6 native routing is small.  Only some providers will
spend the money to service them, and that is fine because if
all providers spent the money to service them, then no providers
would ever make any return back.

As the customer base that wants to pay for IPv6 natively continues
to grow, more and more of these customers will leave their native
IPv4-only providers and go to IPv6/IPv4 native providers.  Eventually
a point is reached with the IPv4-only providers that they lose enough
customers and have enough difficulty attracting new ones due to
IPv6 demands that they will see it as a necessary expense to retain
their existing customer base, and tool up to supply IPv6.

The problem here is that there's some people out there who want to
cheat.  Instead of simply being honest and saying that if you want to
get IPv6, quit and find another provider, they are electing to go out
there and lie like dogs, and tell people that IPv6 will never amount
to anything.  They know that not all of their customers will believe
them, but they are hoping that some will so they can stave off the
expenditure for another couple of years.

In the meantime this sales and marketing lying is confusing a lot
of people.

What people who buy bandwidth for resale need to know is that they
should be doing 3 things now:

1) Asking whoever they buy bandwidth from if they have IPv6 EVEN IF they
have no intention of running it right now.

2) Making IPv6 a requirement for a bandwidth contract renewal from their
suppliers.

3) If they are shopping around for bandwidth, don't buy it from anyone who
isn't offering IPv6 or will not committ in the contract to offering it
in the next few years.

If your not buying bandwidth, and your current suppliers don't offer IPv6,
then you can't do anything to apply pressure to anyone in the market to
supply it, so you might as well just relax and wait and see what happens,
in the meantime get a test IPv6 tunnel from someone for free, and play
with it a bit.

Ted