[arin-ppml] Encouraging IPv6 Transition (was: Clarify /29 assignment identification requirement)

[Owen DeLong]

On May 16, 2012, at 5:34 AM, William Herrin wrote:

> On 5/16/12, Owen DeLong <owen at delong.com> wrote:
>> On May 15, 2012, at 12:18 PM, William Herrin wrote:
>>> Compare to the preemptive assignment approach:
>>> 
>>> 6.3.2. Uniqueness: pass
>>> 6.3.3. Registration: pass
>>> 6.3.4. Aggregation: pass
>>> 6.3.5. Conservation: weak. Some waste of addresses will occur here,
>>> though not especially worse than what occurs due to sparse allocation
>>> in general.
>>> 6.3.6. Fairness: potential long-term implications of IPv4 or AS
>>> holders getting IPv6 addresses automatically while anybody new has to
>>> pay.
>>> 6.3.7. Minimized Overhead: very strong. Bulk process based on a
>>> relatively simple database pull.
>>> 6.3.8. Conflict: pass. Priority on aggregation is maintained.
>> 
>> Er... I think that should read:
>> 6.3.8 Conflict: fail: Aggregation is degraded to to probability of
>> improperly sized allocations
> 
> Hi Owen,
> 
> Given:
> 
> 1. Recent discussions about the need to loosen subsequent allocation
> rules due to commonplace errors in initial IPv6 allocation choices
> with the existing process,
> 2. Sparse allocation intended to allow modest resizing without
> creating disjoint assignments, and
> 3. The recipient's ability to turn in the assignment when requesting a
> replacement should it be evident in an up-front manner that the
> assignment is not the right size
> 
> The foundation for a claim that preemptive assignment meaningfully
> harms aggregation is most weak.
> 

We can agree to disagree about this.

> 
>> Looks to me like the current process is the best of the three even without
>> the above correction to your analysis.
> 
> Until you throw in the missing goal, the one we're discussing in this
> thread: Until IPv6 use is ubiquitous, barriers to acquiring
> technically needful IPv6 address assignments should be minimized to
> the maximum extent practical. Personally, I'd rank that goal second
> only to aggregation. Certainly it's far more important than 6.3.5:
> conservation.

To some extent, I agree with you. However, I don't believe that preemptive
assignments remove barriers so much as create an illusory consumption.
As such, I would argue that preemptive assignments fall somewhere between
weak and fail in that particular goal.

> ARIN policy on IPv6 assignment presents far fewer barriers than it did
> four years ago, but reasonable analysis grades any resource request
> from ARIN as "difficult." For IPv4, that's as it should be.
> Conservation is IPv4's leading goal, so there is supposed to be major
> back pressure to careless consumption. For IPv6, it's a needless
> barrier to adoption.

I disagree. It took  me less than an hour to prepare HE's subsequent
allocation request for ARIN and submit it. It took less than 48 hours
for ARIN to issue the requested /24.

When I got my /48 for my own end-site, it was as simple as filling out
the template with a statement of "I have PI IPv4, please give me a /48".
It took ARIN less than 3 days to approve my request and issue my
addresses.

I've done multiple IPv6 end-user and ISP requests for various clients.

None of them were what I would call difficult on the ARIN side. The largest
difficulties are usually explaining ARIN policy and the limitations thereof
to the clients and this is primarily a problem for IPv4. The second hardest
part is dealing with the client's poor record keeping in determining how
to justify an appropriate request to ARIN.

While pre-emptive assignments/allocations MAY work around those issues,
I would argue that working around those issues rather than resolving them
is NOT a desired outcome.

Owen