[arin-ppml] Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries - Revised

David Farmer farmer at umn.edu
Wed Mar 11 17:08:42 EDT 2009


On 11 Mar 2009 Martin Hannigan wrote:

> Changes that are ok under the global pdp are very minor non-contextual
> changes. Changes that would be subject to scrutiny by the ASO AC are
> changes that cause a policy to significantly differ from one region to
> another. If the AC, for example, fixed some fuzzy language, that could
> be enough to significantly change the policy since it could be
> interepreted differently vs. a version in another region.
>
> My suggestion would be that the AC either forward this policy or send
> it back to the authors so that they can decide how they want to
> proceed, either withdrawing it and starting from scratch or trying to
> fix it without a major contextual change.

Based on your previous post I assume you are not in favor of moving it 
forward, and would favor sending it back to the authors.

I believe we should send it back to the authors too, but if we do that and we 
want them to make changes, rather than just scrap it, I believe it would be a 
good idea to give them feedback on how we would like to see it changed to 
as be more suitable to the ARIN community

There are several issues I think we should give them feedback on:

1.  RIR assigned vs. Legacy Blocks -  It might be be helpful to differentiate 
between Legacy assignments and RIR assigned /8s.  Like making return of 
RIR assigned block optional, and Legacy assigned block mandatory.

2. General Fragmentation - There are several reasons, geolocation, regional 
route aggregation, etc... that it is useful to be able to make assumptions 
about addresses in big blocks.  While some amount of this kind of 
fragmentation is inevitable, to the extent possible it would be helpful to 
minimize this fragmentation.  At the very least, IANA should be charged to 
minimize fragmentation when reallocating blocks to the RIRs

3. DNS Reverse Zone Fragmentation - Fragmentation will also affect the 
DNS reverse zones, while probably a manageable issue, it wouldn't hut to 
minimize this as much as possible too.  From a reverse zone point of view, 
/16 is the next logical break point down from /8 where IANA manages things 
now.  How do we plan to deal with this, does it become a inter-RIR issue to 
redelegate the appropriate reverse zones, or does IANA take over the /8 
level and delegate out the /16 reverse zones appropriately to the RIRs? 

4. Big blocks vs. small block - This is kind of related to #2 and #3.  
Personally, I could agree that big blocks are resources of the whole Internet 
and should go back to IANA.  I would consider /8 - /16 as big blocks for sure, 
and there is definatly value in retruning those to IANA.   But the value of 
returning smaller blocks, /20 or longer for sure, to IANA in my opinion is 
minimal.  Especially compared to the fragmentation effects and just general 
confusion that it would create. So maybe small blocks should remain with or 
be returned to the RIR associated managing the /8 the block is part of.  I'm 
willing to be flexible if /17 - /19 are considered big or small. But, from a DNS 
reverse zone point of view there is an advantage of picking /16 as the 
divider.

5. Need criteria -  an RIR should still have to justify need to get additional 
address blocks, it is not clear to me that as currently drafted that an RIR 
would still have to justify its need for any blocks it receives.

6. Incentives -  What if an RIR has to provide incentives to motivate the 
return address space?  Should the RIR be able to keep blocks returned for 
which incentives were paid?  Should the other RIRs have to reimburse the 
RIR providing the incentive pro-rata shares?  Maybe if an RIR pays 
incentives worth more than some amount (say $5,000 for discussion) then 
they keep 50% of the block and must return 50% of the block to IANA.  


=======================================================
David Farmer				     Email:	farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-0815
2218 University Ave SE			     Cell:		612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-1818
=======================================================




More information about the ARIN-PPML mailing list