Protocol Action: Implications of Various Address Allocation Policies for Internet Routing to BCP

The IESG <iesg-secretary@CNRI.Reston.VA.US> Tue, 11 June 1996 19:47 UTC

Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25713; 11 Jun 96 15:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18326; 11 Jun 96 15:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25676; 11 Jun 96 15:47 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25476; 11 Jun 96 15:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18197; 11 Jun 96 15:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa25468; 11 Jun 96 15:42 EDT
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: cidrd@iepg.org
Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US
From: The IESG <iesg-secretary@CNRI.Reston.VA.US>
Subject: Protocol Action: Implications of Various Address Allocation Policies for Internet Routing to BCP
Date: Tue, 11 Jun 1996 15:42:53 -0400
X-Orig-Sender: scoya@CNRI.Reston.VA.US
Message-ID: <9606111542.aa25468@IETF.CNRI.Reston.VA.US>


  The IESG has approved the Internet-Draft "Implications of Various
  Address Allocation Policies for Internet Routing"
  <draft-ietf-cidrd-addr-ownership-07.txt> for publication as a Best
  Current Practices RFC. This document is the product of the CIDR
  Deployment Working Group. The IESG contact persons are Scott Bradner
  and Michael O'Dell.


Technical Summary

   The purpose of this document is to articulate certain relevant
   fundamental technical issues that must be considered in formulating
   unicast address allocation and management policies for the Public
   Internet, and to provide recommendations with respect to these
   policies.

   The major focus of this document is on two possible policies,
   "address ownership" and "address lending," and the technical
   implications of these policies for the Public Internet.  For the
   organizations that could provide reachability to a sufficiently
   large fraction of the total destinations in the Internet, and could
   express such reachability through a single IP address prefix the
   document suggests to use the "address ownership" policy. However,
   applying the "address ownership" policy to every individual site or
   organization that connects to the Internet results in a non-scalable
   routing.  Consequently, this document also recomments that the
   "address lending" policy should be formally added to the set of
   address allocation policies in the Public Internet. The document
   also recommends that organizations that do not provide a sufficient
   degree of routing information aggregation, but wish to obtain access
   to the Internet routing services should be strongly encouraged to
   use this policy to gain access to the services.

Working Group Summary

   There was a clear consensus in the working group in support of this
   document.  There was a spirited discussion in response to the IETF
   Last-Call but a consensus developed that, given the currently
   deployed routing technology, this document describes those practices
   which would best conserve the IPv4 address space and thus the
   document should be advanced as a BCP.

Protocol Quality

   The document was reviewed for the IESG by Scott Bradner and Mike O'Dell.


Note to RFC Editor:

   Please include the following text as part of the boilerplate:

	The addressing constraints described in this document are
	largely the result of the interaction of existing router
	technology, address assignment, and architectural history.
	After extensive review and discussion, the authors of this
	document, the IETF working group that reviewed it and the IESG
	have concluded that there are no other currently deployable
	technologies available to overcome these limitations. In the
	event that routing or router technology develops to the point
	that adequate routing aggregation can be achieved by other
	means or that routers can deal with larger routing and more
	dynamic tables, it may be appropriate to review these
	constraints.