Re: "No questions asked" policy draft
Two queries:
1 - does this (or is this intended to) apply to members and non-members
of APNIC equally?
2 - Does this apply to any returned address prefix?
regards,
Geoff
At 09:24 PM 1/5/97 +0900, David R. Conrad wrote:
>Hi,
>
>The following document formalizes a current policy of APNIC.
>I'd appreciate any comments you might have.
>
>Thanks,
>-drc
>--------
>Introduction
>
>As the Internet is currently experiencing problems relating to the
>number of prefixes found in the routing system and these problems can
>have very significant impact on the operation of the Internet, APNIC
>has undertaken a policy to reduce the number of announced routing
>prefixes found within the blocks of addresses APNIC is responsible
>for. This document describes that policy.
>
>The "No Questions Asked" Return Policy
>
>While it should be stressed that for the Internet to scale, all
>organizations should obtain address space from their service provider,
>pragmatically speaking addresses which were allocated historically
>("legacy prefixes") have advantages for those who make use of them.
>Specifically, because legacy prefixes are historically allocated, they
>are unlikely to be subject to prefix length filters, thereby providing
>long prefix provider independence.
>
>In many cases, an organization will have multiple legacy prefixes all
>of which require independent routing entries. In order to help reduce
>the strain resulting from the continued growth of the default free
>routing tables in routers on the Internet, APNIC will exchange
>existing provider independent prefixes for a single provider
>independent prefix of equal length or one bit shorter (to round up
>should the amount of space not work out to a CIDR boundary) given all
>of the following are true:
>
> - at least 3 prefixes are returned
>
> - the requestor can present documentation indicating they
> have been delegated the prefixes in question
>
> - all prefixes returned are provider independent
>
>All three of these requirements must be met for the exchange to take
>place.
>
>APNIC will ask no questions with respect to the usage of said address
>space -- more specifically, APNIC will waive the normal requirements
>for address space utilization for the new address space allocated in
>exchange for the discontiguous prefixes. The goal here is to trade
>off address conservation for routing table entry conservation given
>that the Internet operations community considers the latter to be a
>significantly scarcer resource. However, as always, it must be
>stressed that APNIC can make absolutely no guarantees that the newly
>allocated prefix will be routable on the Internet.
>
>Example
>
>Suppose ISP A has four discontiguous provider independent prefixes
>that are currently being routed, specifically 202.10.24.0/23,
>202.12.113.0/24, 203.202.150.0/24, 203.224.18.0/24. If ISP A agrees
>to return those prefixes, APNIC will provide ISP A with a single /21
>provider independent prefix rounding up to the next CIDR boundary.
>
>Conclusion
>
>The purpose of this policy is to attempt to help clean up the swamp.
>While it is true that the most appropriate course of action for an
>organization with multiple discontiguous prefixes would be for that
>organization to renumber into its service provider's address space,
>realistically speaking the likelihood of organizations renumbering
>into provider based space from routed provider independent space is
>assumed to be small. This proposal is consciously trading off address
>space for routing prefix space as the latter is considered more scarce
>than the former and is subject to revision should conditions within
>the Internet change.
>_________________________________________________________________________
>| To unsubscribe: send "unsubscribe" to apnic-talk-request at apnic dot net |
>+-----------------------------------------------------------------------+
>
>
>
_________________________________________________________________________
| To unsubscribe: send "unsubscribe" to apnic-talk-request at apnic dot net |
+-----------------------------------------------------------------------+