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

[Bill Darte]

And while you are answering these questions, or just browsing, please
state plainly whether you are 'in favor' of this policy proposal, or
'opposed'.

This will help the AC determine the extent to which consensus
exists...and we thank you for that as well!

Bill Darte 

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