[ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal

[Scott Leibrand]

First of all, thanks to everyone for their feedback and discussion of 
the 2008-2 policy proposal.

One item that I still think needs further discussion is the question of 
whether and how to restrict transferor deaggregation in an IPv4 Transfer 
Policy.  The question is, should we place restrictions on both the 
transferee and transferor to limit deaggregation, or would a more 
limited set of restrictions be sufficient?

Some background (or skip down to the bottom if you want):

In 8.3.2  Conditions on the transferee, there are two bullet points 
permitting and requiring transferees to get a larger block than they 
might otherwise, to help prevent deaggregation:
•	The transferee may request and receive a contiguous CIDR block large 
enough to provide a 12 month supply of IPv4 addresses.
•	The transferee may only receive one IPv4 address transfer through this 
Simple Transfer process every 6 months.

In 8.3.3  Conditions on the IPv4 address block to be transferred, a 
transferor is permitted to split their block into two pieces, keeping 
one and transferring the other.  This could be an even split into two 
CIDR blocks, or at the other extreme it could mean splitting a /8, 
keeping a /22, and transferring the remaining /9, /10, /11, /12, /13, 
/14, /15, /16, /17, /18, /19, /21, and /22.  However, it also means that 
a holder of a large IPv4 address block cannot simply transfer it off as 
16,384 /22's.

In 8.3.6  Deaggregation when Permitted by ARIN, further deaggregation 
beyond 8.3.3 is allowed, at ARIN's discretion, in order to deal with any 
shortage of smaller blocks resulting from the restrictions above.

The conditions in 8.3.3 and 8.3.6 above represent a compromise between 
two views.  On the one hand, there is the view that the transferee 
conditions in 8.3.2 are sufficient to recreate an environment very 
similar to the one we have today, in that recipients must justify their 
need for addresses, and then they receive a block large enough to meet 
their needs for a certain number of months.  Today that block comes out 
of a /8 allocated from IANA to ARIN, so each such allocation generates 
at least one additional route in the routing table.  There is little 
reason to believe that the number of prefixes demanded will change 
significantly, so there would be no incentive for transferors to 
deaggregate more than we do today, and therefore in this view the 8.3.2 
conditions are adequate, and the last bullet of 8.3.3 and section 8.3.6 
are unnecessary.

The other view is that, without conditions restricting them from doing 
so, transferors of large netblocks will deaggregate their holdings to a 
large degree and transfer off the resulting pieces, resulting in a 
shortage of larger blocks.  Under this view, the transfer policy should 
restrict the degree to which deaggregation is permitted, thereby 
encouraging transfer of larger blocks instead of smaller ones.

In version 1.0 of the proposal, section 8.3.6  Deaggregation when 
Permitted by ARIN did not exist.  Without it, a convincing argument was 
made that supply of small netblocks would be restricted, thereby driving 
up the price of small netblocks and driving down the price of large 
ones.  To address this, we added section 8.3.6 in version 1.1.



So, a few questions to discuss:

Do you think that the IPv4 Transfer Policy should restrict deaggregation 
of transferred netblocks?  Why or why not?

If so, what restrictions should be placed on deaggregation, and what 
types of deaggregation should be allowed to provide supply of smaller 
netblocks?

Should any restrictions on deaggregation be written into the policy, or 
should ARIN staff be given discretion to adjust the restrictions as 
needed to best serve the interests of the community (section 8.3.6)?

Thanks,
Scott