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

[Scott Leibrand]

Yes, there have been some numbers produced by ARIN staff 
(http://www.arin.net/statistics/index.html), which the AC has been using 
(along with some data from whois) to judge the likely demand and supply 
of larger and smaller blocks.

In addition, I would anticipate that ARIN staff will also be able to use 
the prices on the listing service to decide whether/when to adjust 
deaggregation thresholds.  If the per-IP price for smaller blocks gets 
to be higher than that for larger blocks, for example, that may mean 
that more deaggregation needs to be permitted.

Fortunately, ARIN not only has a very smart staff, but also has the 
engaged the services of an economics expert with experience in a wide 
range of Internet issues (Ben), so I have confidence that they will be 
well prepared to make the decisions required to ensure smooth 
functioning of the market.

-Scott

Jim Weyand wrote:
> 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.
> _______________________________________________
> 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.