Internet Engineering Task Force Robert E. Gilligan INTERNET-DRAFT Erik Nordmark Bob Hinden Sun Microsystems, Inc. November 10, 1993 IPAE: The SIPP Interoperability and Transition Mechanism Abstract The Internet is experiencing growing pains. The phenomenal success of TCP/IP -- the exponential growth in the size of the global IP-connected Internet and the ever increasing number of systems deployed on isolated networks running the Internet protocols -- is likely to bring about two serious problems in the near future. First, since the IP routing system has little hierarchical structure it may not scale much above its current size. Secondly, since the 32-bit IP address space is assigned in an inefficient manner, it may be exhausted within a few years. These problems have given rise to a number of proposals for revising the Internet Protocol. SIPP -- the Simple Internet Protocol Plus -- is one proposal for a next generation Internet Protocol. If SIPP, or any next generation IP, is to be successful, it must provide an easy mechanism by which hosts and routers implementing the new protocol can continue to interoperate with systems using the existing IP version. Also, there must be mechanism to transition the Internet to the new protocol without disrupting operation of the Internet. This specification details both with the mechanisms by which SIPP systems interoperate with those using the current version of IP, and the plan for transitioning the IP-connected Internet to SIPP. While specifically cast in terms of SIPP, the IPAE techniques could be applied to the other network layer protocol transitions as well. Status of this Memo 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. This Internet Draft expires on May 10, 1994. 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." draft-ietf-sipp-ipae-transition-00.txt [Page 1] INTERNET-DRAFT IPAE Specification November 1993 Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. Acknowledgements This document is the result of the efforts of three IETF working groups -- the IPAE working group, the SIP working group, and the SIPP working group -- over a period of more than a year. The groups met a number of times over this period and exchanged a great amount of electronic mail. A number of individuals made significant contributions. Bob Hinden devised the original IPAE encapsulation scheme. Dave Crocker brought the idea of global addresses to IPAE. Steve Deering brought the idea of a simple new version IP. And Paul Francis contributed the advanced routing ideas of PIP. The working groups have included contributions from: Craig Partridge of BBN, Tom Kessler, Geoff Mulligan, Erik Nordmark, and Bob Gilligan of Sun Microsystems, Greg Chesson, Ronald Jacoby, and and Rob Warnock of Silicon Graphics, Hon Wah Chin and Dave Newman of Protocol Engines, Ross Callon of Wellfleet, Mike Reilly of TGV, Virgil Champlin of Digital Equipment, Michael Conn of MCI, John Moy of Proteon, John Veizades of FTP software, Jeffrey Burgan of NASA, R. Govindan of Bellcore, and Vince Fuller of BARRNET. Thanks to all who provided feedback to the first revision of this document, including Jim Bound, Jon Crowcroft, and (your name goes here, after you send in your insightful comments and suggestions). draft-ietf-sipp-ipae-transition-00.txt [Page 2] INTERNET-DRAFT IPAE Specification November 1993 Status of this Memo Acknowledgements 1. Introduction 1.1. Organization 2. Problem Statement 3. The IPAE Solution 3.1. IPAE Addressing 3.2. IPAE Tunneling: SIPP within IPv4 3.3. IPAE Host Operation 3.4. IPAE Header Translation 4. IPAE Routers 4.1. Multiple Routing Domains 4.2. Tunneling SIPP in IPv4 4.3. Encapsulating SIPP in IPv4 4.4. Decapsulating IPAE Packets 4.5. Tracking the Tunnel State 4.6. Generating ICMP Error Packets 5. IPAE Translators 5.1. Translating IPv4 to SIPP 5.2. Mapping Table 5.3. Translating SIPP to IPv4 5.4. SIPP and IPv4 Routing Configuration 5.5. Translation of Fragments 5.6. Knowing when to Translate 6. IPAE Hosts 6.1. What Packet Format to Send 6.2. Transport Pseudo-header Checksum 6.3. TCP and UDP Connection Identification 6.4. ICMP Error Messages 6.4.1. Sending ICMP Error Messages 6.4.2. Receiving ICMP Error Messages 6.5. Transport API changes 6.6. IP Addresses Embedded In Application Protocols 6.6.1. FTP 6.6.2. Mail (RFC 822) 6.6.3. Domain Name System (DNS) 6.6.4. SMI, MIB-II, Forwarding Table MIB 6.6.5. RARP, BOOTP, DHCP, Bootparams 6.6.6. BSD Talk Protocol Appendix 1. Definitions Appendix 2. The IPv4 to SIP Transition Appendix 3. Examples A3.1. IPAE Encapsulation Appendix 4. Design Decisions A4.1. The C-bit A4.2. Global vs. Local Scope for C-bit Appendix 5. Open Issues A5.1. How is the DF Bit Handled? draft-ietf-sipp-ipae-transition-00.txt [Page 3] INTERNET-DRAFT IPAE Specification November 1993 A5.2. Should we Map IPv4 TOS bits into a Flow ID? A5.3. How Should we Set the ID field? A5.4. ICMP Error Message Handling? A5.5 IPv4 Path MTU Discovery when Encapsulating Security Considerations References Author's Address draft-ietf-sipp-ipae-transition-00.txt [Page 4] INTERNET-DRAFT IPAE Specification November 1993 1. Introduction IPAE is designed to serve two purposes. First, it is the set of mechanisms by which SIPP systems interoperate with systems that only understand the current (version 4) version of IP. Secondly, it is the means by which the operational Internet can transition to SIPP. The transition mechanisms build on the interoperability features. All SIPP hosts that support IPAE are able to interoperate with IPv4 hosts anywhere in the Internet. This feature minimizes the impact of transition to SIPP on the users, since they may upgrade their hosts SIPP at their own pace. IPAE provides a similar "incremental upgrade" feature for routers. SIPP traffic can be encapsulated within IPv4 packets and then routed by IPv4 routers. This leverages the existing IPv4 routing infrastructure. It allows sites and the Internet backbone service providers to upgrade their routers to SIPP in an incremental fashion. The IPv4 routers do not need to be converted to SIPP at the same time. The Internet can gain some of the benefits of SIPP after only a small number of the IPv4 routers are converted to SIPP. IPAE also defines a mechanism by which IPv4 traffic may be carried by the SIPP routing infrastructure, once it is constructed. This provides complete global connectivity for IPv4 hosts up to the time when IPv4 addresses are no longer unique (i.e. when all of the IPv4 addresses are assigned. After the time when IPv4 addresses run out, there is no practical way to provide global IPv4 connectivity, although it may be possible to continue selective connectivity for some IPv4 destinations.) With this feature, IPAE provides service for those IPv4 hosts that can not be upgraded to SIPP, or whose users' simply choose not to upgrade. What's more, the IPv4 traffic being carried by the SIPP routing infrastructure receives the same benefits of route scaling as the SIPP traffic. IPAE is a collection of protocols, mechanisms, and operational procedures that are built upon SIPP. IPAE can be viewed as an add-on to SIPP. It is being cast as a mechanism separate from SIPP with an eye toward the time -- probably in the far distant future -- when the Internet may no longer require interoperability between SIPP and IPv4 hosts and routers. At that time, the IPAE mechanisms can be retired, and the IPAE software can be de-commissioned. Another reason for separating the "IPv4 compatibility" features from the core SIPP is that SIPP may be used in in environments in which there are no IPv4 systems. There may be a desire in the short term for "SIPP-only" hosts or routers in isolated settings. In order to differentiate those SIPP-speaking systems that interoperate with IPv4 draft-ietf-sipp-ipae-transition-00.txt [Page 5] INTERNET-DRAFT IPAE Specification November 1993 systems from those that do not, we offer the following definitions: A "SIPP-only" host or router conforms to the SIPP specifications, but not the IPAE specification. An IPAE host or router conforms to both the SIPP specifications and the IPAE specification. Both IPAE and SIPP-only systems can be referred to as "SIPP systems" since they both support SIPP. It is expected that for the foreseeable future, all of the SIPP systems deployed on the Internet will need to interoperate with IPv4 systems. Thus it is likely that most or all of the SIPP hosts or routers will also be IPAE systems. This paper assumes familiarity with SIPP. We recommend that readers read the SIPP specification before reading this paper. Finally, a word on the term "IPAE." IPAE was originally used as the acronym for one of the IP next generation proposals. The IPAE working group merged with the SIP working group, but the new group maintained the IPv4 interoperability techniques developed in the former group. After that, the SIP working group merged with the PIP working group to form the SIPP group, again keeping the IPAE techniques. Today, IPAE is no longer an acronym; it is simply a convenient term for the interoperability and transition mechanisms originally developed in the IPAE working group. 1.1. Organization The remainder of this paper is organized as follows: - Chapter 2 details the scaling problems that SIPP and IPAE were designed to overcome. - Chapter 3 gives an overview of IPAE. - Chapters 4, 5, and 6 give detailed specifications and requirements for the components of the IPAE network. - The five appendices, A1 through A5, provide additional details and background information. The reader can gain an understanding of IPAE by reading chapters 2 and 3. Implementors should read chapters 4, 5, and 6 as well as the appendices. draft-ietf-sipp-ipae-transition-00.txt [Page 6] INTERNET-DRAFT IPAE Specification November 1993 2. Problem Statement Due to the widespread adoption the TCP/IP technology 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 will 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. 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, so as to allow route-aggregation in table entries to neighboring networks. Even Classless Inter-Domain Routing [CIDR], which is reducing the size of the routing tables in the short term, can not be guaranteed to solve this problem for an extended period of time due to sites changing providers and policy constraints in the backbone networks. While the 32-bits of the IP address space theoretically can reference about 4 billion nodes, the bits have been partitioned to facilitate assignment and aggregation into networks. This reduces the realistic maximum number of networks and hosts. 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 networks. SIPP and IPAE provide a solution to these problems. IPAE as the transition mechanism for SIPP was designed around a number of objectives to make the transition from IPv4 to SIPP as smooth as possible. These objectives are: - The transition to SIPP should cause as little impact as possible on the end users of hosts. - The transition to SIPP should leverage as much of the users' and administrators' intangible investment in IPv4 operations, training, terminology as possible. We should recognize that users, administrators, and network operators have extensively invested in "understanding" IPv4. That investment should not be lost. - The transition should be "asynchronous". Users and network operators should be able to transition at their own pace. Users draft-ietf-sipp-ipae-transition-00.txt [Page 7] INTERNET-DRAFT IPAE Specification November 1993 should be able to upgrade hosts and routers incrementally. - Sites which deploy IPAE should accumulate the benefits and features of SIPP and IPAE as they deploy. For example a new IPAE host should be able to use the SIPP auto-configuration mechanisms immediately. The benefits should not be accrued only after everyone else has deployed IPAE. - The larger addresses of SIPP should be used to solve the IPv4 route scaling problem early on in the transition. - It must provide complete, global interoperability between SIPP and IPv4 hosts for as long as IPv4 can provide global interconnectivity. - It should provide global connectivity for IPv4 traffic for as long as possible. (Note that is only possible to maintain global IPv4 connectivity only so long as IPv4 addresses are unique. After "the day IPv4 address run out", it will no longer be possible to have direct global IPv4 connectivity.) - It should leverage the existing IPv4 routing infrastructure wherever possible. draft-ietf-sipp-ipae-transition-00.txt [Page 8] INTERNET-DRAFT IPAE Specification November 1993 3. The IPAE Solution The design of IPAE centers on four core elements: - A 64-bit SIPP addressing plan that is compatible with the current 32-bit IPv4 addressing plan. - A mechanism for encapsulating SIPP traffic within IPv4 packets for routing over parts of the Internet that have only IPv4 routers. - Algorithms in IPAE hosts to know when they are communicating with IPv4 hosts and format packets that are compatible. - Use of "translation agents" to maintain global IPv4 connectivity. Each of these elements is described in more detail below. 3.1. IPAE Addressing We have defined a 64-bit SIPP addressing structure that is compatible with the existing 32-bit IPv4 addressing structure. IPv4 compatible SIPP addresses -- which we call "IPAE Addresses" -- have the following features: 1) They have an IPv4 address embedded within them as the low-order 32 bits. 2) The state of the high-order bit -- which is termed the "C-bit" -- encodes whether the entity the address identifies is capable of processing the SIPP packet format. If the high-order bit of an IPAE address is 0, the system that it represents is SIPP capable. If the high-order bit is 1, the system may not be SIPP capable. 3) The remaining 31 bits are used to uniquely identify and address a new element of the Internet topology called an ``IPAE site.'' As part of the introduction of IPAE, the Internet will be sub-divided into a number of logical regions called ``IPAE sites.'' This is done without changing any physical elements of the Internet; it is only a logical organization of the existing topology. The only requirement for an IPAE site is that IPv4 traffic must be routed completely within the boundaries of each site. That is, all of the routers within a site must continue to support IPv4 and must be draft-ietf-sipp-ipae-transition-00.txt [Page 9] INTERNET-DRAFT IPAE Specification November 1993 capable of routing to all IPv4 destinations within the site. (Routers within a site MAY also support SIPP, in which case they are IPAE routers; but they MUST support IPv4. Also, the routers may be able to route IPv4 traffic directly to destinations outside of the site, but this is not required in order to qualify as an IPAE site.) Each IPAE site is assigned a unique 31-bit ``site prefix,'' which is used in the high-order bits of the IPAE addresses of all hosts and routers within that site. A hierarchal structure may be defined for site prefixes, but details of their structure is outside the scope of this paper. Thus 64-bit IPAE addresses have the following structure: 6 3 3 0 3 2 1 0 +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ |C| Site Prefix | IPv4 Address | +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ An IPAE address has three components: C-bit Encodes whether the entity addressed supports SIPP or not. Site Prefix Uniquely identifies the site that the addressed entity is located in. IPv4 Address Uniquely identifies the addressed entity. 64-bit IPAE addresses can be assigned to both IPAE and IPv4 hosts and routers. While an IPv4 host or router only ``knows'' its IPv4 address (the low-order 32-bits of its IPAE address), it may have an IPAE address assignment, which may be listed in the DNS. Once an IPAE site has been defined and assigned a site prefix, all existing IPv4 hosts and routers located within that site can be given IPAE address assignments. This assignment is straightforward, since the IPv4 hosts' and routers' addresses are derived from their previously assigned IPv4 addresses. Specifically, IPAE addresses for IPv4 hosts and routers can be assigned as follows: C-bit = 1. Site Prefix = prefix assigned to this site. IPv4 Address = IPv4 address assigned to this host or router. draft-ietf-sipp-ipae-transition-00.txt [Page 10] INTERNET-DRAFT IPAE Specification November 1993 When a new IPv4 host or router is introduced into a site, it is first assigned an IPv4 address that is consistent with the IPv4 addressing plan employed within the site. Then, an IPAE address is assigned to the host in the same manner as pre-existing IPv4 hosts. When an IPAE host is introduced into a site, it is also first assigned an IPv4 address that is consistent with the IPv4 addressing plan employed within the site. It is then assigned an IPAE address as follows: C-bit = 0. Site Prefix = prefix assigned to this site. IPv4 Address = IPv4 address assigned to this host. When an IPv4 host within a site is upgraded to support SIPP (i.e. it becomes an IPAE host), the C-bit in the host's IPAE address is changed from 1 to 0. As long as IPv4 addresses remain unique in the Internet (that is, until the time when IPv4 addresses "run out"), the IPv4 address portion of IPAE addresses will be sufficient to uniquely identify a host or router. 3.2. IPAE Tunneling: SIPP within IPv4 IPAE hosts and routers use the IPAE tunneling technique to carry SIPP packets over regions of the Internet that route only IPv4 packets. In IPAE tunneling, the end-to-end SIPP datagram is encapsulated within an IPv4 datagram. An IPAE tunnel may extend through only part of the end-to-end path (e.g. between two IPAE routers), or may be used for the entire path between two IPAE hosts (e.g. when the only routers along the path are IPv4). On its journey from source host to destination host, a SIPP datagram may be routed through one IPAE tunnel, many IPAE tunnels, or none at all. We use the term "IPAE packet format" to describe a SIPP datagram encapsulated within an IPv4 header. The IPAE packet format is shown below, along with the IPv4 and SIPP packet formats for comparison: draft-ietf-sipp-ipae-transition-00.txt [Page 11] INTERNET-DRAFT IPAE Specification November 1993 +------------+ +------------+ +------------+ | IPv4 | | IPv4 | | SIPP | | Header | | Header | | Header | +------------+ +------------+ +------------+ | Transport | | SIPP | | Transport | | Layer | | Header | | Layer | | Header | +------------+ | Header | +------------+ | Transport | +------------+ | | | Layer | | | ~ Data ~ | Header | ~ Data ~ | | +------------+ | | +------------+ | | +------------+ ~ Data ~ | | +------------+ IPv4 Packet IPAE Packet SIPP Packet Format Format Format In the IPAE packet format, the IPv4 source and destination addresses identify the "endpoints of the tunnel." The SIPP source and destination addresses identify the end hosts -- the sender and recipient of the datagram. The IPv4 routers on the "interior" of a tunnel route the packet based on its IPv4 header. The IPAE router at the end of a tunnel decapsulates the packet and routes it based on the SIPP header. When an IPAE host or router composes a packet in the IPAE format, it sets the IPv4 Time To Live (TTL) field to be the same as the SIPP Hop Limit. When an IPAE router receives a packet in the IPAE format, it copies the IPv4 TTL into the SIPP hop limit field and subtracts one. Thus IPv4 "hops" are counted in the SIPP hop limit. It is possible that one of the IPv4 routers along the tunnel interior might encounter an error while processing an IPAE packet, causing it to return an IPv4 ICMP error message to the source endpoint of the tunnel. The three types of ICMP errors that can occur in this circumstance are: - Packet too big. - Time Exceeded. - Destination Unreachable. Unfortunately, the ICMP spec only requires IPv4 routers to return 8 bytes (64 bits) of the packet beyond the IPv4 header. This is not enough to include the SIPP source address, so it is not generally possible for an IPAE router to immediately reflect a SIPP ICMP message back to the source host when it receives an IPv4 ICMP message from the interior of a draft-ietf-sipp-ipae-transition-00.txt [Page 12] INTERNET-DRAFT IPAE Specification November 1993 tunnel. However, by carefully maintaining "soft state" about its tunnels, an IPAE router can return accurate SIPP ICMP messages in most cases. An IPAE router should maintain at least the following soft state information about each tunnel: - MTU of the tunnel. - TTL (path length) of the tunnel - Reachability of the end of the tunnel. An IPAE router uses the IPv4 ICMP messages it receives from the interior of a tunnel to update the soft state information for that tunnel. When subsequent SIPP packets that would transit the tunnel arrive, the router checks the soft state for the tunnel. If the packet would violate the state of the tunnel (e.g. packet would be larger than the tunnel MTU; the SIPP hop limit is less than the tunnel TTL) the router sends a SIPP ICMP error message back to the source, but also forwards the packet into the tunnel. Using this technique, the SIPP ICMP error messages sent by IPAE routers may not alway match up one-to-one with errors encountered by IPv4 routers, but they will accurately reflect the state of the network. 3.3. IPAE host operation. The requirements on IPAE hosts can be expressed as three simple rules: 1) IPAE hosts accept packets in the IPv4 format. 2) IPAE hosts transmit packets in the IPv4 format when sending to IPv4 hosts within the same site. 3) IPAE hosts use the IPv4 transport connection-identification and pseudo-header checksum algorithms when communicating with IPv4 hosts. IPAE hosts need to be able to communicate with IPv4 hosts within their "site" without the help of any other agents. This is important so that the first IPAE systems deployed at a site will immediately interoperate with the deployed IPv4 hosts and routers without the need to first deploy IPAE routers or translation agents. The three rules above will guarantee that IPAE hosts always send IPv4 format packets to IPv4 hosts within their sites and that the IPv4 packets that the IPv4 hosts send back will be handled properly. IPAE hosts can use the C-bit of the destination address, along with knowledge draft-ietf-sipp-ipae-transition-00.txt [Page 13] INTERNET-DRAFT IPAE Specification November 1993 of the site prefix of the outgoing interface, to determine whether a destination address is located within the same site, and whether it is an IPv4 host or not. IPAE hosts can use the IPv4 packet format when sending to IPv4 hosts in the local site because IPv4 is always routed within a site. But since IPv4 traffic may not be routed globally, IPAE hosts must use the SIPP packet format when sending to IPv4 hosts in remote sites. The IPAE translator (described in the next section) in the remote site will take care of translating the packet into IPv4 format before it is delivered to the destination IPv4 host. Thus packets for all hosts in remote sites can be sent in the SIPP format. When sending to IPv4 hosts, IPAE hosts must calculate the transport-layer pseudo-header checksum in such a way that it will be accepted by the IPv4 host. Similarly, when receiving packets from IPv4 hosts, the IPAE host must calculate the checksum in a way that a correctly generated packet will be accepted. This means that only the low-order 32 bits of the SIPP address are used in the pseudo-header calculation when communicating with IPv4 hosts. Also, the connection identification logic in the transport layer of the IPAE host must associate packets received from IPv4 hosts with the correct connection state. This means that IPAE hosts only use the low-order 32 bits of the SIPP addresses in the connection identification algorithm when communicating with IPv4 hosts. 3.4. IPAE Header Translation IPAE translation agents, also called "IPAE translators", provide global IPv4 connectivity once IPv4 is no longer routed globally. They do this by translating the Internet headers of all intra-site IPv4 traffic. Each site is equipped with at least one IPAE translator whose job it is to: 1) Translate the IPv4 headers of all IPv4 traffic that is generated within the site, and is addressed to destinations in remote sites, into SIPP headers. The resulting SIPP packets are then forwarded into the SIPP routing system, where they are routed based on their full 64-bit SIPP destination addresses. 2) Translate the SIPP headers of all SIPP traffic that is sent from remote sites, and is addressed to IPv4 destinations in the local site, into IPv4 headers. The resulting IPv4 packets are then forwarded into the IPv4 routing system within the site for delivery to the destination IPv4 host. draft-ietf-sipp-ipae-transition-00.txt [Page 14] INTERNET-DRAFT IPAE Specification November 1993 The IPAE translators operate only on the Internet headers of packets. They never look beyond the SIPP or IPv4 headers into the transport layer headers or application data. The interoperation of IPAE and IPv4 systems using application layer protocols that carry IPv4 addresses is addressed in section 6.6. In order to perform task (1) above, the IPAE translator must map the destination IPv4 address of the packet into a 64-bit SIPP address. This is done with the help of a mapping table. The mapping table maps IPv4 destination addresses into 32-bit prefixes. The prefix is prepended to the 32-bit IPv4 destination address to compose a complete 64-bit SIPP which is stored in the SIPP header. In order to efficiently encode mapping information, the entries in the table are keyed by a 32-bit mask and 32-bit IP address. The mask + address are associated with a 32-bit SIPP address prefix. For example, this entry: mask address SIPP address prefix ---- ------- -------------------- 255.255.0.0 129.144.0.0 1404:1:0.0.0.0 states that all destination addresses with the high order 16 bits equal to "129.144" should be given the prefix 1404:1. draft-ietf-sipp-ipae-transition-00.txt [Page 15] INTERNET-DRAFT IPAE Specification November 1993 4. IPAE routers We call a router that understands both the IPv4 and SIPP packet formats, and participates in both the IPv4 and SIPP routing protocols an IPAE router. Each site must have at least one IPAE router that participates in both the IPv4 routing system within the site, and the global SIPP routing system. In addition to participating in multiple routing domains the IPAE router has to be able to tunnel SIPP datagrams by encapsulating them in Ipv4 packets. Finally, IPAE routers have to generate ICMP errors containing an "offending packet" that the recipient of the ICMP error can understand. 4.1 Multiple routing domains In addition to participating the SIPP routing system, an IPAE router has to be capable of participating in multiple IPv4 routing domains. This is required since each interface potentially belongs in a separate routing domain, and after IPv4 addresses "run out" the IPv4 addresses will only be unique within each routing domain/site. This implies that the router has to maintain logically separate IPv4 routing tables for each domain/site and be able to send return packets back to the correct site. This can be implemented by tagging each incoming IPv4 packet with the address prefix (with the C-bit set) of the interface in arrived on. 4.2 Tunneling SIPP in IPv4 IPAE routers, as well as IPAE hosts, tunnel SIPP datagrams by encapsulating the in IPv4 packets. The tunneling mechanism consists of: - The entry router of the tunnel (the encapsulating router) creating an encapsulating IPv4 header. - The exit router of the tunnel (the decapsulating router) removing the IPv4 header and updating the SIPP header. - The encapsulating router maintaining soft state for each tunnel in order to generate SIPP ICMP errors. There are two sets of tunnels used in IPAE: - configured tunnels between IPAE routers. draft-ietf-sipp-ipae-transition-00.txt [Page 16] INTERNET-DRAFT IPAE Specification November 1993 - implicit tunnels i.e. where the IPv4 addresses of the tunnel endpoint is the 32 low-order bits of the SIPP destination address. The configured tunnels could be set up either manually or by a routing protocol. The implicit tunnels are always present. A host with an address prefix of A has implicit tunnels to all SIPP addresses that share the A prefix. An IPAE router with an interface to a site with address prefix A also has implicit tunnels to all SIPP address with the A prefix. Thus there will potentially exist a very large number of implicit tunnels in IPAE hosts and IPAE routers. Therefore the state associated with the tunnels should be kept cache so that it can be discarded when no longer used and later recreated. 4.3 Encapsulating SIPP in IPv4 The encapsulating header should have the Don't Fragment bit set in order for the tunnel entry point to discover the tunnel mtu. The SIPP hop limit field is copied into the IPv4 TTL field. Either the SIPP hop limit must be decremented by one before the packet is encapsulated, or the IPv4 TTL must be decremented by one after the encapsulation (as part of the normal forwarding mechanism). SIPP routers, in general, do not fragment SIPP datagrams that exceed the MTU even if the datagram contains a fragmentation header. Thus, in particular, there is no need for an encapsulating router to perform any fragmentation. +-------------+ | IPv4 | | Header | +-------------+ +-------------+ | SIPP | | SIPP | | Header | | Header | +-------------+ +-------------+ | Transport | | Transport | | Layer | ===> | Layer | | Header | | Header | +-------------+ +-------------+ | | | | ~ Data ~ ~ Data ~ | | | | +-------------+ +-------------+ SIPP Encapsulation in IPv4 draft-ietf-sipp-ipae-transition-00.txt [Page 17] INTERNET-DRAFT IPAE Specification November 1993 When encapsulating a SIPP datagram in an IPv4 datagram, the IPv4 header fields are set as follows: Version: 4 IP Header Length in 32-bit words: 5 (There are no IPv4 options in the encapsulating header.) Type of Service: 0 Total Length: Payload length from SIPP header plus length of SIPP and IPv4 headers (i.e. a constant 44 bytes) Identification: Generated uniquely as for any IPv4 packet transmitted by the host function in the system. Flags: Set the Don't fragment flag. Fragment offset: 0. Time to Live: Copied from the SIPP hop limit field. Protocol: 41 (Assigned payload type number for SIPP) Header Checksum: Calculate the header checksum. Source Address: draft-ietf-sipp-ipae-transition-00.txt [Page 18] INTERNET-DRAFT IPAE Specification November 1993 IPv4 address of outgoing interface. Destination Address: IPv4 address of remote end of tunnel. Any SIPP options are preserved in the packet (after the SIPP header). 4.4 Decapsulating IPAE packets When a host or a router receives an IPv4 datagram destined to one of its IPv4 address with the protocol field set to 41 it must decapsulate the packet. When decapsulating such IPAE packets the SIPP hop limit is set to the IPv4 TTL. The SIPP hop limit must be decremented by one after the packet has been decapsulated (as part of the normal SIPP forwarding mechanism.) +-------------+ | IPv4 | | Header | +-------------+ +-------------+ | SIPP | | SIPP | | Header | | Header | +-------------+ +-------------+ | Transport | | Transport | | Layer | ===> | Layer | | Header | | Header | +-------------+ +-------------+ | | | | ~ Data ~ ~ Data ~ | | | | +-------------+ +-------------+ Decapsulating SIPP from IPv4 When decapsulating the IPAE packet only one field in the SIPP header is modified: Hop Limit: TTL value copied from the encapsulating IPv4 header. Then the encapsulating IPv4 header is dropped. draft-ietf-sipp-ipae-transition-00.txt [Page 19] INTERNET-DRAFT IPAE Specification November 1993 4.5 Tracking the tunnel state Tunnels are "traceroute visible" i.e. a traceroute program running on a SIPP or IPv4 host will report all the routers internal to the tunnel. This is accomplished by copying the TTL from the SIPP header into the encapsulating IPv4 header plus maintaining soft state about the tunnel in the encapsulating router. The soft state for the tunnel is based the ICMP errors that are received from IPv4 routers interior to the tunnel. This tunnel state is associated with the IPv4 address of the endpoint of the tunnel and consists of: - Tunnel MTU. - Path length of the tunnel (number of hops). - For each TTL 't' between 1 and the path length of the tunnel, the IPv4 address of the router that was last known to be 't' hops into the tunnel. - Reachability of the end of the tunnel. - The IPv4 address of the router reporting unreachability. The tunnel state does not have to be allocated until an ICMP error is received; in the absence of tunnel state the tunnel MTU is assumed to be the MTU of the outgoing interface, the path length one hop and the endpoint being reachable. When a datagram is encapsulated the router consults the tunnel state to check if the packet is likely to generate an ICMP error from a router interior to the tunnel. In such a case (e.g. packet size greater than the tunnel MTU) the router generates the appropriate ICMP error and also forwards the packet into the tunnel. Any ICMP error caused by the forwarded packet will refresh the tunnel state. When the encapsulator receives an ICMP errors destined to one of its IPv4 addresses where the "offending packet" is IPv4 with the IP protocol field being 41, it updates the tunnel state associated with the IPv4 destination in the "offending packet". The update depends on the type of ICMP error: - Host or network unreachable: Mark the tunnel endpoint as unreachable and record the source of the ICMP error as the source of unreachability. - Time exceeded in transit: The TTL "consumed" before reaching the router that send the time exceeded message is extracted from the draft-ietf-sipp-ipae-transition-00.txt [Page 20] INTERNET-DRAFT IPAE Specification November 1993 SIPP hop limit field in the "offending packet" (the SIPP hop limit field is in the first 8 bytes of the SIPP header thus it will be returned in the ICMP packet). Compute the updated tunnel path length as the maximum of the currently recorded path length and the extracted SIPP hop limit. Record the source of the ICMP error as the router at 'SIPP hop limit' hops into the tunnel. - "Packet too big": If the ICMP packet contains the MTU (see RFC 1191) update the tunnel MTU to be that value. If the ICMP packet does not contain the MTU use the IPv4 Total length field in the "offending packet" and the recommended plateaus in RFC 1191 to compute the new MTU for the tunnel. Note that this can either increment or decrement the recorded tunnel mtu. - For all other ICMP errors log a network management event. When the encapsulator forwards a packet into the tunnel it performs the following checks against the tunnel state: - If the tunnel endpoint is unreachable it generates a SIPP ICMP network unreachable with the source address being the recorded router that reported the unreachability. The address is extended to 64 bits by using the 32 bit prefix of the tunnel's outgoing interface with the C-bit set. - If the hop limit is less than the recorded tunnel ttl it generates a SIPP ICMP time exceeded in transit with the source address being the recorded router address that is 'hop limit' hops into the tunnel. If there is no router address recorded for the specified hop limit, the router generates an ICMP time exceeded with a source address of 127.0.0.1. The recorded addresses are expanded to 64 bits just like for network unreachables. - If the MTU exceeds the recorded tunnel mtu it generates a SIPP ICMP "packet too big" with itself as the source and setting the returned MTU to the recorded tunnel mtu minus the size of the IPv4 header (20 bytes). (The 20 byte adjustment is needed since the packets will "expand" by 20 bytes when being encapsulated.) In all of the above cases the datagram is also forwarded into the tunnel. The mechanism described so far does not detect when an error condition in the tunnel is lifted (e.g. the tunnel endpoint becomes reachable or when the tunnel path length decreases). The simple solution to detecting such "improvements" is to periodically draft-ietf-sipp-ipae-transition-00.txt [Page 21] INTERNET-DRAFT IPAE Specification November 1993 discard the recorded tunnel state. More elaborate schemes can be envisioned, such as counting the number of 1) datagrams that should have generated a certain ICMP error and 2) the actual number of such ICMP errors received, and discarding the state when the ratio between them exceeds some value. 4.6 Generating ICMP error packets IPAE routers, as well as IPAE hosts, have to generate ICMP error packets that the receiving host or router can decode. The possible formats for the "offending packet" in the ICMP errors are: - A SIPP header followed by the transport header (with possibly SIPP option headers between the SIPP header and the transport header) - An IPv4 header followed by the transport header. The first format is used when the C-bit is not set in the source address in the offending packet. The second format is used when the C-bit is set in the source address. When the IPAE router or host receives a SIPP datagram and it has to generate an ICMP error in the second format it creates, for the sole purpose of the ICMP error, an IPv4 header derived from the SIPP header including any SIPP option headers. +-------------+ +-------------+ | SIPP | | IPv4 | | Header | | Header | +-------------+ +-------------+ | Transport | | Transport | | Layer | ===> | Layer | | Header | | Header | +-------------+ +-------------+ | | | | ~ Data ~ ~ Data ~ | | | | +-------------+ +-------------+ ICMP "offending packet" conversion When generating the IPv4 header from the SIPP header, the IPv4 header fields are set as follows: Version: draft-ietf-sipp-ipae-transition-00.txt [Page 22] INTERNET-DRAFT IPAE Specification November 1993 4 IP Header Length in 32-bit words: 5 Type of Service: 0 Total Length: Payload length from SIPP header minus length of any SIPP optional headers plus length of the IPv4 header. Identification: If SIPP fragmentation option is present, copy low-order 16 bits from ID field. Otherwise set to zero. Flags: If SIPP fragmentation option is not present, set the Don't fragment flag. Fragment offset: 0. (Only the first fragment will generate ICMP errors.) Time to Live: Copy from the SIPP hop limit field. Protocol: Payload type value copied from SIPP header or, if known SIPP options are present, from last SIPP option header. Header Checksum: Calculate the header checksum. Source Address: Copy the low-order 32-bits of the SIPP source address. Destination Address: draft-ietf-sipp-ipae-transition-00.txt [Page 23] INTERNET-DRAFT IPAE Specification November 1993 Copy the low-order 32 bits of the SIPP destination address. The IPv4 header is immediately followed by the transport header i.e. any SIPP option headers are ignored. draft-ietf-sipp-ipae-transition-00.txt [Page 24] INTERNET-DRAFT IPAE Specification November 1993 5. IPAE Translators. IPAE translators perform the task of translating intra-site IPv4 traffic between the IPv4 and SIPP packet formats so that it can be carried over the SIPP backbone. IPv4 traffic originating within the site is translated into the SIPP format and then forwarded into the SIPP backbone. SIPP traffic to IPv4 destinations within the site is translated into the IPv4 format, and then forwarded into the IPv4 routing system within the site. Each site must have at least one IPAE translator. Additional IPAE translators can be deployed within a site to provide fault tolerance and robustness. IPAE translators only operate on the SIPP and IPv4 headers of packets. They never look beyond the Internet headers into the transport layer headers or application data. The function of the IPAE translator does not have to reside in a dedicated machine. It may be co-resident in a machine that also has another function, such as the IPAE border router. This work of the IPAE translator consists of five separate tasks: - Translating IPv4 packets into SIPP format. - Maintaining a table to map IPv4 addresses into SIPP address prefixes. - Translating SIPP packets into IPv4 format. - Participating in IPv4 routing within the site, and global SIPP routing. - Knowing when to translate IPv4 into SIPP and SIPP into IPv4. The rest of this section details each of these tasks. 5.1 Translating IPv4 to SIPP When an IPAE translator receives an IPv4 datagram addressed to a destination in a remote site, it translates the IPv4 header of that packet into a SIPP header, and then forwards the packet based on the SIPP destination address. The original IPv4 header on the packet is removed and replaced by a SIPP header; The transport layer header and data portion of the packet are left unchanged. draft-ietf-sipp-ipae-transition-00.txt [Page 25] INTERNET-DRAFT IPAE Specification November 1993 +-------------+ +-------------+ | IPv4 | | SIPP | | Header | | Header | +-------------+ +-------------+ | Transport | | Transport | | Layer | ===> | Layer | | Header | | Header | +-------------+ +-------------+ | | | | ~ Data ~ ~ Data ~ | | | | +-------------+ +-------------+ IPv4 to SIPP Header Translation After the IPv4 header has been translated into a SIPP header, the packet may be further encapsulated within an IPv4 header if the next hop is via an IPv4 router. When translating from the IPv4 format into SIPP, the SIPP header fields are set as follows: Version: 6 Flow ID: 0 (all zero bits) Payload Length: Total length value from IPv4 header, minus the size of the IPv4 header and IPv4 options, if present. Payload Type: Protocol field copied from IPv4 header Hop Limit: TTL value copied from IPv4 header, decremented by one. High-order 32 bits of Source Address: C-bit: 1 Site Prefix: Prefix of the local site. Low-order 32 bits of Source Address: Source address copied from IPv4 header. High-order 32 bits of Destination SIPP address: Mapping table entry for IPv4 destination address. draft-ietf-sipp-ipae-transition-00.txt [Page 26] INTERNET-DRAFT IPAE Specification November 1993 Low-order 32 bits of Destination SIPP address: Destination address copied from IPv4 header. If IPv4 options are present in the IPv4 packet, they are dealt with as follows: No Operation (Type = 1) This option is used only for padding. It is ignored. Security (Type = 130) The RFC 791 security option is obsolete. It is ignored. Strict Source and Record Route (Type = 137) Since SIPP does not support the Strict Source route model, this option can not be translated into SIPP. If this option is present, the packet must be dropped, and an IPv4 ICMP destination unreachable message back to the source. Loose Source and Record Route (Type = 131) The IPv4 LSRR option can be translated into the SIPP Route option. The payload type in the SIPP header is set to the number assigned to the SIPP route option. The fields of the SIPP route option are set as follows: Payload Type: Protocol field copied from IPv4 header. Number of addresses, n: Number of IPv4 addresses in the IPv4 LSRR option. Next Address, i: The number of the IPv4 address pointed to by the pointer field LSRR option. For example, if the pointer field points to the first IPv4 address in the LSRR option, then the Next Address field is set to 1. If the pointer field points past the end of the route data, then the Next Address field is set to the same value as the Number of Addresses field. For each of address 1 through j in the LSRR route data, set the value of the corresponding SIPP address in the draft-ietf-sipp-ipae-transition-00.txt [Page 27] INTERNET-DRAFT IPAE Specification November 1993 SIPP Route Options as follows: High-order 32 bits of SIPP address [j]: Mapping table entry for LSRR option address [j] Low-order 32 bits of SIPP address [j]: LSRR option address [j] Record Route (Type = 7) Since SIPP does not provide a record route option, this option is ignored. Stream Identifier (Type = 136) This Stream Identifier option is obsolete. It is ignored Internet Timestamp (Type = 68) Since SIPP does not provide a timestamp option, this option is ignored. All other IPv4 options If any other IPv4 options are present, they are ignored. By "ignored", we mean that the option is not processed, and no further action is taken on it. The translated SIPP packet is forwarded and no ICMP error message is sent back to the source host. If the IPv4 packet is a fragment (i.e. if either the More Fragments bit is set, or the fragment-offset field of the packet is non-zero), then a SIPP fragmentation option is added to the packet. The payload type in the SIPP header should be set to the number assigned to the fragmentation option. The fields of the SIPP fragmentation option should then be set as follows: Payload Type: Protocol field copied from IPv4 header. More bit: More fragments bit copied from IPv4 header. Fragment offset: draft-ietf-sipp-ipae-transition-00.txt [Page 28] INTERNET-DRAFT IPAE Specification November 1993 Fragment Offset value copied from IPv4 header. High-order 16 bits of the Identification field: 0 (all zero bits) Low-order 16 bits of the Identification field: Value of the identification field copied from IPv4 header. 5.2 Mapping Table IPAE Translators must implement a mapping table to map IPv4 addresses into 32-bit SIPP address prefixes. The mapping table is used in the process of translating IPv4 packets into SIPP headers. The destination address in the IPv4 packet is looked up in the mapping table. If a matching entry is found, the 32-bit prefix in that entry is prepended to the 32-bit IPv4 address to form a complete 64-bit SIPP address for the destination. This address is then used as the destination address of the SIPP header that is formed. The 64-bit SIPP address that is formed for the destination is also an IPAE address. Thus the 32-bit prefix in the mapping table covers the C-bit and the Site Prefix fields of the IPAE address: 6 3 3 0 3 2 1 0 +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ |C| Site Prefix | IPv4 Address | +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ ^ ^ ^ | 32-bit prefix from | IPv4 address | | the mapping table | from the original | | | IPv4 packet | In order to aggregate a large number of address mappings into a single entry, the "key" in each mapping table entry should consist of a 32-bit IPv4 address and a 32-bit mask. The "value" information in the mapping table is the 32-bit SIPP address prefix. A destination IPv4 address "matches" a mapping table entry if the destination address, logically and-ed with the key mask, equals the key address. More than one entry may match. The lookup process uses a "longest match" algorithm to locate the best matching entry in the mapping table. If more than one matching entry exist in them mapping table, the entry with the longest mask is the one that is used. draft-ietf-sipp-ipae-transition-00.txt [Page 29] INTERNET-DRAFT IPAE Specification November 1993 Here is an example of a mapping table entry: Key mask Key address ==> SIPP address prefix -------- ----------- ------------------- 255.255.0.0 129.144.0.0 ==> 9404:3 It is important that the C-bit field of the prefixes in the mapping table entries be set correctly. The mapping table must be configured so that the IPAE addresses composed for IPv4 destinations always have the C-bit set to 1. This will cause an IPAE translator in the destination site to translate the packet into the IPv4 form before it is transmitted to the destination IPv4 host. The C-bit of the prefixes for IPAE hosts is less critical because IPAE hosts accept packets in either the SIPP, IPAE, or IPv4 packet format. If the C-bit is set to 1, packets will be delivered in the IPv4 form; if the C-bit is set to 0, packets will be delivered in SIPP form. The traffic will be sub-optimal if the C-bit is 1, since it will undergo an unnecessary translation into the IPv4 form. But in order to condense the size of the mapping table, it may be desirable to have some entries that produce addresses for IPAE hosts with the C-bit set to 1. Once a prefix is assigned for a site, it likely will not need to be changed often. For that reason, the mapping table will be continually growing, but the individual entries, once added to the table, will change only rarely. For that reason, we do not need a highly dynamic mechanism to distribute the mapping table to the IPAE translators. In the initial deployment of IPAE and SIPP, the mapping table for the entire Internet will be maintained at a central site and distributed to all of the IPAE translators on a regular basis via FTP. The mapping table will be kept in a file on the central site, and the IPAE translators will "pull" the file with FTP. Each IPAE translator can set its own schedule to pull the mapping table. The central server from which the mapping table is FTP'ed must be an IPAE system. It can not be an IPv4 system. This is required so that the FTP traffic between the IPAE translators and the central sites does not depend on the correct operation of the IPAE translators themselves. 5.3 Translating SIPP to IPv4 When an IPAE translator receives a SIPP datagram addressed to an IPv4 destination in the local site, it translates the SIPP header of that packet into an IPv4 header, and then forwards the packet based on the IPv4 destination address. The original SIPP header on the packet is draft-ietf-sipp-ipae-transition-00.txt [Page 30] INTERNET-DRAFT IPAE Specification November 1993 removed and replaced by an IPv4 header; the transport header and data portion of the packet are left unchanged. +-------------+ +-------------+ | SIPP | | IPv4 | | Header | | Header | +-------------+ +-------------+ | Transport | | Transport | | Layer | ===> | Layer | | Header | | Header | +-------------+ +-------------+ | | | | ~ Data ~ ~ Data ~ | | | | +-------------+ +-------------+ SIPP to IPv4 Header Translation When translating from the SIPP format into IPv4, the IPv4 header fields are set as follows: Version: 4 IP Header Length in 32-bit words: 5 plus length of IPv4 options, if added (see below) Type of Service: 0 Total Length: Payload length from SIPP header plus length of IPv4 header and options, if added (see below). Identification: If SIPP fragmentation option is present, copy low-order 16 bits from ID field. Otherwise generate a unique value for every packet. Flags: If SIPP fragmentation option is present, set MF bit if More bit is set in option. If the SIPP fragmentation draft-ietf-sipp-ipae-transition-00.txt [Page 31] INTERNET-DRAFT IPAE Specification November 1993 option is not present, and the C-bit is set in the source address, then set the DF bit. Fragment offset: If SIPP fragmentation option is present, copy the fragment offset value from the option. Time to Live: Hop limit field copied from the SIPP header. Protocol: Payload type value copied from SIPP header or, if known SIPP options are present, from last SIPP option header. Header Checksum: Calculate the header checksum. Source Address: Copy the low-order 32-bits of the SIPP source address. Destination Address: Copy the low-order 32 bits of the SIPP destination address. If any end-to-end SIPP options are present, they are handled as follows: Fragmentation option: Copy the values from the option into the IPv4 header as described above. Route option: The SIPP Route option can be translated into an IPv4 LSRR option. The option values are set as follows: Length: 3 + 4 * (number of addresses) Pointer: draft-ietf-sipp-ipae-transition-00.txt [Page 32] INTERNET-DRAFT IPAE Specification November 1993 3 + 4 * (next address) Route data: Low-order 32 bits of each address in the SIPP Route option. All others: The above two options are the only SIPP options defined at the time this document was written. Since SIPP encodes end-to-end options using payload type codes, the codes for new options will be indistinguishable from those of transport layer protocols. Packets with unknown payload type codes should be translated and forwarded. When new SIPP options are defined, the specification should detail how they should be handled by IPAE translators. As of this writing, no hop-by-hop SIPP options are defined. Thus none of the hop-by-hop options can be translated into IPv4. If the hop-by-hop options payload type is given in the SIPP header, the IPAE translator must parse the hop-by-hop options and abide by the "action code" encoded into the low order 2 bits of the option type as specified in the SIPP specification [SIPP]. These action codes are: 00 Ignore the option; Continue processing the packet. 01 Discard the packet. 10 Discard the packet and send an ICMP parameter problem message back to the source. 11 Discard packet and, only if the packet's destination address was not a multicast address, send an ICMP parameter problem message back to the source. 5.4 SIPP and IPv4 Routing Configuration The IPAE translator must have some minimal involvement in both the IPv4 routing system within the site, and the global SIPP routing system. The SIPP and IPv4 routing systems must be configured to deliver those packets that must be translated to the IPAE translator. This means that the IPv4 routing system within the site must deliver the IPv4 traffic for all IPv4 destinations outside of the site to the IPAE translator. And the SIPP routing system must deliver the SIPP traffic addressed to the site's prefix with the C-bit set to 1 to the IPAE translator. (SIPP draft-ietf-sipp-ipae-transition-00.txt [Page 33] INTERNET-DRAFT IPAE Specification November 1993 traffic for the site's prefix with the C-bit set to 0 is routed to the individual SIPP hosts within the site.) In the intra-site IPv4 routing system, there usually must be a default route pointing to the IPAE translator. In the SIPP routing system, there must be a route for the site prefix with the C-bit set to 1 pointing to the IPAE translator. The necessary IPv4 and SIPP routing can be accomplished by static configuration in the IPv4 and SIPP routing systems, or by having the IPAE translator actively participate in the IPv4 and SIPP routing protocols. If multiple IPAE translators are deployed in a site, the routing configuration should be designed to split the traffic load among the translators. 5.5 Translation of fragments The rules for translating fragments, when to set the DF bit, and when to include a fragmentation header are derived from the following constraints: - The translator will not receive ICMP "packet too big" messages since it is not the source address in the packet. The ICMP errors will be delivered to the source host. (This is unlike the encapsulation case, where the encapsulator receives all ICMP errors from routers interior to the tunnel.) Thus the translation rules have to make sure that the source host does not see any ICMP 'packet too big' that it would not have seen without any translators in the path. - The minimum MTU that a link has to support is different for IPv4 and SIPP: 68 and 576 bytes, respectively. Thus SIPP hosts can send 576 bytes without supporting path mtu discovery. - SIPP routers never fragment packets (even when the fragmentation header is present). Thus the translation from IPv4 to SIPP, when the source does not support MTU discovery, has to make sure that the SIPP packet never needs to be fragmented. The different fragmentation cases are presented in the two tables below. The first table covers the cases where the source is an IPv4 system. In this case there can be either just a translation to SIPP (for a SIPP destination) or first a translation to SIPP and then a translation to IPv4 (for an IPv4 destination in a different site). When the source is a SIPP system (the second table) the only possible translation is to IPv4. draft-ietf-sipp-ipae-transition-00.txt [Page 34] INTERNET-DRAFT IPAE Specification November 1993 IPv4 SIPP IPv4 DF not set => fragment to 576 => copy ID field include fragmentation hdr DF not set DF set => no fragmentation hdr => DF set Fragmentation translation for IPv4 source SIPP IPv4 Fragmentation hdr => Copy ID field DF not set No fragmentation hdr => Generate pseudo-unique ID DF not set Fragmentation translation for SIPP source 5.6 Knowing when to Translate. The IPAE translator must translate IPv4 packets destined to hosts outside of the site and SIPP packets destined to hosts within the site. To do this, it must be able to differentiate those packets it must translate from those that it simply processes in the normal manner (and forwards, for example, if the machine is also a router). The translator may need some configuration information in order to make this distinction. This specification does not place any requirements on how the IPAE translator decides which packets to translate. However, the decision can be made based on information the machine has available. The IPAE translator can use the SIPP addresses of its own interfaces to decide which SIPP packets to translate. SIPP packets whose destination address match the 31-bits site prefix of an interface, and with the C-bit set to 1, should be translated. All other SIPP packets should be simply forwarded based on the SIPP destination address. The IPAE translator can use the mapping table along with the addresses of its own interface to decide which IPv4 packets to translate. If a matching entry is found in the mapping table for the destination address of the IPv4 packet, and the prefix in that mapping table entry does not match the site prefix of the address of any interface, then the packet draft-ietf-sipp-ipae-transition-00.txt [Page 35] INTERNET-DRAFT IPAE Specification November 1993 can be translate. Otherwise, the packet should be forwarded based on its IPv4 destination address. draft-ietf-sipp-ipae-transition-00.txt [Page 36] INTERNET-DRAFT IPAE Specification November 1993 6. IPAE Hosts IPAE hosts need to implement a variety of algorithms in order to be compatible with IPv4 hosts and routers, and also use the new facilities of SIPP. The modifications affect the internet and transport layers of the protocol software, as well as the transport layer application program interface (API), and the applications themselves. IPAE hosts must meet a couple of general requirements. They must be able to transmit and receive packets in the SIPP and IPv4 packet formats. They must be able to perform IPAE tunneling (SIPP encapsulated within IPv4). And they must be able to route outbound datagrams to both SIPP and IPv4 destination addresses. 6.1. What packet format to send. The first decision a host must make is which form of packet to transmit: IPv4 or SIPP. When sending traffic to IPv4 hosts within its own site, IPAE hosts always transmit in the IPv4 format. Thus the host can make its initial packet format decision based on the C-bit and high-order 32 bits of the destination SIPP address: if (C-bit of dest == 1) && (dest is in local site) send IPv4 packet else send SIPP packet The destination host is in the same site if the site prefix field (high-order 31 bits to the right of the C-bit) of the destination SIPP address match the site prefix field of the address of the outgoing interface. If a host is sending an IPv4 format packet, the packet can simply be routed using the IPv4 routing features of the host and transmitted. When sending a SIPP format packet, the host must determine whether the packet can be sent in the raw SIPP form, or whether it must be tunneled (encapsulated within an IPv4 header). How the host makes this decision depends on how IPAE tunnels are configured on the host. If the packet is to be tunneled, the SIPP datagram is encapsulated in an IPv4 header, and the IPv4 destination address set to the endpoint of the IPAE tunnel. The datagram is then routed using the IPv4 routing features of the host. The destination addresses in the IPAE packet will be: IPv4 dest addr: IPv4 address of tunnel endpoint. SIPP dest addr: SIPP addr of destination host. draft-ietf-sipp-ipae-transition-00.txt [Page 37] INTERNET-DRAFT IPAE Specification November 1993 If the packet is in the SIPP format and is not tunneled, it is routed using the SIPP routing features of the host and transmitted. 6.2. Transport pseudo-header checksum. TCP [RFC793] and UDP [RFC768] both define a checksum that covers the data portion of the segment along with a 96-bit "pseudo header" that includes the IPv4 source and destination addresses, protocol ID and length fields from the IPv4 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 IPv4 can be viewed logically as this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 destination address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | protocol | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Including the addresses in the checksum is even more important when TCP and UDP are layered above SIPP because the SIPP header is not checksummed. When communicating with other SIPP hosts, the TCP and UDP pseudo header includes the complete 64-bit SIPP source and destination addresses. But since the IPAE mechanism allows IPv4 packets to be translated into SIPP and vice-versa, the IPAE host must implement a compatible pseudo-header checksum when the packets it receives originated from, or the packets it is sending are destined to, an IPv4 host. The pseudo header checksum algorithm must cover only the low-order 32 bits of the SIPP addresses when an IPAE host is communicating with an IPv4 host. When transmitting, the IPAE host can use the C-bit of the SIPP destination address to determine whether the peer is an IPv4 host. When receiving, the C-bit of the SIPP source address can be used. When communicating with an IPv4 host using the IPv4 packet format directly (i.e., an IPv4 host in the same site), the 96 bit pseudo header shown above is used. When communicating in the IPAE or SIPP format with another SIPP host, the following pseudo header is used when the host is: 1) Transmitting and C-bit of SIPP Destination Address is 0, or draft-ietf-sipp-ipae-transition-00.txt [Page 38] INTERNET-DRAFT IPAE Specification November 1993 2) Receiving and C-bit of SIPP Source Address is 0 0 8 16 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | protocol | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + SIPP Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + SIPP Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPP peer pseudo header When communicating in the IPAE or SIPP format with an IPv4 host the following pseudo header is used when the host is: 1) Transmitting and C-bit of SIPP Destination Address is 1, or 2) Receiving and C-bit of SIPP Source Address is 1. 0 8 16 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zero | Protocol | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-LSB of SIPP Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-LSB of SIPP Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SIPP - IPv4 compatible pseudo-header 6.3. TCP and UDP connection identification. 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 draft-ietf-sipp-ipae-transition-00.txt [Page 39] INTERNET-DRAFT IPAE Specification November 1993 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 as well -- from the received segment to find the matching socket or connection in its own connection table. When communicating with another SIPP host, TCP must use the full SIPP source and destination addresses to identify connections and sockets. But when communicating with IPv4 hosts using the SIPP packet format, TCP must use only the low order 32 bits of global source and destination to identify the connection. This is necessary since the 64 bit SIPP addresses may not carried end-to-end; only the low-order 32 bits are end-to-end. Thus the high-order bits can be different in received packets from what was sent when the source or destination is in a multihomed site (a site that has multiple prefixes) or when the mapping tables contain prefixes with incorrect C bits. This requires a change to TCP's connection block lookup algorithm for received segments. Assuming that TCP keeps a single table of connection blocks identifying connections to both IPv4 hosts and SIPP 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 SIPP source and destination address in TCP's connection block table, 2) If the format of the received packet is SIPP, then: 2a) If the C-bit of the SIPP source address is 1, then: use the low-order 32 bits of the SIPP source and destination addresses in the packet to compare the low-order 32 bits of the SIPP source and destination address in the connection block table, 2b) If the C-bit of the SIPP source address is 0, then: use the full SIPP source and destination addresses in the packet to compare with the full SIPP source and destination addresses in the connection block table. The host should implement this same algorithm in UDP if UDP supports the draft-ietf-sipp-ipae-transition-00.txt [Page 40] INTERNET-DRAFT IPAE Specification November 1993 notion of a connected endpoint. In addition, any user-level UDP applications that use IP addresses to match replies with requests should implement a similar algorithm. 6.4. ICMP Error Messages. 6.4.1. Sending ICMP Error Messages. All of the ICMP error messages include an "offending packet" in the data part of the message. The "offending packet" is the internet header plus at least the first 8 bytes of the packet that caused the error being reported. The offending packet is used by the recipient of the ICMP error message to locate the transport-layer endpoint that caused the error. When sending ICMP error messages, the IPAE host must take into account the C-bit of the intended recipient, and make sure that the offending packet is in a form (IPv4 or SIPP) that the recipient understands. This is not always straightforward. If the C-bit of the recipient is 1, then the offending packet must be in the IPv4 form. But since IPAE translators may translate packets sent from IPv4 hosts into SIPP form, it is possible that the packet that caused the error might be in the SIPP form, even though the source was an IPv4 only host. (The IPAE host knows this because the C-bit of the Source SIPP address is 1.) When this happens, the IPAE host must "generate" an IPv4 header for use in the offending packet part of the ICMP error message. The IPAE host can use the information in the SIPP header of the packet that actually caused the error to generate the IPv4 header. Since the offending packet is going to be used by the recipient to identify a connection, the address fields must be correct. The IPAE host can the IPv4 header of the offending packet from the received SIPP packet in the same way that an IPAE translator translates SIPP to IPv4: Version: 4 IP Header Length in 32 bit words: 5 Type of Service: 0 Total Length: draft-ietf-sipp-ipae-transition-00.txt [Page 41] INTERNET-DRAFT IPAE Specification November 1993 Payload length from SIPP header + 20 Identification: If SIPP fragmentation option is present, copy low-order 16 bits from ID field. Otherwise generate a unique value for every packet. Flags: If SIPP fragmentation option is present, set MF bit if More bit is set in option. If the SIPP fragmentation option is not present, and the C-bit is set in the source address, then set the DF bit. Fragment offset: If SIPP fragmentation option is present, copy the fragment offset value from the option. Time to Live: Hop limit field copied from the SIPP header. Protocol: Payload type value copied from SIPP header or, if known SIPP options are present, from last SIPP option header. Header Checksum: Calculate the header checksum. Source Address: Copy the low-order 32-bits of the SIPP source address. Destination Address: Copy the low-order 32 bits of the SIPP destination address. The resulting ICMP error message can be sent within an IPv4 header (if the destination is within the same site), or within a SIPP header (if the destination is located in another site). Thus the following two header configurations are possible: draft-ietf-sipp-ipae-transition-00.txt [Page 42] INTERNET-DRAFT IPAE Specification November 1993 +------------+ +------------+ | SIPP | | IPv4 | | Header | | Header | +------------+ +------------+ | ICMP | | ICMP | | Header | | Header | +------------+ +------------+ |"Generated" | |"Generated" | | IPv4 | | IPv4 | | Header of | | Header of | | offending | | offending | | packet | | packet | +------------+ +------------+ | Transport | | Transport | | Header | | Header of | | Offending | | Offending | | Packet | | Packet | ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~ Sending ICMP error messages to destinations whose addresses have their C-bit set to 0 is simpler. Both the header of the offending packet and the header of the ICMP message are of the SIPP form: +------------+ | SIPP | | Header | +------------+ | ICMP | | Header | +------------+ | SIPP | | Header | | (offending | | packet) | +------------+ | Transport | | Header | | (Offending | | packet) | ~~~~~~~~~~~~~~ 6.4.2 Receiving ICMP Error Messages. IPAE hosts must be prepared to receive ICMP error messages encapsulated within either SIPP or IPv4 headers. They must also be able to decode the "offending packet" within the ICMP error message that is in either the SIPP or IPv4 header format. They must use the same connection matching rules spelled out in section 6.3 to match the "offending draft-ietf-sipp-ipae-transition-00.txt [Page 43] INTERNET-DRAFT IPAE Specification November 1993 packet" in the received ICMP error message with an existing TCP connection or UDP endpoint. 6.5. Transport API changes. Most IPv4 systems that are modified to support SIPP will already have an existing application program interface (API) through which applications use TCP and UDP. These APIs typically carry a 32 bit IPv4 address in order to bind a TCP or UDP endpoint to a local address, to specify the destination address of a UDP datagram being sent, or to specify the destination address of a TCP connection being opened. The 32 bit IPv4 address shows up in other parts of the API, such as the return value from a hostname-to-IPv4 address lookup function. Generally, these APIs provide fixed-size fields to hold IPv4 addresses and TCP and UDP port numbers. For the most part, these APIs must modified be to carry 64-bit addresses in order to support SIPP. The IPAE mechanism does not impose any specific requirements on how the the APIs in a IPAE system should be changed to support SIPP. However, we offer here some general considerations in designing these new APIs. Some desirable features of a SIPP API are: 1) The new API should allow applications to pass in both 32-bit IPv4 addresses and 64-bit SIPP addresses. Even new applications may encounter 32 bit IPv4 addresses. The API should allow the program to pass these addresses in. 2) The new API should provide both source and binary compatibility with the existing IPv4 API. Applications written to the old API should continue to operate when run in binary form, or when re-compiled on an IPAE system with the new API. 3) Un-modified applications should provide as much SIPP service as possible. 4) Applications that do not manipulate IP addresses (e.g. TCP servers) should run without any modifications. Along with the API changes, application programs that manipulate IP addresses must usually be modified. Often these changes can be isolated to the code that that parses SIPP addresses typed in by users, and the code that deals with SIPP addresses returned by the name to address translation functions (DNS lookups). 6.6. IP Addresses Embedded in Application Protocols draft-ietf-sipp-ipae-transition-00.txt [Page 44] INTERNET-DRAFT IPAE Specification November 1993 There are many application protocols layered above TCP and UDP. Some of them carry IPv4 addresses as part of their protocol. We have examined the most popular application layer protocols, considering for each how IPAE hosts would interoperate with IPv4 hosts, and with each other, using these protocols. In this section, we specify how IPAE hosts should use existing application protocols. This section addresses only application layer protocols. The internet routing protocols, control protocols, transport protocols, or layering (e.g. IP over appletalk) protocols which carry IPv4 addresses are specific to IPv4 and would not require any change for IPAE. SIPP versions may be developed, but that will be addressed in other documents. The application protocols that we analyzed fell into four categories: 1) Application protocols that do not carry embedded IPv4 addresses. These protocols can be used immediately between IPAE and IPv4 systems and between IPAE systems. They require no change. 2) Application protocols that carry IPv4 addresses, but the protocol or its use of IPv4 addresses is obsolete. These protocols do not need to be changed. They can continue to be used between IPAE and IPv4 systems and between IPAE systems indefinitely. 3) Application protocols that carry IPv4 addresses, but that are used exclusively by IPv4 systems, or the IPv4 parts of IPAE systems. These protocols also do not need to be changed, although new versions of them may be necessary in order to support the same function in SIPP and IPAE systems. 4) Application protocols that carry IPv4 addresses, but that are not IPv4 specific. Only one protocol, FTP, fell into this category. FTP provides its full functionallity when used between IPv4 and IPAE systems, and that provide a subset of that functionallity when used among IPAE systems. It will have to be extended in order to provide its full functionallity among SIPP and IPAE systems. Most of the application layer protocols that we examined fell into the first category. These protocols, which require no change at all to be used between IPAE and IPv4 systems, are: Telnet (RFC 854, RFC 855) SMTP (RFC 821) TFTP (RFC 1350) BSD "rlogin" protocol (RFC 1282) draft-ietf-sipp-ipae-transition-00.txt [Page 45] INTERNET-DRAFT IPAE Specification November 1993 BSD "rsh" protocol (note: passes port number, bug not IP addr) BSD "biff" protocol (in.comsat) BSD "lpr" protocol (RFC 1179) BSD "syslog" protocol ONC RPC protocol (RFC 1057) ONC original "portmap" protocol (documented in RFC 1057) ONC+ new "rpcbind" protocol (replaces portmap) Echo - TCP and UDP (RFC 862) Discard - TCP and UDP (RFC 863) Chargen - TCP and UDP (RFC 864) Quote of the Day - TCP and UDP (RFC 865) Active users - TCP or UDP (RFC 866) Daytime - TCP or UDP (RFC 867) Time - TCP or UDP (RFC 868) Nicname/Whois (RFC 954) Finger (RFC 1288) DNS mail routing (RFC 974) SNMP (RFC 1157) POP3 (RFC 1225) Concise-MIB (RFC 1212) Content type mail header field (RFC 1049) MIME (RFC 1341) NNTP (RFC 977) BSD "rexec" protocol NTP (RFC 1119) NFS A few protocols fell into the second category. These protocols -- which carry IPv4 addresses, but do not need to be changed because their use of IPv4 is obsolete -- are: Mail (RFC 822) BSD "talk" protocol More protocols fell into the third category. They are used only by IPv4 systems, and may need to be revised in order to provide a similar function between SIPP systems: SMI (RFC 1155) MIB-II (RFC 1213) IP Forwarding table MIB (RFC 1354) RARP (RFC 903) BOOTP (RFC 951, RFC 1084) DHCP (RFC 1531) PPP IP address negotiation options ONC "bootparams" RPC protocol DNS (RFC 1034, RFC 1035) draft-ietf-sipp-ipae-transition-00.txt [Page 46] INTERNET-DRAFT IPAE Specification November 1993 The one protocol in the fourth category, which will need to be extended in order to provide full functionallity to SIPP systems, is: FTP (RFC 959) We did not have enough information to evaluate two application protocols: Kerberos (Where are the complete protocol spec?) Telnet options (Is there a complete list of all options?) The remainder of this section discusses how IPAE systems should use the IPv4 address carrying application protocols. 6.6.1. FTP IPv4 addresses are encoded in FTP in two places: - the arguments to the PORT command. - the reply to the PASV command. Both the argument to the PORT command and the reply to the PASV command contain a 32-bit IPv4 address and a 16-bit TCP port number. These commands are used for two specific purposes: 1) In a 2-party FTP transaction, the client uses the PORT command to specify a TCP port number on the client's machine other than the default (port 20) for the server to connect back to the client on. 2) In a 3-party FTP transaction involving one client FTP and two server FTPs. The client gives the PASV command command to FTP server 1 and records the address reply. Then it sends the PORT command command to FTP server 2, giving the address returned by server 1. Then it sends the STOR or RETR command to server 2 to transfer file(s) directly between server 1 and server 2. IPAE hosts must implement the algorithm below, which provides complete interoperability for 2-party FTP transactions between IPv4 hosts and all other IPAE hosts. It also provides interoperability for 3-party FTP transactions with other IPv4 and IPAE hosts within the same IPAE site. This algorithm does not allow 3-party FTP transactions among hosts in different IPAE sites. Such a feature could be provided by modifying the FTP protocol, but such a change is outside the scope of this document. In a 2-party FTP, the client may generate PORT commands of the form: draft-ietf-sipp-ipae-transition-00.txt [Page 47] INTERNET-DRAFT IPAE Specification November 1993 PORT a1,a2,a3,a4,p1,p2 The semantics of this are that the bytes a1, a2, a3 and a4 are the low-order 32 bits of the 64 bit SIPP address that the server should connect to. The high-order 32-bits of the SIPP address that the server should connect to are communicated implicitly: they are the high-order 32 bits of the client's SIPP address used in the FTP control connection. Thus the FTP client can communicate any SIPP address in the PORT command so long as the high-order 32 bits of that address are the same as the client-side address of the control connection. The client may communicate the SIPP address of any of its SIPP interfaces so long as all of those addresses share the same high-order 32 bits as the control connection. If a host is multi-homed in multiple SIPP sites (i.e. it has multiple SIPP interfaces with different high-order 32 bits), it can not communicate the addresses of those interfaces connected to different sites. The FTP server, when it receives a PORT command composes the 64 bit SIPP address to connect back to by concatenating the 32 high-order bits of the client's address of the control connection with the low-order 32 address bits passed in the PORT command. An FTP server generates a replies to the PASV command with the form: 227 Entering Passive Mode. a1,a2,a3,a4,p1,p2 The bytes a1, a2, a3, and a4 are the low-order 32 bits of the 64 bit SIPP address that the client can connect to the server on. The high-order 32 bits of the connect address are communicated implicitly: they are the high-order 32 bits of the SIPP address of the server side of the control connection. The server may return any 64 bit SIPP address in its PASV reply that shares the same high-order 32 bits as the server side of the control connection. Thus, for example, it can return the address of any other interface on the server that is in the same SIPP site, but may not return the address of interfaces that are in other SIPP sites. A client FTP may initiate a 3-party FTP *only* if the SIPP addresses of all three participants -- the FTP client, server 1 and server 2 -- share the same high-order 32 bits. 6.6.2. Mail (RFC 822) The only place where IPv4 addresses appear in the RFC 822 mail header format is in the "domain literal" address construct. It is possible to specify a domain address as a dotted-decimal address. For example, one could specify: draft-ietf-sipp-ipae-transition-00.txt [Page 48] INTERNET-DRAFT IPAE Specification November 1993 Gilligan@[192.9.9.1] This construct is specified in section 6.2.3 of RFC 822. The spec includes the following warning: Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It is permitted only as a means of bypassing temporary system limitations, such as name tables which are not complete. In IPAE, we continue the campaign to "discourage" the domain-literal address construct by not modifying its syntax to support 64 bit SIPP addresses. IPAE hosts may continue to use the domain-literal address format as specified in RFC 822. However, this format specifies only a 32 bit IPv4 address and not a SIPP address. IPAE hosts that parse a domain-literal address treat the resulting 32-bit IPv4 address the same as if they had parsed a domain name that translated (via a DNS lookup that returned an "A" record) to a 32-bit IPv4 address. Thus domain literal addresses will still be useful globally so long as IPv4 addresses are globally unique. After IPv4 addresses are no longer globally unique, the domain literal form can still be used within a SIPP site. 6.6.3. Domain Name System (DNS) There are two places within the DNS where IPv4 addresses are encoded: - The "A" record format. - The structure of the "in-addr.arpa" tree. A new address record is being defined to hold 64-bit SIPP addresses. This new record is specified in another document [SIPPDNS]. There is no need to change the existing "A" record format or the "in-addr.arpa" tree. They can continue to be used by IPv4 systems for as long as necessary. IPAE hosts can use the A records and "in-addr.arpa" in addition to the new 64-bit SIPP address records and reverse lookup tree. 6.6.4. SMI, MIB-II, Forwarding Table MIB The SMI RFC defines a data type for the 32-bit IPv4 address. This type is named "IpAddress". The MIB-II and some other MIBs use this data structure. These definitions can remain unchanged and can continue to be used by IPv4 hosts and routers. Management stations running on IPAE hosts can continue to use these definitions when managing IPv4 hosts and routers. IPAE hosts and routers may choose to continue to support the IPv4-based MIBs in order to provide meaningful information to the draft-ietf-sipp-ipae-transition-00.txt [Page 49] INTERNET-DRAFT IPAE Specification November 1993 installed base of management stations. For SIPP and IPAE systems, a new data type for the 64-bit SIPP address will need to be defined. All of the MIBs that include IP address data types (at least MIB-II and the Forwarding table MIB) will need to be revised for SIPP and IPAE systems. In addition, a MIB will need to be defined for the mapping table stored on IPAE translators. 6.6.5. RARP, BOOTP, DHCP, Bootparams RARP, BOOTP, DHCP, and Bootparams are all used to support booting. RARP, BOOTP, and DHCP all provide a mechanism for a host to acquires its own IPv4 address. These protocols can continue to be used without change by IPv4 systems. These protocols can be used without change to provide limited service to IPAE systems. The Bootparams protocol carries 32-bit IPv4 addresses in two places: The "whoami" RPC returns the 32-bit IPv4 address of a default router, and the "getfile" RPC returns the 32-bit IPv4 address of a file server. IPAE systems can use the whoami call to learn their default IPv4 router address. IPAE systems should use the SIPP router discovery mechanism to learn the addresses of SIPP routers. IPAE hosts can continue to use the getfile call to communicate with IPv4 or IPAE file servers within the local site. In order to provide their full functionallity to SIPP and IPAE systems, these three protocols will have to either be revised to return 64-bit SIPP addresses, or incorporated into a new host configuration scheme. SIPP host configuration is being addressed in another spec [SIPPDISC]. The ONC RPC system includes a versioning mechanism that should allow us to revise the bootparams protocol in a compatible way. 6.6.6. BSD talk protocol. This protocol is obsolete. We make no attempt to convert it to SIPP. draft-ietf-sipp-ipae-transition-00.txt [Page 50] INTERNET-DRAFT IPAE Specification November 1993 Appendix 1. Definitions IPv4: The Internet Protocol, version 4. This is the version of the Internet Protocol specified in RFC 791. SIPP: The Simple Internet Protocol Plus. This is the working name for the next generation Internet Protocol being designed by the IETF SIPP working group. If SIPP is accepted as the next generation IP, it will likely be re-named simply IP. IPAE: The set of protocols and operational techniques that provide interoperability between IPv4 and SIPP systems, and transition the Internet from IPv4 to SIPP. The acronym "IPAE" no longer stands for anything. IPAE Address: A 64-bit SIPP address that is structured so as to be compatible with IPv4. The format of an IPAE address is: 6 3 3 0 3 2 1 0 +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ |C| Site Prefix | IPv4 Address | +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ An IPAE address has three components: C-bit Encodes whether the entity addressed supports SIPP or not. Site Prefix Uniquely identifies the IPAE site that the addressed entity is located in. IPv4 Address Uniquely identifies the addressed entity. IPAE Host: A host adhering to both the SIPP specifications and the IPAE specifications. An IPAE host is capable of sending and receiving packets in any of the three packet formats - IPv4, SIPP, and IPAE. draft-ietf-sipp-ipae-transition-00.txt [Page 51] INTERNET-DRAFT IPAE Specification November 1993 IPAE Packet Format: SIPP encapsulated within IPv4. IPAE Router: A router capable of sending, receiving, and processing the three packet formats -- IPv4, SIPP and IPAE. An IPAE router also participates in both IPv4 and SIPP routing protocols. IPAE Site: A region of the Internet that contains IPv4 hosts and routes IPv4 packets. An IPAE site typically has at least one IPAE router providing SIPP connectivity to the global Internet. IPAE Translator - or - IPAE Translation Agent: An IPAE router that performs the following additional functions to support intra-site IPv4-to-IPv4 and IPv4-to-SIPP traffic: - Mapping the source and destination addresses of locally generated IPv4 traffic into SIPP addresses through the use of a mapping table. - Translating headers of locally generated IPv4 traffic from IPv4 format to SIPP format. - Translating headers of remotely-generated SIPP traffic from SIPP format to IPv4 format. IPAE translators must participate in IPv4 and SIPP routing to the extent that they receive: - All IPv4 traffic generated within the site destined to IPv4 hosts outside the site. This is usually accomplished by pointing an IPv4 default route at the IPAE translator. - All SIPP traffic generated external to the site with destination SIPP address of the site with the C-bit set. SIPP-only Host: A host that sends and receives *only* the SIPP format. draft-ietf-sipp-ipae-transition-00.txt [Page 52] INTERNET-DRAFT IPAE Specification November 1993 SIPP-only hosts can not send or receive IPv4 or IPAE format packets. SIPP-only Router: A router that sends and receives *only* the SIPP format. SIPP-only routers can not send or receive IPv4 or IPAE format packets. SIPP-only Site: A region of the Internet that consists of only SIPP or IPAE hosts and SIPP routers. No IPv4 or IPAE traffic will be seen in a SIPP-only site. IPv4-only Host: A host that sends and receives only IPv4 format packets. IPv4-only Router: A router that sends and receives only IPv4 format packets. draft-ietf-sipp-ipae-transition-00.txt [Page 53] INTERNET-DRAFT IPAE Specification November 1993 Appendix 2. The IPv4 to SIPP Transition The Internet's transition to SIPP takes place in a number of sequential steps: 1) The first IPAE systems are deployed on the Internet. IPAE site boundaries are defined, and the first IPAE site prefixes are assigned. 64-bit SIPP address records are added to the DNS for each new SIPP system as well as IPv4 systems. 2) Backbone SIPP routing topology is designed. Sites begin to deploy IPAE routers. Backbone SIPP routing runs in parallel with IPv4 routing. 3) Sites begin to deploy IPAE translators. Site-internal default routes are configured to point to the IPAE translators. SIPP C-bit routes are propagated. After a IPAE translator has been deployed at a site, 64-bit SIPP address records (with C-bit on) are added to the DNS for each IPv4 host within that site. 4) Deployment of IPAE routers and IPAE translators at every site connected to the backbone is complete. 5) Backbone IPv4 routing is turned off. All inter-site IPv4-to-IPv4 and IPv4-to-SIPP traffic uses IPAE translators. 6) Internet runs out of IPv4 network numbers. IPAE translators are de-commissioned. Inter-site IPv4-to-IPv4 and IPv4-to-SIPP traffic is no longer possible. Intra-site IPv4-to-IPv4 and IPv4-to-SIPP traffic can continue indefinitely. draft-ietf-sipp-ipae-transition-00.txt [Page 54] INTERNET-DRAFT IPAE Specification November 1993 Time What is Happening ---- ----------------- | Today --+ | - IPv4 is routed globally. | - All hosts speak IPv4. | T1 ---+ - First IPAE hosts deployed | - IPAE hosts use IPAE tunneling across the IPv4 | infrastructure to reach other IPAE hosts. | - IPAE hosts use IPv4 packet format to communicate with | IPv4 hosts | T2 ---+ - SIPP routing is started. | - IPAE hosts route intra-site SIPP traffic via IPAE routers. | - IPAE hosts continue to use IPv4 packet format to communicate | IPv4 hosts. | T3 ---+ - Installation of IPAE translators begins. | - IPAE hosts send SIPP packets to IPv4 hosts in other sites | where translators have been installed. | - IPv4 traffic generated in sites with IPAE translators | and destined for sites with translators is translated. | T4 ---+ - IPAE routers and translators have been installed in | every site. | - All inter-site IPv4-to-IPv4 and IPv4-to-SIPP traffic | should be using IPAE translators and are carried via | the backbone SIPP routing system. Only mis-configured | routers use IPv4 backbone routing. | T5 ---+ - Backbone IPv4 routing is cut. | - Users should not notice any change. | - Mis-configurations are detected and repaired. | | T6 ---+ - IPv4 address "run-out" day. | - Since IPv4 addresses are no longer unique, global | IPv4 connectivity is discontinued. IPAE translators | are de-commissioned. | - IPv4 hosts continue to have complete connectivity within | their site. | - IPv4 hosts continue to have complete interoperability | with IPAE hosts within their site. | - Remaining IPv4 hosts and routers may be converted to | SIPP at the convenience of their owners, but | conversion is not required. | - Note: introduction of new SIPP services may require draft-ietf-sipp-ipae-transition-00.txt [Page 55] INTERNET-DRAFT IPAE Specification November 1993 | conversion of some routers to SIPP. The transition starts by dividing the existing Internet into a collection of IPAE sites. This doesn't involve any physical re-configuration or re-numbering of the Internet. We simply take the existing Internet topology and identify individual regions. Generally speaking, a "site" will be a single administrative entity, such as a University campus or a corporation. Each site is assigned a unique 32-bit SIPP prefix which comprises a 1-bit C-bit and a 32-bit IPAE site prefix. These prefixes are selected based on a global 64-bit SIPP addressing plan to be drawn up. A 64-bit SIPP address for each host and router is formed by concatenating the site's 32-bit prefix with the host or router's previously assigned 32-bit IPv4 address. The C-bit field of the addresses of all SIPP-capable hosts and routers is set to 0. For those hosts and routers that speak only IPv4, the C-bit is set to 1. All hosts and routers in the Internet keep their existing IPv4 address assignments. No IPv4 re-numbering is required. The Internet continues to use the CIDR-based IPv4 address allocation scheme. New IPv4 hosts and routers can continue to be added during the SIPP transition. Next, the Internet backbone is converted to route SIPP traffic. This can be done by converting all of the routers from the sites into the backbone and the sites to route SIPP. Next, an IPAE translator is installed in each site. The IPAE translator can be co-resident with the IPAE router. draft-ietf-sipp-ipae-transition-00.txt [Page 56] INTERNET-DRAFT IPAE Specification November 1993 Appendix 3. Examples A3.1. IPAE Encapsulation Consider the following topology, which includes two IPAE hosts, two IPAE routers, and two IPv4 routers: ---+----------------------------------+--- (Subnet A) | | (1404:1:192.9.5.2) (192.9.5.1) IPAE Host H1 IPv4 Router R1 (192.9.6.1) | -----+-----------+------- (Subnet B) | (1404:1:192.9.6.17) IPAE Router R2 (1404:8:192.9.88.13) | -------+----------------+------ (Subnet C) | (1404:8:192.9.88.3) IPAE Router R3 (1404:8:192.9.89.3) | ---+-------+----- (Subnet D) | (192.9.89.77) IPv4 Router R4 (192.9.123.68 | ---+-----------------------------+-------- (Subnet E) | (1404:8:192.8.123.244) IPAE Host H2 A UDP datagram is sent from IPAE host A to IPAE host B. The packet transits two IPAE tunnels. One tunnel runs from the source host, H1, to the IPAE router, R2. The router R3 sends the packet to router R3 in the raw SIPP packet format. The packet then rides the second tunnel from IPAE router R3 to the destination host, H2. The packet transmitted on Subnet A and Subnet B looks like this: IPv4 src = 192.9.5.2 IPvr dst = 192.9.6.17 SIPP src = 1404:1:192.9.5.2 SIPP dst = 1404:8:192.9.123.244 draft-ietf-sipp-ipae-transition-00.txt [Page 57] INTERNET-DRAFT IPAE Specification November 1993 The packet as transmitted on Subnet C looks like this: SIPP src = 1404:1:192.9.5.2 SIPP dst = 1404:8:192.9.123.244 The packet as transmitted on Subnet D and Subnet E looks like this: IPv4 src = 192.9.89.3 IPvr dst = 192.9.123.244 SIPP src = 1404:1:192.9.5.2 SIPP dst = 1404:8:192.9.123.244 draft-ietf-sipp-ipae-transition-00.txt [Page 58] INTERNET-DRAFT IPAE Specification November 1993 Appendix 4. Design Decisions This section explains the reasoning behind some of the decisions made in the design of IPAE. A4.1. The C-bit. Question: The C-bit wasts a full bit in the address space, effectively halving its size. Why not just define a single prefix for IPv4 hosts (A C-prefix instead of a C-bit)? Answer: The C-bit as it is defined allows IPv4 traffic to have the same benefits of scaling that SIPP traffic enjoys. Since intra-site IPv4 traffic is translated early on into SIPP form by the IPAE translators, it is routed over the backbone by its 64 bit SIPP destination address, not its 32-bit IPv4 address. The 64-bit SIPP addresses that the IPAE translators convert the IPv4 addresses into have the same hierarchical structure as SIPP hosts. We viewed the near-term benefits of route scaling for IPv4 traffic as outweighing the cost of the C-bit in terms of address space. A4.2. Global vs. Local scope for C-bit. Question: Why wasn't the C-bit defined with local scope? That way it could C-bits could be recycled after a site was completely converted to SIPP. Answer: That was one of our early designs. However, we quickly found that there the C-bit could be used in a number of different places. To limit the C-bit to local scope, we would have to change each of those places where we use the C-bit. draft-ietf-sipp-ipae-transition-00.txt [Page 59] INTERNET-DRAFT IPAE Specification November 1993 Appendix 5. Open Issues In this section, we discuss those issues that are not yet decided. A5.1. How is the DF bit handled? How should the IPAE translators handle IPv4 packets that arrive with the DF bit set? A5.2. Should we map IPv4 TOS bits into a flow ID? When translating IPv4 to SIPP, should the IPAE translators map the 8-bit IPv4 TOS field into the SIPP flow ID? A5.3. How should we set the ID field? The IPv4 header has an ID field that is used by the receiving host when re-assembling fragments. In order to ensure proper reassembly, the IPv4 ID field must be unique per IP source and destination address. When a SIPP packet is translated into an IPv4 packet for delivery to an IPv4 host, the IPv4 ID field must be generated by the IPAE translator. The translator can generate an ID field that is unique relative to itself. However, it is possible that datagrams from one source host to one destination source might be translated by more than one IPAE translator. If more than one translator translates packets from this host pair, fragments of different IPv4 packets might end up with the same ID field. There are a number of potential solutions to this problem: 1) Allow only one IPAE translator per site. 2) Have the IPAE translators choose random ID values for each packet. 3) Have the IPAE translators choose per-destination unique values that start with a random seed. A5.4. ICMP error message handling? How should an IPAE translator deal with IPv4 ICMP error messages returned for "last hop" packets translated from SIP to IPv4 and then sent by an IPAE translator? How should they deal with SIPP ICMP error messages returned for packets translated from IPv4 to SIP by the IPAE translator? draft-ietf-sipp-ipae-transition-00.txt [Page 60] INTERNET-DRAFT IPAE Specification November 1993 One solution is to have the IPAE translators translate both the IPv4 or SIPP headers of the ICMP message, as well as the IPv4 or SIPP headers of the "offending packet" that is within the ICMP error message. This would be possible to implement, but would be complex. It would be nice if we could find a simpler solution. A5.5 IPv4 path mtu discovery when encapsulating. Section 4.3 states that the Don't fragment bit should always be set in the IPv4 header when encapsulating SIPP (in order for the encapsulator to track the tunnel mtu so that it can generate SIPP ICMP errors back to the source). Should we allow simple IPAE hosts to send IPAE packets without performing IPV4 path MTU discovery? A5.6 Determining "improvements" in tunnel state Can the mechanism to discard stale tunnel state in an encapsulating host or router be a simple periodic discarding of the timer state or should we use more sophisticated algorithms? A more elaborate scheme would be to count the number of 1) datagrams that should have generated a certain ICMP error and 2) the actual number of such ICMP errors received, and discarding the state when the ratio between them exceeds some value. draft-ietf-sipp-ipae-transition-00.txt [Page 61] INTERNET-DRAFT IPAE Specification November 1993 Security Considerations Security issues are not discussed in this document. References [CIDR] Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. Fuller, V.; Li, T.; Yu, J.; Varadhan, K.; September 1993. RFC 1519 [SIPP] Simple Internet Protocol Plus Specification. To be published. [IP] Internet Protocol. Postel, J.B. September 1981. RFC 791. [RFC793] Transmission Control Protocol. Postel, J.B. September 1981. RFC 793. [RFC768] User Datagram Protocol. Postel, J.B. August 1980. RFC-768. [SIPPDNS] SIP addresses in the domain name service specifications, Internet Draft, 06/11/1993, [SIPPCONF] SIP System Discovery, Internet Draft, 06/09/1993, Authors' Address Robert E. Gilligan Sun Microsystems, Inc. 2550 Garcia Avenue Mailstop UMTV05-44 Mountain View, California 94043-1100 415-336-1012 bob.gilligan@eng.sun.com draft-ietf-sip-ipae-transition-00.txt [Page 62]