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

[Owen DeLong]

On Oct 7, 2010, at 12:49 PM, Gary Giesen wrote:

> 
> 
> On 10-10-07 3:37 PM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> My biggest concerns with both policies and with 6rd in general are as
>> follows:
>> 
>> 1.    If it becomes a permanent deployment, it will seriously degrade end
>> user
>>   capabilities and stifle innovation and place unnecessary limits on
>> future
>>   product development. Thus, while it doesn't contain the same evils as
>>   NAT, it may actually have a similar impact to NAT in some ways.
> 
> If this is truly the case, I think the market will decide, and users will
> move to those ISPs that make the move to native connectivity
> 
This assumes a greater level of choice than is present in many markets.

> 
>> 2.    As much as I favor liberal allocation/assignment of IPv6 space and
>>   don't generally tend to accept most of the conservatism arguments,
>>   6rd is impressively wasteful, even by my standards. We've got the
>>   ability to support it as a short-term solution, but, I'd hate to see
>> these
>>   assignments become in any way permanent usage.
> 
> I agree that this can seriously have the potential to again create the
> same dual-class networks (Legacy vs post-RIR) we have in v4, where those
> who got in early got a vast amount of address space and those who came
> later were less fortunate.
> 
Indeed.

> 
>> As such, I cannot support any 6rd or transition policy which does not have
>> the following safeguards:
>> 
>> 1.    A time horizon of not more than 5 years before the space is to
>>   be deprecated. (If there is need for an extension, a policy amendment
>>   can take care of this problem).
> 
> I can live with this, although I expect these will live much longer.
> 
Probably, but, at least having a date,  a clock, and requiring policy
change to allow them to do so provides the right message.
>> 
>> 2.    Space from a separate prefix which can be reclaimed in its entirety
>>   and filtered by service providers to facilitate the aforementioned
>>   deprecation.
> 
> In considering your arguments (and some of my responses), I'm now leaning
> this way as well. I think it's actually a good thing that we attach some
> sort of stigma to these prefixes to emphasize their temporary nature.
> 
Thank you.

>> 
>> 3.    Strict limits on the maximum prefix size to be allocated to any
>> organization
>>   to facilitate the technology.
> 
> What do you propose these are?
> 
Probably a /24. That allows a /56 for end-sites which is suboptimal
(end sites should be at least a /48), but, hopefully doesn't consume
too vast a swath of IPv6 in the process (roughly a  /8).

>> 
>> 4.    Limitations of not more than 3 such allocations for different
>> transition
>>   technologies per organization. (If you want to deploy a third, then,
>>   deprecate the first and return that space before you can get a fourth)
> 
> Seems entirely reasonable.

Thanks.

Owen