-------------------------------------------------------------------
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.