[arin-ppml] Opposed to 2010-9 and 2010-12
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
>1. If it becomes a permanent deployment, it will seriously degrade end
> capabilities and stifle innovation and place unnecessary limits on
> 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
>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
> 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.
>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.
>2. Space from a separate prefix which can be reclaimed in its entirety
> and filtered by service providers to facilitate the aforementioned
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.
>3. Strict limits on the maximum prefix size to be allocated to any
> to facilitate the technology.
What do you propose these are?
>4. Limitations of not more than 3 such allocations for different
> 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.