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

[Owen DeLong]

On May 15, 2012, at 12:18 PM, William Herrin wrote:

> On 5/14/12, Jimmy Hess <mysidia at gmail.com> wrote:
>> Telephone number is also not the only option, btw.  The longest IPv4
>> prefix ARIN allocates is a /24.
>> 
>> Another option is set aside a /8,  under which
>> every  ARIN  /24 IPv4  allocation is automatically  mapped to a unique
>> global
>> unicast /32 IPv6 allocation;   that is...   under the /8,  the
>> assigned /24 IPv4  prefix bits are used to populate  24 bits in the IPv6
>> prefix.
> 
> Hi Jimmy,
> 
> One challenge with this sort of approach draws from NRPM 6.3.8: "In
> IPv6 address policy, the goal of aggregation is considered to be the
> most important."
> 
> Let's stack the phone number approach against the goals:
> 
> 6.3.2. Uniqueness: pass
> 6.3.3. Registration: assume they'll file paperwork with ARIN. Otherwise, fail.
> 6.3.4. Aggregation: very weak. All but the smallest orgs have many
> disjoint phone numbers.
> 6.3.5. Conservation: weak. Any unclaimed phone number is lost addresses.
> 6.3.6. Fairness: pass
> 6.3.7. Minimized Overhead: pass. Must still file paperwork with ARIN.
> 6.3.8. Conflict: fail. Aggregation goal is not prioritized.
> 
> 
> 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

> Compare to "do nothing" and let the existing process play itself out:
> 
> 6.3.2. Uniqueness: pass
> 6.3.3. Registration: pass
> 6.3.4. Aggregation: pass
> 6.3.5. Conservation: pass
> 6.3.6. Fairness: pass
> 6.3.7. Minimized Overhead: weak. Requires manual RIR analysis of
> request, payment.
> 6.3.8. Conflict: pass. Priority on aggregation is maintained.

Looks to me like the current process is the best of the three even without the above correction to your analysis.

Owen