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

[Owen DeLong]

Apologies to the list for responding to myself.

I will state for the record that my employer does not share
all of my views on this subject.

Owen

On Oct 13, 2010, at 3:51 PM, Owen DeLong wrote:

> 
> 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
> 
> _______________________________________________
> 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.