------------------------------------------------------------------- APNIC Document identity Title: The "No Questions Asked" Prefix Return Policy Short title: no-questions-policy Document ref: APNIC-055 Version: 001 Date of original publication: 30 May 1997 Date of this version: 30 May 1997 Review scheduled: n/a Obsoletes: n/a Status: Obsolete Comments: Obsoleted by APNIC-072 -------------------------------------------------------------------- The "No Questions Asked" Prefix Return Policy Issued: May 30, 1997 Expires: N/A 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 - the organization requesting the trade-in operates in the Asia Pacific service area All of these requirements must be met for the exchange to take place, however being a current member of APNIC is *not* a requirement to take advantage of this policy. 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 and organizations are *strongly* encouraged to contact their providers for Internet address space. In addition, APNIC encourages providers to waive their requirements for address space allocation in a similar fashion. 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.