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

[James Hess]

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 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.
[..]
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
fewer announcements.

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
customers.

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
ARIN.


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
being re-assigned.


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
customers.

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..

[snip]
> 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
[snip]

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
year.

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 "6.5.9.2 No usage-based eligibility requirements shall apply to IPv6
allocations."

_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..


--
-J