[arin-ppml] Opposed to 2010-9 and 2010-12
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
>> 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
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
>> 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.
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
> 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?
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
>> 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.