Re: [sig-policy] prop-080: Removal of IPv4 prefix exchange policy
Actually, it's more than I expected (in particular, 3 times in last year)
BTW, are we re-utilizing prefixes which have been returned
by this current policy for new allocation or assignment?
If answer is "no", it means that current policy has bad side effect
which may accelerate the exhaustion. It may be another advantage of your proposal.
Rgs,
Masato YAMANISHI
Softbank BB Corp.
> -----Original Message-----
> From: Guangliang Pan [mailto:gpan at apnic dot net]
> Sent: Wednesday, February 03, 2010 10:21 AM
> To: 山西 正人(ネットワーク本部)
> Cc: sig-policy at apnic dot net
> Subject: Re: [sig-policy] prop-080: Removal of IPv4 prefix
> exchange policy
>
> Dear Masato,
>
> 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
> >>
>