Internet Draft R. Hinden Sun Microsystems D. Crocker The Branch Office 25 June 1992 A Proposal for IP Address Encapsulation (IPAE): A Compatible Version of IP with Large Addresses STATUS OF THIS MEMO This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.auto to learn the current status of any Internet Draft. 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. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 1 IP Address Encapsulation (IPAE) 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. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 2 IP Address Encapsulation (IPAE) 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. TABLE OF CONTENTS 1 INTRODUCTION 2 ADDRESS EXTENSION & ENCAPSULATION 2.1 IP Addressing Commonwealth 2.2 Address Size and Format 3 PROTOCOL SPECIFICATION 3.1 Service Description 3.1.1 Intra-Commonwealth Routing 3.1.2 Inter-Commonwealth Routing 3.2 Packet Format 3.2.1 "Classic" IP Header Fields 3.2.2 Extended IP Header Fields 3.3 Protocol Mechanisms 3.3.1 IP 3.3.2 ICMP 3.3.3 Interior Router Procedures 3.3.4 Exterior Router Procedures 3.3.5 IPAC Router Procedures 4 TRANSITION PLAN 4.1 Schedule 4.1.1 Initial Deployment of IPAE (Milestone I) 4.1.2 IPAE Deployment in Hosts (Milestone H) 4.1.3 Internet Runs Out of 32-Bit IP Addresses (Milestone R) Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 3 IP Address Encapsulation (IPAE) 4.2 Effects on Current Implementations & Procedures 4.2.1 Protocol Effects 4.2.2 Host Procedures 4.2.3 DNS Procedures 4.2.4 IPAC Router Transition Procedures 5 SECURITY 6 REFERENCES 7 CONTACTS 1 INTRODUCTION The Internet Protocol (IP) is the common core to the existing Internet. While support for additional protocols is moving the Internet to a hybrid stack, IP remains the one element that is common to the vast majority of real-time, interactive traffic on the Internet. The operational base of this system is doubling approximately every year, creating enormous inertia with its software, training and operations base. It is clear, however, that larger and more structured addresses must be added. This specification seeks to fix the one immediate, serious problem with IP -- namely, its addressing -- without perturbing any other aspect of the technology. The Internet has encountered limitations to its technology before. In fact, a philosophical precept to Internet development has been the framing of a clean, concrete architecture that has immediate applicability, which then is quickly implemented and deployed, with modifications made to it as experience dictates. In most cases, these modifications are accomplished in an upward compatible fashion, causing the smallest disturbance to the installed base of users and systems as possible. This proposal simply attempts to pursue the same style of incremental enhancement that has been a hallmark of Internet technical efforts. Wherever possible, it reuses concepts. Wherever possible, it reuses terminology and formats. Wherever possible, it makes no changes. The Internet, today, represents an enormous investment in software, people, and operational infrastructure. Any change to it will be expensive. However, not all changes are equally costly. For example, staff can learn additional terminology within an existing base of knowledge more easily than they can replace their current vocabulary, even when the new vocabulary represents similar semantics to the old. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 4 IP Address Encapsulation (IPAE) There is considerable experience in teaching TCP/IP concepts, terminology and practises to engineers, technicians, support & operations staff, and sales & marketing personnel who have already been familiar with similar technologies. While there is little risk in the learning process, it takes remarkably more effort and time than would be expected. Besides terms and formats, an operational technology is a culture. People learn new cultures slowly and usually prefer to retain one with which they are familiar. Also from the simple standpoint of operational effort, it makes sense to seek a solution which requires changes in the smallest number of components. It would be ideal, for example, if it were possible to extend IP addresses in an operationally reliable and efficient manner but without changing any host software, while also being invisible to end-users. This proposal does not accomplish this however. But it does retain the majority of current software and operations procedures, with changes made only incrementally. In particular hosts do not have to implement this proposal at the beginning. They need to begin to support it midway into the transition. Support will be provided for hosts that do not ever convert and not all hosts will need to convert. 2 ADDRESS EXTENSION & ENCAPSULATION The current IP routing architecture is divided into two divisions: intra-domain and inter-domain. An administrative domain is defined to be a set of routers operated under a single administration. Intra- domain defines traffic that is inside such an autonomously administered system. Inter-domain defines traffic that goes between autonomous systems. 2.1 IP Addressing Commonwealth This proposal introduces the term _IP Addressing Commonwealth_ (_IPAC_). An IPAC is an area within which current-style, 32-bit wide IP addresses are unique. Today this is an internetwork, such as the current Internet. Traffic that goes between IPACs is called Inter-IP- Addressing-Commonwealth (Inter-IPAC). The terms to describe different forms of network routing are: Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 5 IP Address Encapsulation (IPAE) Entity Routing Relationship ------------ ------------------ ------------------------ Network Intra-Domain intra-administration Commonwealth Intra-Commonwealth inter-admin = Intra-IPAC = IP Classic Internetwork Inter-Commonwealth Inter-IPAC Hence, the hierarchy of structures becomes sub-networks, networks, commonwealths. A collection of connected commonswealths is an internetwork. Sub-networks form logical segments within a network. These are connected by "interior" routers. Connections between networks use "exterior" routers. Connections between commonwealths are by commonwealth routers, with those attached to two or more commonwealths called "border" routers. 2.2 (done?) Address Size and Format An Extended IP Address is specified as an enhancement to the current IP Address. Only a mechanism for carrying additional bits is defined; specification of the format and semantics of the for the additional addressing bits requires a separate effort. However, the requirement to maximize upward compatibility dictates that Extended IP Addressing be a superset of the current IP Addressing framework. The requirement to minimize the impact of moving to use of the new format dictates placing the new addressing information into the data portion of standard IP datagrams. Hence, the new fields are logical extensions to the IP header, but are encapsulated to appear to be data. A general discussion of encapsuation issues is found in [WOOD92]. The new addresses are presumed to consist of some type of hierarchical information, since the benefits demonstrated by the current, limited, two-level scheme are substantial. The specific constraint imposed by this proposal is: The low-order four octets of the new addressing hierarchy represent a classic, 32-bit IP address in the style and format that is currently used. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 6 IP Address Encapsulation (IPAE) The new Extended IP Address (EIPA) is organized as follows: n 32 31 0 +-----------------------------------+-----------------+ | | | | Global IP Prefix Bits | 32-Bit IP Addr | | | | +-----------------------------------+-----------------+ | <--- Extended IP Address ---> | Using a 32-bit IP address as the low-order part of the Extended IP address retains compatibility with many parts of the existing Internet system. It can be used in the pseudo-checksum calculation in TCP and UDP to permit these protocols to be used with out any changes. It serves as a shortened form of the extended address, such as for address processing by routers within a commonwealth, permitting retention of all current behaviors within a IP Addressing Commonwealth. No routers within a commonwealth ever need to change and no host-router interactions ever need to change. The current routing protocols used within an Addressing Commonwealth can remain unchanged. They can continue to exchange 32-Bit IP addresses. 3 PROTOCOL SPECIFICATION 3.1 Service Description A host's model of routing services for the Internet involve a two-level mechanism. An originating host distinguishes "local" traffic among hosts directly attached to the same segment (sub-network) versus traffic which must go to a different segment via a router. A host sends local traffic directly to its destination. To send traffic farther, a host only needs to choose the "first hop" router. The current proposal defines a mechanism which has the same algorithm, but applies it for routing among commonwealths. Hence, a host sends "directly" to those hosts within the host's commonwealth or it chooses a "first hop" commonwealth border router when sending packets to a host in a different commonwealth. In the IPAE proposal an end system distinguishes traffic for hosts within the current IP Addressing Commonwealth, versus traffic that is between IP Addressing Commonwealths. For intra-IPAC traffic, the host uses procedures that are _identical_ to current practise. For inter- Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 7 IP Address Encapsulation (IPAE) IPAC traffic, the end system must select a border IPAC router, in the same fashion that is currently used to select default, first-hop routers. This also is very similar to what is done today by routers through the addition of default routes. In this case, the border router is a "first hop" relative to commonwealths. Since the border router has an address within the host's commonwealth, the host places the intra- IPAC address (i.e., the classic 32-bit IP address) of the router in the Destination IP address field that is currently used, but places the destination end system's longer host address in the Global Destination IP address field of the Extended IP Header. This is conceptually identical to the current practice of placing a destination's IP address in the IP Destination field, but placing the first hop router's media address in the Link/Network layer frame address. It is a key feature of this proposal that systems within an IP Addressing Commonwealth can continue to interact in the manner that is currently used, even when a "new" system is interacting with an "old" one. Only traffic that goes between IP Addressing Commonwealths is required to employ the new format. Hosts which have not upgraded by the time that the current IP addresses are no longer globally unique will require support through an address- mapping facility, but only for inter-IPAC traffic. The requirement for such a mapping (or translation) facility is inherent in any plan for smooth transition support of an operational service and is in no way specific to this proposal. However, the scope of the requirement for this proposal is significantly more limited than would be required for most other approaches to enhancing IP addressing. 3.1.1 (dave c) Intra-Commonwealth Routing Intra-commonwealth routing does not need to change. _Ever_. Current formats, algorithms and protocols are unaffected. Classic IP datagrams and those with IP Address Encapsulation all appear to be Classic IP datagrams, for the purpose of routing within a subnetwork, a network and a IP Addressing Commonwealth (i.e., a distinct internetwork). Only the End-system hosts wishing to communicate with hosts outside their IP Addressing Commonwealth and the IPAC routers that connect internetworks (border routers) are required to be aware of the header extensions to IP. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 8 IP Address Encapsulation (IPAE) 3.1.2 (bob h) Inter-Commonwealth Routing IPAC routers need to run a common protocol to distribute Inter- Commonwealth routing information. The IPAC routers need to perform analogous functions for Inter-Commonwealth routing that is done today using protocols such as BGP, IDRP, OSPF, and IS-IS by current routers. Inter-IPAC routers need the same set of routing protocol functions appropriate to existing routers, as well as being able to support the new Global Internet Address format. The only thing different from current routing protocols is the size of the Global IP addresses. The selection of the size of the Global IP Address will have a major effect in the selection of the routing protocol to use, but that choice need not be part of this proposal. While not a trivial task, the dissemination of Inter-Commonwealth routing information imposes no requirements different from those of today's Internet, except for the change in address format. 3.2 (bob h-done) Packet Format The following figure defines the format of an current IP header with an Extended IP header using new Global IP addresses. Only the fields in the current IP header that are distinctive for IPAE are shown. All other fields are unchanged from their current use. 31 0 --------- +------------------------------------+ 0 | | Current +------------------------------------+ 4 IP | | Header +-------+--------+-------------------+ 8 | |PRO=IPAE| | +-------+--------+-------------------+ 12 | Source IP Address | +------------------------------------+ 16 | Destination IP Address | +------------------------------------+ 20 | IP Options (if present) | | | -------- +-+-----+--------+-------------------+ 20+nO Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 9 IP Address Encapsulation (IPAE) |E| RES | PROT | CHECKSUM | Extended +-+----------------------------------+ 24+nO IP | Global IP Source Address | Header | | | | +------------------------------------+ 24+nO+nGIPA | Global IP Destination Address | | | | | -------- +------------------------------------+ 24+nO+2*nGIPA | Data | | | Note: nO is size of options in octets. nGIPA is size of Global IP Address in octets. 3.2.1 "Classic" IP Header Fields Protocol-ID field is set to the value for IP Address Encapsulation (IPAE). This will identify the extended IP header, with encapsulated global addressing fields. The Source IP Address and Destination IP Address fields are the current style of IP addresses. They are used to identify the source and destination addresses of the datagram in the current Addressing Commonwealth. All other fields in the Current IP Header remain the same. 3.2.2 Extended IP Header Fields The E one-bit format field is a flag used to encode whether the Global IP Address destination implements the IPAE or IP. The value of one means that the destination implements IPAE. The value of zero means that the destination only implements IP. This flag will be used in the transition of IP to IPAE. The RES field is reserved for future use. The Protocol-ID field of the Extended Header identifies the data being carried. This is the same as the original meaning of the protocol field in the current IP header. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 10 IP Address Encapsulation (IPAE) The CHECKSUM field is calculated using the same algorithm (16-bit 1's complement sum) as is used in IP and TCP. It covers both the data in the the Current IP header and the Extended IP header. It should be computed by starting with the original IP header checksum value and adding to it the fields of the Extended IP header with the Extended IP header CHECKSUM initialized to zero. The Global IP Source Address and Global IP Destination Address fields contain the new, larger IP addresses of which the last 32-bits are the "classic" IP address. The length of the extended IP header is fixed. Its exact size will be determined by the size of the Global IP addresses which are not defined at this time. The length in octets of the data portion of the datagram can be computed by subtracting the length of the current IP header and the length of the Extended IP header from Total Length field of the Current IP header. 3.3 Protocol Mechanisms 3.3.1 (steve d) IP IP datagrams exchanged between hosts within the same IP Addressing Commonwealth remain unchanged. When a packet is to be sent to a host in a different commonwealth, the sending host places the 32-bit IP address of the "first hop" IPAC router into the classic Destination IP Address field, with the end-system host's Global IP Address being placed into the Global Destination IP Address field. 3.3.2 (steve d) ICMP ICMP within a commonwealth is unchanged. Between commonwealths, ICMP must be upgraded to support the new address format, to be sent among IPAC routers and hosts supporting IPAE. Since this proposal permits permanent use of unmodified routers, old-style ICMP messages are a permanent feature of the service. Hence, an old-style router may generate an ICMP message to a distant, new host, by sending the control message to the 32-bit Source IP address in the core IP header. Since this address really will be the most-recent IPAC router in the forward chain, it will receive the control message and need to map it to the Global IP Address of the originating host and forward the ICMP message on to it. The IPAC router will need to obtain the Global IP address from the data portion of the ICMP message. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 11 IP Address Encapsulation (IPAE) 3.3.3 Interior Router Procedures None of the functions performed by interior routers change in this proposal. This includes: Packet Forwarding Default Route Selection Operation of Routing Protocols Interactions with Hosts (ICMP, etc.) Network Management 3.3.4 Exterior Router Procedures None of the functions performed by exterior routers change in this proposal. This includes: Packet Forwarding Default Route Selection Operation of Routing Protocols Interactions with Hosts (ICMP, etc.) Network Management 3.3.5 IPAC Router Procedures IPAC routers perform two types of functions. The first set is for forwarding datagrams with Extended IP Headers. The second set is for the support of hosts which do not yet support Extended IP Headers. IPAC routers are similar to other routers in most functions. The have all of the functions that interior and exterior routers run. This includes: Packet Forwarding Default Route Selection Operation of Routing Protocols Interactions with Hosts (ICMP, etc.) Network Management The additional functions that make a router into a IPAC router relate to the additional layers of hierarchy added by this proposal. These new functions are as follows: Run IP Addressing Commonwealth routing protocol Forward datagrams with Extended IP Headers Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 12 IP Address Encapsulation (IPAE) Inject default routes into intra-commonwealth routing Send ICMP messages which include Extended IP Header It is expected that all border routers (IPAC routers) will serve as translation gateways between unmodified hosts and those supporting IPAE. This is required during the transition and is likely to be required for the indefinite future. However, the translation function is logically separate from basic forwarding function of an IPAC router. The requirements for such a capability are relatively straightforward, although administratively cumbersome, primarily requiring the use of static address translation tables. IPAE imposes no special requirements on such a facility, beyond the functions required for any scheme which intends to provide a smooth transition path between old and new hosts. Given the size of the Internet and its rate of software change, it is the authors' opinion that such support is essential. Procedurally, an IPAC border router providing translation services will: Lookup Global IP Addressed based on IP Address Add Extended IP Headers Remove Extended IP Headers Collect and filter ICMP errors back to original IP hosts. 4 TRANSITION PLAN 4.1 Schedule The transition plan for IPAE is based around a timeline which has a number of milestones. The timeline is as follows: | | |----------|---------|----------|-----------------| | | TODAY -> I H R -> FUTURE Milestone I is the initial deployment of IPAE in selected Border Routers. Milestone H is large scale deployment of IPAE in Hosts. Milestone R is when the Internet runs out of the current 32-bit IP addresses. Each milestone in the transition plan is discussed in the following sections. The first objective of the transition plan is to install IPAE in critical router locations. This will reduce the size of routing tables Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 13 IP Address Encapsulation (IPAE) and the load of routing computation in the Internet. The authors of this proposal believe this is very important to keep the Internet growing. It will be done without any changes to hosts. The second objective is to install IPAE in hosts before the current 32- bit IP addresses are all allocated. This will permit an orderly transition to a global routing and addressing scheme with a minimum of disruption to the existing internet. 4.1.1 Initial Deployment of IPAE (Milestone I) The first step of IPAE deployment is to define the first IP Addressing Commonwealths. Initially these should be large areas of the Internet, such as portions of a single continent. The goal is to reduce the amount of intra-commonwealth routing traffic by an order of magnitude or more. The first deployment of IPAE will occur in border IPAC routers. The border routers will create the first IP Addressing Commonwealths. However, at that time the current 32-bit IP addresses will still be globally unique. This will allow the border routers to look up the global IP addresses from the 32-bit IP addresses and build packets with extended IP headers for the hosts. The hosts will not have to implement IPAE in the first stage of deployment. The benefit of this stage of the deployment will be to reduce the size of routing tables in routers (interior, exterior, and border) and to reduce the routing computation load on these routers. The functions performed by the border routers are primarily of inserting/removing extended IP headers and looking up Global IP addresses based 32-bit addresses. Several approaches are possible for the procedure to lookup the Destination Global IP Address. One approach is a static table keep in the border routers. The mappings in this table would be based on the number of networks in the Internet. While this would be a large table towards the time the existing 32-bit IP Address space runs out, even then it would be possible to maintain this table within the small set of border routers. Another approach is to use the Internet's Domain Name System to maintain this mapping table. The DNS is well-suited to this task and it would be a straightforward extension to add the information required. This approach has the border routers do a DNS look as part of its forwarding procedure. This would require careful engineering of the border router / DNS interactions to prevent their becoming a bottleneck. It is expected that the size of the resulting cache in border routers will be Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 14 IP Address Encapsulation (IPAE) much smaller in size than with current operations because most Internet traffic tends to stay in its own IPAC and only a small percentage of total networks will pass through a border router. It should be noted that any requirements for address mapping, whether static or via the DNS, are in no way specific to the IPAE proposal. Any scheme which wishes to provide communication among old-style hosts and new-style hosts having a different address format will require some type of address translation. IPAE simply makes the mapping process easier than would be required if the new address format were entirely unrelated to old-style IP addresses. 4.1.2 IPAE Deployment in Hosts (Milestone H) The second phase of IPAE deployment is deployment to Internet hosts. Hosts will need to be able to support both classic IP Headers format and Extended IP Header format. They will use classic IP Headers when communicating within their commonwealth and will use Extended IP Headers when communicating with hosts in different commonwealths. The goal for this phase of IPAE deployment it to have the majority of Internet hosts implement IPAE before the Internet runs out of 32-bit IP addresses. While it is not possible to have every host implement IPAE, there is sufficient time before Milestone R occurs that it can be implemented by the vast majority, since the amount of new software, documentation and training required will be quite small. This will reduce the need for address translation support in the next phase of deployment. 4.1.3 Internet Runs Out of 32-Bit IP Addresses (Milestone R) At the third phase of the IPAE deployment, hosts which do not implement IPAE will only be able to communicate directly only with hosts in their own commonwealth. There are several possible methods to extend their connectvity if it is necessary to provide these hosts with global Internet service. One straightforward approach is to stage their communication through a host which supports IPAE. This would permit services such as electronic mail and news to operate transparently. Even in today's Internet, mail service often operates in this fashion. Other services such as Telnet and FTP would require an application-level forwarding agent or double login. Another approach is to perform automatic address mapping. Various schemes are possible to support this and are under discussion in the IETF forum. IPAE imposes no special constraints on the choices. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 15 IP Address Encapsulation (IPAE) 4.2 Effects on Current Implementations & Procedures 4.2.1 Protocol Effects ICMP datagrams carry the header of the IP datagram that triggered the ICMP response. This specification extends the requirement to have ICMP datagrams carry the extended IP header, which contains the IP Address Encapsulation information. Transport-level bits specified by ICMP as up to 64 bits, also is to be carried, although it has become common practise to carry more than that amount and is recommended in the Host Requirements documents [BRAD89a, BRAD89b, BRAD89c]. The mapping of physical layer addresses to IP addresses currently being done with ARP-style mechanisms and protocols does not change in this proposal. All of the current mechanisms are used without any changes, since mapping physical layer addresses to IP addresses is an intra- autonomous-system issue. The PPP IPCP (Internet Protocol Control Protocol) specifies a mechanism for negotiating IP addresses and compression protocols between the endpoints of point-to-point links. IPCP option type 3 (IP address) specifies a fixed 4 octet IP address for address negotiation. Most inter IP Addressing Commonwealth point-to-point links are dedicated with no address option negotiation and dial-up access nodes which use this option are likely to be of an _intra_- IPAC nature. Any modification of the current IP header structure will affect current commpression protocols, even if only minimally. Since implementations of transport protocols have an inteface to IP and must specify the destination host address, the programmatic interfaces to the application-level and to the IP-level must be modifed, to pass Global IP Addresses. No detailed understanding of the new format, such as knowledge of intra-commonwealth and inter-commonwealth addressing is required and there are no modifications to the transport protocols. This is the same as the current handling of addresses on the same subnetwork or network, versus those that are on another network. The application does not need to be aware of the difference. Also, these changes will be required for _any_ scheme which modifies or replaces the current IP addresses. However, IPAE provides the smallest amount of change to the installed base. Requirements for Application-level software are the same as for transport services. Also, Domain Name Service interactions must be enhanced, for applications needing inter-commonwealth connectivity. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 16 IP Address Encapsulation (IPAE) For network management, all existing frameworks, protocols and formats can be used, unchanged, within a commonwealth. For inter-commonwealth management, all fields that refer to IP addresses must support Global IP Addresses, but no other changes are required to protocols or formats. (These changes will be required for _any_ scheme which modifies Internet addressing.) 4.2.2 Host Procedures In this scheme "old" hosts will continue to operate the way they always have; no changes to should be necessary to the host software, for communication within a commonwealth. In addition to being able to receive and store the "new" extended IP header, "new" hosts need to modify their packet forwarding algorithm. As before, the host looks up the destination's address in the DNS. If the address is a "new" style address and is on the host's local network it forwards the packet onto that network. In the case of an old style address on the host's local network the host forwards an old style packet onto the network. A "new" host can determine whether a destination host is in the same IP Addressing Commonwealth by matching the upper bits of the "new" style destination address with the upper bits of its own address. If the host receives a new style address within its IP Addressing Commonwealth it forwards that datagram to a router which is discovered through one of the usual methods. The destination in the IP classic header is the lower 32 bits of the "new" address it received from the DNS. As before, when the host receives a "new" address from the DNS that is in a different IP Addressing Commonwealth, the host finds the appropriate border gateway through the DNS and forwards a new style IP packet to the appropriate router. The destination address in the classic IP header of the new style packet contains the IP address of the border gateway, _not_ the address of the final destination. If the destination is an old style host that is not in machines current IP Addressing Commonwealth the DNS returns the information as if the destination were a "new" style host. It is the responsibility of the border router in the destination IP Addressing Commonwealth to forward the packet to an encapsulating gateway. "New" hosts will continue to do ARP and old-style ICMP messages as they used to. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 17 IP Address Encapsulation (IPAE) 4.2.3 DNS Procedures The DNS must be modified to support the new addresses. This must be done in a fashion which retains current information, so that queries in the old (current) style continue to work. The easiest way to insure this is to define a new DNS resource record for the extended address. Hence, queries from old and new DNS resolvers can be distinguished, with each receiving the style of address that is appropriate to them. It may also be prudent to define an additional "proxy" resource type to aid in using translation gateways. However, this does not necessarily require that hosts and networks have two different entries, since the old-style IP address is a part of the new, larger format. In any event, the resource records for 32-bit addresses will need to last as long as that address format is viable. 4.2.4 IPAC Router Transition Procedures To support a transition, as well as provide long-term support for unmodifed hosts, IPAC routers are required to be able to perform several additional procedures, as listed in the section on IPAC Router Procedures. The first transition function is the ability to look up the Global IP Address, given a 32-bit format IP address as input. This is used when receiving a datagram from a host which does not support Extended IP. The IPAC router will use this information to create an Extended IP Header. The mapping may be accomplished with such techniques as a statically-configured table or special entries in the Domain Name Service. The next functions are procedures to add and remove extended IP headers to/from IP datagrams which do not have them. Besides adding/removing addresses, the router must place the real Protocol-ID value into the correct field. The last transition function is to receive ICMP messages with Extended IP Headers and remove the extended IP header from inside the ICMP message and forward the updated ICMP message to the host which the message is intended. They also must receive old-style ICMP messages, from interior routers, and map them into larger-format before forwarding them to their intended host recipient. Since new-format IP datagrams add header information as part of standard IP datagrams, the additional header information reduces the maximum Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 18 IP Address Encapsulation (IPAE) amount of data (transport and above) that can be carried, by the number of octets in the Extended IP Header. When an old-format datagram is translated into the new format, it may result in having to place some of the data in a second datagram. This may require the definition of a special fragmentation facility for use with the new format. 5 SECURITY This proposal pertains to the interworking of independently administered systems. It specifies the use of special routers for that function. Such routers will therefore have extraordinary access to data and connectivity information, as is generally true of routers. This specification creates no security exposures not already present with Internet-based use of IP technology and it provides no special security- related features. This proposal specifies additions to the logical IP header with no special authentication of its contents, besides typical checksum-derived data integrity. This proposal has no affect upon TCP and UDP port number usage and therefore will have no effect upon fultering gateway behavior based upon port numbers. 6 REFERENCES [BRAD89a] Braden, R.T., RFC 1127: Perspective on the Host Requirements RFCs. 1989 October [BRAD89b] Braden, R.T., ed., RFC 1122: Requirements for Internet hosts - communication layers. 1989 October. [BRAD89c] Braden, R.T.,ed., RFC 1123: Requirements for Internet hosts - application and support. 1989 October [WOOD92] Woodburn, R & D. Mills, "A Scheme for an Internet Encapsulation Protocol: Version 1", RFC 1241. July 1991. Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 19 IP Address Encapsulation (IPAE) 7 CONTACTS Robert Hinden Sun Microsystems, Inc. MS MTV-44 2550 Garcia Avenue Mountain View, CA 94043-1100 +1 415 336 2082 David H. Crocker The Branch Office 675 Spruce Dr. Sunnyvale, CA 94086 +1 408 246 8253 Internet Draft 6/25/92 - 12:57 PM (Expires: 12/92) 20