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

[Jim Weyand]

Scott-
Is there any quantitative data on the effect of deaggregation?  

The proposal relies on ARIN staff to make decisions regarding
deaggregation. What skills and experience will be required of staff
members to make reasonable decisions?

-Jim Weyand

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf
Of
> Scott Leibrand
> Sent: Tuesday, March 11, 2008 12:54 PM
> To: arin ppml
> Subject: [ppml] Restrictions on transferor deaggregation in 2008-2:
IPv4
> Transfer Policy Proposal
> 
> 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
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if
you
> experience any issues.