idnits 2.17.1 draft-iab-ipversion7-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-25) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (July 1992) is 11607 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: 'RFC-1287' is mentioned on line 88, but not defined == Unused Reference: 'CLNP' is defined on line 681, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CIDR' -- Possible downref: Non-RFC (?) normative reference: ref. 'CLNP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ES-IS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEN-005' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPAE' ** Obsolete normative reference: RFC 1237 (ref. 'OSI-NSAP') (Obsoleted by RFC 1629) ** Downref: Normative reference to an Informational RFC: RFC 1174 -- Possible downref: Non-RFC (?) normative reference: ref. 'Realtime' -- Possible downref: Non-RFC (?) normative reference: ref. 'ROAD' ** Downref: Normative reference to an Historic RFC: RFC 1347 (ref. 'TUBA') Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Internet Architecture Board 3 July 1992 4 Expires: January 1993 6 IP Version 7 7 **DRAFT 8** 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six months. 17 Internet Drafts may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet Drafts 19 as reference material or to cite them other than as a ``working 20 draft'' or ``work in progress.'' 22 Please check the 1id-abstracts.txt listing contained in the internet- 23 drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, 24 ftp.nisc.sri.com, or munnari.oz.auto to learn the current status of 25 any Internet Draft. 27 Abstract 29 Internet growth has created serious problems of address space 30 consumption and routing information explosion. A solution to these 31 problems requires a new version of the Internet Protocol, which we 32 call IP version 7 ("IPv7"). This memo presents architectural 33 guidelines that any IPv7 should meet. It then discusses how an IPv7 34 based upon the OSI CLNP protocol would meet these requirements, and 35 presents the reasons for the IAB's preference for this solution. 36 Finally, it makes a three-part recommendation: (1) proceed at full 37 speed on CIDR; (2) do the design work on IPv7 based on CLNP; and (3) 38 continue to pursue research in advanced routing and other future 39 extensions of the Internet architecture. 41 TABLE OF CONTENTS 43 1. INTRODUCTION .................................................. 2 44 2. ARCHITECTURAL PRINCIPLES ...................................... 4 45 3. POSSIBLE APPROACHES TO IPv7 ................................... 9 46 4. RESEARCH AREAS ................................................ 13 47 5. THE WAY FORWARD ............................................... 14 48 REFERENCES ....................................................... 15 50 1. INTRODUCTION 52 1.1 The Need for IPv7 54 The rapid growth of the Internet has exposed the consequences of a 55 design choice made 15 years ago, the choice of a fixed-length 32- 56 bit address field for IP [IEN-005]. At that time, 32 bits appeared 57 to be a very wide field, allowing many thousands of networks and 58 millions of hosts, several orders of magnitude beyond the likely 59 size of the Internet. However, the Internet has now grown to this 60 order of magnitude, leading to two different scaling problems: 62 * Routing Information Explosion 64 The cost and complexity of Internet routing grow very rapidly 65 with the number of networks. This growth is creating 66 increasingly serious operational problems. 68 * Address Space Consumption 70 Current IP addresses are 32 bits. While this seems to be a 71 very large number (4*10**9), its division into host and 72 network parts and into class A, B, and C networks 73 significantly reduces the available space. Projections are 74 difficult and highly arguable, but at the current rate of 75 growth, the existing space may be used up in the foreseeable 76 future. 78 We believe that the current Internet Protocol, version 4 ("IPv4"), 79 cannot practically be extended to solve these problems, and that a 80 new version of IP is needed. We follow current nomenclature by 81 calling the next generation Internet Protocol "IP version 7" or 82 "IPv7". 84 1.2 History 86 The IAB took its first step towards considering the IP scaling 87 problems during a workshop on "The Future of the Internet 88 Architecture" in July 1991. [RFC-1287]. The results of this 89 group's deliberations were reported to the November 1991 IETF 90 meeting. Partly as an IAB initiative and partly as a result of 91 internal IETF working group discussions, a task group known as 92 "ROAD" was formed in November 1991. This group worked very 93 intensively for the following three months, with the mandate of 94 developing one or more plausible architectural starting points for 95 attacking the scaling problems. Although the ROAD group did not 96 reach a definitive recommendation, it turned out to be enormously 97 helpful in structuring the problem, and laid the groundwork for 98 this memo [ROAD]. 100 More recently, there has been an intense debate on various mailing 101 lists and a profusion of new suggestions. Each of these reflects 102 careful thought by informed people. All of this prior work has 103 been factored into the contents of this document. In particular, a 104 recent paper by Callon [TUBA] is very complementary to our 105 discussion in Section 3. 107 This document presents a summary of the IAB's analysis of the ROAD 108 issues and its resulting specific recommendations. A more complete 109 description of the way in which these conclusions were reached 110 would be valuable, and will be included in a later version. 112 1.3 Overall Plan 114 In ROAD discussions, it was useful to divide the solution of the IP 115 scaling problems into short-term, medium-term, and long-term phases 116 [ROAD]. The real situation is much more complicated, with 117 considerable overlap as well as uncertainty about time frames, yet 118 this is a useful model for planning. We support the ROAD group 119 model that IPv7 belongs to the mid-term time frame, in the sense 120 that: 122 (1) more immediate steps must be taken to avoid exhaustion of the 123 address space before IPv7 can be deployed; and 125 (2) there are substantial research questions which must be 126 pursued, but which cannot be expected to be resolved until 127 after IPv7 is deployed. 129 For the short-term effort, we support the ROAD group suggestion of 130 CIDR (Classless Inter-domain Routing) [CIDR], a form of "super- 131 netting". CIDR will provide short-term relief from exhaustion of 132 the address space by breaking the rigidly fixed boundaries that 133 define class A, B, and C IP addresses, using a more flexible bit- 134 level mask (or equivalently a variable-length address prefix) to 135 distinguish the network number. To attack the routing information 136 explosion, CIDR will select addresses to match topology, allowing 137 the aggregation of routes. As we point out later, this aggregation 138 will carry over to, and indeed is important to the success of, 139 IPv7. 141 We do not dwell on CIDR here; there are already several CIDR- 142 related engineering efforts in progress in the IETF. This memo 143 emphasizes IPv7. Section 2 introduces a set of requirements that 144 must be satisfied by any IPv7 architecture, while Section 3 145 discusses two alternative approaches for realizing IPv7. One 146 approach is based upon encapsulation and the other is based upon 147 OSI CLNP. Section 4 briefly surveys some of the important research 148 problems and efforts that are vital to a long-term solution to the 149 problems posed by a billion-node Internet. Section 5 summarizes 150 proposed directions and actions for the community. 152 2. ARCHITECTURAL PRINCIPLES 154 To guide our work and to help sort out the competing proposals, an 155 overall set of design principles is needed. It is customary to refer 156 to such a set of principles as the "architecture". We believe that a 157 viable IPv7 should obey the following basic principles. 159 * Architectural simplicity, 161 * Globally unique addresses, 163 * Larger address space, 165 * Distributed address registration, 167 * Route aggregation, 169 * Topology independence, 171 * Extensibility, 173 * Compatibility, and 175 * Interoperability. 177 All of these are discussed in later sections. 179 This list is in no sense ordered; we believe all of these requirements 180 to be important. An actual engineering solution will naturally 181 involve detailed trade-offs among these objectives, but there are no 182 simple precedence relations among them. 184 Before discussing these principles, we make a basic philosophical 185 point: whatever the choice for IPv7, its "change control" must rest 186 with the IAB/IETF. Despite our desire to eventually converge with 187 other standards groups, the ability for protocol and architectural 188 evolution within the IRTF and IETF is absolutely essential to the 189 continued success of the Internet. 191 2.1. Architectural Simplicity 193 We believe that the success of the Internet architecture (as 194 evidenced by the growth problem discussed in this memo) rests on 195 its simplicity, which should be retained to the extent possible. 197 As an example of simplicity, we would prefer an architecture that 198 does not introduce any new logical boundaries into the Internet. 199 Such boundaries could make the job of address registration and 200 route aggregation harder. 202 2.2. Globally-Unique Addresses 204 We believe that an important characteristic of the Internet 205 architecture is the availability of "globally unique" addresses. 206 The alternative would be to allocate temporary local addresses 207 dynamically through an address translation scheme, relying upon 208 directory or name service to map these addresses. 210 Globally-unique addresses permeate the design of many applications. 211 For example, 213 (1) Globally-unique addresses are passed by applications like FTP 214 to identify third parties. 216 (2) Globally-unique addresses are very useful for a number of 217 security schemes. 219 (3) Globally-unique addresses are important for system management 220 of the global Internet. 222 The lack of a globally-unique address would break a number of 223 applications, impose severe boundary problems in the network, and 224 make security more difficult. In addition, the directory mechanism 225 itself would introduce substantial new security risks. It would 226 also require much more robust and closely-managed servers, speedily 227 updated, than we have in today's DNS. 229 A consequence of globally-unique addresses is that when the IPv4 230 address space becomes totally exhausted, "old" hosts (those which 231 speak only IPv4) will be unable to communicate with some "new" 232 hosts. We are prepared to accept this, in the belief that 233 continuing evolution is a necessary and desirable property of the 234 Internet, and that we will be able to provide a more-than- 235 reasonable period for conversion to IPv7 by all hosts. In the 236 asymptotic situation, application-level gateways can be used to 237 provide continued connectivity (with reduced functionality) for old 238 hosts. 240 2.3. Larger Address Space 242 Since we require globally unique addresses and since the current 243 address space is too small, we must escape the limitations imposed 244 by the current 32-bit addresses. The new architecture must allow 245 much wider address fields, to accommodate: 247 (1) registering several millions, or even billions, of networks; 249 (2) allowing some degree of inefficiency in the address 250 registration; 252 (3) permitting the expression of a hierarchy in the address; 254 (4) allowing for new addressing architectures in the future, if 255 the need arises. 257 Here (2) and (3) are needed in order to allow decentralized 258 registration and route aggregation (see Sections 2.4 and 2.5). 260 This move to a new address format is likely to impact much host and 261 router software; every piece of software that handles an Internet 262 address will have to be modified to handle wider addresses. It is 263 important to note the nature of this impact: broad (many modules 264 affected) but shallow (very specific, localized changes). 266 We furthermore argue in favor of a variable-length address format, 267 with a known upper bound. This upper bound will need to be large, 268 potentially increasing the IP header size significantly. However, 269 with a reasonable address assignment scheme, most networks numbers 270 will be much smaller. Indeed, it might be desirable to use the 271 existing 4-byte IP addresses for many hosts during a transition. 273 2.4. Distributed Address Registration 275 As the Internet becomes more and more international, it is no 276 longer appropriate to centralize all address registration in one 277 country. The new IP architecture must allow a decentralized 278 address registration scheme, for example by means of a multi-layer 279 hierarchical structure [RFC-1174]. Furthermore, decentralized 280 registration will be required even within single countries, as the 281 scale of the Internet increases. 283 Another important requirement is the capability to embed the 284 existing IP addresses into the new address space. This will avoid 285 separate old and new routing tables for IP, and it will prevent 286 network administrators having to form a huge queue in front of the 287 new registration agencies during the transition to IPv7. 289 2.5. Route Aggregation 291 Current IP addresses have three components: a "network number", an 292 optional "subnet" number, and a "host" number. Networks are 293 logically grouped into autonomous domains, but the space of network 294 numbers is flat, without any internal structure. This flat 295 addressing space leads to routing tables and routing updates that 296 grow nearly linearly with the total number of networks in the 297 Internet. Thus, adding a new network has a cost for all the 298 routers. 300 It may be objected that, in practice, many routing tables grow much 301 more slowly than linearly with the number of networks because of 302 the use of default routes. While this is true, the use of defaults 303 implies careful route engineering. Such engineering is the norm in 304 the Internet today, but growth is making it increasingly difficult. 305 For example, adding a second link to a stub Autonomous Systems will 306 result in its networks being announced on two entry points instead 307 of one, and this will require far distant parts of the Internet to 308 administratively decide which path to use. Soon, such planning 309 will become impossible. Another drawback of defaults is that they 310 restrict the amount of implicit policy routing that can be 311 achieved. Finally, there will always be a core of border routers 312 that must know all destinations, and whose tables must grow 313 linearly with the number of networks in the Internet. 315 To solve this problem, the Internet must aggregate routes, i.e., 316 allow one routing table entry to define the next hop for a group of 317 networks. This requires some structure in the addresses. When all 318 networks belonging to the same "routing domain" share addresses 319 whose most significant bits are the same, we can represent this 320 group of networks by a single entry in the routing tables. 321 Moreover, this aggregation scheme can be used hierarchically, so 322 that, for example, all networks in the Hawaiian archipelago may 323 appear as a single group to the Internet, and all networks of the 324 island of Oahu as a single group in the archipelago 325 [Kleinrock&Kamoun] 327 2.6. Topology Independence 329 We believe that an important long-term objective is to free the 330 assignment of addresses from dependence upon the routing topology, 331 just as domain names are assigned independently of network 332 connectivity. Managing the allocation of the address space to 333 match the topology will be an administrative nightmare (which 334 unfortunately we cannot avoid in the short- and medium-term). 336 There should be a level of indirection between addressing (naming) 337 a destination and routing to it. This would allow addresses to 338 have a hierarchical structure determined purely by the 339 administrative decentralization of address assignment. A directory 340 service lookup of some sort would be necessary to map these 341 topology-free names into routes. This lookup would need to be 342 performed by routers in the forwarding path, but it could be 343 partially circumvented with route cacheing. Such a scheme would 344 result in the cost of a new network being felt primarily by those 345 routers that are actually trying to reach it. 347 It is clear that such an indirection scheme with route cacheing is 348 a hard problem, and at present it must be the subject of research. 349 Until that research is completed, we will have to accept some 350 topological constraints on addressing and routing. General "policy 351 routing" is another research topic that is not ready for 352 engineering at this time. Further research on these topics is 353 essential, as discussed in Section 4. 355 2.7. Extensibility 357 Evolution from IPv4 to IPv7 will be occurring at the same time that 358 research work is on the verge of requiring architectural extensions 359 in other areas. Two important examples are supporting real time 360 applications (e.g., packet voice and video) [Realtime], and 361 providing better security services. IPv7 should provide easy 362 extensibility in order to support such new areas. 364 In particular, it is vital to escape the 60 byte limit on the IPv4 365 header, in order to have more space available for options. 367 2.8. Compatibility 369 As mentioned above, larger addresses should by no means imply a 370 change in the overall Internet architecture. In particular, it 371 should certainly not imply a reduction in the network 372 functionality. For example, it is mandatory that IPv7 should 373 continue to support the IP multicast architecture. Also, the 374 current techniques for debugging (e.g., "ping" and "traceroute") 375 should still be possible. 377 There are many "tendrils" from IPv4 that reach up into the 378 transport and application layers [RFC-1122]. Examples are the 379 receipt of ICMP Unreachable, Redirect, and Source Quench messages, 380 and setting TOS and TTL values and/or source routes. Other 381 examples arise in the use of Internet addresses by applications, 382 e.g., IP. We would ideally like to minimize the impact on the 383 layers above IP, although this may not prove entirely feasible. 385 2.9. Interoperability 387 Transition from IPv4 to IPv7 must occupy a number of years, so it 388 will be necessary for IPv4 hosts to be able to interoperate with 389 IPv7 hosts. A general scheme for handling old/new host 390 interoperability, based upon the DNS, is given in [TUBA]. 392 In order to ease the transition and ensure connectivity within the 393 Internet, the addressing plan should allow the address space to be 394 *embedded* into the IPv7 space. For example, this will avoid the 395 need to maintain parallel routing tables. 397 The following diagram shows the protocol stack that a host may 398 expect to implement. During the transition to IPv7 (which is 399 likely to be lengthy), an Internet host must support both IPv4 and 400 IPv7. It would use IPv4 for communication with an unmodified host 401 [TUBA]. 403 _________________________________ 404 | | 405 | | 406 | TCP/UDP | 407 | | 408 |_________________________________| 409 | | | 410 | | | 411 | IPv4 | IPv7 | 412 | | | 413 |_______________|_________________| 415 3. POSSIBLE APPROACHES TO IPv7 417 Two divergent approaches have been suggested for IPv7. 419 (1) Some form of IP encapsulation. A good example of this approach 420 is the IP Address Encapsulation proposal [IPAE]. 422 Encapsulation schemes maximize Internet-layer protocol 423 compatibility by design; however, these schemes also represent a 424 significant change in the IP architecture. 426 (2) Keep the IP architecture essentially unchanged, but change the 427 format of an IP header to expand the addresses. 429 A solution based on the existing CLNP protocol is a recent 430 candidate for the expanded header format [TUBA]. CLNP can be 431 regarded as a revision of IP to fit into the OSI framework, 432 following the IP architecture without much added functionality. 433 The primary technical difference between IPv4 and CLNP is the 434 latter's much wider address fields, variable length up to 20 435 bytes. 437 After consideration of the principles of Section 2, the IAB favors the 438 second class of solutions, and in particular, basing IPv7 on CLNP. It 439 is important to understand exactly what we mean by basing IPv7 on 440 CLNP; the rest of this section is therefore devoted to expanding on 441 this topic. 443 The IAB proposal is to adopt the CLNP protocol specification and 444 packet formats for IPv7. The eventual consequence of this decision 445 will be the publication, at some point in the future, of a complete 446 IPv7 specification that is functionally and syntactically compatible 447 with CLNP (defined by the second edition of the ISO 8473 standard, 448 published in 1992). The intent is to run the existing and future 449 Internet transport protocols -- in particular, TCP and UDP -- above 450 IPv7. This would let us benefit from the larger addresses of CLNP 451 while maintaining the present Internet architecture, without inventing 452 a new protocol specification and without losing change control. We 453 must of course avoid gratuitous changes, but the IAB/IETF must be able 454 to make any changes that are necessary for successful deployment, 455 operation, and evolution of IPv7. In the longer term, the use of CLNP 456 will contribute to the inevitable convergence of the OSI and TCP/IP 457 protocol suites in the Internet (IAB/IETF) context. 459 The next section reviews the advantages of this CLNP-based solution. 460 Section 3.2.discusses the issues that must be resolved before a CLNP- 461 based IPv7 can be deployed in the Interne. 463 3.1. The case for (and against) CLNP 465 An advantage of CLNP is simply that the protocol is already 466 specified, and several implementations exist. Adopting (and 467 adapting; see the next section) the CLNP format will avoid design 468 of a new protocol from scratch, a process that would consume 469 valuable time and delay testing and deployment. 471 Besides the change to variable-length 20 bytes addresses, CLNP has 472 another important technical advantage: it frees us from the 60-byte 473 limitation on an IP header. CLNP has a limit of 254, and there is 474 an escape code (length 255) that could allow an extended header; 475 this will allow more extensive use of IP options for future 476 extensions. 478 We should admit frankly some technical limitations of CLNP, which 479 it shares with IPv4: 481 * Maximum packet length is limited to 64K bytes. 483 * The message identifier uses a 16-bit field. 485 * The Time-to-live field is one byte. 487 * If full-size (20 byte) addresses are used in options, the 255 488 byte limit gets used up fast. For example, the largest source 489 route with 20-byte addresses will be 8 hops. 491 In addition, CLNP has awkward boundary alignments for RISC- 492 architecture machines. We do not regard any of these as show- 493 stoppers. 495 3.2 Additional Issues with CLNP. 497 To adopt the CNLP format for IPv7, a number of issues must be 498 resolved. Callon has provided one analysis of the changes needed 499 and the interoperability issues for using CLNP as the basis for 500 IPv7 [TUBA]. 502 * Address Format and Registration Plan 504 The existing NSAP registration plans [OSI-NSAP], which were 505 designed for OSI usage, will have to be reviewed in light of 506 the Internet needs. One requirement is to embed the existing 507 Internet addresses. 509 * Protocol Identification 511 A substitute for the IPv4 "protocol identification" field will 512 have to be defined. A plausible solution would be to use the 513 "last address byte" (the "NSEL" or "NSAP selector" field, 514 which is defined to be the last byte of the NSAP address by 515 ANSI standard X3.210-1992). 517 * Transport Pseudo-Header 519 The transport protocols TCP and UDP currently include in their 520 checksums a "pseudo-header" constructed out of the address and 521 length fields abstracted from the IP header. A suitable 522 modification to the pseudo-header will have to be designed (or 523 the pseudo-header dropped from TCP and UDP). This problem is 524 well-described in [TUBA]. 526 * Layer Interactions 527 The impact upon all the other layers will have to be worked 528 out in detail. 530 * Error Reporting 532 Most important is the reporting of errors from the IP layer. 533 It might be that the most effective and economical solution 534 will be to continue to use ICMP with IPv7. Otherwise, it will 535 be necessary to modify the error-handling strategy of existing 536 transport protocols to use the OSI error reporting mechanism. 538 * Address Resolution 540 A related issue is whether to continue to use ARP for address 541 resolution on broadcast networks, or whether to adopt the OSI 542 ES-IS protocol [ES-IS], which essentially combines ICMP and 543 ARP functions. 545 * Domain Name Lookups 547 It will be necessary to modify the DNS to return the new wide 548 addresses. This problem is well described in [TUBA]. 550 * Header Size 552 The possible problems posed by increasing the size of the IP 553 header will have to be evaluated. The impact on slow Internet 554 links may be alleviated by adapting header compression 555 algorithms analogous to Jacobson's [RFC-1144]. 557 * Multicasting 559 The proposed extensions to CLNP for multicasting will have to 560 be incorporated. 562 In general, a very careful review will be required to quickly 563 locate the potential problems and to cure them. In line with the 564 Internet tradition of "learning from experience", this will need 565 early experiments, which will have to be taken into account in the 566 transition timing. 568 Note that the IPv7 implementation may differ from the OSI CLNP 569 implementation by having a different "service" interface to the 570 transport layer. That is, IPv7 implementors may choose to minimize 571 changes on the transport side of the interface [RFC-1122]. Thus, a 572 host that supports both the Internet and the OSI stacks may have 573 the following protocol stacks: 575 ________________ _________________________________ 576 | || | 577 | || | 578 | TP4 || TCP/UDP | 579 | || | 580 |________________||_________________________________| 581 | || | | 582 | || | | 583 | OSI CLNP || IPv4 | IPv7 | 584 | || | | 585 |________________||_______________|_________________| 587 It is of course a long-term objective to work towards a single 588 unified internet protocol layer for the entire Internet. 590 In the OSI framework, IS-IS and IDRP are the currently-defined IGP 591 and EGP routing protocols, respectively. A careful study may be 592 needed to evaluate whether to adopt ISO routing protocols or to 593 evolve IP routing protocols to support IPV7. The routing protocols 594 currently in use in the Internet represent a huge investment that 595 should be thrown away only for compelling reasons. Furthermore, we 596 must facilitate further research in routing protocols. 598 In order to survive the transition to IPv7, the existing routing 599 protocols will have to be upgraded to handle long variable-length 600 addresses and masks/prefixes. The careful study of routing 601 protocols is an important element in the success of the migration. 603 4. RESEARCH AREAS 605 A number of long-term approaches have been suggested for major 606 advances in Internet routing. These include IDPR, NIMROD, and PIP. 607 We urge that these ideas be aggressively researched. 609 Section 2.5 exhibited weak points of the current Internet architecture 610 and routing technology. Extending the number of connected networks or 611 the number of Internet links causes additional cost for all (or at 612 least many) Internet routers. Ideally, the cost would be borne only 613 by those who intend to engage in exchanges with the new networks or 614 over the new links. Furthermore, the assignment of addresses is tied 615 to the topology, to allow route aggregation. 617 Removing these constraints requires the development of an indirection 618 and route cacheing mechanism. This is very important for the future, 619 but it is definitely a research project. One definition of research 620 is "a project which is allowed to fail", and indeed it is a matter of 621 conjecture that a route lookup mechanism can be designed with 622 sufficient speed and robustness to satisfy the requirements. Research 623 in this area should be a critical task for the long-term evolution of 624 Internet routing. 626 General policy-based routing is another issue that we regard as a 627 research topic, for the long term. 629 5. THE WAY FORWARD 631 In order to guarantee the survival of the Internet, work should start 632 now on the various items detailed in this document. Delaying by a few 633 more months in order to gather more information would be very unlikely 634 to help us make a decision, and would encourage people to spend their 635 time crafting arguments for why CLNP is or is not a better solution 636 than some alternative, rather than working on the detailed 637 specification of how CLNP can be used as the basis for IPv7 and 638 resolving the technical questions (particularly in the area of address 639 administration and the effect on existing application software) that 640 must be answered in order to specify a deployment plan for IPv7. 642 We therefore recommend: 644 1. An immediate IETF effort to engineer CIDR, including the 645 extensions to the inter-AD routing protocols to allow 646 masks/prefixes, and the associated address administration 647 paradigm. The latter is critical to the success of CIDR. 649 The routing information explosion is upon us now. Already, some 650 pockets of the Internet are showing restricted connectivity due 651 to routing table overflow. With the rapid pace of Internet 652 growth, the problem has to be addressed immediately, even before 653 introducing IPv7 and its large addresses. We urge that route 654 aggregation be incorporated as soon as possible, using the CIDR 655 scheme. 657 2. An immediate IETF effort to prepare a detailed technical and 658 organizational plan for using CLNP as the basis for IPv7. 660 The IAB favors CLNP, which retains the general Internet 661 architecture and its principles unchanged while changing the IP 662 packet format to accommodate wider addresses. 664 3. That the long-term research discussed in Section 4 be continued 665 and encouraged. 667 It is important to observe that CIDR uses 32 bit addresses with the L 668 first bits used for routing. Here L is determined distinctly for each 669 routing table entry. Projecting this onto IPv7, we see that IPv7 will 670 use X bit addresses with the L first bits used for routing, where X is 671 to be determined. Thus, we see that CIDR is a natural step along the 672 route to IPv7, and a step that needs to be started as soon as 673 possible. 675 REFERENCES 677 [CIDR] Fuller, V., Li, T., and J. Yu, "Supernetting: an Address 678 Assignment and Aggregation Strategy", RFC in preparation, April 679 10, 1992. 681 [CLNP] "Protocol for Providing the Connectionless-Mode Network 682 Service", ISO 8473, 1988. 684 [ES-IS] "End-System to Intermediate System Routing Exchange Protocol 685 for use in Conjunction with the Protocol for the Provision of the 686 Connectionless-mode Network Service", ISO 9542, 1987. 688 [IEN-005] Cerf, V., "TCP Version 2 Specification", Internet Experiment 689 Note IEN-005, March 1977. 691 [IPAE] Hinden, R. and D. Crocker, "A Proposal for IP Address 692 Encapsulation (IPAE): A Compatible Version of IP with Large 693 Addresses", RFC in preparation. 695 [Kleinrock&Kamoun] Kleinrock, L. and K. Kamoun, "Hierarchical Routing 696 for Large Networks: Performance Evaluation and Optimization", 697 Computer Networks, 1, 155-174, 1977. 699 [OSI-NSAP] Collella, R., Gardner, E., and R. Callon, "Guidelines for 700 OSI NSAP Allocation in the Internet", RFC-1237, July 1991. 702 [RFC-1122] Braden, R., Ed., "Requirements for Internet Hosts -- 703 Communication Layers", RFC-1122, October 1989. 705 [RFC-1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed 706 Serial Links", RFC-1144, February 1990. 708 [RFC-1174] Cerf, V., "IAB Recommended Policy on Distributing Internet 709 Identifier Assignment", RFC-1174, August 1990. 711 [Realtime] Braden, R., "Integrated Service in the Internet 712 Architecture", High-Performance Network Research Report, ISI, 713 October 1991. 715 [ROAD] "The Internet Routing and Addressing Task Force: Summary 716 Report", Brim, S. and P. Ford, Working Draft, 23 June 1992. 718 [TUBA] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), a Simple 719 Proposal for Internet Addressing and Routing", RFC-1347, June 720 1992. 722 Security Considerations 724 Support for privacy and security is fundamental to the architectural 725 choice of globally unique addresses, as noted in Section 2.2. 727 Author's Address 729 Internet Architecture Board 730 c/o Robert Braden, IAB Executive Director 731 USC Information Sciences Institute 732 4676 Admiralty Way 733 Marina del Rey, CA 90292-6695 735 Phone: 310-822-1511 736 Fax: 310-823-6714 738 Email: Braden@ISI.EDU