Internet Draft D. Crocker The Branch Office R. Hinden Sun Microsystems November 11, 1992 IP Address Encapsulation (IPAE): A Mechanism for Introducing a New IP 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 seeks to increase the amount of IP address space that is available for hosts and to decrease the amount of table storage that is required by routers. Ultimately, the current IP (IP version 4) and any replacement are inherently incompatible and movement to the new version requires very substantial change to the IP installed base. This specification describes an approach which retains as much software, operations and training as possible, and minimizes overall operational disruption by allowing subsets of the Internet to carry the new-format Internet datagrams inside old-style IPv4 datagrams, using a technique called "IP Address Encapsulation" (IPAE). This permits incremental and asynchronous introduction and makes transition entirely optional for portions of the Internet infrastructure. It further permits early reduction to routing table size. This specification emphasizes extreme ease of transition to a new version of IP that is as close to the existing version as is appropriate. Hence, this IP Address Encapsulation (IPAE) specification is notable for attempting to fix only the current and urgent problems and for neither solving nor precluding solution to less well- understood problems. By utilizing a separately-defined protocol for the final deployment, IPAE can be viewed as a transition technology, rather than as a protocol, itself. ACKNOWLEDGEMENTS IPAE has had the benefit of on-going contribution by many members of the Internet community, with very substantial changes and enhancements ensuing from the collaborative group engineering process. Bob Hinden originally suggested encapsulating one IP datagram inside another [HIND92b]. Dave Crocker & Bob Hinden brought a modified idea -- to encapsulate new, global addresses inside normal IP datagrams, using the IP address fields for "next hop" carriage [HIND92a] -- to the IPAE working group. While permitting very smooth transition, this left an end-state for IPAE which was not a very clean, since the IPAE header is a hybrid. Bob Gilligan observed similarities between IPAE's "mini-layer" and Deering's SIP design, resulting in IPAE focus on SIP. Craig Partridge developed a very early code analysis for implementing the original IPAE in the Berkeley kernel, permitting much more concrete understanding of the implementation impact of the encapsulation scheme and the general effects of increasing the IP address size. Recent implementation work by Erik Nordmark and Bob Gilligan has added to the base of empirical data. The working group has included contributions from: Craig Partridge of BBN, Tom Kessler, Erik Nordmark, and Bob Gilligan of Sun Microsystems, Steve Deering of Xerox PARC, Greg Chesson, Ronald Jacoby,and and Rob Warnock of Silicon Graphics, Hon Wah Chin and Dave Newman of Protocol Engines, Ross Callon, Mike Reilly, Virgil Champlin and Geoff Mulligan of Digital Equipment, Michael Conn of MCI, John Moy of Proteon, John Veizades of Apple, Jeffrey Burgan of NASA, and Vince Fuller of BARRNET. Internet Draft 2 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) TABLE OF CONTENTS STATUS OF THIS MEMO SUMMARY ACKNOWLEDGEMENTS TABLE OF CONTENTS 1. PROBLEM STATEMENT: IP DEFICIENCIES 2. SOLUTION REQUIREMENTS 2.1. Address characteristics 2.2. Timing of benefits 2.3. Preservation of Installed Base 2.4. Transition Ease & Independence 3. IP ADDRESS ENCAPSULATION APPROACH 3.1. Encapsulation 3.2. Address Format 3.3. Interoperation 3.4. Translation 3.4.1 Transit Net(s) Only 3.4.2 IPAE Host to IPAE Host 3.4.3 IP Host to IPAE Host 3.4.4 IPAE Host to SIP Host 3.4.5 IP Host to SIP Host 4. IPAE PROTOCOL COMPONENTS 4.1. SIP Address Format 4.2. Datagram Formats 4.2.1 SIP Format 4.2.2 IPAE Format 4.3. ICMP & IGMP 4.4. Routing Protocol(s) 4.5. Transport & Above 4.5.1 Pseudo header checksum 4.5.2 TCP Connection ID 4.6. Subnetwork & Below 4.7. Network Management 5. IPAE HEADER FIELD MAPPINGS 5.1. SIP Derived from IP Datagrams 5.2. IP Derived from SIP Datagrams 5.3. Receipt of IPAE Datagrams 6. IPAE NETWORK COMPONENTS 6.1. Hosts 6.2. Interior Routers 6.3. Border Routers 7. IPAE ADDRESSING EXAMPLE 8. TRANSITION SEQUENCE 8.1. Initial Deployment of IPAE (Milestone I) 8.2. IPAE Deployment in Hosts (Milestone H) 8.3. Internet Runs Out of 32-Bit IPv4 Network Numbers (Milestone R) 8.4. Administrative Domains Fully Convert to SIP (Milestone S) 9. REFERENCES 10. CONTACTS Internet Draft 3 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 1. PROBLEM STATEMENT: IP DEFICIENCIES The Internet is experiencing explosive growth, usually described as doubling every 12 months. There is no indication that this growth will reduce and development of IP use into mass markets would create an even steeper growth curve. The result is a crisis in IP router table storage and use and in near- term exhaustion of available IP network numbers. A variety of extensions to current IP service also are desired, but they are not part of the current operational crisis. IP routers which record routes to all networks in the Internet must maintain an entry for each such network, since the IP network address space is flat. That is, neighboring networks do not necessarily have any similarity in the IP network portion of their address. A new address structure is required, probably with a hierarchical scheme, so as to allow route-aggregation in table entries to neighboring networks. While the 32-bits of the IP address space theoretically can reference about 4 billion nodes, the bits have been partitioned to faciliate assignment and aggregation into networks, thereby reducing the realistic maximum number of nodes and -- more importantly -- networks. While estimates vary considerably, it is possible that IP network number exhaustion will occur within the next few years. For example, IP could begin to make penetrations in mass markets. Since the damage caused by being unable to assign new IP network numbers is so great, it is prudent to pursue an urgent path to increasing the number of bits. Again, there is debate about the total number of bits that is necessary, with proposals ranging from 64-bits to 160-bits (as well as the suggestion that there be no limit.) In any event, the Internet needs to determine the size and format for a new, larger IP address. Various additional enhancements to IP are being discussed, such as provision for real-time data delivery (i.e., guaranteed throughput and delay), network- level security features, and support for mobile hosts. While there is much discussion about these, and other, issues they represent topics of interest, rather than of concrete and stable experience and agreement. No proposals have achieved concensus in the Internet and none have acquired a substantial operational base. Hence, they must be deemed "research" for current purposes. 2. SOLUTION REQUIREMENTS This section describes the the characteristics of the required solution that are held to be primary by this specification. While not attempting to exclude additional features and consideration, the specification does place particular emphasis on its concern for the installed base of IP users, while providing relief from the current technical and operational difficulties: Internet Draft 4 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 2.1. Address characteristics The new version of IP must provide a hierarachical address, sufficient to permit distributed assignment and administration and sufficient to permit route-aggregation in IP forwarding devices (routers). A hierarchy which recognizes country boundaries appears to be the most viable, administratively. The address space must permit 10**9 networks. 2.2. Timing of benefits The need for route aggregation is immediate. A specification must permit reductions in route table size in the near term. It is preferred that a router achieve this benefit as soon as the new version of IP is implemented in a router. 2.3. Preservation of Installed Base A specification for a new IP must consider the current installed base of software and people. IP has an enormous installed base of operational systems, as well as an installed base of people who provide, support and use such systems. Each change to the existing technology carries the expense of changes to people, software and operations. Given the size of the installed base, the aggregate expense of each such change can be quite large, particularly if it causes reduced utility to the Internet. To this end, a specification must justify each and every change to formats, terminology, services, software and operations, with respect to the current IP Internet. This applies to IP, itself, as well as to related components, such as the addressing framework, internetwork control, subnetwork interfaces and transport-layer interfaces. 2.4. Transition Ease & Independence Movement from the existing IP to its replacement will be accomplished over an extended period of time. It must not require a highly coordinated change throughout the Internet community, since the diversity of network administrations and operations does not permit such coordination. Further, movement to the new IP must be accomplished in a manner which permits network- layer interoperation between users of the existing and new versions, for as long as is operationally practical. Hence, this specification emphasizes smooth and voluntary transitions, attempting to provide incremental benefit Internet Draft 5 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) when adopted, and imposes no changes that are not of fundamental and well- understood benefit. 3. IP ADDRESS ENCAPSULATION APPROACH This specification seeks to solve the technical problems of immediate concern to the Internet and does not attempt to provide other, desired functional and operational enhancements. Neither does it appear to preclude such enhancements and there is some indication that its design will prove entirely adequate for later inclusion of such enhancements. While a variety of new protocols may satisfy the urgent addressing and routing table concerns for the Internet, this specifications views concerns for protecting the installed base as requiring the new protocol to have as little difference from current IP as possible. Consequently, this specification focusses on Simple IP (SIP), by Steve Deering, as the appropriate choice for the new IP [DEER92a, DEER92b]. While the general IPAE transition scheme, using encapsulation of the new protocol inside the old, can be applied to other candidates, it appears that a number of transition benefits will not accrue with those candidates. In particular, the packet and address similarities to IPv4 greatly facilitate IPv4-SIP translation, which permits combinations of interoperability tht permit an extremely wide range of transition options. At its simplest, IPAE envisions three phases to the adoption of a new IP: IP -> IPAE -> SIP Initially, all nodes use only the old IP. The goal is to operate all nodes only with SIP. While it is expected that this end-state will take a very long time to reach for the whole Internet, portions of the Internet may achieve "pure" SIP operation rather quickly. Between the current use of IP and the eventual use of SIP, there will be an extended period of partial adoption and therefore requiring techniques for smooth transition and interoperation. IPAE specifically attends to those requirements. IPAE permits continued operation of IP-only hosts and IP-only routers. It further supports SIP-knowledgeable hosts and routers. A host may operate SIP- only, without any IP support, and/or may be able to encapsulate SIP within IP datagrams, in an IPAE mode. Routers which support IPAE generally will serve as "border" routers between IP and IPAE or SIP domains. The border routing function can operate at a logical routing level above IP, using IP as a type of subnetwork-layer service. A border router also can take native IP datagrams and turn them into IPAE hybrid datagrams, when the router is acting as an internetwork-layer gateway translation service. Internet Draft 6 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 3.1. Encapsulation This specification defines a technique that is called "IP Address Encapsulation" (IPAE) because it moves the Internet over to a new version IP by allowing hosts and routers to upgrade, to the new addressing and datagram format, in a manner that is transparent to nodes which have not yet made the transition. The technique for accomplishing this is to encapsulate the new protocol inside the old. Hence, users of the enhanced addressing scheme may "tunnel" their datagrams over the existing IP infrastructure. Neighbors which have completed conversion to the new IP can interoperate without encapsulation, whenever that is convenient. IPAE packets stacks as: +-----------+ | Transport | +-----------+ | SIP | +-----------+ | IP | +-----------+ | Link | +-----------+ 3.2. Address Format Support of interoperation between nodes using the old and new versions of IP is best accomplished by defining the new IP address to contain old IP addresses in its lower 32-bits. This is accomplished by conceptually extending the network field or by adding one or more fields "above" the IP Network field. Preserving the definition of the existing 32-bits permits local operations to default the new bits, if they desire, and faciliates translation between old and new IP datagrams. Further the address, itself, must contain specification of the IP version (old versus new) that is used by the referenced node. This feature eliminates the need for routers at the border of an administrative domain to maintain state information about their user nodes. Such reduced router and operations complexity greatly facilitates transition to SIP. Any new address format will dictate a change to the Domain Name Service and to any protocol modules which are cognizant of IP addresses. While fundamental to the success of an Internet transition, the details of such changes are beyond the scope of this specification. Further, the details appear to be identical for any IP replacement that is envisioned. Internet Draft 7 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 3.3. Interoperation This specification supports interoperation between hosts supporting only the old IP and those supporting only the new IP, through the use of a translation service. Translation usually is a hand-crafted and operated service, with limited ability to scale to large operations. However, this specification supports general-purpose network-level translation between IP and SIP, as desired. This is possible by ensuring that: a) Host operating mode (old versus new IP) is detected easily, b) Address formats map well and algorithmically, and c) Header field semantics map well and algorithmically. 3.4. Translation Translation can be provided by special routers, or by nodes themselves. The latter facility is expected to permit interoperation between hosts operating on the same network, particularly prior to conversion of the interior routers for a network. Hence, nodes operating with the new version of IP may have an implementation which treats the two versions of IP as entirely independent network modules. Alternatively, a node may operate as if all datagrams are coded as new IP datagrams and then treat translation to/from old IP as a special case. Transmission of new IP datagrams can be direct in their native form, translated into an old IP format, or encapsulated with the new inside the old. The first form is, of course, preferred. But it is expected that few nodes will be able to utilize the new IP initially. Hence, the choice usually will be between translation and encapsulation. If the next SIP hop is the recipient (final) host, and that host supports only old IP, then the SIP datagram must be translated into the format of an old IP datagram. If the next SIP hop is an intermediate router and that router supports only old IP, then the SIP datagram needs to be encapsulated in an IP datagram. Note: In the following examples, "IPa", "IPb", and RIPcS represent three, different IP headers, generated independently. For example, IPa might be generated by the originating host, but might be discarded when the datagram is translated into a "pure" SIP datagram. Later, a border router might need to have the datagram transit an IP network and would create a fresh IP header (IPb) derived from the SIP header. Internet Draft 8 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 3.4.1 Transit Net(s) Only IPAE can be deployed without awareness of hosts: Orig Router Router Router Router Dest IP IPAE IP IPAE IP IP | | | | | | | | | | ----------- ----------- ----------- ----------- ----------- +-----+ +-----+ +-----+ +-----+ +-----+ | IPa | | SIP | | SIP | | IPa | | IPa | +-----+ +-----+ +-----+ +-----+ +-----+ | IPb | | IPb | +-----+ +-----+ This permits transit networks to employ IPAE for reduction of routing tables, without waiting for host-level deployment, since routing can be based on the structured SIP address rather than the flat IP address. 3.4.2 IPAE Host to IPAE Host IPAE packets which move through the Internet between two IPAE hosts may undergro modification, such as: Orig Router Router Router Router Dest IPAE IP IP IPAE IP IPAE | | | | | | | | | | ----------- ----------- ----------- ----------- ----------- +-----+ +-----+ +-----+ +-----+ +-----+ | SIP | | SIP | | SIP | | SIP | | SIP | +-----+ +-----+ +-----+ +-----+ +-----+ | IPa | | IPa | | IPa | | IPb | | IPb | +-----+ +-----+ +-----+ +-----+ +-----+ In this case, two IPAE hosts go through an Internet in which IPAE routers are rare. This IPAE router discards the IP header it receives (IPa) and generates a new one (IPb) just as it does with media frame headers, when relaying between local area networks. Internet Draft 9 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 3.4.3 IP Host to IPAE Host Common to early stages of deployment, a pure-IP host can talk with an IPAE or pure-SIP host via an IP-accessible router: Orig Router Router Router Router Dest IP IP IPAE IP IPAE IPAE | | | | | | | | | | ----------- ----------- ----------- ----------- ----------- +-----+ +-----+ +-----+ +-----+ +-----+ | IPa | | IPa | | SIP | | SIP | | SIP | +-----+ +-----+ +-----+ +-----+ +-----+ | IPb | | IPb | | IPc | +-----+ +-----+ +-----+ This is generally identical to the previous example, except that the first IPAE router also serves as an IP-to-IPAE translation gateway, deriving the necessary SIP header from the IP header. 3.4.4 IPAE Host to SIP Host As localities begin to support "pure" SIP operation, the following scenario will occur: Orig Router Router Router Router Dest IPAE IP IP IPAE SIP SIP | | | | | | | | | | ----------- ----------- ----------- ----------- ----------- +-----+ +-----+ +-----+ +-----+ +-----+ | SIP | | SIP | | SIP | | SIP | | SIP | +-----+ +-----+ +-----+ +-----+ +-----+ | IP | | IP | | IP | +-----+ +-----+ +-----+ In this case, the IP header simply is stripped from the datagram and the SIP portion continues on, to a pure-SIP host. Internet Draft 10 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 3.4.5 IP Host to SIP Host Use of IPAE can be helpful even in only one router, to map between to internetworks which employ IP-only and SIP-only: Orig Router Router Router Dest IP IP IPAE SIP SIP | | | | | | | | ----------- ----------- ----------- ----------- +-----+ +-----+ +-----+ +-----+ | IP | | IP | | SIP | | SIP | +-----+ +-----+ +-----+ +-----+ A key point, here, is that such pure gatewaying is a straightforward side- effect of the IPAE principles, when coupled with similarity between IP and SIP semantics. The gateway router behaves identically with a configuration of IPAE border router which treats IP encapsulation as a side-effect and which supports translation of IP into SIP. 4. IPAE PROTOCOL COMPONENTS The primary change in IPAE is to the Internet layer. Other layers must be changed whenever they use Internet addresses. In particular, some change is necessary at the transport and application layers. The IPAE proposal introduces two new Internet layer packet formats that we refer to as SIP and IPAE. The SIP header is a revised version of the IPv4 header with larger addresses and streamlined functionallity. The IPAE header is composed of a SIP header encapsulated within an IPv4 header. The IPAE packet format is used to transit regions connected with IPv4 routers, while the SIP packet format is used between directly connected IPAE/SIP hosts and routers. SIP is specified separately [DEER92a, DEER92b], but details are summarized in this specification, to facilitate discussion. 4.1. SIP Address Format The the basic requirement driving the current effort is to provide enough additional bits to support global administration, with 2 or more levels of hierarchy above the existing IP address portion, and the top level referencing country. Internet Draft 11 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) Given the goal of facilitating transition to SIP, IPAE-related operation requires enhancements to the current IP address, beyond the base requirement for a larger address space. These requirements are: a) A bit indicating whether the referenced host is using old or new IP; this eliminates the need for routers that provide translation gatewaying to maintain state tables about the capabilities of specific hosts; and b) Preservation of the existing format for 32-bit IP addresses, within the new format, to faciliate local interoperation between old and new IP hosts. The resulting SIP address specification is: 1 15 32 16 +-+--------+--------+--------+--------+ | |Country+|Site / Subscriber| Local | |C|Provider|..........................| | |/ Metro | | IP Address | +-+--------+--------+--------+--------+ C Region Attachment Local C (IP Compatibility) bit is 0 for IPAE/SIP destination, 1 for IP destination Multicast is encoded by a special country code. The C-bit is used to indicate the capabilities of the referenced node. If the bit is zero, then the node supports SIP, and possibly IPAE. (In reality, IPAE is viewed as a per-hop encapsulation technique, so that its use depends upon the characteristics of the next-hop node, rather than upon the end-system.) The Region field is used for global routing and includes the top of the addressing hierarchy which is the country having assignment authority. Subordinate to this is specification either of the service provider for the referenced subscriber or the metropolitan area of the site's attachment to the Internet. Service providers assign Subscriber IDs. Locations operating with coordinated metropolitan interchanges (MIX) may use Country+Metro code and then assign Site IDs. The last 4 bytes of an address function as a IPv4 address. However, the actual boundary between IP address and Site/Subscriber information varies. In effect, Site/Subscriber is an extension to the network portion of the IP address. Until IP network number space is exhausted, 32-bit IP addresses will be assigned according to current practise, so that providers (and MIX operations) Internet Draft 12 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) will assign only the upper 32 bits of a SIP address. Later, they also will assign those bits currently used to specify the IP Network field. Hence, the transition model permits an independent network site (an "administrative domain", or AD) to operate internally with 32-bit IP addresses and to pre-pend an additional 32 bits for global routing. If an AD network is multi-homed to the Internet, then the bottom-half of its two SIP addresses will be the same, during the transition period. After IP network number exhaustion, the current specification of SIP means that an AD may have a single "host" field (subnetwork and host) as currently used by IP, but different network addresses for each point of attachment and one more for IP internal exchanges. 4.2. Datagram Formats IPAE/SIP hosts may transmit packets using any of the three packet formats: IPv4, IPAE, or SIP. IPAE/SIP hosts must be able to receive packets in all three packet formats. 4.2.1 SIP Format The SIP header is a revision of IP version 4 header format SIP shares all of the datalink layer encapsulations that have been defined for IPv4. A new IP version number differentiates SIP from IP version 4. This is the format of the SIP header: 0 3 15 23 31 +---+------------+---------+---------+ 0 |V=6| RESERVED | +---+------------+---------+---------+ 4 | DATA LENGTH | HOP LMT | PAYLOAD | +----------------+---------+---------+ 8 | | + Global IP Source Address + | | +------------------------------------+ 12 | | + Global IP Destination Address + | | +------------------------------------+ 16 | Data | | | Internet Draft 13 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 4.2.2 IPAE Format The IPAE packet format uses the SIP header encapsulated within an IPv4 header. This is the format of the IPAE header, with relevant portions of the IP header labeled. 0 3 7 15 23 31 --------- +---+---+--------+---------+---------+ 0 |V=4| | Length | +---+------------+-------------------+ 4 | | Current +-------+--------+-------------------+ 8 IP | TTL |PTCL=SIP| | Header +-------+--------+-------------------+ 12 | Source IP Address | +------------------------------------+ 16 | Destination IP Address | +------------------------------------+ 20 | IP Options (if present) | | | --------- +---+------------+---------+---------+ 20+n0 |V=6| RESERVED | +---+------------+---------+---------+ 24+n0 | DATA LENGTH | HOP LMT | PAYLOAD | Extended +-------+--------+-------------------+ 28+nO IP | | Header + Global IP Source Address + | | (SIP) +------------------------------------+ 36+nO | | + Global IP Destination Address + | | -------- +------------------------------------+ 44+nO | Data | | | Note: nO is size of IP options in octets. When the IPAE format is used, the destination and source IP addresses located in the IPv4 header target the next hop IPAE/SIP system along the path to the destination. In both the SIP and IPAE formats, the global IP source and destination addresses identify the end systems. It is the global source and destination addresses located in the SIP header that are used by UDP and TCP to uniquely identify transport endpoints. Most of the features of IPv4, including options and fragmentation and Internet Draft 14 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) reassembly, are available in SIP. Thus it is possible to map an IPv4 packet into an IPAE or SIP packet and vice versa. Options are carried in SIP by using defined Payload values and the last SIP Option header contains the actual transport Payload value. When Options are present, the Global destination address references the host that is to process the option. 4.3. ICMP & IGMP The SIP specification defines any required ICMP and IGMP changes or extensions. Use of IPAE adds no further requirements, except for relaying ICMP messages from IP-only routers to IPAE/SIP source hosts. An IPAE datagram that traverses an IP network may result in having an IP-only interior router generate an ICMP error message. The router will specify a destination for the ICMP datagram which is, in reality, the previous IPAE border router, rather than the originating IPAE (or SIP) host. The border router must function as an ICMP relaying service, when possible, as discussed in the section on Border Routers, below. 4.4. Routing Protocol(s) IPAE uses SIP and IP routing mechanisms. An administrative domain is free to use any acceptible IP routing protocol, among is interior routers, with an appropriate rule for deriving 32-bit addresses from the larger SIP addresses. 4.5. Transport & Above IPAE imposes no special requirements on applications or transport, except for pseudo-header checksum calculation. Any development of a larger IP address will directly affect programming interfaces and some application protocols, since they use current IP addresses directly. Primarily, enhancements appears to be straightforward and simply need to handle the larger string, often simply as an uninterpreted string. A node may implement IPAE (i.e., SIP over IP) as a special network-level interface or may make it equivalent to a subnetwork-/link-level option for SIP. In the former case, the transport layer needs to select IPAE from the set of alternatives, including IP and SIP. In the latter case, the transport layer selects a generic internet layer which, in turn, chooses IP, SIP or IPAE to get to the next (or final) SIP node. TCP and UDP must be modified somewhat in order to be layered above IPAE and Internet Draft 14 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) SIP. Changes are needed to the "pseudo-header" used in the checksum algorithm, and to TCP's connection or socket identification algorithm. 4.5.1 Pseudo header checksum The TCP spec [RFC793] and the UDP spec [RFC768] both define a checksum that covers the data portion of the segment along with a 96-bit "pseudo header" that includes the IP source and destination addresses, protocol ID and length fields from the IP header. Including this pseudo header in the transport checksum protects the transport layer against misrouted segments. The pseudo header used in the transport checksum when TCP and UDP are layered above IP can viewed logically as this: 0 7 15 31 +--------+--------+--------+--------+ | source address | +--------+--------+--------+--------+ | destination address | +--------+--------+--------+--------+ | zero |protocol| length | +--------+--------+--------+--------+ Inclusion of a pseudo header that covers the addresses in the checksum of TCP and UDP layered above IPAE and SIP is even more important since the SIP header is not checksummed. When communicating with other IPv4/IPAE/SIP hosts, the TCP and UDP pseudo header includes the complete global source and destination addresses. But since the IPAE mechanism allows IPv4 packets to be translated into IPAE or SIP and vice-versa, the IPv4/IPAE/SIP host must implement a compatible pseudo- header checksum when the packets it receives originated from, or the packets it is sending are destined for, an IPv4 host. The IPv4/IPAE/SIP pseudo header checksum algorithm must cover only the low-order 32 bits of the global addresses when it is communicating with an IPv4 host. When transmitting, the IPv4/IPAE/SIP host can use the C-bit of the global destination address to determine whether the peer is an IPv4 host. When receiving, the C-bit of the global source address can be used. When communicating with an IPv4 host using the IPv4 packet format directly (e.g., an IPv4 host on the same subnet), the 96 bit pseudo header shown above is used. Internet Draft 16 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) When sending or receiving packets in the IPAE or SIP format to another IPv4/IPAE/SIP host the following pseudo header is used when the processing node is: 1) Transmitting and C-bit of Global Destination Address is 0, or 2) Receiving and C-bit of Global Source Address is 0 0 7 15 31 +--------+--------+--------+--------+ | zero |protocol| length | +--------+--------+--------+--------+ | | + Global source address + | | +--------+--------+--------+--------+ | | + Global destination address + | | +--------+--------+--------+--------+ IPAE/SIP peer pseudo header When sending or receiving packets in the IPAE or SIP format to an IPv4 host the following pseudo header is used when the processing node is: 1) Transmitting and C-bit of Global Destination Address is 1, or 2) Receiving and C-bit of Global Destination Address is 1. 0 7 15 31 +--------+--------+--------+--------+ | zero |protocol| length | +--------+--------+--------+--------+ | zero | +-----------------------------------+ | 32-LSB of global source addr | +--------+--------+--------+--------+ | zero | +-----------------------------------+ | 32-LSB of global destination addr | +--------+--------+--------+--------+ IPAE/SIP - IPv4 compatible pseudo-header Internet Draft 16 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 4.5.2 TCP Connection ID TCP uses the concatenation of local and remote IP address with local and remote port number to uniquely identify a connection. TCP uses the term "socket" to identify one endpoint of a connection. The local socket is identified by the local IP address and local port number, while the remote socket is identified by the remote IP address and remote port number. In processing received segments and ICMP error messages, TCP must use the destination IP address and port number -- and possibly the source IP address and port number -- from the received segment in a lookup in its list of connection blocks in order to find a matching socket or connection. When communicating with another IPv4/IPAE/SIP host, TCP host must use the full global source and destination addresses to identify connections and sockets. But when communicating with IPv4 hosts using the IPAE or SIP packet formats, TCP must use only the low order 32 bits of global source and destination to identify the connection. This requires a change to TCP's connection block lookup for received segments. Assuming that TCP keeps a single list of connection blocks identifying connections to both IPv4 hosts and IPv4/IPAE/SIP hosts, the change can be summarized like this: 1) If the format of the received packet is IPv4, Then: use the source and destination IP addresses in the received packet to compare with the low-order 32 bits of the global source and destination address in TCP's connection block list, Else: 2) If the format of the received packet is IPAE or SIP, And: 2a) If the C-bit of the global source address is 1, Then: use the low-order 32 bits of the global source and destination addresses in the packet to compare the low-order 32 bits of the global source and destination address in the connection block list, Else: 2b) If the C-bit of the global source address is 0, Then: use the full global source and destination addresses in the packet to compare with the full global source and destination addresses in the connection block list. Internet Draft 17 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 4.6. Subnetwork & Below IPAE, as SIP-over-IP, employs standard IP-over-media capabilities. SIP-over- media will use the same mechanisms as IP currently uses. Hence, there are no changes to use of ARP, or the like. Note that host references internal to an administrative domain will require 32-bits or less, as they do now, so that the upper 32-bits of SIP address space are not required for subnetwork references. 4.7. Network Management Management within an AD can continue to operate, without change, since nodes retain their IP addresses. For global management, MIB specifications must be enhanced to accomodate the larger addresses. There is no expectation of additional protocol changes. 5. IPAE HEADER FIELD MAPPINGS By keeping the semantic details of the new IP and the old IP closely related, it is possible to map between the header fields of either, greatly facilitating support of internetwork-level translation gateways. Three cases need to be supported: Turning an IP datagram into a SIP or IPAE (SIP-over-IP) datagram, generation of an IP header from a SIP header, and general handling of a received IPAE (SIP-over-IP) datagram. 5.1. SIP Derived from IP Datagrams If a router supports IPAE for hosts that use only IP, then the router is a border IPAE router that also provides internetwork-level translation gatewaying. That is, it turns IP datagrams into SIP datagrams. It may also then send the SIP datagram onward, within an IP encapsulation, but this is a separate function from gateway translation. On receipt of an IP datagram that is determined to be destined for a SIP host or that is otherwise in need of a SIP header, the gateway module will map IP fields into SIP fields as follows: Hop Limit: The value of the IP Time To Live field shall be copied into SIP Hop Limit field. (This presumes that the router has already performed its own decrement to the IP TTL field.) Though TTL has slightly different semantics, Internet Draft 18 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) there is no need to perform a more complicated translation. Payload: The value of the IP Protocol field shall be copied into the SIP Payload field. Source Address: The value of the Source IP Address shall be mapped to a SIP Global Source Address, as appropriate. Usually, this will require pre-pending a constant value to the Source's IP address. Destination Address: The value of the Source IP Address shall be mapped to the SIP Global Destination Address, as appropriate. Border routers will support a table for such mappings. While IP addresses remain globally unique, this table can be maintained through the Domain Name Service or other coordinated Internet service. Options: If the IP datagram contains options, then each shall be mapped to the appropriate SIP option, as appropriate. Options which do not map are dropped. Note that creation of SIP options alters the value of the SIP Payload value, placing the actual value into the Payload field of the SIP Option mini-layer. Other fields: All remaining IP fields are ignored. 5.2. IP Derived from SIP Datagrams When a border router needs to create an IP header, either for the purpose of IPAE encapsulation to achieve transit through an IP-only domain, or to translate the SIP header for receipt by an IP-only host, the router shall perform the following mappings: TTL: The value of the SIP Hop Limit field shall be copied into the IP Time To Live field. (This presumes that the router has already performed its own decrement to the SIP Hop Limit field.) Protocol: The value of the SIP Payload field shall be copied into the IP Protocol field. Source Address: The value of the SIP Global Source Address shall be mapped to the IP address of the source, if the router has determined that the datagram is traversing its final IPAE hop, that is, if it being delivered to the recipient host, or if it is being fully converted to an IP-only datagram. While IP addresses remain globally unique, the value of the IP Source Address field is the value of the lower 32-bits of the SIP Global Source Address. If the IP header is to serve an encapsulation function, with the SIP header being retained, then the Source Address shall contain the IP address of the Internet Draft 19 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) border router that is creating the IP header. Destination Address: The value of the SIP Global Destination Address shall be mapped to the IP address of the destination, if the router has determined that the datagram is traversing its final IPAE hop, that is, if it is being delivered to the recipeint host, or if it is being fully converted to an IP- only datagram. While IP addresses remain globally unique, the value of the IP Destination Address field is the value of the lower 32-bits of the SIP Global Destination Address. If the IP headers is to serve an encapsulation function, with the SIP header being retained, then the Destination Address shall contain the IP address of the next IPAE-knowledgeable hop. 5.3. Receipt of IPAE Datagrams An IPAE datagram contains a SIP header and an IP header. The IP header is for the purpose of permitting transit of the SIP datagram through IP-only networks. Hence, the IP header should not be viewed as containing the end-to- end information. However, the similarity between SIP/IP relationship and IP/Link relationship has one significant difference: The SIP header needs to reflect changes to the IP header that occur during transit. In particular, an IPAE router needs to update the SIP header fields in the following manner: Hop Limit: The value of the IP Time to Live field is copied into the SIP Hop Limit field. Hence, the SIP Hop Limit count must be adequate to count both SIP-knowledgeable and IP-only hops. Other fields: Values in all other IP fields may be ignored. 6. IPAE NETWORK COMPONENTS 6.1. Hosts An IPAE host supports IP, SIP and SIP-over-IP. An originating IPAE host must be able to derive an IP header from the SIP header, in order to create the SIP/IP encapsulation. Internet Draft 20 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 6.2. Interior Routers For IPAE operation, it is presumed that the interior routers of an administrative domain are not IPAE-aware and hence need no modification, since they will transmit the IPAE datagram on the basis of the IP encapsulating datagram. However, administrative domains are expected to convert their routers over to use of IPAE and/or SIP, eventually, in which case their behavior for doing IP/SIP translation, address mapping, and the like will be similar to that of a border router. 6.3. Border Routers An IPAE/SIP border router performs the following basic functions: a) Typical router store-and-forward relaying, for SIP datagrams, b) Participation in local IP infrastuctures, sufficiently to appear to other IP routers as if the border router is also an IP router, c) IP-base encapsulation/decapsulation of SIP datagrams, and d) Translation gateway creation of a SIP header based on the contents of an IP header, and vice-versa. SIP routing functions are discussed in [DEER92b]. Encapsulation/decapsulation functions are to be performed using the derivation rules specified in the previous section. It is expected that conversion of IP datagrams to SIP or IPAE datagrams will permit the converting border router in an AD to maintain smaller routing tables, immediately. For IP, router tables include a source information base with a copy of the information about all Internet nets, for each of the router's neighbors. For SIP, the table still needs to maintain a copy of the information received from each neighbor, but it can be reduced to a portion of the global hierarchy, such as all countries, as well as all "local" networks of interest. Currently for IPv4, the real-time information base used to make direct datagram forwarding decisions needs to have an entry for each network on the Internet. For SIP, it needs to have only the relevant portions of the hierarchy, so that the table information about Internet neighbors can share the same entry. Internet Draft 21 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 7. IPAE ADDRESSING EXAMPLE The relationship between IP and SIP addressing, particularly when both are present in an IPAE datagram, appears to be the greatest source of confusion concerning IPAE dynamics. This section provides an extended example of the end-to-end handling of both types of addresses as a datagram moves through the Internet. Notation: IP addresses are represented in the usual, four decimal fields, separated by periods. SIP addresses also use a decimal dotted notation, showing Country.Metro/Provider.Site/Subscriber, followed by the site's IP address. The SIP portion is separated from the IP portion by a slash. Reference to IP or SIP networks, without referencing specific nodes on those networks, uses only the network portion of the address. For example, a Class C IP network would be shown as the first 3 octets of its address, such as 192.3.4. A SIP network address would show only the first 4 octets of the 64- bit address, indicating only the Region and Metro/Provider. IPAE forms a set of logical networks "above" the set of IP networks, so that one or more IP networks are the equivalent of IPAE subnetworks. Hence, IPAE network boundaries occur only at IPAE routers. In this example, note that the last system of the first line (Router IPAEx) is the same as the first system on the second line. This shows one intermediate IPAE hop, with an intermediate IP hop between the originating host and the IPAE router, and another between the IPAE router and the destination host. The transit sequence for the datagram is: SIP Net <- 1.213.77. -> || IP Net <- 192.3.4. | <- 128.1. -> || | || Node: H(IP-O) R(IPa) R(IPAEx)... |1:213:77:5/ | | 1:213:77:5/| |192.3.4.1 | | 128.1.1.2| | | | | | 192.3.4.2| |128.1.1.1 | | | | | -------->-------- ------>-------- Datagram: SIP SIP SRC:1:213:77:5: SRC:1:213:77:5: 192.3.4.1 192.3.4.1 DST:1:2:2:8: DST:1:2:2:8: 201.5.7.250 201.5.7.250 ----------------- ----------------- IP IP SRC: 192.3.4.1 SRC:192.3.4.1 DST: 128.1.1.2 DST:128.1.1.2 Internet Draft 22 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) SIP Net || <- 1.002.2. -> IP Net || <- 10. | 201.5.7. -> || | Node: ...R(IPAEx) R(IPb) H(IPAE-D) |1.2.2.75: | | 1.2.2.8:| |10.0.0.3 | | 201.5.7.250| | | | | | 10.1.2.3| |201.5.7.9 | | | | | -------->-------- ------->------- Datagram: SIP SIP SRC:1:213:77:5: SRC:1:213:77:5: 192.3.4.1 192.3.4.1 DST:1:2:2:8: DST:1:2:2:8: 201.5.7.250 201.5.7.250 ----------------- ---------------- IP IP SRC:10.0.0.3 SRC:10.0.0.3 DST:201.5.7.250 DST:201.5.7.250 The pattern of manipulation to observe is that the SIP source and destination address fiels are unchanged. The IP source and destination addresses show the addresses of the IPAE nodes for the specific SIP hop and are unchanged when passing through an IP-only router. 8. TRANSITION SEQUENCE 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 S -> 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. Milestone S indicates large scale conversion of administrative domains to pure SIP operations. Each milestone in the transition plan is discussed in the Internet Draft 23 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 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 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 network 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. As an administrative domain comes to use IPAE universally, then it may decide to permit pure SIP exchanges, without IPAE encapsulation. 8.1. Initial Deployment of IPAE (Milestone I) The first step of IPAE deployment is to define the first SIP administrative domains. Initially these should be large areas of the Internet, such as portions of a single continent. The goal is to reduce the amount of routing traffic and the size of routing tables by an order of magnitude or more. The first deployment of IPAE will occur in border routers. The border routers will create the first SIP administrative domains. 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 border routers and to reduce the routing computation load on these routers. The functions performed by the border routers are primarily of inserting/removing SIP 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 kept 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 periodically performa a DNS lookup to obtain recent Internet Draft 24 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) additions to the routing table. (That is, the DNS would provide a means of maintained a distributed copy of the Internet address mappings.) 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 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. 8.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 IPv4 Headers format and IPAE/SIP Header format. They will use IPv4 Headers when communicating within their administrative domain and will use SIP Headers when communicating with hosts in different domains. 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. 8.3. Internet Runs Out of 32-Bit IPv4 Network Numbers (Milestone R) At the third phase of the IPAE deployment, hosts which do not implement IPAE will be able to communicate directly only with hosts in their own administrative domain, via IP. 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. Internet Draft 25 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) Another approach is to perform automatic address mapping. Various schemes are possible to support this and IPAE imposes no special constraints on the choices. 8.4. Administrative Domains Fully Convert to SIP (Milestone S) The final stage of IPAE deployment is the demise of IPAE usage within individual administrative domains. As neighboring domains support pure SIP, then the border routers between them can be configured to omit the IPAE SIP- over-IP encapsulation for inter-domain exchanges. It is important to note, however, that decisions to permit pure SIP operation are entirely at the discretion of the local administrations, rather than requiring larger, Internet coordination. 9. 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. [DEER92a] Deering, S. Simple Internet Protocol (SIP) Specification. 1992 November. [DEER92b] Deering, S. Simple Internet Protocol (SIP) Addressing and Routing. 1992 November. [E.163] CCITT, Numbering Plan for the International Telephone Services. [HIND92a] Hinden, B., "New Scheme for Internet Routing and Addressing (ENCAPS)", Email message to Big-Internet mailing list, March 16, 1992 [HIND92b] A Proposal for IP Address Encapsulation (IPAE): A Compatible Version of IP with Large Addresses; (draft, June 1992) [WOOD92] Woodburn, R & D. Mills, "A Scheme for an Internet Encapsulation Protocol: Version 1", RFC 1241. July 1991. Internet Draft 26 11/11/92 - 2:30 PM (Expires: 5/93) IP Address Encapsulation (IPAE) 10. CONTACTS David H. Crocker The Branch Office 675 Spruce Dr. Sunnyvale, CA 94086 +1 408 246 8253 Robert Hinden Sun Microsystems, Inc. MS MTV-44 2550 Garcia Avenue Mountain View, CA 94043-1100 +1 415 336 2082