idnits 2.17.1 draft-ietf-sipp-ipae-transition-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 69 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 343: '...within a site MAY also support SIPP, i...' RFC 2119 keyword, line 344: '...outers; but they MUST support IPv4. A...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2078 has weird spacing: '... is permi...' == Line 2079 has weird spacing: '...s which are ...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 10, 1993) is 11125 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SIPPDISC' is mentioned on line 2147, but not defined == Unused Reference: 'IP' is defined on line 2562, but no explicit reference was found in the text == Unused Reference: 'SIPPCONF' is defined on line 2575, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIPP' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIPPDNS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIPPCONF' Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Robert E. Gilligan 2 INTERNET-DRAFT Erik Nordmark 3 Bob Hinden 4 Sun Microsystems, Inc. 5 November 10, 1993 7 IPAE: The SIPP Interoperability and Transition Mechanism 9 Abstract 11 The Internet is experiencing growing pains. The phenomenal success of 12 TCP/IP -- the exponential growth in the size of the global IP-connected 13 Internet and the ever increasing number of systems deployed on isolated 14 networks running the Internet protocols -- is likely to bring about two 15 serious problems in the near future. First, since the IP routing system 16 has little hierarchical structure it may not scale much above its 17 current size. Secondly, since the 32-bit IP address space is assigned 18 in an inefficient manner, it may be exhausted within a few years. These 19 problems have given rise to a number of proposals for revising the 20 Internet Protocol. SIPP -- the Simple Internet Protocol Plus -- is one 21 proposal for a next generation Internet Protocol. 23 If SIPP, or any next generation IP, is to be successful, it must provide 24 an easy mechanism by which hosts and routers implementing the new 25 protocol can continue to interoperate with systems using the existing IP 26 version. Also, there must be mechanism to transition the Internet to 27 the new protocol without disrupting operation of the Internet. This 28 specification details both with the mechanisms by which SIPP systems 29 interoperate with those using the current version of IP, and the plan 30 for transitioning the IP-connected Internet to SIPP. While specifically 31 cast in terms of SIPP, the IPAE techniques could be applied to the other 32 network layer protocol transitions as well. 34 Status of this Memo 36 Internet Drafts are working documents of the Internet Engineering Task 37 Force (IETF), its Areas, and its Working Groups. Note that other groups 38 may also distribute working documents as Internet Drafts. 40 Internet Drafts are draft documents valid for a maximum of six months. 41 This Internet Draft expires on May 10, 1994. Internet Drafts may be 42 updated, replaced, or obsoleted by other documents at any time. It is 43 not appropriate to use Internet Drafts as reference material or to 44 cite them other than as a "working draft" or "work in progress." 45 Please check the I-D abstract listing contained in each Internet Draft 46 directory to learn the current status of this or any other Internet 47 Draft. 49 Distribution of this memo is unlimited. 51 Acknowledgements 53 This document is the result of the efforts of three IETF working 54 groups -- the IPAE working group, the SIP working group, and the SIPP 55 working group -- over a period of more than a year. The groups met a 56 number of times over this period and exchanged a great amount of 57 electronic mail. A number of individuals made significant 58 contributions. Bob Hinden devised the original IPAE encapsulation 59 scheme. Dave Crocker brought the idea of global addresses to IPAE. 60 Steve Deering brought the idea of a simple new version IP. And Paul 61 Francis contributed the advanced routing ideas of PIP. 63 The working groups have included contributions from: Craig Partridge 64 of BBN, Tom Kessler, Geoff Mulligan, Erik Nordmark, and Bob Gilligan 65 of Sun Microsystems, Greg Chesson, Ronald Jacoby, and and Rob Warnock 66 of Silicon Graphics, Hon Wah Chin and Dave Newman of Protocol Engines, 67 Ross Callon of Wellfleet, Mike Reilly of TGV, Virgil Champlin of 68 Digital Equipment, Michael Conn of MCI, John Moy of Proteon, John 69 Veizades of FTP software, Jeffrey Burgan of NASA, R. Govindan of 70 Bellcore, and Vince Fuller of BARRNET. 72 Thanks to all who provided feedback to the first revision of this 73 document, including Jim Bound, Jon Crowcroft, and (your name goes 74 here, after you send in your insightful comments and suggestions). 76 Status of this Memo 77 Acknowledgements 78 1. Introduction 79 1.1. Organization 80 2. Problem Statement 81 3. The IPAE Solution 82 3.1. IPAE Addressing 83 3.2. IPAE Tunneling: SIPP within IPv4 84 3.3. IPAE Host Operation 85 3.4. IPAE Header Translation 86 4. IPAE Routers 87 4.1. Multiple Routing Domains 88 4.2. Tunneling SIPP in IPv4 89 4.3. Encapsulating SIPP in IPv4 90 4.4. Decapsulating IPAE Packets 91 4.5. Tracking the Tunnel State 92 4.6. Generating ICMP Error Packets 93 5. IPAE Translators 94 5.1. Translating IPv4 to SIPP 95 5.2. Mapping Table 96 5.3. Translating SIPP to IPv4 97 5.4. SIPP and IPv4 Routing Configuration 98 5.5. Translation of Fragments 99 5.6. Knowing when to Translate 100 6. IPAE Hosts 101 6.1. What Packet Format to Send 102 6.2. Transport Pseudo-header Checksum 103 6.3. TCP and UDP Connection Identification 104 6.4. ICMP Error Messages 105 6.4.1. Sending ICMP Error Messages 106 6.4.2. Receiving ICMP Error Messages 107 6.5. Transport API changes 108 6.6. IP Addresses Embedded In Application Protocols 109 6.6.1. FTP 110 6.6.2. Mail (RFC 822) 111 6.6.3. Domain Name System (DNS) 112 6.6.4. SMI, MIB-II, Forwarding Table MIB 113 6.6.5. RARP, BOOTP, DHCP, Bootparams 114 6.6.6. BSD Talk Protocol 115 Appendix 1. Definitions 116 Appendix 2. The IPv4 to SIP Transition 117 Appendix 3. Examples 118 A3.1. IPAE Encapsulation 119 Appendix 4. Design Decisions 120 A4.1. The C-bit 121 A4.2. Global vs. Local Scope for C-bit 122 Appendix 5. Open Issues 123 A5.1. How is the DF Bit Handled? 124 A5.2. Should we Map IPv4 TOS bits into a Flow ID? 125 A5.3. How Should we Set the ID field? 126 A5.4. ICMP Error Message Handling? 127 A5.5 IPv4 Path MTU Discovery when Encapsulating 128 Security Considerations 129 References 130 Author's Address 132 1. Introduction 134 IPAE is designed to serve two purposes. First, it is the set of 135 mechanisms by which SIPP systems interoperate with systems that only 136 understand the current (version 4) version of IP. Secondly, it is the 137 means by which the operational Internet can transition to SIPP. The 138 transition mechanisms build on the interoperability features. 140 All SIPP hosts that support IPAE are able to interoperate with IPv4 141 hosts anywhere in the Internet. This feature minimizes the impact of 142 transition to SIPP on the users, since they may upgrade their hosts SIPP 143 at their own pace. 145 IPAE provides a similar "incremental upgrade" feature for routers. SIPP 146 traffic can be encapsulated within IPv4 packets and then routed by IPv4 147 routers. This leverages the existing IPv4 routing infrastructure. It 148 allows sites and the Internet backbone service providers to upgrade 149 their routers to SIPP in an incremental fashion. The IPv4 routers do 150 not need to be converted to SIPP at the same time. The Internet can 151 gain some of the benefits of SIPP after only a small number of the IPv4 152 routers are converted to SIPP. 154 IPAE also defines a mechanism by which IPv4 traffic may be carried by 155 the SIPP routing infrastructure, once it is constructed. This provides 156 complete global connectivity for IPv4 hosts up to the time when IPv4 157 addresses are no longer unique (i.e. when all of the IPv4 addresses are 158 assigned. After the time when IPv4 addresses run out, there is no 159 practical way to provide global IPv4 connectivity, although it may be 160 possible to continue selective connectivity for some IPv4 destinations.) 161 With this feature, IPAE provides service for those IPv4 hosts that can 162 not be upgraded to SIPP, or whose users' simply choose not to upgrade. 163 What's more, the IPv4 traffic being carried by the SIPP routing 164 infrastructure receives the same benefits of route scaling as the SIPP 165 traffic. 167 IPAE is a collection of protocols, mechanisms, and operational 168 procedures that are built upon SIPP. IPAE can be viewed as an add-on to 169 SIPP. It is being cast as a mechanism separate from SIPP with an eye 170 toward the time -- probably in the far distant future -- when the 171 Internet may no longer require interoperability between SIPP and IPv4 172 hosts and routers. At that time, the IPAE mechanisms can be retired, 173 and the IPAE software can be de-commissioned. 175 Another reason for separating the "IPv4 compatibility" features from the 176 core SIPP is that SIPP may be used in in environments in which there are 177 no IPv4 systems. There may be a desire in the short term for 178 "SIPP-only" hosts or routers in isolated settings. In order to 179 differentiate those SIPP-speaking systems that interoperate with IPv4 180 systems from those that do not, we offer the following definitions: A 181 "SIPP-only" host or router conforms to the SIPP specifications, but not 182 the IPAE specification. An IPAE host or router conforms to both the 183 SIPP specifications and the IPAE specification. Both IPAE and SIPP-only 184 systems can be referred to as "SIPP systems" since they both support 185 SIPP. 187 It is expected that for the foreseeable future, all of the SIPP systems 188 deployed on the Internet will need to interoperate with IPv4 systems. 189 Thus it is likely that most or all of the SIPP hosts or routers will 190 also be IPAE systems. 192 This paper assumes familiarity with SIPP. We recommend that readers 193 read the SIPP specification before reading this paper. 195 Finally, a word on the term "IPAE." IPAE was originally used as the 196 acronym for one of the IP next generation proposals. The IPAE working 197 group merged with the SIP working group, but the new group maintained 198 the IPv4 interoperability techniques developed in the former group. 199 After that, the SIP working group merged with the PIP working group to 200 form the SIPP group, again keeping the IPAE techniques. Today, IPAE is 201 no longer an acronym; it is simply a convenient term for the 202 interoperability and transition mechanisms originally developed in the 203 IPAE working group. 205 1.1. Organization 207 The remainder of this paper is organized as follows: 209 - Chapter 2 details the scaling problems that SIPP and IPAE were 210 designed to overcome. 212 - Chapter 3 gives an overview of IPAE. 214 - Chapters 4, 5, and 6 give detailed specifications and 215 requirements for the components of the IPAE network. 217 - The five appendices, A1 through A5, provide additional 218 details and background information. 220 The reader can gain an understanding of IPAE by reading chapters 2 and 221 3. Implementors should read chapters 4, 5, and 6 as well as the 222 appendices. 224 2. Problem Statement 226 Due to the widespread adoption the TCP/IP technology the Internet is 227 experiencing explosive growth, usually described as doubling every 12 228 months. There is no indication that this growth will reduce and 229 development of IP use into mass markets will create an even steeper 230 growth curve. The result is a crisis in IP router table storage and use 231 and in near-term exhaustion of available IP network numbers. 233 IP routers which record routes to all networks in the Internet must 234 maintain an entry for each such network, since the IP network address 235 space is flat. That is, neighboring networks do not necessarily have 236 any similarity in the IP network portion of their address. A new 237 address structure is required, so as to allow route-aggregation in table 238 entries to neighboring networks. Even Classless Inter-Domain Routing 239 [CIDR], which is reducing the size of the routing tables in the short 240 term, can not be guaranteed to solve this problem for an extended period 241 of time due to sites changing providers and policy constraints in the 242 backbone networks. 244 While the 32-bits of the IP address space theoretically can reference 245 about 4 billion nodes, the bits have been partitioned to facilitate 246 assignment and aggregation into networks. This reduces the realistic 247 maximum number of networks and hosts. While estimates vary 248 considerably, it is possible that IP network number exhaustion will 249 occur within the next few years. For example, IP could begin to make 250 penetrations in mass markets. Since the damage caused by being unable 251 to assign new IP network numbers is so great, it is prudent to pursue an 252 urgent path to increasing the number of networks. 254 SIPP and IPAE provide a solution to these problems. IPAE as the 255 transition mechanism for SIPP was designed around a number of objectives 256 to make the transition from IPv4 to SIPP as smooth as possible. These 257 objectives are: 259 - The transition to SIPP should cause as little impact as possible 260 on the end users of hosts. 262 - The transition to SIPP should leverage as much of the users' and 263 administrators' intangible investment in IPv4 operations, 264 training, terminology as possible. We should recognize that 265 users, administrators, and network operators have extensively 266 invested in "understanding" IPv4. That investment should not be 267 lost. 269 - The transition should be "asynchronous". Users and network 270 operators should be able to transition at their own pace. Users 271 should be able to upgrade hosts and routers incrementally. 273 - Sites which deploy IPAE should accumulate the benefits and 274 features of SIPP and IPAE as they deploy. For example a new 275 IPAE host should be able to use the SIPP auto-configuration 276 mechanisms immediately. The benefits should not be accrued only 277 after everyone else has deployed IPAE. 279 - The larger addresses of SIPP should be used to solve the 280 IPv4 route scaling problem early on in the transition. 282 - It must provide complete, global interoperability between SIPP 283 and IPv4 hosts for as long as IPv4 can provide global 284 interconnectivity. 286 - It should provide global connectivity for IPv4 traffic for as 287 long as possible. (Note that is only possible to maintain 288 global IPv4 connectivity only so long as IPv4 addresses are 289 unique. After "the day IPv4 address run out", it will no longer 290 be possible to have direct global IPv4 connectivity.) 292 - It should leverage the existing IPv4 routing infrastructure 293 wherever possible. 295 3. The IPAE Solution 297 The design of IPAE centers on four core elements: 299 - A 64-bit SIPP addressing plan that is compatible with the 300 current 32-bit IPv4 addressing plan. 302 - A mechanism for encapsulating SIPP traffic within IPv4 packets 303 for routing over parts of the Internet that have only IPv4 304 routers. 306 - Algorithms in IPAE hosts to know when they are communicating 307 with IPv4 hosts and format packets that are compatible. 309 - Use of "translation agents" to maintain global IPv4 310 connectivity. 312 Each of these elements is described in more detail below. 314 3.1. IPAE Addressing 316 We have defined a 64-bit SIPP addressing structure that is compatible 317 with the existing 32-bit IPv4 addressing structure. IPv4 compatible 318 SIPP addresses -- which we call "IPAE Addresses" -- have the following 319 features: 321 1) They have an IPv4 address embedded within them as the low-order 322 32 bits. 324 2) The state of the high-order bit -- which is termed the "C-bit" 325 -- encodes whether the entity the address identifies is capable 326 of processing the SIPP packet format. If the high-order bit of 327 an IPAE address is 0, the system that it represents is SIPP 328 capable. If the high-order bit is 1, the system may not be SIPP 329 capable. 331 3) The remaining 31 bits are used to uniquely identify and address 332 a new element of the Internet topology called an ``IPAE site.'' 334 As part of the introduction of IPAE, the Internet will be sub-divided 335 into a number of logical regions called ``IPAE sites.'' This is done 336 without changing any physical elements of the Internet; it is only a 337 logical organization of the existing topology. 339 The only requirement for an IPAE site is that IPv4 traffic must be 340 routed completely within the boundaries of each site. That is, all of 341 the routers within a site must continue to support IPv4 and must be 342 capable of routing to all IPv4 destinations within the site. (Routers 343 within a site MAY also support SIPP, in which case they are IPAE 344 routers; but they MUST support IPv4. Also, the routers may be able to 345 route IPv4 traffic directly to destinations outside of the site, but 346 this is not required in order to qualify as an IPAE site.) 348 Each IPAE site is assigned a unique 31-bit ``site prefix,'' which is 349 used in the high-order bits of the IPAE addresses of all hosts and 350 routers within that site. A hierarchal structure may be defined for 351 site prefixes, but details of their structure is outside the scope of 352 this paper. 354 Thus 64-bit IPAE addresses have the following structure: 356 6 3 3 0 357 3 2 1 0 358 +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ 359 |C| Site Prefix | IPv4 Address | 360 +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ 362 An IPAE address has three components: 364 C-bit Encodes whether the entity addressed supports 365 SIPP or not. 367 Site Prefix Uniquely identifies the site that the 368 addressed entity is located in. 370 IPv4 Address Uniquely identifies the addressed entity. 372 64-bit IPAE addresses can be assigned to both IPAE and IPv4 hosts and 373 routers. While an IPv4 host or router only ``knows'' its IPv4 address 374 (the low-order 32-bits of its IPAE address), it may have an IPAE address 375 assignment, which may be listed in the DNS. 377 Once an IPAE site has been defined and assigned a site prefix, all 378 existing IPv4 hosts and routers located within that site can be given 379 IPAE address assignments. This assignment is straightforward, since the 380 IPv4 hosts' and routers' addresses are derived from their previously 381 assigned IPv4 addresses. Specifically, IPAE addresses for IPv4 hosts 382 and routers can be assigned as follows: 384 C-bit = 1. 386 Site Prefix = prefix assigned to this site. 388 IPv4 Address = IPv4 address assigned to this host or router. 390 When a new IPv4 host or router is introduced into a site, it is first 391 assigned an IPv4 address that is consistent with the IPv4 addressing plan 392 employed within the site. Then, an IPAE address is assigned to the host 393 in the same manner as pre-existing IPv4 hosts. 395 When an IPAE host is introduced into a site, it is also first assigned 396 an IPv4 address that is consistent with the IPv4 addressing plan 397 employed within the site. It is then assigned an IPAE address as 398 follows: 400 C-bit = 0. 402 Site Prefix = prefix assigned to this site. 404 IPv4 Address = IPv4 address assigned to this host. 406 When an IPv4 host within a site is upgraded to support SIPP (i.e. it 407 becomes an IPAE host), the C-bit in the host's IPAE address is changed 408 from 1 to 0. 410 As long as IPv4 addresses remain unique in the Internet (that is, until 411 the time when IPv4 addresses "run out"), the IPv4 address portion of 412 IPAE addresses will be sufficient to uniquely identify a host or router. 414 3.2. IPAE Tunneling: SIPP within IPv4 416 IPAE hosts and routers use the IPAE tunneling technique to carry SIPP 417 packets over regions of the Internet that route only IPv4 packets. In 418 IPAE tunneling, the end-to-end SIPP datagram is encapsulated within an 419 IPv4 datagram. An IPAE tunnel may extend through only part of the 420 end-to-end path (e.g. between two IPAE routers), or may be used for the 421 entire path between two IPAE hosts (e.g. when the only routers along 422 the path are IPv4). On its journey from source host to destination 423 host, a SIPP datagram may be routed through one IPAE tunnel, many IPAE 424 tunnels, or none at all. 426 We use the term "IPAE packet format" to describe a SIPP datagram 427 encapsulated within an IPv4 header. The IPAE packet format is shown 428 below, along with the IPv4 and SIPP packet formats for comparison: 430 +------------+ +------------+ +------------+ 431 | IPv4 | | IPv4 | | SIPP | 432 | Header | | Header | | Header | 433 +------------+ +------------+ +------------+ 434 | Transport | | SIPP | | Transport | 435 | Layer | | Header | | Layer | 436 | Header | +------------+ | Header | 437 +------------+ | Transport | +------------+ 438 | | | Layer | | | 439 ~ Data ~ | Header | ~ Data ~ 440 | | +------------+ | | 441 +------------+ | | +------------+ 442 ~ Data ~ 443 | | 444 +------------+ 446 IPv4 Packet IPAE Packet SIPP Packet 447 Format Format Format 449 In the IPAE packet format, the IPv4 source and destination addresses 450 identify the "endpoints of the tunnel." The SIPP source and destination 451 addresses identify the end hosts -- the sender and recipient of the 452 datagram. 454 The IPv4 routers on the "interior" of a tunnel route the packet based on 455 its IPv4 header. The IPAE router at the end of a tunnel decapsulates 456 the packet and routes it based on the SIPP header. 458 When an IPAE host or router composes a packet in the IPAE format, it 459 sets the IPv4 Time To Live (TTL) field to be the same as the SIPP Hop 460 Limit. When an IPAE router receives a packet in the IPAE format, it 461 copies the IPv4 TTL into the SIPP hop limit field and subtracts one. 462 Thus IPv4 "hops" are counted in the SIPP hop limit. 464 It is possible that one of the IPv4 routers along the tunnel interior 465 might encounter an error while processing an IPAE packet, causing it to 466 return an IPv4 ICMP error message to the source endpoint of the tunnel. 467 The three types of ICMP errors that can occur in this circumstance are: 469 - Packet too big. 470 - Time Exceeded. 471 - Destination Unreachable. 473 Unfortunately, the ICMP spec only requires IPv4 routers to return 8 474 bytes (64 bits) of the packet beyond the IPv4 header. This is not enough 475 to include the SIPP source address, so it is not generally possible for 476 an IPAE router to immediately reflect a SIPP ICMP message back to the 477 source host when it receives an IPv4 ICMP message from the interior of a 478 tunnel. 480 However, by carefully maintaining "soft state" about its tunnels, an 481 IPAE router can return accurate SIPP ICMP messages in most cases. An 482 IPAE router should maintain at least the following soft state 483 information about each tunnel: 485 - MTU of the tunnel. 486 - TTL (path length) of the tunnel 487 - Reachability of the end of the tunnel. 489 An IPAE router uses the IPv4 ICMP messages it receives from the interior 490 of a tunnel to update the soft state information for that tunnel. When 491 subsequent SIPP packets that would transit the tunnel arrive, the router 492 checks the soft state for the tunnel. If the packet would violate the 493 state of the tunnel (e.g. packet would be larger than the tunnel MTU; 494 the SIPP hop limit is less than the tunnel TTL) the router sends a SIPP 495 ICMP error message back to the source, but also forwards the packet into 496 the tunnel. 498 Using this technique, the SIPP ICMP error messages sent by IPAE routers 499 may not alway match up one-to-one with errors encountered by IPv4 500 routers, but they will accurately reflect the state of the network. 502 3.3. IPAE host operation. 504 The requirements on IPAE hosts can be expressed as three simple rules: 506 1) IPAE hosts accept packets in the IPv4 format. 508 2) IPAE hosts transmit packets in the IPv4 format when sending to 509 IPv4 hosts within the same site. 511 3) IPAE hosts use the IPv4 transport connection-identification and 512 pseudo-header checksum algorithms when communicating with IPv4 513 hosts. 515 IPAE hosts need to be able to communicate with IPv4 hosts within their 516 "site" without the help of any other agents. This is important so that 517 the first IPAE systems deployed at a site will immediately interoperate 518 with the deployed IPv4 hosts and routers without the need to first 519 deploy IPAE routers or translation agents. 521 The three rules above will guarantee that IPAE hosts always send IPv4 522 format packets to IPv4 hosts within their sites and that the IPv4 523 packets that the IPv4 hosts send back will be handled properly. IPAE 524 hosts can use the C-bit of the destination address, along with knowledge 525 of the site prefix of the outgoing interface, to determine whether a 526 destination address is located within the same site, and whether it is 527 an IPv4 host or not. 529 IPAE hosts can use the IPv4 packet format when sending to IPv4 hosts in 530 the local site because IPv4 is always routed within a site. But since 531 IPv4 traffic may not be routed globally, IPAE hosts must use the SIPP 532 packet format when sending to IPv4 hosts in remote sites. The IPAE 533 translator (described in the next section) in the remote site will take 534 care of translating the packet into IPv4 format before it is delivered 535 to the destination IPv4 host. Thus packets for all hosts in remote 536 sites can be sent in the SIPP format. 538 When sending to IPv4 hosts, IPAE hosts must calculate the 539 transport-layer pseudo-header checksum in such a way that it will be 540 accepted by the IPv4 host. Similarly, when receiving packets from IPv4 541 hosts, the IPAE host must calculate the checksum in a way that a 542 correctly generated packet will be accepted. This means that only the 543 low-order 32 bits of the SIPP address are used in the pseudo-header 544 calculation when communicating with IPv4 hosts. 546 Also, the connection identification logic in the transport layer of the 547 IPAE host must associate packets received from IPv4 hosts with the 548 correct connection state. This means that IPAE hosts only use the 549 low-order 32 bits of the SIPP addresses in the connection identification 550 algorithm when communicating with IPv4 hosts. 552 3.4. IPAE Header Translation 554 IPAE translation agents, also called "IPAE translators", provide global 555 IPv4 connectivity once IPv4 is no longer routed globally. They do this 556 by translating the Internet headers of all intra-site IPv4 traffic. 558 Each site is equipped with at least one IPAE translator whose job it is 559 to: 561 1) Translate the IPv4 headers of all IPv4 traffic that is generated 562 within the site, and is addressed to destinations in remote 563 sites, into SIPP headers. The resulting SIPP packets are then 564 forwarded into the SIPP routing system, where they are routed 565 based on their full 64-bit SIPP destination addresses. 567 2) Translate the SIPP headers of all SIPP traffic that is sent from 568 remote sites, and is addressed to IPv4 destinations in the local 569 site, into IPv4 headers. The resulting IPv4 packets are then 570 forwarded into the IPv4 routing system within the site for 571 delivery to the destination IPv4 host. 573 The IPAE translators operate only on the Internet headers of packets. 574 They never look beyond the SIPP or IPv4 headers into the transport layer 575 headers or application data. The interoperation of IPAE and IPv4 576 systems using application layer protocols that carry IPv4 addresses is 577 addressed in section 6.6. 579 In order to perform task (1) above, the IPAE translator must map the 580 destination IPv4 address of the packet into a 64-bit SIPP address. This 581 is done with the help of a mapping table. The mapping table maps IPv4 582 destination addresses into 32-bit prefixes. The prefix is prepended to 583 the 32-bit IPv4 destination address to compose a complete 64-bit SIPP 584 which is stored in the SIPP header. 586 In order to efficiently encode mapping information, the entries in the 587 table are keyed by a 32-bit mask and 32-bit IP address. The mask + 588 address are associated with a 32-bit SIPP address prefix. For example, 589 this entry: 591 mask address SIPP address prefix 592 ---- ------- -------------------- 593 255.255.0.0 129.144.0.0 1404:1:0.0.0.0 595 states that all destination addresses with the high order 16 bits equal 596 to "129.144" should be given the prefix 1404:1. 598 4. IPAE routers 600 We call a router that understands both the IPv4 and SIPP packet 601 formats, and participates in both the IPv4 and SIPP routing protocols 602 an IPAE router. 604 Each site must have at least one IPAE router that 605 participates in both the IPv4 routing system within the site, and the 606 global SIPP routing system. 608 In addition to participating in multiple routing domains the IPAE router 609 has to be able to tunnel SIPP datagrams by encapsulating them in Ipv4 610 packets. 612 Finally, IPAE routers have to generate ICMP errors containing an 613 "offending packet" that the recipient of the ICMP error can understand. 615 4.1 Multiple routing domains 617 In addition to participating the SIPP routing system, an IPAE router has 618 to be capable of participating in multiple IPv4 routing domains. This is 619 required since each interface potentially belongs in a separate routing domain, 620 and after IPv4 addresses "run out" the IPv4 addresses will only be unique 621 within each routing domain/site. This implies that the router has to maintain 622 logically separate IPv4 routing tables for each domain/site and be able 623 to send return packets back to the correct site. This can be implemented by 624 tagging each incoming IPv4 packet with the address prefix (with the C-bit set) 625 of the interface in arrived on. 627 4.2 Tunneling SIPP in IPv4 629 IPAE routers, as well as IPAE hosts, tunnel SIPP datagrams by encapsulating 630 the in IPv4 packets. The tunneling mechanism consists of: 632 - The entry router of the tunnel (the encapsulating router) creating 633 an encapsulating IPv4 header. 635 - The exit router of the tunnel (the decapsulating router) 636 removing the IPv4 header and updating the SIPP header. 638 - The encapsulating router maintaining soft state for each tunnel 639 in order to generate SIPP ICMP errors. 641 There are two sets of tunnels used in IPAE: 643 - configured tunnels between IPAE routers. 645 - implicit tunnels i.e. where the IPv4 addresses of the tunnel 646 endpoint is the 32 low-order bits of the SIPP destination 647 address. 649 The configured tunnels could be set up either manually or by a routing 650 protocol. The implicit tunnels are always present. A host with an 651 address prefix of A has implicit tunnels to all SIPP addresses that share 652 the A prefix. An IPAE router with an interface to a site with address prefix A 653 also has implicit tunnels to all SIPP address with the A prefix. 655 Thus there will potentially exist a very large number of implicit tunnels 656 in IPAE hosts and IPAE routers. Therefore the state associated with the 657 tunnels should be kept cache so that it can be discarded when no longer 658 used and later recreated. 660 4.3 Encapsulating SIPP in IPv4 662 The encapsulating header should have the Don't Fragment bit set in order 663 for the tunnel entry point to discover the tunnel mtu. The SIPP hop limit 664 field is copied into the IPv4 TTL field. 666 Either the SIPP hop limit must be decremented by one before the 667 packet is encapsulated, or the IPv4 TTL must be decremented by one after 668 the encapsulation (as part of the normal forwarding mechanism). 670 SIPP routers, in general, do not fragment SIPP datagrams that exceed 671 the MTU even if the datagram contains a fragmentation header. Thus, in 672 particular, there is no need for an encapsulating router to perform any 673 fragmentation. 675 +-------------+ 676 | IPv4 | 677 | Header | 678 +-------------+ +-------------+ 679 | SIPP | | SIPP | 680 | Header | | Header | 681 +-------------+ +-------------+ 682 | Transport | | Transport | 683 | Layer | ===> | Layer | 684 | Header | | Header | 685 +-------------+ +-------------+ 686 | | | | 687 ~ Data ~ ~ Data ~ 688 | | | | 689 +-------------+ +-------------+ 691 SIPP Encapsulation in IPv4 693 When encapsulating a SIPP datagram in an IPv4 datagram, the IPv4 header fields 694 are set as follows: 696 Version: 698 4 700 IP Header Length in 32-bit words: 702 5 (There are no IPv4 options in the encapsulating header.) 704 Type of Service: 706 0 708 Total Length: 710 Payload length from SIPP header plus length of SIPP and 711 IPv4 headers (i.e. a constant 44 bytes) 713 Identification: 715 Generated uniquely as for any IPv4 packet transmitted 716 by the host function in the system. 718 Flags: 720 Set the Don't fragment flag. 722 Fragment offset: 724 0. 726 Time to Live: 728 Copied from the SIPP hop limit field. 730 Protocol: 732 41 (Assigned payload type number for SIPP) 734 Header Checksum: 736 Calculate the header checksum. 738 Source Address: 740 IPv4 address of outgoing interface. 742 Destination Address: 744 IPv4 address of remote end of tunnel. 746 Any SIPP options are preserved in the packet (after the SIPP header). 748 4.4 Decapsulating IPAE packets 750 When a host or a router receives an IPv4 datagram destined to one of 751 its IPv4 address with the protocol field set to 41 it must decapsulate the 752 packet. 754 When decapsulating such IPAE packets the SIPP hop limit is set to the 755 IPv4 TTL. The SIPP hop limit must be decremented by one after the 756 packet has been decapsulated (as part of the normal SIPP forwarding 757 mechanism.) 759 +-------------+ 760 | IPv4 | 761 | Header | 762 +-------------+ +-------------+ 763 | SIPP | | SIPP | 764 | Header | | Header | 765 +-------------+ +-------------+ 766 | Transport | | Transport | 767 | Layer | ===> | Layer | 768 | Header | | Header | 769 +-------------+ +-------------+ 770 | | | | 771 ~ Data ~ ~ Data ~ 772 | | | | 773 +-------------+ +-------------+ 775 Decapsulating SIPP from IPv4 777 When decapsulating the IPAE packet only one field in the SIPP header is 778 modified: 780 Hop Limit: 781 TTL value copied from the encapsulating IPv4 header. 783 Then the encapsulating IPv4 header is dropped. 785 4.5 Tracking the tunnel state 787 Tunnels are "traceroute visible" i.e. a traceroute program running on 788 a SIPP or IPv4 host will report all the routers internal to the tunnel. 789 This is accomplished by copying the TTL from the SIPP header into 790 the encapsulating IPv4 header plus maintaining soft state about the tunnel 791 in the encapsulating router. 793 The soft state for the tunnel is based the ICMP errors that are received 794 from IPv4 routers interior to the tunnel. This tunnel state is associated 795 with the IPv4 address of the endpoint of the tunnel and consists of: 797 - Tunnel MTU. 799 - Path length of the tunnel (number of hops). 801 - For each TTL 't' between 1 and the path length of the tunnel, 802 the IPv4 address of the router that was last known to be 't' 803 hops into the tunnel. 805 - Reachability of the end of the tunnel. 807 - The IPv4 address of the router reporting unreachability. 809 The tunnel state does not have to be allocated until 810 an ICMP error is received; in the absence of tunnel state the tunnel 811 MTU is assumed to be the MTU of the outgoing interface, the path length 812 one hop and the endpoint being reachable. 814 When a datagram is encapsulated the router consults the tunnel state 815 to check if the packet is likely to generate an ICMP error from 816 a router interior to the tunnel. In such a case (e.g. packet size 817 greater than the tunnel MTU) the router generates the appropriate 818 ICMP error and also forwards the packet into the tunnel. Any ICMP error 819 caused by the forwarded packet will refresh the tunnel state. 821 When the encapsulator receives an ICMP errors destined to one of its IPv4 822 addresses where the "offending packet" is IPv4 with the IP protocol field being 823 41, it updates the tunnel state associated with the IPv4 destination 824 in the "offending packet". The update depends on the type of ICMP error: 826 - Host or network unreachable: Mark the tunnel endpoint as 827 unreachable and record the source of the ICMP error as the 828 source of unreachability. 830 - Time exceeded in transit: The TTL "consumed" before reaching the 831 router that send the time exceeded message is extracted from the 832 SIPP hop limit field in the "offending packet" (the SIPP hop 833 limit field is in the first 8 bytes of the SIPP header thus it 834 will be returned in the ICMP packet). Compute the updated tunnel 835 path length as the maximum of the currently recorded path length 836 and the extracted SIPP hop limit. Record the source of the ICMP 837 error as the router at 'SIPP hop limit' hops into the tunnel. 839 - "Packet too big": If the ICMP packet contains the MTU (see RFC 840 1191) update the tunnel MTU to be that value. If the ICMP packet 841 does not contain the MTU use the IPv4 Total length field in the 842 "offending packet" and the recommended plateaus in RFC 1191 to 843 compute the new MTU for the tunnel. Note that this can either 844 increment or decrement the recorded tunnel mtu. 846 - For all other ICMP errors log a network management event. 848 When the encapsulator forwards a packet into the tunnel it performs 849 the following checks against the tunnel state: 851 - If the tunnel endpoint is unreachable it generates a SIPP ICMP 852 network unreachable with the source address being the recorded 853 router that reported the unreachability. The address is extended 854 to 64 bits by using the 32 bit prefix of the tunnel's outgoing 855 interface with the C-bit set. 857 - If the hop limit is less than the recorded tunnel ttl it 858 generates a SIPP ICMP time exceeded in transit with the source 859 address being the recorded router address that is 'hop limit' 860 hops into the tunnel. If there is no router address recorded 861 for the specified hop limit, the router generates an ICMP time 862 exceeded with a source address of 127.0.0.1. The recorded 863 addresses are expanded to 64 bits just like for network 864 unreachables. 866 - If the MTU exceeds the recorded tunnel mtu it generates a SIPP 867 ICMP "packet too big" with itself as the source and setting the 868 returned MTU to the recorded tunnel mtu minus the size of the 869 IPv4 header (20 bytes). (The 20 byte adjustment is needed since 870 the packets will "expand" by 20 bytes when being encapsulated.) 872 In all of the above cases the datagram is also forwarded into the tunnel. 874 The mechanism described so far does not detect when an error 875 condition in the tunnel is lifted (e.g. the tunnel endpoint becomes 876 reachable or when the tunnel path length decreases). The simple 877 solution to detecting such "improvements" is to periodically 878 discard the recorded tunnel state. More elaborate schemes can be 879 envisioned, such as counting the number of 1) datagrams that should 880 have generated a certain ICMP error and 2) the actual number of such 881 ICMP errors received, and discarding the state when the ratio between 882 them exceeds some value. 884 4.6 Generating ICMP error packets 886 IPAE routers, as well as IPAE hosts, have to generate ICMP error packets 887 that the receiving host or router can decode. The possible formats for 888 the "offending packet" in the ICMP errors are: 890 - A SIPP header followed by the transport header (with possibly 891 SIPP option headers between the SIPP header and the transport 892 header) 894 - An IPv4 header followed by the transport header. 896 The first format is used when the C-bit is not set in the source address 897 in the offending packet. The second format is used when the C-bit is set 898 in the source address. 900 When the IPAE router or host receives a SIPP datagram and it has to generate 901 an ICMP error in the second format it creates, for the sole purpose of the 902 ICMP error, an IPv4 header derived from the SIPP header including any SIPP 903 option headers. 905 +-------------+ +-------------+ 906 | SIPP | | IPv4 | 907 | Header | | Header | 908 +-------------+ +-------------+ 909 | Transport | | Transport | 910 | Layer | ===> | Layer | 911 | Header | | Header | 912 +-------------+ +-------------+ 913 | | | | 914 ~ Data ~ ~ Data ~ 915 | | | | 916 +-------------+ +-------------+ 918 ICMP "offending packet" conversion 920 When generating the IPv4 header from the SIPP header, the IPv4 header fields 921 are set as follows: 923 Version: 925 4 927 IP Header Length in 32-bit words: 929 5 931 Type of Service: 933 0 935 Total Length: 937 Payload length from SIPP header minus length of any SIPP 938 optional headers plus length of the IPv4 header. 940 Identification: 942 If SIPP fragmentation option is present, copy low-order 943 16 bits from ID field. Otherwise set to zero. 945 Flags: 947 If SIPP fragmentation option is not present, set the 948 Don't fragment flag. 950 Fragment offset: 952 0. (Only the first fragment will generate ICMP errors.) 954 Time to Live: 956 Copy from the SIPP hop limit field. 958 Protocol: 960 Payload type value copied from SIPP header or, if known 961 SIPP options are present, from last SIPP option header. 963 Header Checksum: 965 Calculate the header checksum. 967 Source Address: 969 Copy the low-order 32-bits of the SIPP source address. 971 Destination Address: 973 Copy the low-order 32 bits of the SIPP destination 974 address. 976 The IPv4 header is immediately followed by the transport header i.e. any 977 SIPP option headers are ignored. 979 5. IPAE Translators. 981 IPAE translators perform the task of translating intra-site IPv4 982 traffic between the IPv4 and SIPP packet formats so that it can be 983 carried over the SIPP backbone. IPv4 traffic originating within the 984 site is translated into the SIPP format and then forwarded into the 985 SIPP backbone. SIPP traffic to IPv4 destinations within the site is 986 translated into the IPv4 format, and then forwarded into the IPv4 987 routing system within the site. 989 Each site must have at least one IPAE translator. Additional IPAE 990 translators can be deployed within a site to provide fault tolerance 991 and robustness. 993 IPAE translators only operate on the SIPP and IPv4 headers of packets. 994 They never look beyond the Internet headers into the transport layer 995 headers or application data. 997 The function of the IPAE translator does not have to reside in a 998 dedicated machine. It may be co-resident in a machine that also has 999 another function, such as the IPAE border router. 1001 This work of the IPAE translator consists of five separate tasks: 1003 - Translating IPv4 packets into SIPP format. 1005 - Maintaining a table to map IPv4 addresses into SIPP address 1006 prefixes. 1008 - Translating SIPP packets into IPv4 format. 1010 - Participating in IPv4 routing within the site, and global SIPP 1011 routing. 1013 - Knowing when to translate IPv4 into SIPP and SIPP into IPv4. 1015 The rest of this section details each of these tasks. 1017 5.1 Translating IPv4 to SIPP 1019 When an IPAE translator receives an IPv4 datagram addressed to a 1020 destination in a remote site, it translates the IPv4 header of that 1021 packet into a SIPP header, and then forwards the packet based on the 1022 SIPP destination address. The original IPv4 header on the packet is 1023 removed and replaced by a SIPP header; The transport layer header and 1024 data portion of the packet are left unchanged. 1026 +-------------+ +-------------+ 1027 | IPv4 | | SIPP | 1028 | Header | | Header | 1029 +-------------+ +-------------+ 1030 | Transport | | Transport | 1031 | Layer | ===> | Layer | 1032 | Header | | Header | 1033 +-------------+ +-------------+ 1034 | | | | 1035 ~ Data ~ ~ Data ~ 1036 | | | | 1037 +-------------+ +-------------+ 1039 IPv4 to SIPP Header Translation 1041 After the IPv4 header has been translated into a SIPP header, the packet 1042 may be further encapsulated within an IPv4 header if the next hop is via 1043 an IPv4 router. 1045 When translating from the IPv4 format into SIPP, the SIPP header fields 1046 are set as follows: 1048 Version: 1049 6 1051 Flow ID: 1052 0 (all zero bits) 1054 Payload Length: 1055 Total length value from IPv4 header, minus the size of 1056 the IPv4 header and IPv4 options, if present. 1058 Payload Type: 1059 Protocol field copied from IPv4 header 1061 Hop Limit: 1062 TTL value copied from IPv4 header, decremented by one. 1064 High-order 32 bits of Source Address: 1065 C-bit: 1 1066 Site Prefix: Prefix of the local site. 1068 Low-order 32 bits of Source Address: 1069 Source address copied from IPv4 header. 1071 High-order 32 bits of Destination SIPP address: 1072 Mapping table entry for IPv4 destination address. 1074 Low-order 32 bits of Destination SIPP address: 1075 Destination address copied from IPv4 header. 1077 If IPv4 options are present in the IPv4 packet, they are dealt with as 1078 follows: 1080 No Operation (Type = 1) 1082 This option is used only for padding. It is ignored. 1084 Security (Type = 130) 1086 The RFC 791 security option is obsolete. It is ignored. 1088 Strict Source and Record Route (Type = 137) 1090 Since SIPP does not support the Strict Source route 1091 model, this option can not be translated into SIPP. 1092 If this option is present, the packet must be dropped, 1093 and an IPv4 ICMP destination unreachable message back 1094 to the source. 1096 Loose Source and Record Route (Type = 131) 1098 The IPv4 LSRR option can be translated into the SIPP 1099 Route option. The payload type in the SIPP header is 1100 set to the number assigned to the SIPP route option. 1101 The fields of the SIPP route option are set as follows: 1103 Payload Type: 1104 Protocol field copied from IPv4 header. 1106 Number of addresses, n: 1107 Number of IPv4 addresses in the IPv4 LSRR option. 1109 Next Address, i: 1110 The number of the IPv4 address pointed to by the 1111 pointer field LSRR option. For example, if the 1112 pointer field points to the first IPv4 address 1113 in the LSRR option, then the Next Address field 1114 is set to 1. If the pointer field points past 1115 the end of the route data, then the Next Address 1116 field is set to the same value as the Number of 1117 Addresses field. 1119 For each of address 1 through j in the LSRR route data, 1120 set the value of the corresponding SIPP address in the 1121 SIPP Route Options as follows: 1123 High-order 32 bits of SIPP address [j]: 1124 Mapping table entry for LSRR option address [j] 1126 Low-order 32 bits of SIPP address [j]: 1127 LSRR option address [j] 1129 Record Route (Type = 7) 1131 Since SIPP does not provide a record route option, this 1132 option is ignored. 1134 Stream Identifier (Type = 136) 1136 This Stream Identifier option is obsolete. It is 1137 ignored 1139 Internet Timestamp (Type = 68) 1141 Since SIPP does not provide a timestamp option, this 1142 option is ignored. 1144 All other IPv4 options 1146 If any other IPv4 options are present, they are ignored. 1148 By "ignored", we mean that the option is not processed, and no further 1149 action is taken on it. The translated SIPP packet is forwarded and no 1150 ICMP error message is sent back to the source host. 1152 If the IPv4 packet is a fragment (i.e. if either the More Fragments bit 1153 is set, or the fragment-offset field of the packet is non-zero), then a 1154 SIPP fragmentation option is added to the packet. The payload type in 1155 the SIPP header should be set to the number assigned to the 1156 fragmentation option. The fields of the SIPP fragmentation option 1157 should then be set as follows: 1159 Payload Type: 1161 Protocol field copied from IPv4 header. 1163 More bit: 1165 More fragments bit copied from IPv4 header. 1167 Fragment offset: 1169 Fragment Offset value copied from IPv4 header. 1171 High-order 16 bits of the Identification field: 1173 0 (all zero bits) 1175 Low-order 16 bits of the Identification field: 1177 Value of the identification field copied from IPv4 1178 header. 1180 5.2 Mapping Table 1182 IPAE Translators must implement a mapping table to map IPv4 addresses 1183 into 32-bit SIPP address prefixes. The mapping table is used in the 1184 process of translating IPv4 packets into SIPP headers. The destination 1185 address in the IPv4 packet is looked up in the mapping table. If a 1186 matching entry is found, the 32-bit prefix in that entry is prepended to 1187 the 32-bit IPv4 address to form a complete 64-bit SIPP address for the 1188 destination. This address is then used as the destination address of 1189 the SIPP header that is formed. 1191 The 64-bit SIPP address that is formed for the destination is also an 1192 IPAE address. Thus the 32-bit prefix in the mapping table covers the 1193 C-bit and the Site Prefix fields of the IPAE address: 1195 6 3 3 0 1196 3 2 1 0 1197 +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ 1198 |C| Site Prefix | IPv4 Address | 1199 +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ 1201 ^ ^ ^ 1202 | 32-bit prefix from | IPv4 address | 1203 | the mapping table | from the original | 1204 | | IPv4 packet | 1206 In order to aggregate a large number of address mappings into a single 1207 entry, the "key" in each mapping table entry should consist of a 32-bit 1208 IPv4 address and a 32-bit mask. The "value" information in the mapping 1209 table is the 32-bit SIPP address prefix. A destination IPv4 address 1210 "matches" a mapping table entry if the destination address, logically 1211 and-ed with the key mask, equals the key address. More than one entry 1212 may match. The lookup process uses a "longest match" algorithm to 1213 locate the best matching entry in the mapping table. If more than one 1214 matching entry exist in them mapping table, the entry with the longest 1215 mask is the one that is used. 1217 Here is an example of a mapping table entry: 1219 Key mask Key address ==> SIPP address prefix 1220 -------- ----------- ------------------- 1221 255.255.0.0 129.144.0.0 ==> 9404:3 1223 It is important that the C-bit field of the prefixes in the mapping 1224 table entries be set correctly. The mapping table must be configured so 1225 that the IPAE addresses composed for IPv4 destinations always have the 1226 C-bit set to 1. This will cause an IPAE translator in the destination 1227 site to translate the packet into the IPv4 form before it is transmitted 1228 to the destination IPv4 host. 1230 The C-bit of the prefixes for IPAE hosts is less critical because IPAE 1231 hosts accept packets in either the SIPP, IPAE, or IPv4 packet format. 1232 If the C-bit is set to 1, packets will be delivered in the IPv4 form; if 1233 the C-bit is set to 0, packets will be delivered in SIPP form. The 1234 traffic will be sub-optimal if the C-bit is 1, since it will undergo an 1235 unnecessary translation into the IPv4 form. But in order to condense 1236 the size of the mapping table, it may be desirable to have some entries 1237 that produce addresses for IPAE hosts with the C-bit set to 1. 1239 Once a prefix is assigned for a site, it likely will not need to be 1240 changed often. For that reason, the mapping table will be continually 1241 growing, but the individual entries, once added to the table, will 1242 change only rarely. For that reason, we do not need a highly dynamic 1243 mechanism to distribute the mapping table to the IPAE translators. 1245 In the initial deployment of IPAE and SIPP, the mapping table for the 1246 entire Internet will be maintained at a central site and distributed 1247 to all of the IPAE translators on a regular basis via FTP. The 1248 mapping table will be kept in a file on the central site, and the IPAE 1249 translators will "pull" the file with FTP. Each IPAE translator can 1250 set its own schedule to pull the mapping table. 1252 The central server from which the mapping table is FTP'ed must be an 1253 IPAE system. It can not be an IPv4 system. This is required so that 1254 the FTP traffic between the IPAE translators and the central sites does 1255 not depend on the correct operation of the IPAE translators 1256 themselves. 1258 5.3 Translating SIPP to IPv4 1260 When an IPAE translator receives a SIPP datagram addressed to an IPv4 1261 destination in the local site, it translates the SIPP header of that 1262 packet into an IPv4 header, and then forwards the packet based on the 1263 IPv4 destination address. The original SIPP header on the packet is 1264 removed and replaced by an IPv4 header; the transport header and data 1265 portion of the packet are left unchanged. 1267 +-------------+ +-------------+ 1268 | SIPP | | IPv4 | 1269 | Header | | Header | 1270 +-------------+ +-------------+ 1271 | Transport | | Transport | 1272 | Layer | ===> | Layer | 1273 | Header | | Header | 1274 +-------------+ +-------------+ 1275 | | | | 1276 ~ Data ~ ~ Data ~ 1277 | | | | 1278 +-------------+ +-------------+ 1280 SIPP to IPv4 Header Translation 1282 When translating from the SIPP format into IPv4, the IPv4 header fields 1283 are set as follows: 1285 Version: 1287 4 1289 IP Header Length in 32-bit words: 1291 5 plus length of IPv4 options, if added (see below) 1293 Type of Service: 1295 0 1297 Total Length: 1299 Payload length from SIPP header plus length of IPv4 1300 header and options, if added (see below). 1302 Identification: 1304 If SIPP fragmentation option is present, copy low-order 1305 16 bits from ID field. Otherwise generate a unique 1306 value for every packet. 1308 Flags: 1310 If SIPP fragmentation option is present, set MF bit if 1311 More bit is set in option. If the SIPP fragmentation 1312 option is not present, and the C-bit is set in the 1313 source address, then set the DF bit. 1315 Fragment offset: 1317 If SIPP fragmentation option is present, copy the 1318 fragment offset value from the option. 1320 Time to Live: 1322 Hop limit field copied from the SIPP header. 1324 Protocol: 1326 Payload type value copied from SIPP header or, if known 1327 SIPP options are present, from last SIPP option header. 1329 Header Checksum: 1331 Calculate the header checksum. 1333 Source Address: 1335 Copy the low-order 32-bits of the SIPP source address. 1337 Destination Address: 1339 Copy the low-order 32 bits of the SIPP destination 1340 address. 1342 If any end-to-end SIPP options are present, they are handled as follows: 1344 Fragmentation option: 1346 Copy the values from the option into the IPv4 header as 1347 described above. 1349 Route option: 1351 The SIPP Route option can be translated into 1352 an IPv4 LSRR option. The option values are set 1353 as follows: 1355 Length: 1357 3 + 4 * (number of addresses) 1359 Pointer: 1361 3 + 4 * (next address) 1363 Route data: 1365 Low-order 32 bits of each address in the SIPP 1366 Route option. 1368 All others: 1370 The above two options are the only SIPP options defined 1371 at the time this document was written. Since SIPP 1372 encodes end-to-end options using payload type codes, the 1373 codes for new options will be indistinguishable from 1374 those of transport layer protocols. Packets with 1375 unknown payload type codes should be translated and 1376 forwarded. When new SIPP options are defined, the 1377 specification should detail how they should be handled 1378 by IPAE translators. 1380 As of this writing, no hop-by-hop SIPP options are defined. Thus none 1381 of the hop-by-hop options can be translated into IPv4. If the 1382 hop-by-hop options payload type is given in the SIPP header, the IPAE 1383 translator must parse the hop-by-hop options and abide by the "action 1384 code" encoded into the low order 2 bits of the option type as specified 1385 in the SIPP specification [SIPP]. These action codes are: 1387 00 Ignore the option; Continue processing the packet. 1389 01 Discard the packet. 1391 10 Discard the packet and send an ICMP parameter problem 1392 message back to the source. 1394 11 Discard packet and, only if the packet's destination 1395 address was not a multicast address, send an ICMP 1396 parameter problem message back to the source. 1398 5.4 SIPP and IPv4 Routing Configuration 1400 The IPAE translator must have some minimal involvement in both the 1401 IPv4 routing system within the site, and the global SIPP routing system. 1402 The SIPP and IPv4 routing systems must be configured to deliver those 1403 packets that must be translated to the IPAE translator. This means that 1404 the IPv4 routing system within the site must deliver the IPv4 traffic 1405 for all IPv4 destinations outside of the site to the IPAE translator. 1406 And the SIPP routing system must deliver the SIPP traffic addressed to 1407 the site's prefix with the C-bit set to 1 to the IPAE translator. (SIPP 1408 traffic for the site's prefix with the C-bit set to 0 is routed to the 1409 individual SIPP hosts within the site.) In the intra-site IPv4 routing 1410 system, there usually must be a default route pointing to the IPAE 1411 translator. In the SIPP routing system, there must be a route for the 1412 site prefix with the C-bit set to 1 pointing to the IPAE translator. 1414 The necessary IPv4 and SIPP routing can be accomplished by static 1415 configuration in the IPv4 and SIPP routing systems, or by having the 1416 IPAE translator actively participate in the IPv4 and SIPP routing 1417 protocols. 1419 If multiple IPAE translators are deployed in a site, the routing 1420 configuration should be designed to split the traffic load among the 1421 translators. 1423 5.5 Translation of fragments 1425 The rules for translating fragments, when to set the DF bit, and when to 1426 include a fragmentation header are derived from the following 1427 constraints: 1429 - The translator will not receive ICMP "packet too big" messages 1430 since it is not the source address in the packet. The ICMP 1431 errors will be delivered to the source host. (This is unlike the 1432 encapsulation case, where the encapsulator receives all ICMP 1433 errors from routers interior to the tunnel.) Thus the 1434 translation rules have to make sure that the source host does 1435 not see any ICMP 'packet too big' that it would not have seen 1436 without any translators in the path. 1438 - The minimum MTU that a link has to support is different for IPv4 1439 and SIPP: 68 and 576 bytes, respectively. Thus SIPP hosts can 1440 send 576 bytes without supporting path mtu discovery. 1442 - SIPP routers never fragment packets (even when the fragmentation 1443 header is present). Thus the translation from IPv4 to SIPP, when 1444 the source does not support MTU discovery, has to make sure that 1445 the SIPP packet never needs to be fragmented. 1447 The different fragmentation cases are presented in the two tables below. 1448 The first table covers the cases where the source is an IPv4 system. In 1449 this case there can be either just a translation to SIPP (for a SIPP 1450 destination) or first a translation to SIPP and then a translation to 1451 IPv4 (for an IPv4 destination in a different site). 1453 When the source is a SIPP system (the second table) the only possible 1454 translation is to IPv4. 1456 IPv4 SIPP IPv4 1458 DF not set => fragment to 576 => copy ID field 1459 include fragmentation hdr DF not set 1461 DF set => no fragmentation hdr => DF set 1463 Fragmentation translation for IPv4 source 1465 SIPP IPv4 1467 Fragmentation hdr => Copy ID field 1468 DF not set 1470 No fragmentation hdr => Generate pseudo-unique ID 1471 DF not set 1473 Fragmentation translation for SIPP source 1475 5.6 Knowing when to Translate. 1477 The IPAE translator must translate IPv4 packets destined to hosts 1478 outside of the site and SIPP packets destined to hosts within the site. 1479 To do this, it must be able to differentiate those packets it must 1480 translate from those that it simply processes in the normal manner (and 1481 forwards, for example, if the machine is also a router). The translator 1482 may need some configuration information in order to make this 1483 distinction. 1485 This specification does not place any requirements on how the IPAE 1486 translator decides which packets to translate. However, the decision 1487 can be made based on information the machine has available. 1489 The IPAE translator can use the SIPP addresses of its own interfaces to 1490 decide which SIPP packets to translate. SIPP packets whose destination 1491 address match the 31-bits site prefix of an interface, and with the 1492 C-bit set to 1, should be translated. All other SIPP packets should be 1493 simply forwarded based on the SIPP destination address. 1495 The IPAE translator can use the mapping table along with the addresses 1496 of its own interface to decide which IPv4 packets to translate. If a 1497 matching entry is found in the mapping table for the destination address 1498 of the IPv4 packet, and the prefix in that mapping table entry does not 1499 match the site prefix of the address of any interface, then the packet 1500 can be translate. Otherwise, the packet should be forwarded based on 1501 its IPv4 destination address. 1503 6. IPAE Hosts 1505 IPAE hosts need to implement a variety of algorithms in order to be 1506 compatible with IPv4 hosts and routers, and also use the new facilities 1507 of SIPP. The modifications affect the internet and transport layers of 1508 the protocol software, as well as the transport layer application 1509 program interface (API), and the applications themselves. 1511 IPAE hosts must meet a couple of general requirements. They must be 1512 able to transmit and receive packets in the SIPP and IPv4 packet 1513 formats. They must be able to perform IPAE tunneling (SIPP encapsulated 1514 within IPv4). And they must be able to route outbound datagrams to both 1515 SIPP and IPv4 destination addresses. 1517 6.1. What packet format to send. 1519 The first decision a host must make is which form of packet to transmit: 1520 IPv4 or SIPP. When sending traffic to IPv4 hosts within its own site, 1521 IPAE hosts always transmit in the IPv4 format. Thus the host can make 1522 its initial packet format decision based on the C-bit and high-order 32 1523 bits of the destination SIPP address: 1525 if (C-bit of dest == 1) && (dest is in local site) 1526 send IPv4 packet 1527 else 1528 send SIPP packet 1530 The destination host is in the same site if the site prefix field 1531 (high-order 31 bits to the right of the C-bit) of the destination SIPP 1532 address match the site prefix field of the address of the outgoing 1533 interface. 1535 If a host is sending an IPv4 format packet, the packet can simply be 1536 routed using the IPv4 routing features of the host and transmitted. 1537 When sending a SIPP format packet, the host must determine whether the 1538 packet can be sent in the raw SIPP form, or whether it must be tunneled 1539 (encapsulated within an IPv4 header). How the host makes this decision 1540 depends on how IPAE tunnels are configured on the host. 1542 If the packet is to be tunneled, the SIPP datagram is encapsulated in an 1543 IPv4 header, and the IPv4 destination address set to the endpoint of the 1544 IPAE tunnel. The datagram is then routed using the IPv4 routing 1545 features of the host. The destination addresses in the IPAE packet will 1546 be: 1548 IPv4 dest addr: IPv4 address of tunnel endpoint. 1549 SIPP dest addr: SIPP addr of destination host. 1551 If the packet is in the SIPP format and is not tunneled, it is routed 1552 using the SIPP routing features of the host and transmitted. 1554 6.2. Transport pseudo-header checksum. 1556 TCP [RFC793] and UDP [RFC768] both define a checksum that covers the 1557 data portion of the segment along with a 96-bit "pseudo header" that 1558 includes the IPv4 source and destination addresses, protocol ID and 1559 length fields from the IPv4 header. Including this pseudo header in the 1560 transport checksum protects the transport layer against misrouted 1561 segments. 1563 The pseudo header used in the transport checksum when TCP and UDP are 1564 layered above IPv4 can be viewed logically as this: 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | IPv4 source address | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 | IPv4 destination address | 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 | zero | protocol | length | 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 Including the addresses in the checksum is even more important when TCP 1575 and UDP are layered above SIPP because the SIPP header is not 1576 checksummed. 1578 When communicating with other SIPP hosts, the TCP and UDP pseudo header 1579 includes the complete 64-bit SIPP source and destination addresses. But 1580 since the IPAE mechanism allows IPv4 packets to be translated into SIPP 1581 and vice-versa, the IPAE host must implement a compatible pseudo-header 1582 checksum when the packets it receives originated from, or the packets it 1583 is sending are destined to, an IPv4 host. The pseudo header checksum 1584 algorithm must cover only the low-order 32 bits of the SIPP addresses 1585 when an IPAE host is communicating with an IPv4 host. When 1586 transmitting, the IPAE host can use the C-bit of the SIPP destination 1587 address to determine whether the peer is an IPv4 host. When receiving, 1588 the C-bit of the SIPP source address can be used. 1590 When communicating with an IPv4 host using the IPv4 packet format 1591 directly (i.e., an IPv4 host in the same site), the 96 bit pseudo header 1592 shown above is used. 1594 When communicating in the IPAE or SIPP format with another SIPP host, 1595 the following pseudo header is used when the host is: 1597 1) Transmitting and C-bit of SIPP Destination Address is 0, or 1598 2) Receiving and C-bit of SIPP Source Address is 0 1600 0 8 16 24 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | zero | protocol | Length | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | | 1605 + SIPP Source Address + 1606 | | 1607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 | | 1609 + SIPP Destination Address + 1610 | | 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 SIPP peer pseudo header 1615 When communicating in the IPAE or SIPP format with an IPv4 host the 1616 following pseudo header is used when the host is: 1618 1) Transmitting and C-bit of SIPP Destination Address is 1, or 1620 2) Receiving and C-bit of SIPP Source Address is 1. 1622 0 8 16 24 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | Zero | Protocol | Length | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Zero | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | 32-LSB of SIPP Source Address | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Zero | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | 32-LSB of SIPP Destination Address | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 SIPP - IPv4 compatible pseudo-header 1637 6.3. TCP and UDP connection identification. 1639 TCP uses the concatenation of local and remote IP address with local and 1640 remote port number to uniquely identify a connection. TCP uses the term 1641 "socket" to identify one endpoint of a connection. The local socket is 1642 identified by the local IP address and local port number, while the 1643 remote socket is identified by the remote IP address and remote port 1644 number. 1646 In processing received segments and ICMP error messages, TCP must use 1647 the destination IP address and port number -- and possibly the source IP 1648 address and port number as well -- from the received segment to find the 1649 matching socket or connection in its own connection table. When 1650 communicating with another SIPP host, TCP must use the full SIPP source 1651 and destination addresses to identify connections and sockets. But when 1652 communicating with IPv4 hosts using the SIPP packet format, TCP must use 1653 only the low order 32 bits of global source and destination to identify 1654 the connection. This is necessary since the 64 bit SIPP addresses may 1655 not carried end-to-end; only the low-order 32 bits are end-to-end. Thus 1656 the high-order bits can be different in received packets from what was 1657 sent when the source or destination is in a multihomed site (a site that 1658 has multiple prefixes) or when the mapping tables contain prefixes with 1659 incorrect C bits. 1661 This requires a change to TCP's connection block lookup algorithm for 1662 received segments. 1664 Assuming that TCP keeps a single table of connection blocks identifying 1665 connections to both IPv4 hosts and SIPP hosts, the change can be 1666 summarized like this: 1668 1) If the format of the received packet is IPv4, then: 1670 use the source and destination IP addresses in the received 1671 packet to compare with the low-order 32 bits of the SIPP source 1672 and destination address in TCP's connection block table, 1674 2) If the format of the received packet is SIPP, then: 1676 2a) If the C-bit of the SIPP source address is 1, then: 1678 use the low-order 32 bits of the SIPP source and destination 1679 addresses in the packet to compare the low-order 32 bits of the 1680 SIPP source and destination address in the connection block 1681 table, 1683 2b) If the C-bit of the SIPP source address is 0, then: 1685 use the full SIPP source and destination addresses in the packet 1686 to compare with the full SIPP source and destination addresses in 1687 the connection block table. 1689 The host should implement this same algorithm in UDP if UDP supports the 1690 notion of a connected endpoint. In addition, any user-level UDP 1691 applications that use IP addresses to match replies with requests should 1692 implement a similar algorithm. 1694 6.4. ICMP Error Messages. 1696 6.4.1. Sending ICMP Error Messages. 1698 All of the ICMP error messages include an "offending packet" in the data 1699 part of the message. The "offending packet" is the internet header plus 1700 at least the first 8 bytes of the packet that caused the error being 1701 reported. The offending packet is used by the recipient of the ICMP 1702 error message to locate the transport-layer endpoint that caused the 1703 error. 1705 When sending ICMP error messages, the IPAE host must take into account 1706 the C-bit of the intended recipient, and make sure that the offending 1707 packet is in a form (IPv4 or SIPP) that the recipient understands. This 1708 is not always straightforward. If the C-bit of the recipient is 1, then 1709 the offending packet must be in the IPv4 form. But since IPAE 1710 translators may translate packets sent from IPv4 hosts into SIPP form, 1711 it is possible that the packet that caused the error might be in the 1712 SIPP form, even though the source was an IPv4 only host. (The IPAE host 1713 knows this because the C-bit of the Source SIPP address is 1.) When 1714 this happens, the IPAE host must "generate" an IPv4 header for use in 1715 the offending packet part of the ICMP error message. The IPAE host can 1716 use the information in the SIPP header of the packet that actually 1717 caused the error to generate the IPv4 header. Since the offending 1718 packet is going to be used by the recipient to identify a connection, 1719 the address fields must be correct. The IPAE host can the IPv4 header 1720 of the offending packet from the received SIPP packet in the same way 1721 that an IPAE translator translates SIPP to IPv4: 1723 Version: 1725 4 1727 IP Header Length in 32 bit words: 1729 5 1731 Type of Service: 1733 0 1735 Total Length: 1737 Payload length from SIPP header + 20 1739 Identification: 1741 If SIPP fragmentation option is present, copy low-order 1742 16 bits from ID field. Otherwise generate a unique 1743 value for every packet. 1745 Flags: 1747 If SIPP fragmentation option is present, set MF bit if 1748 More bit is set in option. If the SIPP fragmentation 1749 option is not present, and the C-bit is set in the 1750 source address, then set the DF bit. 1752 Fragment offset: 1754 If SIPP fragmentation option is present, copy the 1755 fragment offset value from the option. 1757 Time to Live: 1759 Hop limit field copied from the SIPP header. 1761 Protocol: 1763 Payload type value copied from SIPP header or, if known 1764 SIPP options are present, from last SIPP option header. 1766 Header Checksum: 1768 Calculate the header checksum. 1770 Source Address: 1772 Copy the low-order 32-bits of the SIPP source address. 1774 Destination Address: 1776 Copy the low-order 32 bits of the SIPP destination 1777 address. 1779 The resulting ICMP error message can be sent within an IPv4 header (if 1780 the destination is within the same site), or within a SIPP header (if 1781 the destination is located in another site). Thus the following two 1782 header configurations are possible: 1784 +------------+ +------------+ 1785 | SIPP | | IPv4 | 1786 | Header | | Header | 1787 +------------+ +------------+ 1788 | ICMP | | ICMP | 1789 | Header | | Header | 1790 +------------+ +------------+ 1791 |"Generated" | |"Generated" | 1792 | IPv4 | | IPv4 | 1793 | Header of | | Header of | 1794 | offending | | offending | 1795 | packet | | packet | 1796 +------------+ +------------+ 1797 | Transport | | Transport | 1798 | Header | | Header of | 1799 | Offending | | Offending | 1800 | Packet | | Packet | 1801 ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~ 1803 Sending ICMP error messages to destinations whose addresses have their 1804 C-bit set to 0 is simpler. Both the header of the offending packet and 1805 the header of the ICMP message are of the SIPP form: 1807 +------------+ 1808 | SIPP | 1809 | Header | 1810 +------------+ 1811 | ICMP | 1812 | Header | 1813 +------------+ 1814 | SIPP | 1815 | Header | 1816 | (offending | 1817 | packet) | 1818 +------------+ 1819 | Transport | 1820 | Header | 1821 | (Offending | 1822 | packet) | 1823 ~~~~~~~~~~~~~~ 1825 6.4.2 Receiving ICMP Error Messages. 1827 IPAE hosts must be prepared to receive ICMP error messages encapsulated 1828 within either SIPP or IPv4 headers. They must also be able to decode 1829 the "offending packet" within the ICMP error message that is in either 1830 the SIPP or IPv4 header format. They must use the same connection 1831 matching rules spelled out in section 6.3 to match the "offending 1832 packet" in the received ICMP error message with an existing TCP 1833 connection or UDP endpoint. 1835 6.5. Transport API changes. 1837 Most IPv4 systems that are modified to support SIPP will already have an 1838 existing application program interface (API) through which applications 1839 use TCP and UDP. These APIs typically carry a 32 bit IPv4 address in 1840 order to bind a TCP or UDP endpoint to a local address, to specify the 1841 destination address of a UDP datagram being sent, or to specify the 1842 destination address of a TCP connection being opened. The 32 bit IPv4 1843 address shows up in other parts of the API, such as the return value 1844 from a hostname-to-IPv4 address lookup function. Generally, these APIs 1845 provide fixed-size fields to hold IPv4 addresses and TCP and UDP port 1846 numbers. For the most part, these APIs must modified be to carry 64-bit 1847 addresses in order to support SIPP. 1849 The IPAE mechanism does not impose any specific requirements on how the 1850 the APIs in a IPAE system should be changed to support SIPP. However, 1851 we offer here some general considerations in designing these new APIs. 1853 Some desirable features of a SIPP API are: 1855 1) The new API should allow applications to pass in both 32-bit 1856 IPv4 addresses and 64-bit SIPP addresses. Even new applications 1857 may encounter 32 bit IPv4 addresses. The API should allow the 1858 program to pass these addresses in. 1860 2) The new API should provide both source and binary compatibility 1861 with the existing IPv4 API. Applications written to the old API 1862 should continue to operate when run in binary form, or when 1863 re-compiled on an IPAE system with the new API. 1865 3) Un-modified applications should provide as much SIPP service as 1866 possible. 1868 4) Applications that do not manipulate IP addresses (e.g. TCP 1869 servers) should run without any modifications. 1871 Along with the API changes, application programs that manipulate IP 1872 addresses must usually be modified. Often these changes can be isolated 1873 to the code that that parses SIPP addresses typed in by users, and the 1874 code that deals with SIPP addresses returned by the name to address 1875 translation functions (DNS lookups). 1877 6.6. IP Addresses Embedded in Application Protocols 1878 There are many application protocols layered above TCP and UDP. Some of 1879 them carry IPv4 addresses as part of their protocol. We have examined 1880 the most popular application layer protocols, considering for each how 1881 IPAE hosts would interoperate with IPv4 hosts, and with each other, 1882 using these protocols. In this section, we specify how IPAE hosts 1883 should use existing application protocols. 1885 This section addresses only application layer protocols. The internet 1886 routing protocols, control protocols, transport protocols, or layering 1887 (e.g. IP over appletalk) protocols which carry IPv4 addresses are 1888 specific to IPv4 and would not require any change for IPAE. SIPP 1889 versions may be developed, but that will be addressed in other 1890 documents. 1892 The application protocols that we analyzed fell into four categories: 1894 1) Application protocols that do not carry embedded IPv4 addresses. 1895 These protocols can be used immediately between IPAE and IPv4 1896 systems and between IPAE systems. They require no change. 1898 2) Application protocols that carry IPv4 addresses, but the 1899 protocol or its use of IPv4 addresses is obsolete. These 1900 protocols do not need to be changed. They can continue to be 1901 used between IPAE and IPv4 systems and between IPAE systems 1902 indefinitely. 1904 3) Application protocols that carry IPv4 addresses, but that are 1905 used exclusively by IPv4 systems, or the IPv4 parts of IPAE 1906 systems. These protocols also do not need to be changed, 1907 although new versions of them may be necessary in order to 1908 support the same function in SIPP and IPAE systems. 1910 4) Application protocols that carry IPv4 addresses, but that are 1911 not IPv4 specific. Only one protocol, FTP, fell into this 1912 category. FTP provides its full functionallity when used 1913 between IPv4 and IPAE systems, and that provide a subset of that 1914 functionallity when used among IPAE systems. It will have to be 1915 extended in order to provide its full functionallity among SIPP 1916 and IPAE systems. 1918 Most of the application layer protocols that we examined fell into the 1919 first category. These protocols, which require no change at all to be 1920 used between IPAE and IPv4 systems, are: 1922 Telnet (RFC 854, RFC 855) 1923 SMTP (RFC 821) 1924 TFTP (RFC 1350) 1925 BSD "rlogin" protocol (RFC 1282) 1926 BSD "rsh" protocol (note: passes port number, bug not IP addr) 1927 BSD "biff" protocol (in.comsat) 1928 BSD "lpr" protocol (RFC 1179) 1929 BSD "syslog" protocol 1930 ONC RPC protocol (RFC 1057) 1931 ONC original "portmap" protocol (documented in RFC 1057) 1932 ONC+ new "rpcbind" protocol (replaces portmap) 1933 Echo - TCP and UDP (RFC 862) 1934 Discard - TCP and UDP (RFC 863) 1935 Chargen - TCP and UDP (RFC 864) 1936 Quote of the Day - TCP and UDP (RFC 865) 1937 Active users - TCP or UDP (RFC 866) 1938 Daytime - TCP or UDP (RFC 867) 1939 Time - TCP or UDP (RFC 868) 1940 Nicname/Whois (RFC 954) 1941 Finger (RFC 1288) 1942 DNS mail routing (RFC 974) 1943 SNMP (RFC 1157) 1944 POP3 (RFC 1225) 1945 Concise-MIB (RFC 1212) 1946 Content type mail header field (RFC 1049) 1947 MIME (RFC 1341) 1948 NNTP (RFC 977) 1949 BSD "rexec" protocol 1950 NTP (RFC 1119) 1951 NFS 1953 A few protocols fell into the second category. These protocols -- which 1954 carry IPv4 addresses, but do not need to be changed because their use of 1955 IPv4 is obsolete -- are: 1957 Mail (RFC 822) 1958 BSD "talk" protocol 1960 More protocols fell into the third category. They are used only by IPv4 1961 systems, and may need to be revised in order to provide a similar 1962 function between SIPP systems: 1964 SMI (RFC 1155) 1965 MIB-II (RFC 1213) 1966 IP Forwarding table MIB (RFC 1354) 1967 RARP (RFC 903) 1968 BOOTP (RFC 951, RFC 1084) 1969 DHCP (RFC 1531) 1970 PPP IP address negotiation options 1971 ONC "bootparams" RPC protocol 1972 DNS (RFC 1034, RFC 1035) 1974 The one protocol in the fourth category, which will need to be extended 1975 in order to provide full functionallity to SIPP systems, is: 1977 FTP (RFC 959) 1979 We did not have enough information to evaluate two application 1980 protocols: 1982 Kerberos (Where are the complete protocol spec?) 1983 Telnet options (Is there a complete list of all options?) 1985 The remainder of this section discusses how IPAE systems should use the 1986 IPv4 address carrying application protocols. 1988 6.6.1. FTP 1990 IPv4 addresses are encoded in FTP in two places: 1992 - the arguments to the PORT command. 1993 - the reply to the PASV command. 1995 Both the argument to the PORT command and the reply to the PASV command 1996 contain a 32-bit IPv4 address and a 16-bit TCP port number. 1998 These commands are used for two specific purposes: 2000 1) In a 2-party FTP transaction, the client uses the PORT command 2001 to specify a TCP port number on the client's machine other 2002 than the default (port 20) for the server to connect back to 2003 the client on. 2005 2) In a 3-party FTP transaction involving one client FTP and two 2006 server FTPs. The client gives the PASV command command to FTP 2007 server 1 and records the address reply. Then it sends the 2008 PORT command command to FTP server 2, giving the address 2009 returned by server 1. Then it sends the STOR or RETR command 2010 to server 2 to transfer file(s) directly between server 1 and 2011 server 2. 2013 IPAE hosts must implement the algorithm below, which provides complete 2014 interoperability for 2-party FTP transactions between IPv4 hosts and all 2015 other IPAE hosts. It also provides interoperability for 3-party FTP 2016 transactions with other IPv4 and IPAE hosts within the same IPAE site. 2017 This algorithm does not allow 3-party FTP transactions among hosts in 2018 different IPAE sites. Such a feature could be provided by modifying the 2019 FTP protocol, but such a change is outside the scope of this document. 2021 In a 2-party FTP, the client may generate PORT commands of the form: 2023 PORT a1,a2,a3,a4,p1,p2 2025 The semantics of this are that the bytes a1, a2, a3 and a4 are the 2026 low-order 32 bits of the 64 bit SIPP address that the server should 2027 connect to. The high-order 32-bits of the SIPP address that the server 2028 should connect to are communicated implicitly: they are the high-order 2029 32 bits of the client's SIPP address used in the FTP control connection. 2030 Thus the FTP client can communicate any SIPP address in the PORT command 2031 so long as the high-order 32 bits of that address are the same as the 2032 client-side address of the control connection. The client may 2033 communicate the SIPP address of any of its SIPP interfaces so long as 2034 all of those addresses share the same high-order 32 bits as the control 2035 connection. If a host is multi-homed in multiple SIPP sites (i.e. it 2036 has multiple SIPP interfaces with different high-order 32 bits), it can 2037 not communicate the addresses of those interfaces connected to different 2038 sites. 2040 The FTP server, when it receives a PORT command composes the 64 bit SIPP 2041 address to connect back to by concatenating the 32 high-order bits of 2042 the client's address of the control connection with the low-order 32 2043 address bits passed in the PORT command. 2045 An FTP server generates a replies to the PASV command with the form: 2047 227 Entering Passive Mode. a1,a2,a3,a4,p1,p2 2049 The bytes a1, a2, a3, and a4 are the low-order 32 bits of the 64 bit 2050 SIPP address that the client can connect to the server on. The 2051 high-order 32 bits of the connect address are communicated implicitly: 2052 they are the high-order 32 bits of the SIPP address of the server side 2053 of the control connection. The server may return any 64 bit SIPP 2054 address in its PASV reply that shares the same high-order 32 bits as the 2055 server side of the control connection. Thus, for example, it can return 2056 the address of any other interface on the server that is in the same 2057 SIPP site, but may not return the address of interfaces that are in 2058 other SIPP sites. 2060 A client FTP may initiate a 3-party FTP *only* if the SIPP addresses of 2061 all three participants -- the FTP client, server 1 and server 2 -- share 2062 the same high-order 32 bits. 2064 6.6.2. Mail (RFC 822) 2066 The only place where IPv4 addresses appear in the RFC 822 mail header 2067 format is in the "domain literal" address construct. It is possible to 2068 specify a domain address as a dotted-decimal address. For example, one 2069 could specify: 2071 Gilligan@[192.9.9.1] 2073 This construct is specified in section 6.2.3 of RFC 822. 2075 The spec includes the following warning: 2077 Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It 2078 is permitted only as a means of bypassing temporary 2079 system limitations, such as name tables which are not 2080 complete. 2082 In IPAE, we continue the campaign to "discourage" the domain-literal 2083 address construct by not modifying its syntax to support 64 bit SIPP 2084 addresses. IPAE hosts may continue to use the domain-literal address 2085 format as specified in RFC 822. However, this format specifies only a 2086 32 bit IPv4 address and not a SIPP address. IPAE hosts that parse a 2087 domain-literal address treat the resulting 32-bit IPv4 address the same 2088 as if they had parsed a domain name that translated (via a DNS lookup 2089 that returned an "A" record) to a 32-bit IPv4 address. 2091 Thus domain literal addresses will still be useful globally so long as 2092 IPv4 addresses are globally unique. After IPv4 addresses are no longer 2093 globally unique, the domain literal form can still be used within a SIPP 2094 site. 2096 6.6.3. Domain Name System (DNS) 2098 There are two places within the DNS where IPv4 addresses are encoded: 2100 - The "A" record format. 2101 - The structure of the "in-addr.arpa" tree. 2103 A new address record is being defined to hold 64-bit SIPP addresses. 2104 This new record is specified in another document [SIPPDNS]. There is no 2105 need to change the existing "A" record format or the "in-addr.arpa" 2106 tree. They can continue to be used by IPv4 systems for as long as 2107 necessary. IPAE hosts can use the A records and "in-addr.arpa" in 2108 addition to the new 64-bit SIPP address records and reverse lookup tree. 2110 6.6.4. SMI, MIB-II, Forwarding Table MIB 2112 The SMI RFC defines a data type for the 32-bit IPv4 address. This type 2113 is named "IpAddress". The MIB-II and some other MIBs use this data 2114 structure. These definitions can remain unchanged and can continue to 2115 be used by IPv4 hosts and routers. Management stations running on IPAE 2116 hosts can continue to use these definitions when managing IPv4 hosts and 2117 routers. IPAE hosts and routers may choose to continue to support the 2118 IPv4-based MIBs in order to provide meaningful information to the 2119 installed base of management stations. 2121 For SIPP and IPAE systems, a new data type for the 64-bit SIPP address 2122 will need to be defined. All of the MIBs that include IP address data 2123 types (at least MIB-II and the Forwarding table MIB) will need to be 2124 revised for SIPP and IPAE systems. In addition, a MIB will need to be 2125 defined for the mapping table stored on IPAE translators. 2127 6.6.5. RARP, BOOTP, DHCP, Bootparams 2129 RARP, BOOTP, DHCP, and Bootparams are all used to support booting. 2130 RARP, BOOTP, and DHCP all provide a mechanism for a host to acquires its 2131 own IPv4 address. These protocols can continue to be used without 2132 change by IPv4 systems. 2134 These protocols can be used without change to provide limited service to 2135 IPAE systems. The Bootparams protocol carries 32-bit IPv4 addresses in 2136 two places: The "whoami" RPC returns the 32-bit IPv4 address of a 2137 default router, and the "getfile" RPC returns the 32-bit IPv4 address of 2138 a file server. IPAE systems can use the whoami call to learn their 2139 default IPv4 router address. IPAE systems should use the SIPP router 2140 discovery mechanism to learn the addresses of SIPP routers. IPAE hosts 2141 can continue to use the getfile call to communicate with IPv4 or IPAE 2142 file servers within the local site. 2144 In order to provide their full functionallity to SIPP and IPAE systems, 2145 these three protocols will have to either be revised to return 64-bit 2146 SIPP addresses, or incorporated into a new host configuration scheme. 2147 SIPP host configuration is being addressed in another spec [SIPPDISC]. 2148 The ONC RPC system includes a versioning mechanism that should allow us 2149 to revise the bootparams protocol in a compatible way. 2151 6.6.6. BSD talk protocol. 2153 This protocol is obsolete. We make no attempt to convert it to SIPP. 2155 Appendix 1. Definitions 2157 IPv4: 2159 The Internet Protocol, version 4. This is the version of the 2160 Internet Protocol specified in RFC 791. 2162 SIPP: 2164 The Simple Internet Protocol Plus. This is the working name 2165 for the next generation Internet Protocol being designed by 2166 the IETF SIPP working group. If SIPP is accepted as the next 2167 generation IP, it will likely be re-named simply IP. 2169 IPAE: 2171 The set of protocols and operational techniques that provide 2172 interoperability between IPv4 and SIPP systems, and transition 2173 the Internet from IPv4 to SIPP. The acronym "IPAE" no longer 2174 stands for anything. 2176 IPAE Address: 2178 A 64-bit SIPP address that is structured so as to be 2179 compatible with IPv4. The format of an IPAE address is: 2181 6 3 3 0 2182 3 2 1 0 2183 +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ 2184 |C| Site Prefix | IPv4 Address | 2185 +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ 2187 An IPAE address has three components: 2189 C-bit Encodes whether the entity addressed 2190 supports SIPP or not. 2192 Site Prefix Uniquely identifies the IPAE site that 2193 the addressed entity is located in. 2195 IPv4 Address Uniquely identifies the addressed entity. 2197 IPAE Host: 2199 A host adhering to both the SIPP specifications and the IPAE 2200 specifications. An IPAE host is capable of sending and 2201 receiving packets in any of the three packet formats - IPv4, 2202 SIPP, and IPAE. 2204 IPAE Packet Format: 2206 SIPP encapsulated within IPv4. 2208 IPAE Router: 2210 A router capable of sending, receiving, and processing the 2211 three packet formats -- IPv4, SIPP and IPAE. An IPAE router 2212 also participates in both IPv4 and SIPP routing protocols. 2214 IPAE Site: 2216 A region of the Internet that contains IPv4 hosts and routes 2217 IPv4 packets. An IPAE site typically has at least one IPAE 2218 router providing SIPP connectivity to the global Internet. 2220 IPAE Translator - or - IPAE Translation Agent: 2222 An IPAE router that performs the following additional 2223 functions to support intra-site IPv4-to-IPv4 and IPv4-to-SIPP 2224 traffic: 2226 - Mapping the source and destination addresses of 2227 locally generated IPv4 traffic into SIPP addresses 2228 through the use of a mapping table. 2230 - Translating headers of locally generated IPv4 traffic 2231 from IPv4 format to SIPP format. 2233 - Translating headers of remotely-generated SIPP traffic 2234 from SIPP format to IPv4 format. 2236 IPAE translators must participate in IPv4 and SIPP routing 2237 to the extent that they receive: 2239 - All IPv4 traffic generated within the site destined to 2240 IPv4 hosts outside the site. This is usually 2241 accomplished by pointing an IPv4 default route at the 2242 IPAE translator. 2244 - All SIPP traffic generated external to the site with 2245 destination SIPP address of the site with the C-bit 2246 set. 2248 SIPP-only Host: 2250 A host that sends and receives *only* the SIPP format. 2252 SIPP-only hosts can not send or receive IPv4 or IPAE format 2253 packets. 2255 SIPP-only Router: 2257 A router that sends and receives *only* the SIPP format. 2258 SIPP-only routers can not send or receive IPv4 or IPAE format 2259 packets. 2261 SIPP-only Site: 2263 A region of the Internet that consists of only SIPP or IPAE 2264 hosts and SIPP routers. No IPv4 or IPAE traffic will be seen 2265 in a SIPP-only site. 2267 IPv4-only Host: 2269 A host that sends and receives only IPv4 format packets. 2271 IPv4-only Router: 2273 A router that sends and receives only IPv4 format packets. 2275 Appendix 2. The IPv4 to SIPP Transition 2277 The Internet's transition to SIPP takes place in a number of 2278 sequential steps: 2280 1) The first IPAE systems are deployed on the Internet. IPAE 2281 site boundaries are defined, and the first IPAE site prefixes 2282 are assigned. 64-bit SIPP address records are added to the 2283 DNS for each new SIPP system as well as IPv4 systems. 2285 2) Backbone SIPP routing topology is designed. Sites begin to 2286 deploy IPAE routers. Backbone SIPP routing runs in parallel 2287 with IPv4 routing. 2289 3) Sites begin to deploy IPAE translators. Site-internal default 2290 routes are configured to point to the IPAE translators. SIPP 2291 C-bit routes are propagated. After a IPAE translator has been 2292 deployed at a site, 64-bit SIPP address records (with C-bit 2293 on) are added to the DNS for each IPv4 host within that site. 2295 4) Deployment of IPAE routers and IPAE translators at every site 2296 connected to the backbone is complete. 2298 5) Backbone IPv4 routing is turned off. All inter-site 2299 IPv4-to-IPv4 and IPv4-to-SIPP traffic uses IPAE translators. 2301 6) Internet runs out of IPv4 network numbers. IPAE translators 2302 are de-commissioned. Inter-site IPv4-to-IPv4 and IPv4-to-SIPP 2303 traffic is no longer possible. Intra-site IPv4-to-IPv4 and 2304 IPv4-to-SIPP traffic can continue indefinitely. 2306 Time What is Happening 2307 ---- ----------------- 2308 | 2309 Today --+ 2310 | - IPv4 is routed globally. 2311 | - All hosts speak IPv4. 2312 | 2313 T1 ---+ - First IPAE hosts deployed 2314 | - IPAE hosts use IPAE tunneling across the IPv4 2315 | infrastructure to reach other IPAE hosts. 2316 | - IPAE hosts use IPv4 packet format to communicate with 2317 | IPv4 hosts 2318 | 2319 T2 ---+ - SIPP routing is started. 2320 | - IPAE hosts route intra-site SIPP traffic via IPAE routers. 2321 | - IPAE hosts continue to use IPv4 packet format to communicate 2322 | IPv4 hosts. 2323 | 2324 T3 ---+ - Installation of IPAE translators begins. 2325 | - IPAE hosts send SIPP packets to IPv4 hosts in other sites 2326 | where translators have been installed. 2327 | - IPv4 traffic generated in sites with IPAE translators 2328 | and destined for sites with translators is translated. 2329 | 2330 T4 ---+ - IPAE routers and translators have been installed in 2331 | every site. 2332 | - All inter-site IPv4-to-IPv4 and IPv4-to-SIPP traffic 2333 | should be using IPAE translators and are carried via 2334 | the backbone SIPP routing system. Only mis-configured 2335 | routers use IPv4 backbone routing. 2336 | 2337 T5 ---+ - Backbone IPv4 routing is cut. 2338 | - Users should not notice any change. 2339 | - Mis-configurations are detected and repaired. 2340 | 2341 | 2342 T6 ---+ - IPv4 address "run-out" day. 2343 | - Since IPv4 addresses are no longer unique, global 2344 | IPv4 connectivity is discontinued. IPAE translators 2345 | are de-commissioned. 2346 | - IPv4 hosts continue to have complete connectivity within 2347 | their site. 2348 | - IPv4 hosts continue to have complete interoperability 2349 | with IPAE hosts within their site. 2350 | - Remaining IPv4 hosts and routers may be converted to 2351 | SIPP at the convenience of their owners, but 2352 | conversion is not required. 2353 | - Note: introduction of new SIPP services may require 2354 | conversion of some routers to SIPP. 2356 The transition starts by dividing the existing Internet into a 2357 collection of IPAE sites. This doesn't involve any physical 2358 re-configuration or re-numbering of the Internet. We simply take the 2359 existing Internet topology and identify individual regions. Generally 2360 speaking, a "site" will be a single administrative entity, such as a 2361 University campus or a corporation. 2363 Each site is assigned a unique 32-bit SIPP prefix which comprises a 2364 1-bit C-bit and a 32-bit IPAE site prefix. These prefixes are selected 2365 based on a global 64-bit SIPP addressing plan to be drawn up. A 64-bit 2366 SIPP address for each host and router is formed by concatenating the 2367 site's 32-bit prefix with the host or router's previously assigned 2368 32-bit IPv4 address. The C-bit field of the addresses of all 2369 SIPP-capable hosts and routers is set to 0. For those hosts and routers 2370 that speak only IPv4, the C-bit is set to 1. 2372 All hosts and routers in the Internet keep their existing IPv4 address 2373 assignments. No IPv4 re-numbering is required. The Internet continues 2374 to use the CIDR-based IPv4 address allocation scheme. New IPv4 hosts 2375 and routers can continue to be added during the SIPP transition. 2377 Next, the Internet backbone is converted to route SIPP traffic. This 2378 can be done by converting all of the routers from the sites into the 2379 backbone and the sites to route SIPP. 2381 Next, an IPAE translator is installed in each site. The IPAE 2382 translator can be co-resident with the IPAE router. 2384 Appendix 3. Examples 2386 A3.1. IPAE Encapsulation 2388 Consider the following topology, which includes two IPAE hosts, two 2389 IPAE routers, and two IPv4 routers: 2391 ---+----------------------------------+--- (Subnet A) 2392 | | 2393 (1404:1:192.9.5.2) (192.9.5.1) 2394 IPAE Host H1 IPv4 Router R1 2395 (192.9.6.1) 2396 | 2397 -----+-----------+------- (Subnet B) 2398 | 2399 (1404:1:192.9.6.17) 2400 IPAE Router R2 2401 (1404:8:192.9.88.13) 2402 | 2403 -------+----------------+------ (Subnet C) 2404 | 2405 (1404:8:192.9.88.3) 2406 IPAE Router R3 2407 (1404:8:192.9.89.3) 2408 | 2409 ---+-------+----- (Subnet D) 2410 | 2411 (192.9.89.77) 2412 IPv4 Router R4 2413 (192.9.123.68 2414 | 2415 ---+-----------------------------+-------- (Subnet E) 2416 | 2417 (1404:8:192.8.123.244) 2418 IPAE Host H2 2420 A UDP datagram is sent from IPAE host A to IPAE host B. The packet 2421 transits two IPAE tunnels. One tunnel runs from the source host, H1, 2422 to the IPAE router, R2. The router R3 sends the packet to router R3 2423 in the raw SIPP packet format. The packet then rides the second tunnel 2424 from IPAE router R3 to the destination host, H2. 2426 The packet transmitted on Subnet A and Subnet B looks like this: 2428 IPv4 src = 192.9.5.2 2429 IPvr dst = 192.9.6.17 2430 SIPP src = 1404:1:192.9.5.2 2431 SIPP dst = 1404:8:192.9.123.244 2433 The packet as transmitted on Subnet C looks like this: 2435 SIPP src = 1404:1:192.9.5.2 2436 SIPP dst = 1404:8:192.9.123.244 2438 The packet as transmitted on Subnet D and Subnet E looks like this: 2440 IPv4 src = 192.9.89.3 2441 IPvr dst = 192.9.123.244 2442 SIPP src = 1404:1:192.9.5.2 2443 SIPP dst = 1404:8:192.9.123.244 2445 Appendix 4. Design Decisions 2447 This section explains the reasoning behind some of the decisions made in 2448 the design of IPAE. 2450 A4.1. The C-bit. 2452 Question: The C-bit wasts a full bit in the address space, effectively 2453 halving its size. Why not just define a single prefix for IPv4 hosts (A 2454 C-prefix instead of a C-bit)? 2456 Answer: The C-bit as it is defined allows IPv4 traffic to have the same 2457 benefits of scaling that SIPP traffic enjoys. Since intra-site IPv4 2458 traffic is translated early on into SIPP form by the IPAE translators, 2459 it is routed over the backbone by its 64 bit SIPP destination address, 2460 not its 32-bit IPv4 address. The 64-bit SIPP addresses that the IPAE 2461 translators convert the IPv4 addresses into have the same hierarchical 2462 structure as SIPP hosts. 2464 We viewed the near-term benefits of route scaling for IPv4 traffic as 2465 outweighing the cost of the C-bit in terms of address space. 2467 A4.2. Global vs. Local scope for C-bit. 2469 Question: Why wasn't the C-bit defined with local scope? That way it 2470 could C-bits could be recycled after a site was completely converted 2471 to SIPP. 2473 Answer: That was one of our early designs. However, we quickly found 2474 that there the C-bit could be used in a number of different places. 2475 To limit the C-bit to local scope, we would have to change each of 2476 those places where we use the C-bit. 2478 Appendix 5. Open Issues 2480 In this section, we discuss those issues that are not yet decided. 2482 A5.1. How is the DF bit handled? 2484 How should the IPAE translators handle IPv4 packets that arrive with 2485 the DF bit set? 2487 A5.2. Should we map IPv4 TOS bits into a flow ID? 2489 When translating IPv4 to SIPP, should the IPAE translators map the 2490 8-bit IPv4 TOS field into the SIPP flow ID? 2492 A5.3. How should we set the ID field? 2494 The IPv4 header has an ID field that is used by the receiving host 2495 when re-assembling fragments. In order to ensure proper reassembly, 2496 the IPv4 ID field must be unique per IP source and destination 2497 address. When a SIPP packet is translated into an IPv4 packet for 2498 delivery to an IPv4 host, the IPv4 ID field must be generated by the 2499 IPAE translator. The translator can generate an ID field that is 2500 unique relative to itself. However, it is possible that datagrams 2501 from one source host to one destination source might be translated by 2502 more than one IPAE translator. If more than one translator translates 2503 packets from this host pair, fragments of different IPv4 packets might 2504 end up with the same ID field. 2506 There are a number of potential solutions to this problem: 2508 1) Allow only one IPAE translator per site. 2510 2) Have the IPAE translators choose random ID values 2511 for each packet. 2513 3) Have the IPAE translators choose per-destination unique 2514 values that start with a random seed. 2516 A5.4. ICMP error message handling? 2518 How should an IPAE translator deal with IPv4 ICMP error messages 2519 returned for "last hop" packets translated from SIP to IPv4 and then 2520 sent by an IPAE translator? How should they deal with SIPP ICMP error 2521 messages returned for packets translated from IPv4 to SIP by the IPAE 2522 translator? 2523 One solution is to have the IPAE translators translate both the IPv4 2524 or SIPP headers of the ICMP message, as well as the IPv4 or SIPP 2525 headers of the "offending packet" that is within the ICMP error 2526 message. This would be possible to implement, but would be complex. 2527 It would be nice if we could find a simpler solution. 2529 A5.5 IPv4 path mtu discovery when encapsulating. 2531 Section 4.3 states that the Don't fragment bit should always be set in the 2532 IPv4 header when encapsulating SIPP (in order for the encapsulator to track 2533 the tunnel mtu so that it can generate SIPP ICMP errors back to the source). 2535 Should we allow simple IPAE hosts to send IPAE packets without performing IPV4 2536 path MTU discovery? 2538 A5.6 Determining "improvements" in tunnel state 2540 Can the mechanism to discard stale tunnel state in an encapsulating 2541 host or router be a simple periodic discarding of the timer state or 2542 should we use more sophisticated algorithms? 2544 A more elaborate scheme would be to count the number of 1) datagrams 2545 that should have generated a certain ICMP error and 2) the actual 2546 number of such ICMP errors received, and discarding the state when the 2547 ratio between them exceeds some value. 2549 Security Considerations 2551 Security issues are not discussed in this document. 2553 References 2555 [CIDR] Classless Inter-Domain Routing (CIDR): an Address 2556 Assignment and Aggregation Strategy. Fuller, V.; Li, 2557 T.; Yu, J.; Varadhan, K.; September 1993. RFC 1519 2559 [SIPP] Simple Internet Protocol Plus Specification. To be 2560 published. 2562 [IP] Internet Protocol. Postel, J.B. September 1981. RFC 2563 791. 2565 [RFC793] Transmission Control Protocol. Postel, J.B. September 2566 1981. RFC 793. 2568 [RFC768] User Datagram Protocol. Postel, J.B. August 1980. 2569 RFC-768. 2571 [SIPPDNS] SIP addresses in the domain name service 2572 specifications, Internet Draft, 06/11/1993, 2573 2575 [SIPPCONF] SIP System Discovery, Internet Draft, 06/09/1993, 2576 2578 Authors' Address 2580 Robert E. Gilligan 2581 Sun Microsystems, Inc. 2582 2550 Garcia Avenue 2583 Mailstop UMTV05-44 2584 Mountain View, California 94043-1100 2586 415-336-1012 2588 bob.gilligan@eng.sun.com