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

William Herrin bill at herrin.us
Fri Nov 20 12:44:48 EST 2009

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

+Replace 6.3.4 paragraph 4 with:
+Further, RIRs should apply allocation practices that minimize route
 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
+, 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 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 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

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

- ARIN shall accept registration of no more than one address
-block of each size for any single organization.
+ 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. 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. 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
+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
+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

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


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

More information about the ARIN-PPML mailing list