IP Address Encapsulation

[Dave Crocker <[e-mail]>]

Folks,

Bob Hinden and I have been working with a few others to develop
a proposal to support larger IP addresses while protecting the
installed base of systems, software, training, etc., as
much as possible.  We had planned to develop a complete first-draft
specification before subjecting it to general community review, 
but the metabolic rate of community discussion and pressure has
increased too quickly.

As a consequence, we've just submitted a draft of a preliminary
proposal to the Internet Drafts directory.  It should be accessible
tomorrow.  

We feel that the proposal document contains the essential meat of
the specification, although we all understand that it is the
details that make a specification succeed or fail.  We hope to
release a version of the full specification in less than 2 weeks.

To whet your appetites, I am including the Summary section of the 
proposal document.  The full document is about 20 pages:

        draft-crocker-ip-encaps-00.txt.


SUMMARY

The Internet currently is seeking a means of providing for long-term 
growth by increasing the amount of address space that is available for 
hosts and by decreasing the amount of table storage that is required for 
routers.  One solution to these problems is a direct upgrade to a new 
version of IP.  Another is to switch to use of a new protocol such as 
CLNP which has provisions for a larger and more hierarchical address 
space.  Both require very substantial disruption to the IP installed 
base.  This proposal describes an alternative which minimizes overall
 disruption and, in fact, entirely eliminates a significant portion of 
it.

A current IP addresss is defined to be used within its own 32-bit IP 
address space.  This proposal labels such a space an _IP Addressing 
Commonwealth_.  The proposed extension specifies a means of connecting 
such environments by using additional addressing bits, while retaining 
current usage of the original 32-bit format.  

The basic proposal is to define the addressing enhancements to IP so 
that they are carried as IP data and therefore are invisible to all 
current IP hosts and routers, except those that have been modified to 
understand the new format.  Hence only participating end system hosts 
and special routers at the borders of Addressing Commonwealths need to 
understand the new formats.  This scheme is called _IP Address 
Encapsulation_ (_IPAE_).  

Key benefits of this proposal are:  

	Routers interior to Addressing Commonwealths _never_ need 
	to be modified.

	Hosts do not have to change their 32-bit IP address _ever_. 

	Hosts which communicate only within their local addressing 
	commonwealth will require no changing _ever_.

	_All_ IP-related functionality, such as multicasting, is 
	retained without modification.

	_All_ of the Internet's investment in staff training, including 
	procedures, formats and terminology is retained.  Changes to 
	support IPAE only require acquisition of small amounts of 
	additional procedures, formats and terminology.

	_All_ operational support software will continue to function 
	within a commonwealth.

	The current routing table size problems and routing computation 
	problems are alleviated as soon as the first transition step is 
	deployed.

	Hosts are not required to support IPAE directly until the 
	Internet is closer to running out of IP addresses, and then 
	only for hosts wishing full Internet connectivity.   That is, 
	existing hosts will be supported without any changes for a 
	long time. 

This document is in the form of a summary of a preliminary specification 
and represents work-in-progress to describe the new protocols and the 
changes needed to effect a transition to the new addressing and routing 
scheme.  This version of the proposal is intended to provide detail 
about goals and framework, with enough specification to make the basis 
of the proposal concrete.  However, most of the formal specification 
that ultimately will be required is left for a later version.