[arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised

[William Herrin]

Here's the diff:

@@ -6,7 +6,7 @@
     2. email: bill at herrin.us
     3. telephone: 703-534-2652
     4. organization: Self
-3. Proposal Version: 1.0
+3. Proposal Version: 1.1
 4. Date: 11/2009
 5. Proposal type: new
 6. Policy term: permanent.
@@ -15,7 +15,12 @@
 Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4,
 6.5.1-6.5.5, 6.5.8, 6.7, 6.10

-Strike NRPM section 6.9 paragraph 2.
+Strike NRPM 6.3.5 sentence 2.
+
+Strike "/NIR" from NRPM section 6.5.6.
+
+In section 6.9 strike NRPM "/LIR" at the end of paragraph 1 and all of
+paragraph 2.

 Replace 6.2.5 as follows:

@@ -25,31 +30,57 @@
 synonymous. Both terms describe any or all use identified in section
 2.5.

+Replace 6.3.4 paragraph 4 with:
+
+Further, RIRs should apply allocation practices that minimize route
+disaggregation.
+
 Replace 6.5.7 with:

 6.5.7. Existing IPv6 address space holders

 Organizations that received IPv6 allocations under the previous IPv6
 address policy are entitled to either retain those allocations as is
-or trade them in for an allocation under 6.5.9.
+or trade them in for an allocation under 6.5.9. Where the prefix
+length of such registrations differs from the standard lengths in
+6.5.9.1, it shall count as a registration of the next longer length.
+
+The above notwithstanding, ARIN is authorized to standardize the
+prefix lengths within these previously-allocated address pools in a
+manner approaching 6.5.9.4 by increasing the prefix length of all
+registrants within a particular pool to some specific minimum prefix
+length for the pool.
+
+Add NRPM section 6.2.10 as follows:
+
+6.2.10 Organization
+
+An organization under section 6 is either:
+
+one or more legal entities under common control or ownership, or
+
+one such legal entity which operates strictly separate networks from
+the others.

 Add NRPM section 6.5.9 as follows:

-6.5.9 IPv6 Allocations
+6.5.9 Regular IPv6 Allocations

 6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only
-the following denominations: /56, /48, /40, /32, /24
+the following prefix lengths: /56, /48, /40, /32, /24

-6.5.9.2 No utilization-based eligibility requirements shall apply to
-IPv6 allocations.
+6.5.9.2 No usage-based eligibility requirements shall apply to IPv6
+allocations.

-6.5.9.3 ARIN shall accept registration of no more than one address
-block of each size for any single organization.
+6.5.9.3 ARIN shall register no more than one address block of each
+prefix-length for any single organization. These blocks may be
+registered simultaneously. Renumbering of existing blocks is not
+required to receive additional blocks.

 6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the
-identity of the allocation pool serves to classify the expected size
-of allocations within. ISPs may use that classification to filter or
-otherwise manage their routing tables.
+identity of the allocation pool serves to classify the expected prefix
+length of allocations within. ISPs may use that classification to
+filter or otherwise manage their routing tables.

 6.5.9.5 For each allocation size, ARIN shall further manage the
 allocation pools such that the pool identity serves to classify
@@ -106,7 +137,7 @@
 Benefits of this proposal:

 A. Efficient allocation of IP addresses. Orgs get what they need when
-they need it without a great deal of guesswork about actual need.
+they need it without a great deal of guesswork.

 B. Efficient utilization of BGP routing slots. No multihomed orgs will
 announce more than five unfilterable routes, and that only if they're

@@ -318,8 +354,20 @@
 with the check (in the form of routing slot consumption) when an ISP
 goes bankrupt and gets split up.

+Q. What happens to the existing (legacy) IPv6 allocations and
+assignments?
+
+A. An organization will be entitled to retain their existing
+allocations indefinitely if they so desire. If the prefix length does
+not match one of the standard prefix lengths then it will be treated
+as the next smaller prefix length for the purposes of determining
+eligibility for further IPv6 allocations. To discourage unnecessary
+disaggregation, the prefix length of this "legacy" allocation will not
+be expanded even if there is room in the pool to do so.
+
 Q.  What about IPv6 addresses for uses which will not be connected to
 the Internet at all?
+
 A. Folks are welcome to get non-multihomed addresses for any purpose
 whatsoever. If they do eventually decide to connect to the Internet,
 the routes will follow whatever rules the ISPs have imposed for routes
@@ -341,12 +389,45 @@
 on PPML, seeking a follow-on proposal that establishes address pools
 at the /16 level.

+Q. What does standardize prefix lengths within the legacy pools in
+6.5.7 mean?
+
+A. Wes George pointed out that depending on the rules ARIN has
+followed with respect to leaving space between allocations, it may be
+possible to standardize the existing pools on some prefix length as
+well. If it is possible, folks should become able to better filter
+disaggregation in those pools too.
+
+So, for example, if ARIN allocated a /32, a /31 and a /30 from the old
+/32 pool and reserved a /28 for each allocation to expand, ARIN could
+peremptorily increase all three allocations to either /28 and then
+publish that the exact prefix length in that pool is /28.
+
+Another example, if ARIN allocated a bunch of /32's and a /26,
+reserving /28 for each allocated /32, ARIN could increase the /32's to
+/28 and publish that the minimum allocation size for the pool is /28.
+Instead of the /26 registrant being able to disaggregate into 64
+/32's, he might then be constrained to only disaggregate into 4 /28's.
+
+While this proposal does not require ARIN to take that action, it
+authorizes it.
+
 Q. What are the struck sections of the current IPv6 policy and why
 should they be struck?

 A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the
 policy as revised by this proposal.

+6.3.4 paragraph 4 gives instructions on accomplishing address
+aggregation which are, if this proposal's rationale is correct,
+counterproductive to encouraging route aggregation. Address
+aggregation only matters to the extent that it helps bring about route
+aggregation.
+
+6.3.5 sentence 2 speaks to documentation issues that are incompatible
+with this proposal. If this proposal's rationale is correct then fees
+alone are sufficient to prevent unnecessary waste.
+
 The 6.4.3 notion of a minimum allocation is obsoleted by the
 allocation pools of specific size in this proposal.

@@ -398,7 +479,8 @@
 intend to originate or propagate IPv6 BGP routes from the registrant's
 ORG.

-9. Timetable for implementation: immediate
+9. Timetable for implementation: following an update of ARIN's IPv6
+fee structure.

 END OF TEMPLATE


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004