idnits 2.17.1 draft-crocker-ip-encaps-01.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-03-28) 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 == 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 Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 426 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 124 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 323 has weird spacing: '.... This is po...' == Line 1077 has weird spacing: '...llowing secti...' == 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 11, 1992) is 11460 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 section? 'HIND92b' on line 1207 looks like a reference -- Missing reference section? 'HIND92a' on line 1204 looks like a reference -- Missing reference section? 'DEER92a' on line 1196 looks like a reference -- Missing reference section? 'DEER92b' on line 1199 looks like a reference -- Missing reference section? 'RFC793' on line 672 looks like a reference -- Missing reference section? 'RFC768' on line 672 looks like a reference -- Missing reference section? 'BRAD89a' on line 1187 looks like a reference -- Missing reference section? 'BRAD89b' on line 1190 looks like a reference -- Missing reference section? 'BRAD89c' on line 1193 looks like a reference -- Missing reference section? 'WOOD92' on line 1210 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft D. Crocker 3 The Branch Office 4 R. Hinden 5 Sun Microsystems 6 November 11, 1992 8 IP Address Encapsulation (IPAE): 9 A Mechanism for Introducing a New IP 11 STATUS OF THIS MEMO 13 This document is an Internet Draft. Internet Drafts are working documents of 14 the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. 15 Note that other groups may also distribute working documents as Internet 16 Drafts. 18 Internet Drafts are draft documents valid for a maximum of six months. 19 Internet Drafts may be updated, replaced, or obsoleted by other documents at 20 any time. It is not appropriate to use Internet Drafts as reference material 21 or to cite them other than as a ``working draft'' or ``work in progress.'' 23 Please check the 1id-abstracts.txt listing contained in the internet-drafts 24 Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, 25 ftp.nisc.sri.com, or munnari.oz.auto to learn the current status of any 26 Internet Draft. 28 SUMMARY 30 The Internet seeks to increase the amount of IP address space that is 31 available for hosts and to decrease the amount of table storage that is 32 required by routers. Ultimately, the current IP (IP version 4) and any 33 replacement are inherently incompatible and movement to the new version 34 requires very substantial change to the IP installed base. This specification 35 describes an approach which retains as much software, operations and training 36 as possible, and minimizes overall operational disruption by allowing subsets 37 of the Internet to carry the new-format Internet datagrams inside old-style 38 IPv4 datagrams, using a technique called "IP Address Encapsulation" (IPAE). 39 This permits incremental and asynchronous introduction and makes transition 40 entirely optional for portions of the Internet infrastructure. It further 41 permits early reduction to routing table size. 43 This specification emphasizes extreme ease of transition to a new version of 44 IP that is as close to the existing version as is appropriate. Hence, this 45 specification is notable for attempting to fix only the current and urgent 46 problems and for neither solving nor precluding solution to less well- 47 understood problems. By utilizing a separately-defined protocol for the final 48 deployment, IPAE can be viewed as a transition technology, rather than as a 49 protocol, itself. 51 ACKNOWLEDGEMENTS 53 IPAE has had the benefit of on-going contribution by many members of the 54 Internet community, with very substantial changes and enhancements ensuing 55 from the collaborative group engineering process. Bob Hinden originally 56 suggested encapsulating one IP datagram inside another [HIND92b]. Dave 57 Crocker & Bob Hinden brought a modified idea -- to encapsulate new, global 58 addresses inside normal IP datagrams, using the IP address fields for "next 59 hop" carriage [HIND92a] -- to the IPAE working group. 61 While permitting very smooth transition, this left an end-state for IPAE which 62 was not a very clean, since the IPAE header is a hybrid. Bob Gilligan 63 observed similarities between IPAE's "mini-layer" and Deering's SIP design, 64 resulting in IPAE focus on SIP. Craig Partridge developed a very early code 65 analysis for implementing the original IPAE in the Berkeley kernel, permitting 66 much more concrete understanding of the implementation impact of the 67 encapsulation scheme and the general effects of increasing the IP address 68 size. Recent implementation work by Erik Nordmark and Bob Gilligan has added 69 to the base of empirical data. 71 The working group has included contributions from: Craig Partridge of BBN, 72 Tom Kessler, Erik Nordmark, and Bob Gilligan of Sun Microsystems, Steve 73 Deering of Xerox PARC, Greg Chesson, Ronald Jacoby,and and Rob Warnock of 74 Silicon Graphics, Hon Wah Chin and Dave Newman of Protocol Engines, Ross 75 Callon, Mike Reilly, Virgil Champlin and Geoff Mulligan of Digital Equipment, 76 Michael Conn of MCI, John Moy of Proteon, John Veizades of Apple, Jeffrey 77 Burgan of NASA, and Vince Fuller of BARRNET. 79 Internet Draft 2 11/11/92 - 2:30 PM (Expires: 5/93) 80 TABLE OF CONTENTS 82 STATUS OF THIS MEMO 83 SUMMARY 84 ACKNOWLEDGEMENTS 85 TABLE OF CONTENTS 86 1. PROBLEM STATEMENT: IP DEFICIENCIES 87 2. SOLUTION REQUIREMENTS 88 2.1. Address characteristics 89 2.2. Timing of benefits 90 2.3. Preservation of Installed Base 91 2.4. Transition Ease & Independence 92 3. IP ADDRESS ENCAPSULATION APPROACH 93 3.1. Encapsulation 94 3.2. Address Format 95 3.3. Interoperation 96 3.4. Translation 97 3.4.1 Transit Net(s) Only 98 3.4.2 IPAE Host to IPAE Host 99 3.4.3 IP Host to IPAE Host 100 3.4.4 IPAE Host to SIP Host 101 3.4.5 IP Host to SIP Host 102 4. IPAE PROTOCOL COMPONENTS 103 4.1. SIP Address Format 104 4.2. Datagram Formats 105 4.2.1 SIP Format 106 4.2.2 IPAE Format 107 4.3. ICMP & IGMP 108 4.4. Routing Protocol(s) 109 4.5. Transport & Above 110 4.5.1 Pseudo header checksum 111 4.5.2 TCP Connection ID 112 4.6. Subnetwork & Below 113 4.7. Network Management 114 5. IPAE HEADER FIELD MAPPINGS 115 5.1. SIP Derived from IP Datagrams 116 5.2. IP Derived from SIP Datagrams 117 5.3. Receipt of IPAE Datagrams 118 6. IPAE NETWORK COMPONENTS 119 6.1. Hosts 120 6.2. Interior Routers 121 6.3. Border Routers 122 7. IPAE ADDRESSING EXAMPLE 123 8. TRANSITION SEQUENCE 124 8.1. Initial Deployment of IPAE (Milestone I) 125 8.2. IPAE Deployment in Hosts (Milestone H) 126 8.3. Internet Runs Out of 32-Bit IPv4 Network Numbers (Milestone R) 127 8.4. Administrative Domains Fully Convert to SIP (Milestone S) 128 9. REFERENCES 129 10. CONTACTS 131 Internet Draft 3 11/11/92 - 2:30 PM (Expires: 5/93) 132 1. PROBLEM STATEMENT: IP DEFICIENCIES 134 The Internet is experiencing explosive growth, usually described as doubling 135 every 12 months. There is no indication that this growth will reduce and 136 development of IP use into mass markets would create an even steeper growth 137 curve. The result is a crisis in IP router table storage and use and in near- 138 term exhaustion of available IP network numbers. A variety of extensions to 139 current IP service also are desired, but they are not part of the current 140 operational crisis. 142 IP routers which record routes to all networks in the Internet must maintain 143 an entry for each such network, since the IP network address space is flat. 144 That is, neighboring networks do not necessarily have any similarity in the IP 145 network portion of their address. A new address structure is required, 146 probably with a hierarchical scheme, so as to allow route-aggregation in table 147 entries to neighboring networks. 149 While the 32-bits of the IP address space theoretically can reference about 4 150 billion nodes, the bits have been partitioned to faciliate assignment and 151 aggregation into networks, thereby reducing the realistic maximum number of 152 nodes and -- more importantly -- networks. While estimates vary considerably, 153 it is possible that IP network number exhaustion will occur within the next 154 few years. For example, IP could begin to make penetrations in mass markets. 155 Since the damage caused by being unable to assign new IP network numbers is so 156 great, it is prudent to pursue an urgent path to increasing the number of 157 bits. Again, there is debate about the total number of bits that is 158 necessary, with proposals ranging from 64-bits to 160-bits (as well as the 159 suggestion that there be no limit.) In any event, the Internet needs to 160 determine the size and format for a new, larger IP address. 162 Various additional enhancements to IP are being discussed, such as provision 163 for real-time data delivery (i.e., guaranteed throughput and delay), network- 164 level security features, and support for mobile hosts. While there is much 165 discussion about these, and other, issues they represent topics of interest, 166 rather than of concrete and stable experience and agreement. No proposals 167 have achieved concensus in the Internet and none have acquired a substantial 168 operational base. Hence, they must be deemed "research" for current purposes. 170 2. SOLUTION REQUIREMENTS 172 This section describes the the characteristics of the required solution that 173 are held to be primary by this specification. While not attempting to exclude 174 additional features and consideration, the specification does place particular 175 emphasis on its concern for the installed base of IP users, while providing 176 relief from the current technical and operational difficulties: 178 Internet Draft 4 11/11/92 - 2:30 PM (Expires: 5/93) 179 2.1. Address characteristics 181 The new version of IP must provide a hierarachical address, sufficient to 182 permit distributed assignment and administration and sufficient to permit 183 route-aggregation in IP forwarding devices (routers). A hierarchy which 184 recognizes country boundaries appears to be the most viable, administratively. 185 The address space must permit 10**9 networks. 187 2.2. Timing of benefits 189 The need for route aggregation is immediate. A specification must permit 190 reductions in route table size in the near term. It is preferred that a 191 router achieve this benefit as soon as the new version of IP is implemented in 192 a router. 194 2.3. Preservation of Installed Base 196 A specification for a new IP must consider the current installed base of 197 software and people. IP has an enormous installed base of operational 198 systems, as well as an installed base of people who provide, support and use 199 such systems. Each change to the existing technology carries the expense of 200 changes to people, software and operations. Given the size of the installed 201 base, the aggregate expense of each such change can be quite large, 202 particularly if it causes reduced utility to the Internet. 204 To this end, a specification must justify each and every change to formats, 205 terminology, services, software and operations, with respect to the current IP 206 Internet. This applies to IP, itself, as well as to related components, such 207 as the addressing framework, internetwork control, subnetwork interfaces and 208 transport-layer interfaces. 210 2.4. Transition Ease & Independence 212 Movement from the existing IP to its replacement will be accomplished over an 213 extended period of time. It must not require a highly coordinated change 214 throughout the Internet community, since the diversity of network 215 administrations and operations does not permit such coordination. Further, 216 movement to the new IP must be accomplished in a manner which permits network- 217 layer interoperation between users of the existing and new versions, for as 218 long as is operationally practical. Hence, this specification emphasizes 219 smooth and voluntary transitions, attempting to provide incremental benefit 221 Internet Draft 5 11/11/92 - 2:30 PM (Expires: 5/93) 222 when adopted, and imposes no changes that are not of fundamental and well- 223 understood benefit. 225 3. IP ADDRESS ENCAPSULATION APPROACH 227 This specification seeks to solve the technical problems of immediate concern 228 to the Internet and does not attempt to provide other, desired functional and 229 operational enhancements. Neither does it appear to preclude such 230 enhancements and there is some indication that its design will prove entirely 231 adequate for later inclusion of such enhancements. 233 While a variety of new protocols may satisfy the urgent addressing and routing 234 table concerns for the Internet, this specifications views concerns for 235 protecting the installed base as requiring the new protocol to have as little 236 difference from current IP as possible. Consequently, this specification 237 focusses on Simple IP (SIP), by Steve Deering, as the appropriate choice for 238 the new IP [DEER92a, DEER92b]. While the general IPAE transition scheme, 239 using encapsulation of the new protocol inside the old, can be applied to 240 other candidates, it appears that a number of transition benefits will not 241 accrue with those candidates. In particular, the packet and address 242 similarities to IPv4 greatly facilitate IPv4-SIP translation, which permits 243 combinations of interoperability tht permit an extremely wide range of 244 transition options. 246 At its simplest, IPAE envisions three phases to the adoption of a new IP: 248 IP -> IPAE -> SIP 250 Initially, all nodes use only the old IP. The goal is to operate all nodes 251 only with SIP. While it is expected that this end-state will take a very long 252 time to reach for the whole Internet, portions of the Internet may achieve 253 "pure" SIP operation rather quickly. Between the current use of IP and the 254 eventual use of SIP, there will be an extended period of partial adoption and 255 therefore requiring techniques for smooth transition and interoperation. IPAE 256 specifically attends to those requirements. 258 IPAE permits continued operation of IP-only hosts and IP-only routers. It 259 further supports SIP-knowledgeable hosts and routers. A host may operate SIP- 260 only, without any IP support, and/or may be able to encapsulate SIP within IP 261 datagrams, in an IPAE mode. Routers which support IPAE generally will serve 262 as "border" routers between IP and IPAE or SIP domains. The border routing 263 function can operate at a logical routing level above IP, using IP as a type 264 of subnetwork-layer service. A border router also can take native IP 265 datagrams and turn them into IPAE hybrid datagrams, when the router is acting 266 as an internetwork-layer gateway translation service. 268 Internet Draft 6 11/11/92 - 2:30 PM (Expires: 5/93) 269 3.1. Encapsulation 271 This specification defines a technique that is called "IP Address 272 Encapsulation" (IPAE) because it moves the Internet over to a new version IP 273 by allowing hosts and routers to upgrade, to the new addressing and datagram 274 format, in a manner that is transparent to nodes which have not yet made the 275 transition. The technique for accomplishing this is to encapsulate the new 276 protocol inside the old. Hence, users of the enhanced addressing scheme may 277 "tunnel" their datagrams over the existing IP infrastructure. Neighbors which 278 have completed conversion to the new IP can interoperate without 279 encapsulation, whenever that is convenient. 281 IPAE packets stacks as: 283 +-----------+ 284 | Transport | 285 +-----------+ 286 | SIP | 287 +-----------+ 288 | IP | 289 +-----------+ 290 | Link | 291 +-----------+ 293 3.2. Address Format 295 Support of interoperation between nodes using the old and new versions of IP 296 is best accomplished by defining the new IP address to contain old IP 297 addresses in its lower 32-bits. This is accomplished by conceptually 298 extending the network field or by adding one or more fields "above" the IP 299 Network field. Preserving the definition of the existing 32-bits permits 300 local operations to default the new bits, if they desire, and faciliates 301 translation between old and new IP datagrams. 303 Further the address, itself, must contain specification of the IP version (old 304 versus new) that is used by the referenced node. This feature eliminates the 305 need for routers at the border of an administrative domain to maintain state 306 information about their user nodes. Such reduced router and operations 307 complexity greatly facilitates transition to SIP. 309 Any new address format will dictate a change to the Domain Name Service and to 310 any protocol modules which are cognizant of IP addresses. While fundamental 311 to the success of an Internet transition, the details of such changes are 312 beyond the scope of this specification. Further, the details appear to be 313 identical for any IP replacement that is envisioned. 315 Internet Draft 7 11/11/92 - 2:30 PM (Expires: 5/93) 316 3.3. Interoperation 318 This specification supports interoperation between hosts supporting only the 319 old IP and those supporting only the new IP, through the use of a translation 320 service. Translation usually is a hand-crafted and operated service, with 321 limited ability to scale to large operations. However, this specification 322 supports general-purpose network-level translation between IP and SIP, as 323 desired. This is possible by ensuring that: 325 a) Host operating mode (old versus new IP) is detected easily, 327 b) Address formats map well and algorithmically, and 329 c) Header field semantics map well and algorithmically. 331 3.4. Translation 333 Translation can be provided by special routers, or by nodes themselves. The 334 latter facility is expected to permit interoperation between hosts operating 335 on the same network, particularly prior to conversion of the interior routers 336 for a network. Hence, nodes operating with the new version of IP may have an 337 implementation which treats the two versions of IP as entirely independent 338 network modules. Alternatively, a node may operate as if all datagrams are 339 coded as new IP datagrams and then treat translation to/from old IP as a 340 special case. 342 Transmission of new IP datagrams can be direct in their native form, 343 translated into an old IP format, or encapsulated with the new inside the old. 344 The first form is, of course, preferred. But it is expected that few nodes 345 will be able to utilize the new IP initially. Hence, the choice usually will 346 be between translation and encapsulation. If the next SIP hop is the 347 recipient (final) host, and that host supports only old IP, then the SIP 348 datagram must be translated into the format of an old IP datagram. If the 349 next SIP hop is an intermediate router and that router supports only old IP, 350 then the SIP datagram needs to be encapsulated in an IP datagram. 352 Note: In the following examples, "IPa", "IPb", and RIPcS represent three, 353 different IP headers, generated independently. For example, IPa might be 354 generated by the originating host, but might be discarded when the datagram is 355 translated into a "pure" SIP datagram. Later, a border router might need to 356 have the datagram transit an IP network and would create a fresh IP header 357 (IPb) derived from the SIP header. 359 Internet Draft 8 11/11/92 - 2:30 PM (Expires: 5/93) 360 3.4.1 Transit Net(s) Only 362 IPAE can be deployed without awareness of hosts: 364 Orig Router Router Router Router Dest 365 IP IPAE IP IPAE IP IP 366 | | | | | | | | | | 367 ----------- ----------- ----------- ----------- ----------- 368 +-----+ +-----+ +-----+ +-----+ +-----+ 369 | IPa | | SIP | | SIP | | IPa | | IPa | 370 +-----+ +-----+ +-----+ +-----+ +-----+ 371 | IPb | | IPb | 372 +-----+ +-----+ 374 This permits transit networks to employ IPAE for reduction of routing tables, 375 without waiting for host-level deployment, since routing can be based on the 376 structured SIP address rather than the flat IP address. 378 3.4.2 IPAE Host to IPAE Host 380 IPAE packets which move through the Internet between two IPAE hosts may 381 undergro modification, such as: 383 Orig Router Router Router Router Dest 384 IPAE IP IP IPAE IP IPAE 385 | | | | | | | | | | 386 ----------- ----------- ----------- ----------- ----------- 387 +-----+ +-----+ +-----+ +-----+ +-----+ 388 | SIP | | SIP | | SIP | | SIP | | SIP | 389 +-----+ +-----+ +-----+ +-----+ +-----+ 390 | IPa | | IPa | | IPa | | IPb | | IPb | 391 +-----+ +-----+ +-----+ +-----+ +-----+ 393 In this case, two IPAE hosts go through an Internet in which IPAE routers are 394 rare. This IPAE router discards the IP header it receives (IPa) and generates 395 a new one (IPb) just as it does with media frame headers, when relaying 396 between local area networks. 398 Internet Draft 9 11/11/92 - 2:30 PM (Expires: 5/93) 399 3.4.3 IP Host to IPAE Host 401 Common to early stages of deployment, a pure-IP host can talk with an IPAE or 402 pure-SIP host via an IP-accessible router: 404 Orig Router Router Router Router Dest 405 IP IP IPAE IP IPAE IPAE 406 | | | | | | | | | | 407 ----------- ----------- ----------- ----------- ----------- 408 +-----+ +-----+ +-----+ +-----+ +-----+ 409 | IPa | | IPa | | SIP | | SIP | | SIP | 410 +-----+ +-----+ +-----+ +-----+ +-----+ 411 | IPb | | IPb | | IPc | 412 +-----+ +-----+ +-----+ 414 This is generally identical to the previous example, except that the first 415 IPAE router also serves as an IP-to-IPAE translation gateway, deriving the 416 necessary SIP header from the IP header. 418 3.4.4 IPAE Host to SIP Host 420 As localities begin to support "pure" SIP operation, the following scenario 421 will occur: 423 Orig Router Router Router Router Dest 424 IPAE IP IP IPAE SIP SIP 425 | | | | | | | | | | 426 ----------- ----------- ----------- ----------- ----------- 427 +-----+ +-----+ +-----+ +-----+ +-----+ 428 | SIP | | SIP | | SIP | | SIP | | SIP | 429 +-----+ +-----+ +-----+ +-----+ +-----+ 430 | IP | | IP | | IP | 431 +-----+ +-----+ +-----+ 433 In this case, the IP header simply is stripped from the datagram and the SIP 434 portion continues on, to a pure-SIP host. 436 Internet Draft 10 11/11/92 - 2:30 PM (Expires: 5/93) 437 3.4.5 IP Host to SIP Host 439 Use of IPAE can be helpful even in only one router, to map between to 440 internetworks which employ IP-only and SIP-only: 442 Orig Router Router Router Dest 443 IP IP IPAE SIP SIP 444 | | | | | | | | 445 ----------- ----------- ----------- ----------- 446 +-----+ +-----+ +-----+ +-----+ 447 | IP | | IP | | SIP | | SIP | 448 +-----+ +-----+ +-----+ +-----+ 450 A key point, here, is that such pure gatewaying is a straightforward side- 451 effect of the IPAE principles, when coupled with similarity between IP and SIP 452 semantics. The gateway router behaves identically with a configuration of 453 IPAE border router which treats IP encapsulation as a side-effect and which 454 supports translation of IP into SIP. 456 4. IPAE PROTOCOL COMPONENTS 458 The primary change in IPAE is to the Internet layer. Other layers must be 459 changed whenever they use Internet addresses. In particular, some change is 460 necessary at the transport and application layers. 462 The IPAE proposal introduces two new Internet layer packet formats that we 463 refer to as SIP and IPAE. The SIP header is a revised version of the IPv4 464 header with larger addresses and streamlined functionallity. The IPAE header 465 is composed of a SIP header encapsulated within an IPv4 header. The IPAE 466 packet format is used to transit regions connected with IPv4 routers, while 467 the SIP packet format is used between directly connected IPAE/SIP hosts and 468 routers. 470 SIP is specified separately [DEER92a, DEER92b], but details are summarized in 471 this specification, to facilitate discussion. 473 4.1. SIP Address Format 475 The the basic requirement driving the current effort is to provide enough 476 additional bits to support global administration, with 2 or more levels of 477 hierarchy above the existing IP address portion, and the top level referencing 478 country. 480 Internet Draft 11 11/11/92 - 2:30 PM (Expires: 5/93) 481 Given the goal of facilitating transition to SIP, IPAE-related operation 482 requires enhancements to the current IP address, beyond the base requirement 483 for a larger address space. These requirements are: 485 a) A bit indicating whether the referenced host is using old or new IP; this 486 eliminates the need for routers that provide translation gatewaying to 487 maintain state tables about the capabilities of specific hosts; and 489 b) Preservation of the existing format for 32-bit IP addresses, within the 490 new format, to faciliate local interoperation between old and new IP hosts. 492 The resulting SIP address specification is: 494 1 15 32 16 495 +-+--------+--------+--------+--------+ 496 | |Country+|Site / Subscriber| Local | 497 |C|Provider|..........................| 498 | |/ Metro | | IP Address | 499 +-+--------+--------+--------+--------+ 500 C Region Attachment Local 502 C (IP Compatibility) bit is 0 for IPAE/SIP destination, 1 503 for IP destination 505 Multicast is encoded by a special country code. 507 The C-bit is used to indicate the capabilities of the referenced node. If the 508 bit is zero, then the node supports SIP, and possibly IPAE. (In reality, IPAE 509 is viewed as a per-hop encapsulation technique, so that its use depends upon 510 the characteristics of the next-hop node, rather than upon the end-system.) 512 The Region field is used for global routing and includes the top of the 513 addressing hierarchy which is the country having assignment authority. 514 Subordinate to this is specification either of the service provider for the 515 referenced subscriber or the metropolitan area of the site's attachment to the 516 Internet. 518 Service providers assign Subscriber IDs. Locations operating with coordinated 519 metropolitan interchanges (MIX) may use Country+Metro code and then assign 520 Site IDs. 522 The last 4 bytes of an address function as a IPv4 address. However, the 523 actual boundary between IP address and Site/Subscriber information varies. In 524 effect, Site/Subscriber is an extension to the network portion of the IP 525 address. 527 Until IP network number space is exhausted, 32-bit IP addresses will be 528 assigned according to current practise, so that providers (and MIX operations) 530 Internet Draft 12 11/11/92 - 2:30 PM (Expires: 5/93) 531 will assign only the upper 32 bits of a SIP address. Later, they also will 532 assign those bits currently used to specify the IP Network field. 534 Hence, the transition model permits an independent network site (an 535 "administrative domain", or AD) to operate internally with 32-bit IP addresses 536 and to pre-pend an additional 32 bits for global routing. If an AD network is 537 multi-homed to the Internet, then the bottom-half of its two SIP addresses 538 will be the same, during the transition period. After IP network number 539 exhaustion, the current specification of SIP means that an AD may have a 540 single "host" field (subnetwork and host) as currently used by IP, but 541 different network addresses for each point of attachment and one more for IP 542 internal exchanges. 544 4.2. Datagram Formats 546 IPAE/SIP hosts may transmit packets using any of the three packet formats: 547 IPv4, IPAE, or SIP. IPAE/SIP hosts must be able to receive packets in all 548 three packet formats. 550 4.2.1 SIP Format 552 The SIP header is a revision of IP version 4 header format SIP shares all of 553 the datalink layer encapsulations that have been defined for IPv4. A new IP 554 version number differentiates SIP from IP version 4. This is the format of the 555 SIP header: 557 0 3 15 23 31 558 +---+------------+---------+---------+ 0 559 |V=6| RESERVED | 560 +---+------------+---------+---------+ 4 561 | DATA LENGTH | HOP LMT | PAYLOAD | 562 +----------------+---------+---------+ 8 563 | | 564 + Global IP Source Address + 565 | | 566 +------------------------------------+ 12 567 | | 568 + Global IP Destination Address + 569 | | 570 +------------------------------------+ 16 571 | Data | 572 | | 574 Internet Draft 13 11/11/92 - 2:30 PM (Expires: 5/93) 575 4.2.2 IPAE Format 577 The IPAE packet format uses the SIP header encapsulated within an IPv4 header. 578 This is the format of the IPAE header, with relevant portions of the IP header 579 labeled. 581 0 3 7 15 23 31 582 --------- +---+---+--------+---------+---------+ 0 583 |V=4| | Length | 584 +---+------------+-------------------+ 4 585 | | 586 Current +-------+--------+-------------------+ 8 587 IP | TTL |PTCL=SIP| | 588 Header +-------+--------+-------------------+ 12 589 | Source IP Address | 590 +------------------------------------+ 16 591 | Destination IP Address | 592 +------------------------------------+ 20 593 | IP Options (if present) | 594 | | 595 --------- +---+------------+---------+---------+ 20+n0 596 |V=6| RESERVED | 597 +---+------------+---------+---------+ 24+n0 598 | DATA LENGTH | HOP LMT | PAYLOAD | 599 Extended +-------+--------+-------------------+ 28+nO 600 IP | | 601 Header + Global IP Source Address + 602 | | 603 (SIP) +------------------------------------+ 36+nO 604 | | 605 + Global IP Destination Address + 606 | | 607 -------- +------------------------------------+ 44+nO 608 | Data | 609 | | 611 Note: nO is size of IP options in octets. 613 When the IPAE format is used, the destination and source IP addresses located 614 in the IPv4 header target the next hop IPAE/SIP system along the path to the 615 destination. In both the SIP and IPAE formats, the global IP source and 616 destination addresses identify the end systems. It is the global source and 617 destination addresses located in the SIP header that are used by UDP and TCP 618 to uniquely identify transport endpoints. 620 Most of the features of IPv4, including options and fragmentation and 622 Internet Draft 14 11/11/92 - 2:30 PM (Expires: 5/93) 623 reassembly, are available in SIP. Thus it is possible to map an IPv4 packet 624 into an IPAE or SIP packet and vice versa. Options are carried in SIP by 625 using defined Payload values and the last SIP Option header contains the 626 actual transport Payload value. When Options are present, the Global 627 destination address references the host that is to process the option. 629 4.3. ICMP & IGMP 631 The SIP specification defines any required ICMP and IGMP changes or 632 extensions. Use of IPAE adds no further requirements, except for relaying 633 ICMP messages from IP-only routers to IPAE/SIP source hosts. 635 An IPAE datagram that traverses an IP network may result in having an IP-only 636 interior router generate an ICMP error message. The router will specify a 637 destination for the ICMP datagram which is, in reality, the previous IPAE 638 border router, rather than the originating IPAE (or SIP) host. The border 639 router must function as an ICMP relaying service, when possible, as discussed 640 in the section on Border Routers, below. 642 4.4. Routing Protocol(s) 644 IPAE uses SIP and IP routing mechanisms. An administrative domain is free to 645 use any acceptible IP routing protocol, among is interior routers, with an 646 appropriate rule for deriving 32-bit addresses from the larger SIP addresses. 648 4.5. Transport & Above 650 IPAE imposes no special requirements on applications or transport, except for 651 pseudo-header checksum calculation. Any development of a larger IP address 652 will directly affect programming interfaces and some application protocols, 653 since they use current IP addresses directly. Primarily, enhancements appears 654 to be straightforward and simply need to handle the larger string, often 655 simply as an uninterpreted string. 657 A node may implement IPAE (i.e., SIP over IP) as a special network-level 658 interface or may make it equivalent to a subnetwork-/link-level option for 659 SIP. In the former case, the transport layer needs to select IPAE from the 660 set of alternatives, including IP and SIP. In the latter case, the transport 661 layer selects a generic internet layer which, in turn, chooses IP, SIP or IPAE 662 to get to the next (or final) SIP node. 664 TCP and UDP must be modified somewhat in order to be layered above IPAE and 666 Internet Draft 14 11/11/92 - 2:30 PM (Expires: 5/93) 667 SIP. Changes are needed to the "pseudo-header" used in the checksum 668 algorithm, and to TCP's connection or socket identification algorithm. 670 4.5.1 Pseudo header checksum 672 The TCP spec [RFC793] and the UDP spec [RFC768] both define a checksum that 673 covers the data portion of the segment along with a 96-bit "pseudo header" 674 that includes the IP source and destination addresses, protocol ID and length 675 fields from the IP header. Including this pseudo header in the transport 676 checksum protects the transport layer against misrouted segments. 678 The pseudo header used in the transport checksum when TCP and UDP are layered 679 above IP can viewed logically as this: 681 0 7 15 31 682 +--------+--------+--------+--------+ 683 | source address | 684 +--------+--------+--------+--------+ 685 | destination address | 686 +--------+--------+--------+--------+ 687 | zero |protocol| length | 688 +--------+--------+--------+--------+ 690 Inclusion of a pseudo header that covers the addresses in the checksum of TCP 691 and UDP layered above IPAE and SIP is even more important since the SIP header 692 is not checksummed. 694 When communicating with other IPv4/IPAE/SIP hosts, the TCP and UDP pseudo 695 header includes the complete global source and destination addresses. But 696 since the IPAE mechanism allows IPv4 packets to be translated into IPAE or SIP 697 and vice-versa, the IPv4/IPAE/SIP host must implement a compatible pseudo- 698 header checksum when the packets it receives originated from, or the packets 699 it is sending are destined for, an IPv4 host. The IPv4/IPAE/SIP pseudo header 700 checksum algorithm must cover only the low-order 32 bits of the global 701 addresses when it is communicating with an IPv4 host. When transmitting, the 702 IPv4/IPAE/SIP host can use the C-bit of the global destination address to 703 determine whether the peer is an IPv4 host. When receiving, the C-bit of the 704 global source address can be used. 706 When communicating with an IPv4 host using the IPv4 packet format directly 707 (e.g., an IPv4 host on the same subnet), the 96 bit pseudo header shown above 708 is used. 710 Internet Draft 16 11/11/92 - 2:30 PM (Expires: 5/93) 711 When sending or receiving packets in the IPAE or SIP format to another 712 IPv4/IPAE/SIP host the following pseudo header is used when the processing 713 node is: 715 1) Transmitting and C-bit of Global Destination Address is 0, or 717 2) Receiving and C-bit of Global Source Address is 0 719 0 7 15 31 720 +--------+--------+--------+--------+ 721 | zero |protocol| length | 722 +--------+--------+--------+--------+ 723 | | 724 + Global source address + 725 | | 726 +--------+--------+--------+--------+ 727 | | 728 + Global destination address + 729 | | 730 +--------+--------+--------+--------+ 732 IPAE/SIP peer pseudo header 734 When sending or receiving packets in the IPAE or SIP format to an IPv4 host 735 the following pseudo header is used when the processing node is: 737 1) Transmitting and C-bit of Global Destination Address is 1, or 739 2) Receiving and C-bit of Global Destination Address is 1. 741 0 7 15 31 742 +--------+--------+--------+--------+ 743 | zero |protocol| length | 744 +--------+--------+--------+--------+ 745 | zero | 746 +-----------------------------------+ 747 | 32-LSB of global source addr | 748 +--------+--------+--------+--------+ 749 | zero | 750 +-----------------------------------+ 751 | 32-LSB of global destination addr | 752 +--------+--------+--------+--------+ 754 IPAE/SIP - IPv4 compatible 755 pseudo-header 757 Internet Draft 16 11/11/92 - 2:30 PM (Expires: 5/93) 758 4.5.2 TCP Connection ID 760 TCP uses the concatenation of local and remote IP address with local and 761 remote port number to uniquely identify a connection. TCP uses the term 762 "socket" to identify one endpoint of a connection. The local socket is 763 identified by the local IP address and local port number, while the remote 764 socket is identified by the remote IP address and remote port number. 766 In processing received segments and ICMP error messages, TCP must use the 767 destination IP address and port number -- and possibly the source IP address 768 and port number -- from the received segment in a lookup in its list of 769 connection blocks in order to find a matching socket or connection. When 770 communicating with another IPv4/IPAE/SIP host, TCP host must use the full 771 global source and destination addresses to identify connections and sockets. 772 But when communicating with IPv4 hosts using the IPAE or SIP packet formats, 773 TCP must use only the low order 32 bits of global source and destination to 774 identify the connection. 776 This requires a change to TCP's connection block lookup for received segments. 777 Assuming that TCP keeps a single list of connection blocks identifying 778 connections to both IPv4 hosts and IPv4/IPAE/SIP hosts, the change can be 779 summarized like this: 781 1) If the format of the received packet is IPv4, 782 Then: 783 use the source and destination IP addresses in the 784 received packet to compare with the low-order 32 bits of 785 the global source and destination address in TCP's 786 connection block list, 787 Else: 789 2) If the format of the received packet is IPAE or SIP, 790 And: 792 2a) If the C-bit of the global source address is 1, 793 Then: 794 use the low-order 32 bits of the global source and 795 destination addresses in the packet to compare the 796 low-order 32 bits of the global source and 797 destination address in the connection block list, 798 Else: 800 2b) If the C-bit of the global source address is 0, 801 Then: 802 use the full global source and destination addresses 803 in the packet to compare with the full global source 804 and destination addresses in the connection block 805 list. 807 Internet Draft 17 11/11/92 - 2:30 PM (Expires: 5/93) 808 4.6. Subnetwork & Below 810 IPAE, as SIP-over-IP, employs standard IP-over-media capabilities. SIP-over- 811 media will use the same mechanisms as IP currently uses. Hence, there are no 812 changes to use of ARP, or the like. Note that host references internal to an 813 administrative domain will require 32-bits or less, as they do now, so that 814 the upper 32-bits of SIP address space are not required for subnetwork 815 references. 817 4.7. Network Management 819 Management within an AD can continue to operate, without change, since nodes 820 retain their IP addresses. For global management, MIB specifications must be 821 enhanced to accomodate the larger addresses. There is no expectation of 822 additional protocol changes. 824 5. IPAE HEADER FIELD MAPPINGS 826 By keeping the semantic details of the new IP and the old IP closely related, 827 it is possible to map between the header fields of either, greatly 828 facilitating support of internetwork-level translation gateways. Three cases 829 need to be supported: Turning an IP datagram into a SIP or IPAE (SIP-over-IP) 830 datagram, generation of an IP header from a SIP header, and general handling 831 of a received IPAE (SIP-over-IP) datagram. 833 5.1. SIP Derived from IP Datagrams 835 If a router supports IPAE for hosts that use only IP, then the router is a 836 border IPAE router that also provides internetwork-level translation 837 gatewaying. That is, it turns IP datagrams into SIP datagrams. It may also 838 then send the SIP datagram onward, within an IP encapsulation, but this is a 839 separate function from gateway translation. 841 On receipt of an IP datagram that is determined to be destined for a SIP host 842 or that is otherwise in need of a SIP header, the gateway module will map IP 843 fields into SIP fields as follows: 845 Hop Limit: The value of the IP Time To Live field shall be copied into SIP 846 Hop Limit field. (This presumes that the router has already performed its own 847 decrement to the IP TTL field.) Though TTL has slightly different semantics, 849 Internet Draft 18 11/11/92 - 2:30 PM (Expires: 5/93) 850 there is no need to perform a more complicated translation. 852 Payload: The value of the IP Protocol field shall be copied into the SIP 853 Payload field. 855 Source Address: The value of the Source IP Address shall be mapped to a SIP 856 Global Source Address, as appropriate. Usually, this will require pre-pending 857 a constant value to the Source's IP address. 859 Destination Address: The value of the Source IP Address shall be mapped to 860 the SIP Global Destination Address, as appropriate. Border routers will 861 support a table for such mappings. While IP addresses remain globally unique, 862 this table can be maintained through the Domain Name Service or other 863 coordinated Internet service. 865 Options: If the IP datagram contains options, then each shall be mapped to 866 the appropriate SIP option, as appropriate. Options which do not map are 867 dropped. Note that creation of SIP options alters the value of the SIP 868 Payload value, placing the actual value into the Payload field of the SIP 869 Option mini-layer. 871 Other fields: All remaining IP fields are ignored. 873 5.2. IP Derived from SIP Datagrams 875 When a border router needs to create an IP header, either for the purpose of 876 IPAE encapsulation to achieve transit through an IP-only domain, or to 877 translate the SIP header for receipt by an IP-only host, the router shall 878 perform the following mappings: 880 TTL: The value of the SIP Hop Limit field shall be copied into the IP Time To 881 Live field. (This presumes that the router has already performed its own 882 decrement to the SIP Hop Limit field.) 884 Protocol: The value of the SIP Payload field shall be copied into the IP 885 Protocol field. 887 Source Address: The value of the SIP Global Source Address shall be mapped to 888 the IP address of the source, if the router has determined that the datagram 889 is traversing its final IPAE hop, that is, if it being delivered to the 890 recipient host, or if it is being fully converted to an IP-only datagram. 891 While IP addresses remain globally unique, the value of the IP Source Address 892 field is the value of the lower 32-bits of the SIP Global Source Address. 894 If the IP header is to serve an encapsulation function, with the SIP header 895 being retained, then the Source Address shall contain the IP address of the 897 Internet Draft 19 11/11/92 - 2:30 PM (Expires: 5/93) 898 border router that is creating the IP header. 900 Destination Address: The value of the SIP Global Destination Address shall be 901 mapped to the IP address of the destination, if the router has determined that 902 the datagram is traversing its final IPAE hop, that is, if it is being 903 delivered to the recipeint host, or if it is being fully converted to an IP- 904 only datagram. While IP addresses remain globally unique, the value of the IP 905 Destination Address field is the value of the lower 32-bits of the SIP Global 906 Destination Address. 908 If the IP headers is to serve an encapsulation function, with the SIP header 909 being retained, then the Destination Address shall contain the IP address of 910 the next IPAE-knowledgeable hop. 912 5.3. Receipt of IPAE Datagrams 914 An IPAE datagram contains a SIP header and an IP header. The IP header is for 915 the purpose of permitting transit of the SIP datagram through IP-only 916 networks. Hence, the IP header should not be viewed as containing the end-to- 917 end information. However, the similarity between SIP/IP relationship and 918 IP/Link relationship has one significant difference: The SIP header needs to 919 reflect changes to the IP header that occur during transit. 921 In particular, an IPAE router needs to update the SIP header fields in the 922 following manner: 924 Hop Limit: The value of the IP Time to Live field is copied into the SIP Hop 925 Limit field. Hence, the SIP Hop Limit count must be adequate to count both 926 SIP-knowledgeable and IP-only hops. 928 Other fields: Values in all other IP fields may be ignored. 930 6. IPAE NETWORK COMPONENTS 932 6.1. Hosts 934 An IPAE host supports IP, SIP and SIP-over-IP. An originating IPAE host must 935 be able to derive an IP header from the SIP header, in order to create the 936 SIP/IP encapsulation. 938 Internet Draft 20 11/11/92 - 2:30 PM (Expires: 5/93) 939 6.2. Interior Routers 941 For IPAE operation, it is presumed that the interior routers of an 942 administrative domain are not IPAE-aware and hence need no modification, since 943 they will transmit the IPAE datagram on the basis of the IP encapsulating 944 datagram. However, administrative domains are expected to convert their 945 routers over to use of IPAE and/or SIP, eventually, in which case their 946 behavior for doing IP/SIP translation, address mapping, and the like will be 947 similar to that of a border router. 949 6.3. Border Routers 951 An IPAE/SIP border router performs the following basic functions: 953 a) Typical router store-and-forward relaying, for SIP datagrams, 955 b) Participation in local IP infrastuctures, sufficiently to appear to other 956 IP routers as if the border router is also an IP router, 958 c) IP-base encapsulation/decapsulation of SIP datagrams, and 960 d) Translation gateway creation of a SIP header based on the contents of an 961 IP header, and vice-versa. 963 SIP routing functions are discussed in [DEER92b]. 965 Encapsulation/decapsulation functions are to be performed using the derivation 966 rules specified in the previous section. 968 It is expected that conversion of IP datagrams to SIP or IPAE datagrams will 969 permit the converting border router in an AD to maintain smaller routing 970 tables, immediately. For IP, router tables include a source information base 971 with a copy of the information about all Internet nets, for each of the 972 router's neighbors. For SIP, the table still needs to maintain a copy of the 973 information received from each neighbor, but it can be reduced to a portion of 974 the global hierarchy, such as all countries, as well as all "local" networks 975 of interest. 977 Currently for IPv4, the real-time information base used to make direct 978 datagram forwarding decisions needs to have an entry for each network on the 979 Internet. For SIP, it needs to have only the relevant portions of the 980 hierarchy, so that the table information about Internet neighbors can share 981 the same entry. 983 Internet Draft 21 11/11/92 - 2:30 PM (Expires: 5/93) 984 7. IPAE ADDRESSING EXAMPLE 986 The relationship between IP and SIP addressing, particularly when both are 987 present in an IPAE datagram, appears to be the greatest source of confusion 988 concerning IPAE dynamics. This section provides an extended example of the 989 end-to-end handling of both types of addresses as a datagram moves through the 990 Internet. 992 Notation: IP addresses are represented in the usual, four decimal fields, 993 separated by periods. SIP addresses also use a decimal dotted notation, 994 showing Country.Metro/Provider.Site/Subscriber, followed by the site's IP 995 address. The SIP portion is separated from the IP portion by a slash. 996 Reference to IP or SIP networks, without referencing specific nodes on those 997 networks, uses only the network portion of the address. For example, a Class 998 C IP network would be shown as the first 3 octets of its address, such as 999 192.3.4. A SIP network address would show only the first 4 octets of the 64- 1000 bit address, indicating only the Region and Metro/Provider. 1002 IPAE forms a set of logical networks "above" the set of IP networks, so that 1003 one or more IP networks are the equivalent of IPAE subnetworks. Hence, IPAE 1004 network boundaries occur only at IPAE routers. In this example, note that the 1005 last system of the first line (Router IPAEx) is the same as the first system 1006 on the second line. 1008 This shows one intermediate IPAE hop, with an intermediate IP hop between the 1009 originating host and the IPAE router, and another between the IPAE router and 1010 the destination host. The transit sequence for the datagram is: 1012 SIP Net <- 1.213.77. -> || 1013 IP Net <- 192.3.4. | <- 128.1. -> || 1014 | || 1015 Node: H(IP-O) R(IPa) R(IPAEx)... 1016 |1:213:77:5/ | | 1:213:77:5/| 1017 |192.3.4.1 | | 128.1.1.2| 1018 | | | | 1019 | 192.3.4.2| |128.1.1.1 | 1020 | | | | 1021 -------->-------- ------>-------- 1022 Datagram: SIP SIP 1023 SRC:1:213:77:5: SRC:1:213:77:5: 1024 192.3.4.1 192.3.4.1 1025 DST:1:2:2:8: DST:1:2:2:8: 1026 201.5.7.250 201.5.7.250 1027 ----------------- ----------------- 1028 IP IP 1029 SRC: 192.3.4.1 SRC:192.3.4.1 1030 DST: 128.1.1.2 DST:128.1.1.2 1032 Internet Draft 22 11/11/92 - 2:30 PM (Expires: 5/93) 1033 SIP Net || <- 1.002.2. -> 1034 IP Net || <- 10. | 201.5.7. -> 1035 || | 1036 Node: ...R(IPAEx) R(IPb) H(IPAE-D) 1037 |1.2.2.75: | | 1.2.2.8:| 1038 |10.0.0.3 | | 201.5.7.250| 1039 | | | | 1040 | 10.1.2.3| |201.5.7.9 | 1041 | | | | 1042 -------->-------- ------->------- 1044 Datagram: SIP SIP 1045 SRC:1:213:77:5: SRC:1:213:77:5: 1046 192.3.4.1 192.3.4.1 1047 DST:1:2:2:8: DST:1:2:2:8: 1048 201.5.7.250 201.5.7.250 1049 ----------------- ---------------- 1050 IP IP 1051 SRC:10.0.0.3 SRC:10.0.0.3 1052 DST:201.5.7.250 DST:201.5.7.250 1054 The pattern of manipulation to observe is that the SIP source and destination 1055 address fiels are unchanged. The IP source and destination addresses show the 1056 addresses of the IPAE nodes for the specific SIP hop and are unchanged when 1057 passing through an IP-only router. 1059 8. TRANSITION SEQUENCE 1061 The transition plan for IPAE is based around a timeline which has a number of 1062 milestones. The timeline is as follows: 1064 | | 1065 |----------|---------|----------|-----------|--------------| 1066 | | 1068 TODAY -> I H R S -> FUTURE 1070 Milestone I is the initial deployment of IPAE in selected Border Routers. 1071 Milestone H is large scale deployment of IPAE in Hosts. Milestone R is when 1072 the Internet runs out of the current 32-bit IP addresses. Milestone S 1073 indicates large scale conversion of administrative domains to pure SIP 1074 operations. Each milestone in the transition plan is discussed in the 1076 Internet Draft 23 11/11/92 - 2:30 PM (Expires: 5/93) 1077 following sections. 1079 The first objective of the transition plan is to install IPAE in critical 1080 router locations. This will reduce the size of routing tables and the load 1081 of routing computation in the Internet. The authors of this proposal believe 1082 this is very important to keep the Internet growing. It will be done without 1083 any changes to hosts. 1085 The second objective is to install IPAE in hosts before the current 32-bit IP 1086 network addresses are all allocated. This will permit an orderly transition 1087 to a global routing and addressing scheme with a minimum of disruption to the 1088 existing internet. 1090 As an administrative domain comes to use IPAE universally, then it may decide 1091 to permit pure SIP exchanges, without IPAE encapsulation. 1093 8.1. Initial Deployment of IPAE (Milestone I) 1095 The first step of IPAE deployment is to define the first SIP administrative 1096 domains. Initially these should be large areas of the Internet, such as 1097 portions of a single continent. The goal is to reduce the amount of routing 1098 traffic and the size of routing tables by an order of magnitude or more. 1100 The first deployment of IPAE will occur in border routers. The border routers 1101 will create the first SIP administrative domains. However, at that time the 1102 current 32-bit IP addresses will still be globally unique. This will allow 1103 the border routers to look up the global IP addresses from the 32-bit IP 1104 addresses and build packets with extended IP headers for the hosts. The hosts 1105 will not have to implement IPAE in the first stage of deployment. The benefit 1106 of this stage of the deployment will be to reduce the size of routing tables 1107 in border routers and to reduce the routing computation load on these routers. 1108 The functions performed by the border routers are primarily of 1109 inserting/removing SIP headers and looking up Global IP addresses based 32-bit 1110 addresses. 1112 Several approaches are possible for the procedure to lookup the Destination 1113 Global IP Address. One approach is a static table kept in the border routers. 1114 The mappings in this table would be based on the number of networks in the 1115 Internet. While this would be a large table towards the time the existing 32- 1116 bit IP Address space runs out, even then it would be possible to maintain this 1117 table within the small set of border routers. 1119 Another approach is to use the Internet's Domain Name System to maintain this 1120 mapping table. The DNS is well-suited to this task and it would be a 1121 straightforward extension to add the information required. This approach has 1122 the border routers periodically performa a DNS lookup to obtain recent 1124 Internet Draft 24 11/11/92 - 2:30 PM (Expires: 5/93) 1125 additions to the routing table. (That is, the DNS would provide a means of 1126 maintained a distributed copy of the Internet address mappings.) This would 1127 require careful engineering of the border router/DNS interactions to prevent 1128 their becoming a bottleneck. It is expected that the size of the resulting 1129 cache in border routers will be much smaller in size than with current 1130 operations because most Internet traffic tends to stay in its own IPAC and 1131 only a small percentage of total networks will pass through a border router. 1133 It should be noted that any requirements for address mapping, whether static 1134 or via the DNS, are in no way specific to the IPAE proposal. Any scheme which 1135 wishes to provide communication among old-style hosts and new-style hosts 1136 having a different address format will require some type of address 1137 translation. IPAE simply makes the mapping process easier than would be 1138 required if the new address format were entirely unrelated to old-style IP 1139 addresses. 1141 8.2. IPAE Deployment in Hosts (Milestone H) 1143 The second phase of IPAE deployment is deployment to Internet hosts. Hosts 1144 will need to be able to support both IPv4 Headers format and IPAE/SIP Header 1145 format. They will use IPv4 Headers when communicating within their 1146 administrative domain and will use SIP Headers when communicating with hosts 1147 in different domains. 1149 The goal for this phase of IPAE deployment it to have the majority of Internet 1150 hosts implement IPAE before the Internet runs out of 32-bit IP addresses. 1151 While it is not possible to have every host implement IPAE, there is 1152 sufficient time before Milestone R occurs that it can be implemented by the 1153 vast majority, since the amount of new software, documentation and training 1154 required will be quite small. This will reduce the need for address 1155 translation support in the next phase of deployment. 1157 8.3. Internet Runs Out of 32-Bit IPv4 Network Numbers (Milestone R) 1159 At the third phase of the IPAE deployment, hosts which do not implement IPAE 1160 will be able to communicate directly only with hosts in their own 1161 administrative domain, via IP. There are several possible methods to extend 1162 their connectvity if it is necessary to provide these hosts with global 1163 Internet service. One straightforward approach is to stage their 1164 communication through a host which supports IPAE. This would permit services 1165 such as electronic mail and news to operate transparently. Even in today's 1166 Internet, mail service often operates in this fashion. Other services such as 1167 Telnet and FTP would require an application-level forwarding agent or double 1168 login. 1170 Internet Draft 25 11/11/92 - 2:30 PM (Expires: 5/93) 1171 Another approach is to perform automatic address mapping. Various schemes are 1172 possible to support this and IPAE imposes no special constraints on the 1173 choices. 1175 8.4. Administrative Domains Fully Convert to SIP (Milestone S) 1177 The final stage of IPAE deployment is the demise of IPAE usage within 1178 individual administrative domains. As neighboring domains support pure SIP, 1179 then the border routers between them can be configured to omit the IPAE SIP- 1180 over-IP encapsulation for inter-domain exchanges. It is important to note, 1181 however, that decisions to permit pure SIP operation are entirely at the 1182 discretion of the local administrations, rather than requiring larger, 1183 Internet coordination. 1185 9. REFERENCES 1187 [BRAD89a] Braden, R.T., RFC 1127: Perspective on the Host Requirements RFCs. 1188 1989 October. 1190 [BRAD89b] Braden, R.T., ed., RFC 1122: Requirements for Internet hosts - 1191 communication layers. 1989 October. 1193 [BRAD89c] Braden, R.T.,ed., RFC 1123: Requirements for Internet hosts - 1194 application and support. 1989 October. 1196 [DEER92a] Deering, S. Simple Internet Protocol (SIP) Specification. 1992 1197 November. 1199 [DEER92b] Deering, S. Simple Internet Protocol (SIP) Addressing and 1200 Routing. 1992 November. 1202 [E.163] CCITT, Numbering Plan for the International Telephone Services. 1204 [HIND92a] Hinden, B., "New Scheme for Internet Routing and Addressing 1205 (ENCAPS)", Email message to Big-Internet mailing list, March 16, 1992 1207 [HIND92b] A Proposal for IP Address Encapsulation (IPAE): A Compatible 1208 Version of IP with Large Addresses; (draft, June 1992) 1210 [WOOD92] Woodburn, R & D. Mills, "A Scheme for an Internet Encapsulation 1211 Protocol: Version 1", RFC 1241. July 1991. 1213 Internet Draft 26 11/11/92 - 2:30 PM (Expires: 5/93) 1214 10. CONTACTS 1216 David H. Crocker 1218 The Branch Office 1219 675 Spruce Dr. 1220 Sunnyvale, CA 94086 1222 +1 408 246 8253 1224 Robert Hinden 1226 Sun Microsystems, Inc. 1227 MS MTV-44 1228 2550 Garcia Avenue 1229 Mountain View, CA 94043-1100 1231 +1 415 336 2082