[arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.

[George, Wes E [NTK]]

I do not support this policy as written either.
I echo Bill's comments below, at least for the first 3 issues that he raises. I'm not totally convinced of the other few regarding addressing efficiency or lack thereof, but I think that there's value in discussing it further.

Also, I think that this proposal would be much stronger if it cited one or more examples of providers who have tried to request additional space from ARIN for this purpose and been denied based on not meeting criteria for additional space according to the current NRPM. Otherwise, I need some convincing that we're solving a problem that actually exists vs policy for policy's sake. Free.FR is cited as an example, but to my knowledge no similar policy carving out special permission for providers that wish to deploy 6RD exists at RIPE, nor is there a similar policy update proposal on the table. Alternatively, the text could point to differences between ARIN NRPM and RIPE IPv6 Address Allocation and Assignment policy that would lead to a request for space for 6RD being approved by RIPE but not ARIN.

Further, I would still like this proposal to be more generic in nature instead of specific to 6RD, as I don't want to see us writing a new policy for every new transition technology that someone wants to implement. People are writing new ones or variants on existing ones nearly every IETF meeting, so if even some of them stick and get implemented, it's not scalable to write policies based on a single implementation, especially as time becomes of the essence post IPv4-exhaustion. As I said before, I'd support something that points out 6RD as an example where RIPE policy would permit and ARIN would not and suggested changes to the necessary wording to fix this, or something that allows for a more generic "allocation to implement a transition technology" with requirements to justify why a second allocation is required, and some of the language in this current proposal regarding temporary assignment, rejustification and reclamation.

Thanks
Wes George, Sprint

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
Sent: Saturday, September 25, 2010 1:11 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.

On Fri, Sep 24, 2010 at 11:59 AM, ARIN <info at arin.net> wrote:
> Draft Policy 2010-9
> IPv6 for 6rd
>
> Version/Date: 24 September 2010

[[WEG]] snip

After careful consideration, I OPPOSE proposal 2010-9 as written.
Although I agree that 6rd use should justify an IPv6 allocation, I
think this proposal should be deferred until the Spring and thoroughly
rewritten.

My reasons are:

First, 2010-9 as written more or less guarantees an IPv6 /28 to ALL
CURRENT IPv4 REGISTRANTS:

"If you have IPv4 addresses then you automatically qualify for IPv6
space for 6rd. [...] A /28 allows the operator to delegate prefixes
shorter than /64, allowing multiple /64 subnets within the home."

Second, the proposal needs major wordsmithing. The language is too
opaque, making it difficult to tease out how ARIN is supposed to
evaluate IPv6 applications justified by an intent to use 6rd. It
should be rewritten with phrases like "ARIN shall," using far fewer
words per paragraph and with the addition of short headings for
clarity.

Third, the proposal encourages ARIN to allocate /28's in addition to
the ISP's native IPv6 assignment, adding expensive consumption to the
routing table. If the intent is to facilitate 6rd deployments in this
fashion then the policy should explicitly encourage ISPs to accept /27
allocations so that they may employ both 6rd and native IPv6 within a
single contiguous allocation.
[[WEG]] snip

Regards,
Bill Herrin



This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.