[ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal
sleibrand at internap.com
Tue Mar 11 13:53:48 EDT 2008
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
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
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
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)?
More information about the ARIN-PPML