[arin-ppml] Opposed to 2010-9 and 2010-12

[Leo Bicknell]

In a message written on Wed, Oct 13, 2010 at 02:45:54PM -0700, Owen DeLong wrote:
> More likely it provides the lasting impression that /64s are the normal
> subscriber allocation and breaks significant possible innovation.
> My complaint about /56s was that they are too small, not that they
> are too large.

Let's be honest here, in broad strokes, at least in the US...

Cable and FTTH providers are on a track to do native dual stack,
and will likely be doing /48's although a few may opt for /56's.

DSL providers, and their vendors, have been caught with their pants
down with respect to doing dual-stack and are looking hard at 6rd
as a bridge deployment until they can either migrate users to FTTH
or deploy dual stack capable DSL equipment.

Given most areas have a cable plus DSL duopoly if the DSL folks
have to deploy /64's because that's all the mess we can make with
the address space they will be at a competitive disadvantage compared
to the cable providers handing out /48's (or maybe /56's).

> I say we swallow hard and let 6rd eat something approaching a /12
> of /24s handed out to providers to facilitate /56s. Hopefully the fact that
> /56 is not /48 will eventually lead to the deprecation of 6rd in favor of
> native IPv6, but, at least we aren't completely breaking end user
> innovations in favor of unnecessary address conservation.

If you're going to go that big, then why not go the whole way?  A
/16 will allow a provider to do 32 bits of 6rd and still give out
/48's.  Let's craft the policy so you must be turning up at least,
oh, 100,000 subs using this technology.  I think we're now down to
perhaps 10-20 ISP's in the US that can meet that bar and want to
deploy 6rd, they can do it right, and we'll probably burn less than
a /12.

But I have to say, we're in scary land.  For all the IPv6 has lots of
numbers arguments a /16 is only 65536 netblocks.  If we do this for the
top 10-20 providers in every country in the world we're talking about
using up 10-20% of the entire IPv6 space just for ONE transition
technology.  

The only way I can support any of this is if we have strong controls to
make it temporary, but the more folks we turn up on it the more pressure
there is going to be that it not be temporary, or at least that
temporary is a very long time.

The best way to make temporary be really temporary is to make sure
it is more painful than the alternatives.  While I want to put 6rd
in the hands of the folks who need it (especially large DSL providers
with millions of subscribers) I want to make it painful for them
at every step.  Smaller subnets than their competitors, justify it
to ARIN every 3 months, pay 10x the fees, etc.  We must use EVERY tool
at our disposal to make this odious, while staying within the bounds of
it being useful.

> Noone should WANT to deploy 6rd. It's one of those things that we
> swallow hard, hold our noses, and deploy as a hot-fix until our
> vendors catch up and provide working IPv6 last mile technologies.

I agree, but quite frankly, and this is very much opionion, we're
bailing out the folks who were asleep at the switch.  Cable Labs figured
out how to do IPv6 over Cable in plenty of time, and while folks have
not deployed as fast as I would like the gear is there, it works, and is
being deployed.  For some reason the DSL folks, vendors and customers,
stuck their head in the sand and lost a number of years here where they
could have been deploying better stuff.  I am lothe to reward that
behavior.

> The pulling of support won't come in the form of an ARIN decision,
> it will come in the form of providers deciding to filter the prefixes
> that were dedicated to 6rd.

True, but a lot more people will be likely to filter if ARIN says
"experiment over".  I realze the real work is feet on the street, but I
think this is a critical symbolic step.

> ARIN demand for return is pretty irrelevant to the equation.

I disagree strongly.  There will be folks tempted to keep their
customers in the 6rd space so they don't have to renumber.  We've
already seen presentations on native + 6rd hosts from the same block in
Atlanta.  To allow that will create incredably sparely allocated blocks,
and further reward the folks who failed to plan with gigantic blocks
they will never use.  I don't know how that will bite us in the
future, but it will.

If we're going to allocate new blocks specifically for transition
technologies they need to come back to ARIN.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/4804f2db/attachment.sig>