[arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised
mysidia at gmail.com
Thu Dec 17 02:04:50 EST 2009
On Fri, Nov 20, 2009 at 11:38 AM, Member Services <info at arin.net> wrote:
Making V6 allocation more like V4 or classful allocation does seem
to have some major benefits, there's a lot to like about the proposal,
and it's definitely an improvement to reduce the number of different
prefix lengths that may be allocated .. but
> 6.5.7. Existing IPv6 address space holders
[...]> manner approaching 18.104.22.168 by increasing the prefix length of all
>registrants within a particular pool to some specific minimum prefix
>length for the pool.
Increasing the prefix length of an existing registration.... Also
known as: taking back part of an allocation made earlier seems an
exceeding harmful proposition.
Unproven: That you can actually use an RIR address pool scheme to
effectively filter out only TE routes. It's just as unproven that
this is better as it's unproven that sparse allocation results in
The RIR isn't the only organization to allocate IPs. The ISP
distinction is important.
No matter how well ARIN pools allocations, ISPs can allocate /48s
or /56s from e.g. in their shorter /32 prefix to downstream
Multi-homed customers of the ISP who do not otherwise have, want, or
need their own AS number (or may become multi-homed at a later time
after receiving the allocation from their ISP).
As they have done in IPv4. You break connectivity if you only
accept /32s from the ISP /32 PA block, which results in inability
to effectively, safely filter.
Unproven: That pooling RIR allocations by size alone actually makes
filtering particularly easy in the long run.
Suggested alternative... One way to allow more precise filtering in
such cases would be to allow ISPs to have several allocations, from
several RIR pools which the ISP must assign, according to the exact
size, multi-homed status, and justified need of downstream customer
IP address block they are allocating
(e.g. the ISP has to make their allocations along the pool lines).
One possibility would be to sub-divide: allocate /31s to ISPs, and
require ISPs to keep the first bit inside the allocation to equal to
zero, except for multi-homed sub-delegations of a designated prefix
length. So that across the entire ISPs' assignments, longer prefixes
could be filtered when the sub-delegation's multi-homed bit was zero;
and end-users only ever get odd-numbered /32s directly from
E.g. Or another alternative would be to allocate ISPs an additional
/32 or /40 from a separate block.. a "multi-block" for
multi-homed /48s upon request, in addition to their PA space. Let
ARIN require ISPs re-assign from "their" multi-block only to
downstream multi-homed customers, every customer in the multi-block
must be assigned a /48 exactly: require they be assigned sequentially
(one after the other), RE-Assignment registered with ARIN registered,
prior to use. /48 not announced until use: the multi-blocks don't
_really_ belong to the ISP at all, the ISP may not announce the
aggregate; ARIN can let the blocks be portable (with annual
maintenance fee), and any announcements other than /48 are an
end-user's TE routes.
Let ARIN take back any or part of the un-assigned portion at any time,
_and_ have a policy to actually do so, if /48s aren't actually
Aside from multi-blocks: let the ISP get another separate /32 or /40
from which they assign single-homed PA, the "normal" allocation; the
ISP can announce the aggregate, and anything else is TE.
For a larger amount of addresses than /48, don't let their ISP
allocate it; force the end user to go to ARIN directly, and always
assign a /40 or /32 to end-users. Justification _should_ be
required. Fee-based disicentives are insufficient for large
organizations, given the cost of renumbering.
For ISP requests, only allow a /24 multi-block to be allocated to
an ISP who can prove they have more than >20,000 multi-homed
Only allow a /24 PA block to be assigned to an ISP or org who can
document that they have more than 1 million hosts to be attached
to their network.
Anyways, those are some thoughts..
> To prevent wasteful consumption of IPv6 address space without a
> complicated eligibility regime, the author recommends an initial and
> annual fee regime for IPv6 address allocations similar to:
> /56 -- $10 USD
> /48 -- $100 USD
> /40 -- $1000 USD
> /32 -- $10,000 USD
> /24 -- $100,000 USD
I don't like this fee table at all... /40 and /32 appear way too
expensive, /56 and /48 are too cheap. An ISP with an IPv6 /32
should not pay more than an ISP needing a new IPv4 /16 every
V6 adoption is already expensive without creating inflated IP fees.
It (seems) a bit absurd for usable quantities of IPv6 address space
alone to be 10x+ as expensive to maintain as IPv4 address space,
especially given the nature of V6 addressing; it is not clear that it
costs any more for ARIN to maintain such registrations.
I expect prices to go _down_ with V6, not go up.
There is, after all, more supply, and the demand is virtuallly non-existent.
Do not believe ARIN should replace needs-based allocation with
fee-based allocation sizing.
Due to "22.214.171.124 No usage-based eligibility requirements shall apply to IPv6
_Every_ end-user might be inclined to seek a /56, however,
eliminating some need for ISPs to get larger blocks. Since PI
address space has so many advantages.
$10 a year is too low to discourage the very large future
eventual IPv6 user base from simply going directly to ARIN...
It doesn't seem like it's sustainable.
IPv4 equivalent to this would be allowing folks to register an IPv4
/26 for $10...
probably not very useful, but maybe...
However, If end-users get their V6 /56 or any resource from ARIN
and then find they can't get their new block in the routing table
(which is the most likely outcome), that is a bad thing, actually...
Policy should definitely not ignore such considerations altogether..
More information about the ARIN-PPML