Re: [sig-policy] prop-080: Removal of IPv4 prefix exchange policy
Your guess is right :) There are only 10 cases used this policy so
far. I have listed the years they happened and the sizes exchanged for
all cases below.
2003 /21
2005 /19
2005 /18
2005 /22
2006 /14
2007 /21
2008 /22
2009 /21
2009 /21
2009 /21
I hope the above information is of assistance.
Best regards,
Guangliang
==========
myamanis at bb.softbank dot co dot jp wrote:
> Dear Guangliang,
>
> It is a question for clarification.
> How often is this policy used recently?
> (even though I guess it is quite few.)
>
> Rgs,
> Masato YAMANISHI
> Softbank BB Corp.
>
>> -----Original Message-----
>> From: sig-policy-bounces at lists dot apnic dot net
>> [mailto:sig-policy-bounces at lists dot apnic dot net] On Behalf Of Randy Bush
>> Sent: Friday, January 29, 2010 5:05 PM
>> To: Policy SIG
>> Subject: [sig-policy] prop-080: Removal of IPv4 prefix exchange policy
>>
>> Dear SIG members,
>>
>> The proposal, 'Removal of IPv4 prefix exchange policy', has
>> been sent to
>> the Policy SIG for review. It will be presented at the Policy SIG at
>> APNIC 29 in Kuala Lumpur, 1-5 March 2010.
>>
>> We invite you to review and comment on the proposal on the
>> mailing list
>> before the meeting.
>>
>> The comment period on the mailing list before an APNIC meeting is an
>> important part of the policy development process. We encourage you to
>> express your views on the proposal:
>>
>> - Do you support or oppose this proposal?
>> - Does this proposal solve a problem you are experiencing? If
>> so, tell the community about your situation.
>> - Do you see any disadvantages in this proposal?
>> - Is there anything in the proposal that is not clear?
>> - What changes could be made to this proposal to make it more
>> effective?
>>
>>
>> Information about this and other policy proposals is available from:
>>
>> http://www.apnic.net/policy/proposals
>>
>> Randy, Ching-Heng, and Terence
>>
>>
>>
>> ______________________________________________________________
>> __________
>>
>> prop-080-v001: Removal of IPv4 prefix exchange policy
>> ______________________________________________________________
>> __________
>>
>> Authors: Guangliang Pan <gpan at apnic dot net>
>>
>> Version: 1
>>
>> Date: 29 January 2010
>>
>>
>> 1. Introduction
>> ----------------
>>
>> This is a proposal to remove the policy that currently
>> permits resource
>> holders to return three or more noncontiguous IPv4 address blocks and
>> have the prefixes replaced with a single, larger, contiguous block.
>>
>>
>> 2. Summary of current problem
>> ------------------------------
>>
>> Current APNIC policy[1] permits organizations to exchange
>> three or more
>> IPv4 prefixes and receive a single portable CIDR range of equal length
>> or one bit shorter.
>>
>> Such exchanges may be requested without the requirement to
>> document the
>> efficiency of existing assignments and the usage rates.
>>
>> At the time this policy was introduced, it served a good purpose: it
>> aimed to encourage return of noncontiguous small historical blocks to
>> help reduce the size of the global routing table.
>>
>> However, as the remaining unallocated IPv4 addresses continue to be
>> depleted, it will become increasingly difficult for APNIC to fulfil
>> requests made under this prefix exchange policy.
>>
>>
>> 3. Situation in other RIRs
>> ---------------------------
>>
>> ARIN has two policies related to exchanging noncontiguous
>> prefixes. For
>> more information, see section 4.6, "Amnesty and Aggregation Requests"
>> and section 4.7, "Aggregation Requests" in the ARIN Number Resource
>> Policy Manual at:
>>
>> https://www.arin.net/policy/nrpm.html
>>
>> AfriNIC, LACNIC and RIPE have no similar prefix exchange policies.
>>
>>
>> 4. Details of the proposal
>> ---------------------------
>>
>> It is proposed that APNIC remove the policy that enables networks to
>> exchange noncontiguous address blocks in exchange for a single,
>> aggregated range.
>>
>>
>> 5. Advantages and disadvantages of the proposal
>> ------------------------------------------------
>>
>> 5.1 Advantages
>>
>> - It removes a policy responsibility that APNIC will not able to
>> fulfil during the IPv4 exhaustion period.
>>
>> - It prevents organizations taking advantage of the
>> exchange policy
>> to obtain more IPv4 addresses from APNIC by rounding up to the
>> next bit without justification of the need.
>>
>> This is of particular concern as the remaining unallocated IPv4
>> pool becomes smaller.
>>
>>
>> 5.2 Disadvantages
>>
>> - It prevents organizations willing to renumber and aggregate
>> address blocks from being able to do so. However, given the
>> fragmentation of the global routing table for other
>> reasons during
>> the IPv4 address exhaustion period, this is a minor
>> disadvantage,
>> that will have very little adverse impact on the size of the
>> global routing table.
>>
>>
>> 6. Effect on APNIC members
>> ---------------------------
>>
>> This proposal will prevent APNIC members from exchanging noncontiguous
>> prefixes for a single prefix. However, as noted in the "Disadvantages"
>> section above, this inability to aggregate routes is not
>> likely to have
>> a significant impact on the size of the global routing table
>> during the
>> IPv4 address exhaustion period.
>>
>>
>> 7. Effect on NIRs
>> ------------------
>>
>> NIR members will also be prevented from exchanging noncontiguous
>> prefixes for a single prefix.
>>
>>
>> 8. References
>> ---------------
>> [1] See:
>>
>> Section 11.4, "Renumbering to promote aggregation" in
>> "Policies
>> for IPv4 address space management in the Asia Pacific region",
>> http://www.apnic.net/policy/add-manage-policy
>>
>> Section 7, "Historical prefix exchange policy" in
>> "Policies for
>> historical Internet resources in the APNIC Whois Database",
>> http://www.apnic.net/policy/historical-resource-policies
>> * sig-policy: APNIC SIG on resource management
>> policy *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy at lists dot apnic dot net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>