idnits 2.17.1 draft-iesg-roadplan-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 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 56 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 133 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 108 has weird spacing: '...ossible that ...' == Line 142 has weird spacing: '...timates that,...' == Line 143 has weird spacing: '...rective measu...' == Line 149 has weird spacing: '...ssigned multi...' == Line 150 has weird spacing: '...g table explo...' == (51 more instances...) == 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. -- Couldn't find a document date in the document -- date freshness check skipped. 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? 'Fuller92' on line 984 looks like a reference -- Missing reference section? 'Solen92' on line 1025 looks like a reference -- Missing reference section? 'Rekhter92' on line 1014 looks like a reference -- Missing reference section? 'Rekhter92a' on line 616 looks like a reference -- Missing reference section? 'Callon92a' on line 992 looks like a reference -- Missing reference section? 'Hinden92' on line 988 looks like a reference -- Missing reference section? 'Callon92b' on line 1000 looks like a reference -- Missing reference section? 'Chiappa91' on line 1043 looks like a reference -- Missing reference section? 'Tsuchiya92b' on line 1040 looks like a reference -- Missing reference section? 'Gross92a' on line 978 looks like a reference -- Missing reference section? 'Ford92' on line 971 looks like a reference -- Missing reference section? 'Gross92' on line 975 looks like a reference -- Missing reference section? 'Deering92' on line 996 looks like a reference -- Missing reference section? 'Hinden92b' on line 1004 looks like a reference -- Missing reference section? 'Deering92b' on line 1008 looks like a reference -- Missing reference section? 'Stockman92' on line 1011 looks like a reference -- Missing reference section? 'Rekhter92b' on line 1019 looks like a reference -- Missing reference section? 'Rekhter92c' on line 1022 looks like a reference -- Missing reference section? 'Wang92' on line 1028 looks like a reference -- Missing reference section? 'Callon91' on line 1033 looks like a reference -- Missing reference section? 'Tsuchiya92a' on line 1037 looks like a reference -- Missing reference section? 'Clark91' on line 1046 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Phill Gross 2 September 1992 IESG Chair 3 Philip Almquist 4 IESG Internet AD 6 IESG Deliberations on Routing and Addressing 8 CONTENTS 10 Abstract 12 Status Of This Memo 14 Acknowledgements 16 1. INTRODUCTION 18 2. ISSUES OF GROWTH AND EVOLUTION IN THE INTERNET 19 2.1 The Problems 20 2.2 Possible Solutions 22 3. PREPARING FOR ACTION 23 3.1 The IAB Architecture Retreats 24 3.2 The Santa Fe IETF 25 3.3 The ROAD Group and beyond 27 4. SETTING DIRECTIONS FOR THE IETF 28 4.1 The Need For Interim Solutions 29 4.2 The Proposed Phases 30 4.3 A Solution For Routing Table Explosion -- CIDR 31 4.4 Regarding "IP Address Exhaustion" 32 4.5 Milestones And Timetable For Making a Recommendation for 33 "Bigger Internet Addresses" 35 5. SUMMARY 37 Appendix A. FOR MORE INFORMATION 38 Appendix B. INFORMATION AND SELECTION CRITERIA FOR "BIGGER INTERNET 39 ADDRESSES" 40 Appendix C. BIBLIOGRAPHY 42 2 43 Abstract 45 This memo summarizes issues surrounding the routing and addressing 46 scalling problems in the IP architecture, and it provides a brief 47 background of the ROAD group and related activities in the IETF. 49 It also provides a preliminary report of IESG deliberations on how 50 these routing and addressing issues should be pursued in the IAB/IETF, 52 Status Of This Memo 54 Internet Drafts are working documents of the Internet Engineering 55 Task Force (IETF), its Areas, and its Working Groups. Note that 56 other groups may also distribute working documents as Internet 57 Drafts. 59 Internet Drafts are draft documents valid for a maximum of six 60 months. This Internet Draft expires at the end of March 1993. 61 Internet Drafts may be updated, replaced, or obsoleted by other 62 documents at any time. It is not appropriate to use Internet 63 Drafts as reference material or to cite them other than as a 64 "working draft" or "work in progress." 66 Please check the I-D abstract listing contained in each Internet 67 Draft directory to learn the current status of this or any other 68 Internet Draft. 70 Distribution of this memo is unlimited. 72 Acknowledgements 74 This note draws principally from two sources: the output from the 75 ROAD group, as reported at the San Diego IETF meeting, and on 76 numerous detailed discussions in the IESG following the San Diego 77 IETF meeting. Zheng Wang, Bob Hinden, Kent England, and Bob 78 Smart provided input for the "Criteria For Bigger Internet 79 Addresses" section below. Greg Vaudreuil prepared the final 80 version of the bibliography, based on previous bibliographies by 81 Lyman Chapin and bibligraphies distributed on the Big-Internet 82 mailing list. 84 1. INTRODUCTION 86 It seems unlikely that the designers of IP ever imagined at the time 88 3 89 what phenomenal success the Internet would achieve. Internet 90 connections were initially intended primarily for mainframe 91 computers at sites performing DARPA-sponsored research. Now, of 92 course, the Internet has extended its reach to the desktop and is 93 beginning to extend into the home. No longer the exclusive 94 purview of pure R&D establishments, the Internet has become well 95 entrenched in parts of the corporate world and is beginning to 96 make inroads into secondary and even primary schools. While once 97 it was an almost exclusively U.S. phenomenon, the Internet now 98 extends to every continent and within a few years may well include 99 network connections in every country. 101 Over the past couple of years, we have seen increasingly strong 102 indications that all of this success will stress the limits of IP 103 unless appropriate corrective actions are taken. The supply of 104 unallocated class B network numbers is rapidly dwindling, and the 105 amount of routing information now carried in the Internet is 106 increasingly taxing the abilities of both the routers and the 107 people who have to manage them. Somewhat longer term, it is 108 possible that we will run out of host addresses or network 109 numbers altogether. 111 While these problems could be avoided by attempting to restrict 112 the growth of the Internet, most people would prefer solutions 113 that allow growth to continue. Fortunately, it appears that such 114 solutions are possible, and that, in fact, our biggest problem is 115 having too many possible solutions rather than too few. 117 This memo provides a preliminary report of IESG deliberations on 118 how routing and addressing issues can be pursued in the IAB/IETF. 120 In following sections, we will discuss in more detail the problems 121 confronting us and possible approaches. We will give a brief 122 overview of the ROAD group and related activities in the IETF. We 123 will then discuss possible courses of action in the IETF. 124 Ultimately, the IESG will issue a recomendation from the IESG/IETF 125 to the IAB. 127 4 128 2. ISSUES OF GROWTH AND EVOLUTION IN THE INTERNET 130 2.1 The Problems 132 The Internet now faces three growth-related problems: 134 - Class B network number exhaustion - Routing table explosion 135 - IP address space exhaustion 137 2.1.1 Class B Network Number Exhaustion 139 Over the last several years, the number of network numbers 140 assigned and the number of network numbers configured into the 141 Merit NSFnet routing database have roughly doubled every 12 142 months. This has led to estimates that, at the current 143 allocation rate, and in the absence of corrective measures, it 144 will take less than 2 years to allocate all of the currently 145 unassigned Class B network numbers. 147 After that, new sites which wished to connect more than the number 148 of hosts possible in a single Class C (253 hosts) would need to be 149 assigned multiple Class C networks. This will exascerbate the 150 routing table explosion problems described next. 152 2.1.2. Routing Table Explosion 154 As the number of networks connected to the Internet has grown, the 155 amount of routing information that has to be passed around to keep 156 track of them all is likewise growing. This is leading to two 157 types of problems. 159 Hardware and Protocol Limits 161 Routing protocols must pass around this information, and routers 162 must store and use it. This taxes memory limits in the routers, 163 and can also consume significant bandwidth when older routing 164 protocols are used, (such as EGP and RIP, which were designed for 165 a much smaller number of networks). 167 The limits on the memory in the routers seem to be the most 168 pressing. It is already the case that the routers used in the 169 MILNET are incapable of handling all of the current routes, and 170 most other service providers have found the need to periodically 171 upgrade their routers to accommodate ever larger quantities of 172 routing information. An informal survey of router vendors by the 173 ROAD group estimated that most of the currently deployed 174 generation of high-end routers will support O(16000) routes. This 175 will be probably be adequate for the 177 5 178 next 12 to 18 months at the current rate of growth. Most vendors have 179 begun, or will soon begin, to ship routers capable of handling 180 O(64000) routes, which should be adequate for an additional two years 181 if the above Class B Network Number Exhaustion problem is solved. 183 Human Limits 185 The number of routes does not merely tax the network's physical plant. 186 Network operators have found that the inter-domain routing protocol 187 mechanisms often need to be augmented by a considerable amount of 188 configuration to make the paths followed by packets be consistent with 189 the policies and desires of the network operators. As the number of 190 networks increases, the configuration (and the traffic monitoring to 191 determine whether the configuration has been done correctly) becomes 192 increasingly difficult and time-consuming. 194 Although it is not possible to determine a number of networks (and 195 therefore a time frame) where human limits will be exceeded, network 196 operators view this as a significant short-term problem. 198 2.1.3. IP Address Exhaustion 200 If the current exponential growth rate continues unabated, the number 201 of computers connected to the Internet will eventually exceed the 202 number of possible IP addresses. Because IP addresses are divided 203 into "network" and "host" portions, we may not ever fully run out of 204 IP addresses because we will run out of IP network numbers first. 206 There is considerable uncertainty regarding the timeframe when we 207 might exceed the limits of the IP address space. However, the issue 208 is serious enough that it deserves our earliest attention. It is very 209 important that we develop solutions to this potential problem well 210 before we are in danger of actually running out of addresses. 212 6 213 2.1.4. Other Internetwork Layer Issues 215 Although the catalog of problems above is pretty complete as far as 216 the scaling problems of the Internet are concerned, there are other 217 Internet layer issues that will need to be addressed over the coming 218 years. These are issues regarding advanced functionality and service 219 guarantees in the Internet layer. 221 In any attempt to resolve the Internet scaling problems, it is 222 important to consider how these other issues might affect the future 223 evolution of Internet layer protocols. These issues include: 225 1) Policy-based routing 226 2) Flow control 227 3) Weak Quality-of-Service (QOS) 228 4) Service guarantees (strong QOS) 229 5) Charging 231 2.2 Possible Solutions 233 2.2.1. Class B Network Number Exhaustion 235 A number of approaches have been suggested for how we might slow the 236 exhaustion of the class B IP addresses. These include: 238 1) Reclaiming those Class B network numbers which have been assigned 239 but are either unused or used by networks which are not connected to 240 the Internet. 242 2) Modifying address assignment policies to slow the assignment of 243 Class B network numbers by assigning multiple Class C network numbers 244 to organizations which are only a little bit to big to be accommodated 245 by a class C network number. 247 3) Use the class C address space to form aggregations of different 248 size than the normal normal class C addesses. Such schemes include 249 Classless Inter-Domain Routing (CIDR) [Fuller92] and the C# scheme 250 [Solen92]. 252 7 253 2.2.2. Routing Table Explosion 255 As was described earlier, there are actually two parts to this 256 problem. They each have slightly different possible approaches: 258 Hardware and Protocol Limits 260 1) More thrust. We could simply recognize the fact that 261 routers which need full Internet routing information will require 262 large amounts of memory and processing capacity. This is at best 263 a very short-term approach, and we will always need to face this 264 problem in the long term. 266 2) Route servers (a variant of the "More Thrust" solution). 267 Instead of requiring every router to store complete routing 268 information, mechanisms could be developed to allow the tasks of 269 computing and storing routes to be offloaded to a server. Routers 270 would request routes from the server as needed (presumably caching 271 to improve performance). 273 3) Topology engineering. Many network providers already try to 274 design their networks in such a way that only a few of the routers 275 need complete routing information (the others rely on default 276 routes to reach destinations that they don't have explicit routes 277 to). While this is inconvenient for network operators, it is a 278 trend which is likely to continue. 280 It is also the case that network providers could further reduce 281 the number of routers which need full routing information by 282 accepting some amount of suboptimal routing or reducing alternate 283 paths used for backup. 285 4) Charging-based solutions. By charging for network number 286 advertisements, it might be possible to discourage sites from 287 connecting more networks to the Internet than they get signifcant 288 value from having connected. 290 5) Aggregation of routing information. It is fairly clear that 291 in the long-term it will be necessary for addresses to be more 292 hierarchical. This will allow routes to many networks to be 293 collapsed into a single summary route. Therefore, an important 294 question is whether aggregation can also be part of the 295 short-term solution. Of the proposals to date, only CIDR could 296 provide aggregation in the short-term. All longer-term proposals 297 should aggregation. 299 Human Limits 301 1) Additional human resources. Network providers could devote 303 8 304 additional manpower to routing management, or accept the 305 consequences of a reduced level of routing management. This is 306 obviously unattractive as anything other than a very short-term 307 solution. 309 2) Better tools. Network operators and router vendors could 310 work to develop more powerful paradigms and mechanisms for routing 311 management. 312 The IETF has already undertaken some work in the areas of route 313 filtering and route leaking. 315 2.2.3. IP Address Exhaustion 317 The following general approaches have been suggested for dealing 318 with the possible exhaustion of the IP address space: 320 1) Protocol modifications to provide a larger address space. By 321 enhancing IP or by transitioning to another protocol with a larger 322 address space, we could substantially increase the number of 323 available network numbers and addresses. 325 2) Addresses which are not globally unique. Several proposed 326 schemes have emerged whereby a host's domain name is globally 327 unique, but its IP address would be unique only within it's local 328 routing domain. These schemes usually involve address translating 329 gateways at the borders between routing domains. 331 3) Partitioned Internet. The Internet could be partitioned into 332 areas, such that a host's IP address would be unique only within 333 its own area. Such schemes generally postulate application 334 gateways to interconnect the areas. This is not unlike the 335 approach often used to connect differing protocol families. 337 4) Reclaiming network numbers. Network numbers which are not 338 used, or are used by networks which are not connected to the 339 Internet, could conceivably be reclaimed for general Internet 340 use. This isn't a long term solution, but could possibly help in 341 the interim if for some reason address exhaustion starts to occur 342 unexpectedly soon. 344 9 345 3. PREPARING FOR ACTION 347 3.1 The IAB Architecture Retreats 349 In July 1991, the IAB held a special workshop to consider critical 350 issues in the IP architecture (clark91). Of particular concern 351 were the problems related to Internet growth and scaling. The 352 IAB felt the issues were of sufficient concern to begin 353 organizing a special group to explore the issues and to explore 354 possible solutions. Peter Ford (LANL) was asked to organize this 355 effort. The IAB reconvened the architecture workshop in January 356 1992 to further examine these critical issues, and to meet 357 jointly with the then-formed ROAD group (see below). 359 3.2 The Santa Fe IETF 361 At the November 1991 Santa Fe IETF meeting, the BGP Working Groups 362 independently began a concerted exploration of the issues of 363 routing table scaling. The principal approach was to perform 364 route aggregation by using address masks in BGP to do 365 "supernetting" (rather than "subnetting"). This appraoch would 366 eventually evolve into CIDR. The BGP WG decided to form a 367 separate subgroup, to be led by Phill Gross (ANS) to pursue this 368 solution. 370 3.3 The ROAD Group and Beyond 372 At the Santa Fe IETF, the initially separate IAB and BGP WG activities 373 were combined into a special effort, named the "ROuting and ADdressing 374 (ROAD) Group", to be co-chaired by Ford and Gross. 376 The group was asked to explore possible near-term approaches for the 377 scaling problems described in the last section, namely: 379 - Class B address exhaustion 380 - Routing table explosion 381 - IP address space exhaustion 383 The ROAD group was asked to report back to the IETF at the San 384 Diego IETF (March 1992). Suggested guidelines included minimizing 385 changes to hosts, must be incrementally deployable, and must 386 provide support for 10^^9 networks. 388 The ROAD group was not a traditional open IETF working group. It 389 was always presumed that this was a one-time special group that 390 would lead to the formation of other IETF WGs after its report in 391 San Diego. 393 The ROAD group held several face-face meetings between the November 395 10 396 1991 (Santa Fe) and March 1992 (San Diego) IETF meetings. This 397 included several times at the Santa Fe IETF meeting, December 1991 in 398 Reston Va, January 1992 in Boston (in conjunction with the IAB 399 architecture workshop), and January 1992 in Arizona). There was also 400 much discussion by electronic mail. 402 The group produced numerous documents, which have variously been made 403 available as Internet-Drafts or RFCs (see Bibliography in Appendix D). 405 As follow-up, the ROAD co-chairs reported to the IETF plenary in 406 March 1992 in San Diego. Plus, several specific ROAD-related 407 activities took place during the IETF meeting that week. 409 The Ford/Gross presentation served as a preliminary report from the 410 ROAD group. The basic thrust was: 412 1. The Internet community needs a better way to deal with current 413 addresses (e.g., hierarchical address assignments for routing 414 aggregation to help slow class B exhaustion and routing table 415 explosion). Classless Inter-Domain Routing (CIDR; also called 416 "supernetting") was recommended. CIDR calls for: 418 - The development of a plan for hierarchical IP address 419 assignment for aggregation in routing 421 - Enhanced "classless" Inter-domain protocols (i.e., carry 422 address masks along with IP addresses) 424 - Inter-Domain routing "Usage documents" for using addressing 425 and routing plan with the enhanced inter- domain protocols, 426 and for interacting with IGPs 428 2. The Internet community needs bigger addresses for the Internet 429 to stem IP address exhaustion. The ROAD group explored several 430 approaches in some depth. Some of these approaches were discussed 431 at the San Diego IETF. However, a final recommendation of a 432 single approach did not emerge. 434 11 435 3. The Internet community needs to focus more effort on future 436 directions for Internet routing and advanced Internet layer features. 438 Other ROAD-related activities at the San Diego IETF meeting included: 440 - Monday, 8:00 - 9:00 am, Report from the ROAD group on "Internet 441 Routing and Addressing Considerations" 443 - Monday, 9:30-12:00pm, Geographical Addressing and Routing (during 444 NOOP WG session) 446 - Monday, 1:30-3:30pm, Preliminary discussion of a CIDR routing and 447 addressing plan (during ORAD session) 449 - Tuesday, 1:30-6:00pm, Internet Routing and Addressing BOF (to 450 discuss ROAD results and to explore approaches for bigger Internet 451 address space) 453 - Wednesday, 1:30-3:30pm, CIDR Supernetting BOF (joint with BGP WG) 455 - Thursday, 4:00-6:00pm, Summary of ROAD activities in San Diego 456 followed by open plenary discussion. 458 The slides for the Monday presentation (Ford92), slides for the 459 Thursday summary (and notes in the Chair's message) (Gross92), and 460 notes for the other sessions are contained in the Proceedings of the 461 Twenty-Third IETF (San Diego). 463 4. SETTING DIRECTIONS FOR THE IETF 465 4.1 The Need For Interim Solutions 467 Solutions to the problems of advanced Internet layer functionality 468 are far from being well understood. While we should certainly 469 encourage research in these areas, it is premature to start an 470 engineering effort for an Internet layer which would solve not 471 only the scaling problems but also those other issues. 473 Plus, most approaches to the problem of IP address space 474 exhaustion involve changes to the Internet layer. Such approaches 475 mean changes changes to host software that will require us to face 476 the very difficult transition of a large installed base. 478 It is therefore not likely that we can (a) develop a single 479 solution for the near-term scaling problems that will (b) also 480 solve the longer-term problems of advanced Internet-layer 481 functionality, that we 483 12 484 can (c) choose, implement and deploy before the nearer-term problems 485 of Class B exhaustion or routing table explosion confront us. 487 This line of reasoning leads to the inevitable conclusion that we will 488 need to make major enhancements to IP in (at least) two stages. 490 Therefore, we will consider interim measures to deal with Class B 491 address exhaustion and routing table explosion (together), and to deal 492 with IP address exhaustion (separately). 494 We will also suggest that the possible relation between these nearer- 495 term measures and work toward advanced Internet layer functionality 496 should be made an important consideration. 498 4.2 The Proposed Phases 500 The IESG recommends that we divide the overall course of action into 501 several phases. For lack of a better vocabulary, we will term these 502 "immediate", "short-term", mid-term", and "long-term" phases. But, as 503 the ROAD group pointed out, we should start all the phases 504 immediately. We cannot afford to act on these phases consecutively! 506 In brief, the phases are: 508 - "Immediate". These are configuration and engineering actions that 509 can take place immediately without protocol design, development, or 510 deployment. There are a number of actions that can begin immediately. 511 Although none of these will solve any of the problems, they can help 512 slow the onset of the problems. 514 13 515 The IESG specifically endorses 517 1) the need for more conservative address assignement 518 policies, 519 2) alignment of new address assignment policies with any new 520 aggregation schemes, 521 3) efforts to reclaim unused Class B addresses, 522 4) installation of more powerful routers by network operators 523 at key points in the Internet, and 524 5) careful attention to toplogy engineering. 526 - "Short-term". Actions in this phase are aimed at dealing with 527 Class B exhaustion and routing table explosion. These problems are 528 deemed to be quite pressing and to need solutions well before the IP 529 address exhaustion problem needs to be or could be solved. In this 530 timeframe, changes to hosts can *not* be considered. 532 - "Mid-term". In the mid-term, the issue of IP address exhaustion 533 must be solved. This is the most fundamental problem facing the IP 534 architecture. Depending on the expected timeframe, changes to host 535 software could be considered. Note: whatever approach is taken, it 536 must also deal with the routing table explosion. If it does not, then 537 we will simply be forced to deal with that problem again, but in a 538 larger address space. 540 - "Long-term". Taking a broader view, the IESG feels that advanced 541 Internet layer functionality, like QOS support and resource 542 reservation, will be crucial to the long-term success of the Internet 543 architecture. 545 Without these advanced features, the Internet may fill an important 546 niche, but will eventually be supplanted by other advanced 547 technologies like ATM or SMDS. 549 Therefore, planning for advanced Internet layer functionality should 550 play a key role in our choice of mid-term solutions. 552 In particular, we need to keep several things in mind: 554 1) The long-term solution will require replacement and/or extension 555 of the Internet layer. This will be a significant trauma for vendors, 556 operators, and for users. Therefore, it is particularly important 557 that we either minimize the trauma involved in deploying the sort- 558 and mid-term solutions, or we need to assure that the short- and mid- 559 term solutions will provide a smooth transition path for the long- 560 term solutions. 562 2) The long term solution will likely require globally unique 564 14 565 endpoint identifiers with an hierarchical structure to aid routing. 566 Any effort to define hierarchy and assignment mechanisms for short- or 567 mid-term solutions would, if done well, probably have long-term 568 usefulness, even if the long term solution uses radically different 569 message formats. 571 3) To some extent, development and deployment of the interim 572 measures will divert resources away from other important projects, 573 including the development of the long term solution. This diversion 574 should be carefully considered when choosing which interim measures to 575 pursue. 577 4.3 A Solution For Routing Table Explosion -- CIDR 579 The IESG accepted ROAD's endorsement of CIDR [Fuller92]. CIDR solves 580 the routing table explosion problem (for the current IP addressing 581 scheme), makes the Class B exhaustion problem less important, and buys 582 time for the crucial address exhaustion problem. 584 The IESG felt that other alternatives (eg, C#, see Solen92) not did 585 provide both routing table aggregation and Class B conservation at 586 comparable effort. 588 CIDR will require policy changes, protocol specification changes, 589 implementation, and deployment of new router software, but it does 590 not call for changes to host software. 592 The IESG recommends the following course of action to pursue CIDR in 593 the IETF: 595 a. Adopt the CIDR model described in Fuller92 597 b. Develop a plan for "IP Address Assignment Guidelines". 599 The IESG considered the creation of an addressing plan to be an 600 operational issue. Therefore, the IESG asked Bernhard Stockman (IESG 601 Operational Requirements Area Co-Director) to lead an effort to 602 develop such a plan. Bernhard Stockman is in a position to bring 603 important international input (Stockman92) into this effort because he 604 is a key player in RIPE and EBONE and he is a co-chair of the 605 Intercontinental Engineering Planning Group (IEPG). 607 A specific proposal [Rekhter92] has now emerged. [Rekhter92] 608 incorporates the views of the IETF, RIPE, IEPG, and the Federal 609 Engineering Planning group (FEPG). 611 c. Pursue CIDR extensions to BGP in the BGP WG 613 15 614 This activity stated at the San Diego IETF meeting. A new BGP 615 specification, BGP4, incorporating the CIDR extensions, is now 616 available for public comment [Rekhter92a]. 618 d. Form a new WG to consider CIDR-related extensions to IDRP (eg, 619 specify how run IDRP for IP inter-domain routing) 621 e. Give careful consideration to how CIDR will be deployed in the 622 Internet 624 This includes issues such as how to maintain address aggregation 625 across non-CIDR domains and how CIDR and various IGPs will need to 626 interact. Depending on the status of the combined CIDR activities, 627 the IESG may recommend forming a "CIDR Deployment WG", along the same 628 lines as the current BGP Deployment WG. 630 4.4 Regarding "Bigger Internet Addresses" 632 In April-May 1992, the IESG reviewed the various approaches emerging 633 from the ROAD group activities -- e.g., "Simple CLNP" [Callon92a], 634 "IP Encaps" [Hinden92], "CNAT" [Callon92b], and "Nimrod" [Chiappa91]. 636 (Note: These were the only proposals under serious consideration in 637 this time period. Other proposals, namely "The P Internet Protocol 638 (PIP)" [Tsuchiya92b] and "The Simple Internet Protocol (SIP)" 639 [deering92] have since been proposed. Following the San Diego IETF 640 deliberations in March, "Simple CLNP" evolved into "TCP and UDP with 641 Bigger Addresses (TUBA)", and "IP Encaps" evolved into "IP Address 642 Encapsulation (IPAE)" [Hinden92].) 644 The "Simple CLNP" approach perhaps initially enjoyed more support than 645 other approaches. 647 However, the consensus view in the IESG was that the full impact of 648 transition to "Simple CLNP" (or to any of the proposed approaches) had 649 not yet been explored in sufficient detail to make a final 650 recommendation possible at this time. 652 The feeling in the IESG was that such important issues as 654 - impact on operational infrastructure, 655 - impact on current protocols (e.g., checksum computation 656 in TCP and UDP under any new IP-level protocol), 657 - deployment of new routing protocols, 658 - assignment of new addresses, 659 - impact on performance, 660 - ownership of change control 662 16 663 - effect of supporting new protocols, such as for address 664 resolution, 665 - effect on network management and security, and 666 - the costs to network operators and network users who must 667 be trained in the architecture and specifics of any new 668 protocols needed to be explored in more depth before a 669 decision of this magnitude should be made. 671 At first the question seemed to be one of timing. 673 At the risk of oversimplifying some very wide ranging discussions, 674 many in the IESG felt that if a decision had to be made *immediately*, 675 then "Simple CLNP" might be their choice. However, they would feel 676 much more comfortable if more detailed information was part of the 677 decision. 679 The IESG felt there needed to be an open and thorough evaluation of 680 any proposed new routing and addressing architecture. The Internet 681 community must have a thorough understanding of the impact of 682 changing from the current IP architecture to a new one. The 683 community needs to be confident that we all understand which approach 684 has the most benefits for long term internet growth and evolution, 685 and the least impact on the current Internet. 687 The IESG considered what additional information and criteria were 688 needed to choose between alternative approaches. We also considered 689 the time needed for gathering this additional information and the 690 amount of time remaining before it was absolutely imperative to make 691 this decision (i.e., how much time do we have before we are in danger 692 of running out of IP addresses *before* we could deploy a new 693 architecture?). 695 This led the IESG to propose a specific set of selection criteria and 696 information, and specific milestones and timetable for the decision. 698 The next section describes the milestones and timetable for choosing 699 the approach for bigger Internet addresses. 701 The selection criteria referenced in the milestones are contained in 702 Appendix B. 704 4.5 Milestones And Timetable For Making a Recommendation for "Bigger 705 Internet Addresses" 707 In June, the IESG recommended that a call for proposals be made, with 708 initial activities to begin at the July IETF in Boston, and with a 709 strict timetable for reaching a recommendation coming out of the 710 November IETF meeting [Gross92a]. 712 17 713 Eventually, the call for proposals was made at the July meeting 714 itself. 716 A working group will be formed for each proposed approach. The 717 charter of each WG will be to explore the criteria described in 718 Appendix B and to develop a detailed plan for IESG consideration. 720 The WGs will be asked to submit an Internet-Draft prior to the 721 November 1992 IETF, and to make presentations at the November IETF. 722 The IESG and the IETF will review all submitted proposals and then the 723 IESG will make a recommendation to the IAB following the November 1992 724 IETF meeting. 726 Therefore, the milestones and timetable for the IESG to reach a 727 recommendation on bigger Internet addresses are: 729 July 1992 -- Issue a call for proposals at the Boston IETF meeting to 730 form working groups to explore separate approaches for bigger Internet 731 addresses. 733 August-November 1992 -- Proposed WGs submit charters, create 734 discussion lists, and begin their deliberations by email and/or face- 735 face meetings. Redistribute the IESG recommendation (i.e., this memo). 736 Public review, discussion, and modification as appropriate of the 737 "selection criteria" in Appendix B. 739 October 1992 -- By the end of October, each WG will be required to 740 submit a written description of the approach and how the criteria are 741 satisfied. This is to insure that these documents are distributed as 742 Internet-Drafts for public review well before the November IETF 743 meeting. 745 November 1992 -- Each WG will be given an opportunity to present its 746 findings in detail at the November 1992 IETF meeting. Based on the 747 written documents, the presentations, and public discussions (by email 748 and at the IETF), the IESG will forward a recommendation to the IAB 749 after the November IETF meeting. 751 5. SUMMARY 753 The problems of Internet scaling and address exhaustion are 754 fundamentally important to the continued health of the global 755 Internet, and to the long-term success of such programs as the U.S. 756 NREN and the European EBONE. Finding and embarking on a course of 757 action is critical. However, the problem is so important that we 758 need a deep understanding of the information and criteria described 759 in Appendix B before a decision is made. 761 18 762 With this memo, the IESG re-affirms its earlier recommendation to the 763 IAB that (a) we move CIDR forward in the IETF as described in section 764 4.3, and (b) that we encourage the exploration of other proposals for 765 a bigger Internet address space according to the timetable in section 766 4.5. 768 19 769 Appendix A. FOR MORE INFORMATION 771 To become better acquainted with the issues and/or to follow the 772 progress of these activities: 774 - Please see the documents in the Bibliography below 776 - Join the Big-Internet mailing list 777 (big-internet-request@munnari.oz.au), where the general issues are 778 discussed. 780 - Any new WG formed will have an open mailing list. Please feel free 781 to join each as they are announced on the IETF mailing list. The 782 current lists are 783 PIP: pip-request@thumper.bellcore.com 784 TUBA: tuba-request@lanl.gov 785 IPAE: ip-encaps-request@sunroof.eng.sun.com 786 SIP: (to be formed) 788 - Attend the November IETF in Washington DC (where the WGs will report 789 and the IESG recommendation will begin formulating its recommendation 790 to the IAB). 792 Note: In order to receive announcements of: 794 - future IETF meetings and agenda, 795 - new IETF working groups, and 796 - the posting of Internet-Drafts and RFCs, 798 please send a request to join the IETF-Announcement mailing list 799 (ietf-announce-request@nri.reston.va.us). 801 20 802 Appendix B INFORMATION AND SELECTION CRITERIA FOR "BIGGER INTERNET 803 ADDRESSES" 805 This section describes the information and criteria which the IESG 806 felt that any new routing and addressing proposal should supply. As 807 the community has a chance to comment on these criteria, and as the 808 IESG gets a better understanding of the issues relating to selection 809 of a new routing and addressing architecture, this section may be 810 revised and published in a separate document. 812 It is expected that every proposal submitted for consideration should 813 address each item below on an point-by-point basis. 815 B.1 Description of the Proposed Scheme 817 A complete description of the proposed routing and addressing 818 architecture should be supplied. This should be at the level of 819 detail where the functionality and complexity of the scheme can be 820 clearly understood. It should describe how the proposal solves the 821 basic problems of IP address exhaustion and router resource overload. 823 B.2 Changes Required 825 All changes to existing protocols should be documented and new 826 protocols which need to be developed and/or deployed should be 827 specified and described. This should enumerate all protocols which 828 are not currently in widespread operational deployment in the 829 Internet. 831 Changes should also be grouped by the devices and/or functions they 832 affect. This should include at least the following: 834 - Protocol changes in hosts 835 - Protocol changes in exterior router 836 - Protocol changes in interior router 837 - Security and Authentication Changes 838 - Domain name system changes 839 - Network management changes 840 - Changes required to operations tools (e.g., ping, trace- 841 route, etc) - Changes to operational and administration 842 procedures 844 The changes should also include if hosts and routers have their 845 current IP addresses changed. 847 21 848 The impact and changes to the existing set of TCP/IP protocols should 849 be described. This should include at a minimum: 851 - IP 852 - ICMP 853 - DNS 854 - ARP/RARP 855 - TCP 856 - UDP 857 - FTP 858 - RPC 859 - SNMP 861 The impact on protocols which use IP addresses as data should be 862 specifically addressed. 864 B.3 Implementation Experience 866 A description of implementation experience with the proposal should be 867 supplied. This should include the how much of the proposal was 868 implemented and hard it was to implement. If it was implemented by 869 modifying existing code, the extent of the modifications should be 870 described. 872 B.4 Large Internet Support 874 The proposal should describe how it will scale to support a large 875 internet of 10^^9 networks. It should describe how the proposed 876 routing and addressing architecture will work to support an internet 877 of this size. This should include, as appropriate, a description of 878 the routing hierarchy, how the routing and addressing will be 879 organized, how different layers of the routing interact (e.g., 880 interior and exterior, or L1, L2, L3, etc), and relationship between 881 addressing and routing. 883 The addressing proposed should include a description of how addresses 884 will be assigned, who owns the addresses (e.g. user or service 885 provider), and whether there are restrictions in address assignment or 886 topology. 888 22 889 B.5 Syntax and semantics of names, identifiers and addresses 891 Proposals should address the manner in which data sources and 892 sinks are identified and addressed, describe how current domain 893 names and IP addresses would be used/translated/mapped in their 894 scheme, how proposed new identifier and address fields and 895 semantics are used, and should describe the issues involved in 896 administration of these id and address spaces according to their 897 proposal. The deployment plan should address how these new 898 semantics would be introduced and backward compatibility 899 maintained. 901 Any overlays in the syntax of these protocol structures should be 902 clearly identified and conflicts resulting from syntactic overlay 903 of functionality should be clearly addressed in the discussion of 904 the impact on administrative assignment. 906 B.6 Performance Impact 908 The performance impact of the new routing and addressing architecture 909 should be evaluated. It should be compared against the current state 910 of the art with the current IP. The performance evaluation for 911 routers and hosts should include packets-per-second and memory usage 912 projections, and bandwidth usage for networks. Performance should be 913 evaluated for both high speed speed and low speed lines. 915 Performance for routers (table size and computational load) and 916 network bandwidth consumption should be projected based on the 917 following projected data points: 919 -Domains 10^^3 10^^4 10^^5 10^^6 10^^7 10^^8 920 -Networks 10^^4 10^^5 10^^6 10^^7 10^^8 10^^9 921 -Hosts 10^^6 10^^7 10^^8 10^^9 10^^10 10^^11 923 B.7 Support for TCP/IP hosts than do not support the new architecture 925 The proposal should describe how hosts which do not support the new 926 architecture will be supported -- whether they receive full services 927 and can communicate with the whole Internet, or if they will receive 928 limited services. Also, describe if a translation service be provided 929 between old and new hosts? If so, where will be this be done. 931 B.8 Effect on User Community 933 The large and growing installed base of IP systems comprises people, 934 as well as software and machines. The proposal should describe 935 changes in understanding and procedures that are used by the people 936 involved in internetworking. This should include new and/or changes 937 in concepts, terminology, and organization. 939 23 940 B.9 Deployment Plan Description 942 The proposal should include a deployment plan. It should include the 943 steps required to deploy it. Each step should include the devices and 944 protocols which are required to change and what benefits are derived 945 at each step. This should also include at each step if hosts and 946 routers are required to run the current and proposed internet 947 protocol. 949 A schedule should be included, with justification showing that the 950 schedule is realistic. 952 B.10 Security Impact 954 The impact on current and future security plans should be 955 addressed. Specifically do current security mechanisms such as 956 address and protocol port filtering work in the same manner as 957 they do today, and what is the effect on security and 958 authentication schemes currently under development. 960 B.11 Future Evolution 962 The proposal should describe how it lays a foundation for solving 963 emerging internet problems such as security/authentication, mobility, 964 resource allocation, accounting, high packet rates, etc. 966 24 967 Appendix C. BIBLIOGRAPHY 969 -Documents and Information from IETF/IESG: 971 [Ford92] Ford, P., Gross, P., "Routing And Addressing 972 Considerations", Proceedings of the Twenty-Third IETF, March 973 1992. 975 [Gross92] Gross, P., "Chair's Message and Minutes of the Open IETF 976 Plenary" ,Proceedings of the Twenty-Third IETF, March 1992. 978 [Gross92a] Gross, P., "IESG Deliberations on Routing and 979 Addressing", Electronic mail message to the Big-Internet mailing 980 list, June 1992. 982 -Documents directly resulting from the ROAD group 984 [Fuller92] Fuller, V., Li, T., Yu, J., Varadhan, K., 985 "Supernetting: an Address Assignment and Aggregation Strategy", 986 RFC 1338, USC/Information Sciences Institute, June 1992. 988 [Hinden92] Hinden, B., "New Scheme for Internet Routing and 989 Addressing (ENCAPS)", Email message to Big-Internet mailing list, 990 March 16, 1992. 992 [Callon92a] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), 993 A Simple Proposal for Internet Addressing and Routing". RFC 1347, 994 USC/Information Sciences Institute, June 1992 996 [Deering92] Deering, S., "City Codes: An Alternative Scheme for 997 OSI NSAP Allocation in the Internet", Email message to 998 Big-Internet mailing list, January 7, 1992. 1000 [Callon92b] CNAT 1002 -Related Documents 1004 [Hinden92b] Hinden, R., Crocker, D., "A Proposal for IP Address 1005 Encapsulation (IPAE): A Compatible version of IP with Large 1006 Addresses",Internet-Draft, June 1992. 1008 [Deering92b] Deering, S., "The Simple Internet Protocol", 1009 big-internet mailing list. 1011 [Stockman92] Karrenberg, D., Stockman, B., "A Proposal for a 1012 Global Internet Addressing Scheme", Internet-Draft, May 1992). 1014 [Rekhter92] Rekhter, Y., Li, T., "Guidelines for IP Address 1015 Allocation", Internet-Draft, May 1992. 1017 25 1019 [Rekhter92b] Rekhter, Y., Li, T., "The Border Gateway Protocol 1020 (Version 4)", Internet-Draft, September 1992. 1022 [Rekhter92c] Rekhter, Y., Gross, P., "Application of the Border 1023 Gateway Protocol", Internet-Draft, September 1992. 1025 [Solen92] Solensky, F., Kastenholz, F., "A Revision to IP Address 1026 Classifications", Internet-Draft, March 1992. 1028 [Wang92] Wany, Z., Crocroft, J., "A Two-Tier Address Structure 1029 for the Internet: A Solution to the Problem of Address Space 1030 Exhaustion", RFC 1335, USC/Information Sciences Institute, May 1031 1992. 1033 [Callon91] Callon, R., Gardner, E., Colella, R., "Guidelines for 1034 OSI NSAP Allocation in the Internet", RFC 1237, USC/Information 1035 Sciences Institute, July 1991. 1037 [Tsuchiya92a] Tsuchiya, P., The IP Network Address Translator 1038 (NAT): Preliminary Design, deleted Internet-Draft, April 1991. 1040 [Tsuchiya92b] Tsuchiya, P., "The 'P' Internet Protocol", 1041 Internet-Draft, May 1992. 1043 [Chiappa91] Chiappa, J., "A New IP Routing and Addressing 1044 Architectue", deleted Internet-Draft, July 1991. 1046 [Clark91] Clark, D., "Towards the Future Internet Architecture", 1047 RFC 1287, USC/Information Sciences Institute, December 19 91. 1049 26