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

[Owen DeLong]

On Oct 13, 2010, at 3:07 PM, Leo Bicknell wrote:

> 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.
> 
Actually, most of the PON (FTTH) systems are also caught with their
pants down.

> 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.
> 
This applies to DSL and FTTH. It also applies to some of the CMTS
systems that are still running on DOCSIS 2.

> 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).
> 
There are actually a lot of areas where the duopoly isn't like that.
Many areas are DSL vs. DSL or Cable vs. Satellite (also afflicted
with vertically challenged pants syndrome).

>> 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.
> 
1.	There are lots of providers serving less than 100,000 subs
	that need 6rd and I wouldn't advocate policy that freezes
	them out.

2.	There aren't enough /16s to provide them to all the providers
	that likely need 6rd without serious risk to the address space.


> 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.  
> 
Exactly. Very scary. Hence my recommendation that we limit it
to /24s rather than /16s. 


> 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.
> 
I think that if we make it easy to get additional space for native IPv6,
the costs of running 6rd vs. the costs of native where it is possible
will provide reasonably good incentive to go native as quickly as
practicable.

Use of a reserved prefix so that the community can make a subsequent
decision to start filtering it at the borders will also help ensure the
temporary nature of such allocations.

> 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.
> 
I think the nature of 6rd does that pretty well.

I can't advocate the ultra small subnets. That punishes the end users
for the mistakes of the provider's vendors. I can't advocate huge fees,
either since that also would unfairly penalize the end-user for mistakes
well outside of their control.

>> 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.
> 
While that's true, I think we have to provide the bail-out. Penalizing
the end-user for the mistakes made primarily by their provider's
vendors is bad policy in my opinion. I'd love to see a way to
penalize the vendors in question, and, if you have one, I'm all
ears.

FWIW, we're also bailing out a number of cable providers that
have not yet upgraded to DOCSIS 3 and will be using this
over DICSIS 2 as well.

>> 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.
> 
I would support doing so based on a community consensus to
adopt policy deprecating the transitional provisions of this policy.
I don't think we should put a date on it now. I think we should
develop a community consensus at the appropriate time.

>> 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.
> 
I think the policy we put forward addresses this.

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

Owen