diff options
Diffstat (limited to 'doc/rfc/rfc1380.txt')
| -rw-r--r-- | doc/rfc/rfc1380.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc1380.txt b/doc/rfc/rfc1380.txt new file mode 100644 index 0000000..1cce37c --- /dev/null +++ b/doc/rfc/rfc1380.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group P. Gross +Request for Comments: 1380 IESG Chair + P. Almquist + IESG Internet AD + November 1992 + + + IESG Deliberations on Routing and Addressing + +Status Of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard. Distribution of this memo is + unlimited. + +Abstract + + This memo summarizes issues surrounding the routing and addressing + scaling problems in the IP architecture, and it provides a brief + background of the ROAD group and related activities in the Internet + Engineering Task Force (IETF). + + It also provides a preliminary report of the Internet Engineering + Steering Group (IESG) deliberations on how these routing and + addressing issues should be pursued in the Internet Architecture + Board (IAB)/IETF. + +Acknowledgements + + This note draws principally from two sources: the output from the + ROAD group, as reported at the San Diego IETF meeting, and on + numerous detailed discussions in the IESG following the San Diego + IETF meeting. Zheng Wang, Bob Hinden, Kent England, and Bob Smart + provided input for the "Criteria For Bigger Internet Addresses" + section below. Greg Vaudreuil prepared the final version of the + bibliography, based on previous bibliographies by Lyman Chapin and + bibliographies distributed on the Big-Internet mailing list. + +Table of Contents + + 1. INTRODUCTION.................................................. 2 + 2. ISSUES OF GROWTH AND EVOLUTION IN THE INTERNET............... 3 + 2.1 The Problems................................................ 3 + 2.2 Possible Solutions.......................................... 5 + 3. PREPARING FOR ACTION.......................................... 7 + 3.1 The IAB Architecture Retreats................................ 7 + 3.2 The Santa Fe IETF............................................ 7 + 3.3 The ROAD Group and beyond.................................... 8 + + + +Gross & Almquist [Page 1] + +RFC 1380 ROAD November 1992 + + + 4. SETTING DIRECTIONS FOR THE IETF............................... 10 + 4.1 The Need For Interim Solutions............................... 10 + 4.2 The Proposed Phases.......................................... 10 + 4.3 A Solution For Routing Table Explosion -- CIDR............... 12 + 4.4 Regarding "IP Address Exhaustion"............................ 13 + 4.5 Milestones And Timetable For Making a Recommendation for + "Bigger Internet Addresses".................................. 14 + 5. SUMMARY....................................................... 15 + Appendix A. FOR MORE INFORMATION................................. 16 + Appendix B. INFORMATION AND SELECTION CRITERIA FOR "BIGGER + INTERNET ADDRESSES".................................. 16 + Appendix C. BIBLIOGRAPHY......................................... 20 + Security Considerations.......................................... 21 + Authors' Addresses............................................... 22 + +1. INTRODUCTION + + It seems unlikely that the designers of IP ever imagined at the time + what phenomenal success the Internet would achieve. Internet + connections were initially intended primarily for mainframe computers + at sites performing DARPA-sponsored research. Now, of course, the + Internet has extended its reach to the desktop and is beginning to + extend into the home. No longer the exclusive purview of pure R&D + establishments, the Internet has become well entrenched in parts of + the corporate world and is beginning to make inroads into secondary + and even primary schools. While once it was an almost exclusively + U.S. phenomenon, the Internet now extends to every continent and + within a few years may well include network connections in every + country. + + Over the past couple of years, we have seen increasingly strong + indications that all of this success will stress the limits of IP + unless appropriate corrective actions are taken. The supply of + unallocated Class B network numbers is rapidly dwindling, and the + amount of routing information now carried in the Internet is + increasingly taxing the abilities of both the routers and the people + who have to manage them. Somewhat longer-term, it is possible that + we will run out of host addresses or network numbers altogether. + + While these problems could be avoided by attempting to restrict the + growth of the Internet, most people would prefer solutions that allow + growth to continue. Fortunately, it appears that such solutions are + possible, and that, in fact, our biggest problem is having too many + possible solutions rather than too few. + + This memo provides a preliminary report of IESG deliberations on how + routing and addressing issues can be pursued in the IAB/IETF. + + + + +Gross & Almquist [Page 2] + +RFC 1380 ROAD November 1992 + + + In following sections, we will discuss in more detail the problems + confronting us and possible approaches. We will give a brief + overview of the ROAD group and related activities in the IETF. We + will then discuss possible courses of action in the IETF. + Ultimately, the IESG will issue a recommendation from the IESG/IETF + to the IAB. + +2. ISSUES OF GROWTH AND EVOLUTION IN THE INTERNET + +2.1 The Problems + + The Internet now faces three growth-related problems: + + - Class B network number exhaustion - Routing table explosion + - IP address space exhaustion + +2.1.1 Class B Network Number Exhaustion + + Over the last several years, the number of network numbers assigned + and the number of network numbers configured into the Merit NSFnet + routing database have roughly doubled every 12 months. This has led + to estimates that, at the current allocation rate, and in the absence + of corrective measures, it will take less than 2 years to allocate + all of the currently unassigned Class B network numbers. + + After that, new sites which wished to connect more than the number of + hosts possible in a single Class C (253 hosts) would need to be + assigned multiple Class C networks. This will exacerbate the routing + table explosion problems described next. + +2.1.2. Routing Table Explosion + + As the number of networks connected to the Internet has grown, the + amount of routing information that has to be passed around to keep + track of them all is likewise growing. This is leading to two types + of problems. + +Hardware and Protocol Limits + + Routing protocols must pass around this information, and routers must + store and use it. This taxes memory limits in the routers, and can + also consume significant bandwidth when older routing protocols are + used, (such as EGP and RIP, which were designed for a much smaller + number of networks). + + The limits on the memory in the routers seem to be the most pressing. + It is already the case that the routers used in the MILNET are + incapable of handling all of the current routes, and most other + + + +Gross & Almquist [Page 3] + +RFC 1380 ROAD November 1992 + + + service providers have found the need to periodically upgrade their + routers to accommodate ever larger quantities of routing information. + An informal survey of router vendors by the ROAD group estimated that + most of the currently deployed generation of high-end routers will + support O(16000) routes. This will be probably be adequate for the + next 12 to 18 months at the current rate of growth. Most vendors + have begun, or will soon begin, to ship routers capable of handling + O(64000) routes, which should be adequate for an additional two years + if the above Class B Network Number Exhaustion problem is solved. + +Human Limits + + The number of routes does not merely tax the network's physical + plant. Network operators have found that the inter-domain routing + protocol mechanisms often need to be augmented by a considerable + amount of configuration to make the paths followed by packets be + consistent with the policies and desires of the network operators. + As the number of networks increases, the configuration (and the + traffic monitoring to determine whether the configuration has been + done correctly) becomes increasingly difficult and time-consuming. + + Although it is not possible to determine a number of networks (and + therefore a time frame) where human limits will be exceeded, network + operators view this as a significant short-term problem. + +2.1.3. IP Address Exhaustion + + If the current exponential growth rate continues unabated, the number + of computers connected to the Internet will eventually exceed the + number of possible IP addresses. Because IP addresses are divided + into "network" and "host" portions, we may not ever fully run out of + IP addresses because we will run out of IP network numbers first. + + There is considerable uncertainty regarding the timeframe when we + might exceed the limits of the IP address space. However, the issue + is serious enough that it deserves our earliest attention. It is + very important that we develop solutions to this potential problem + well before we are in danger of actually running out of addresses. + +2.1.4. Other Internetwork Layer Issues + + Although the catalog of problems above is pretty complete as far as + the scaling problems of the Internet are concerned, there are other + Internet layer issues that will need to be addressed over the coming + years. These are issues regarding advanced functionality and service + guarantees in the Internet layer. + + In any attempt to resolve the Internet scaling problems, it is + + + +Gross & Almquist [Page 4] + +RFC 1380 ROAD November 1992 + + + important to consider how these other issues might affect the future + evolution of Internet layer protocols. These issues include: + + 1) Policy-based routing + 2) Flow control + 3) Weak Quality-of-Service (QOS) + 4) Service guarantees (strong QOS) + 5) Charging + +2.2 Possible Solutions + +2.2.1. Class B Network Number Exhaustion + + A number of approaches have been suggested for how we might slow the + exhaustion of the Class B IP addresses. These include: + + 1) Reclaiming those Class B network numbers which have been + assigned but are either unused or used by networks which are not + connected to the Internet. + + 2) Modifying address assignment policies to slow the assignment + of Class B network numbers by assigning multiple Class C network + numbers to organizations which are only a little bit to big to be + accommodated by a Class C network number. + + Note: It is already the case that a Class B number is assigned + only if the applicant would need more than "several" Class C + networks. The value of "several" has increased over time from + 1 to (currently) 32. + + 3) Use the Class C address space to form aggregations of + different size than the normal normal Class C addresses. Such + schemes include Classless Inter-Domain Routing (CIDR) [Fuller92] + and the C# scheme [Solen92]. + +2.2.2. Routing Table Explosion + + As was described earlier, there are actually two parts to this + problem. They each have slightly different possible approaches: + +Hardware and Protocol Limits + + 1) More thrust. We could simply recognize the fact that routers + which need full Internet routing information will require large + amounts of memory and processing capacity. This is at best a very + short-term approach, and we will always need to face this problem + in the long-term. + + + + +Gross & Almquist [Page 5] + +RFC 1380 ROAD November 1992 + + + 2) Route servers (a variant of the "More Thrust" solution). + Instead of requiring every router to store complete routing + information, mechanisms could be developed to allow the tasks of + computing and storing routes to be offloaded to a server. Routers + would request routes from the server as needed (presumably caching + to improve performance). + + 3) Topology engineering. Many network providers already try to + design their networks in such a way that only a few of the routers + need complete routing information (the others rely on default + routes to reach destinations that they don't have explicit routes + to). While this is inconvenient for network operators, it is a + trend which is likely to continue. + + It is also the case that network providers could further reduce + the number of routers which need full routing information by + accepting some amount of suboptimal routing or reducing alternate + paths used for backup. + + 4) Charging-based solutions. By charging for network number + advertisements, it might be possible to discourage sites from + connecting more networks to the Internet than they get significant + value from having connected. + + 5) Aggregation of routing information. It is fairly clear that in + the long-term it will be necessary for addresses to be more + hierarchical. This will allow routes to many networks to be + collapsed into a single summary route. Therefore, an important + question is whether aggregation can also be part of the short-term + solution. Of the proposals to date, only CIDR could provide + aggregation in the short-term. All longer-term proposals should + aggregation. + +Human Limits + + 1) Additional human resources. Network providers could devote + additional manpower to routing management, or accept the + consequences of a reduced level of routing management. This is + obviously unattractive as anything other than a very short-term + solution. + + 2) Better tools. Network operators and router vendors could work + to develop more powerful paradigms and mechanisms for routing + management. + + The IETF has already undertaken some work in the areas of route + filtering and route leaking. + + + + +Gross & Almquist [Page 6] + +RFC 1380 ROAD November 1992 + + +2.2.3. IP Address Exhaustion + + The following general approaches have been suggested for dealing with + the possible exhaustion of the IP address space: + + 1) Protocol modifications to provide a larger address space. By + enhancing IP or by transitioning to another protocol with a larger + address space, we could substantially increase the number of + available network numbers and addresses. + + 2) Addresses which are not globally unique. Several proposed + schemes have emerged whereby a host's domain name is globally + unique, but its IP address would be unique only within it's local + routing domain. These schemes usually involve address translating + + 3) Partitioned Internet. The Internet could be partitioned into + areas, such that a host's IP address would be unique only within + its own area. Such schemes generally postulate application + gateways to interconnect the areas. This is not unlike the + approach often used to connect differing protocol families. + + 4) Reclaiming network numbers. Network numbers which are not + used, or are used by networks which are not connected to the + Internet, could conceivably be reclaimed for general Internet use. + This isn't a long-term solution, but could possibly help in the + interim if for some reason address exhaustion starts to occur + unexpectedly soon. + +3. PREPARING FOR ACTION + +3.1 The IAB Architecture Retreats + + In July 1991, the IAB held a special workshop to consider critical + issues in the IP architecture (Clark91). Of particular concern were + the problems related to Internet growth and scaling. The IAB felt + the issues were of sufficient concern to begin organizing a special + group to explore the issues and to explore possible solutions. Peter + Ford (LANL) was asked to organize this effort. The IAB reconvened + the architecture workshop in January 1992 to further examine these + critical issues, and to meet jointly with the then-formed ROAD group + (see below). + +3.2 The Santa Fe IETF + + At the November 1991 Santa Fe IETF meeting, the BGP Working Groups + independently began a concerted exploration of the issues of routing + table scaling. The principal approach was to perform route + aggregation by using address masks in BGP to do "supernetting" + + + +Gross & Almquist [Page 7] + +RFC 1380 ROAD November 1992 + + + (rather than "subnetting"). This approach would eventually evolve + into CIDR. The BGP WG decided to form a separate subgroup, to be led + by Phill Gross (ANS) to pursue this solution. + +3.3 The ROAD Group and Beyond + + At the Santa Fe IETF, the initially separate IAB and BGP WG + activities were combined into a special effort, named the "ROuting + and ADdressing (ROAD) Group", to be co-chaired by Ford and Gross. + + The group was asked to explore possible near-term approaches for the + scaling problems described in the last section, namely: + + - Class B address exhaustion + - Routing table explosion + - IP address space exhaustion + + The ROAD group was asked to report back to the IETF at the San Diego + IETF (March 1992). Suggested guidelines included minimizing changes + to hosts, must be incrementally deployable, and must provide support + for a billion networks. + + The ROAD group was not a traditional open IETF working group. It was + always presumed that this was a one-time special group that would + lead to the formation of other IETF WGs after its report in San + Diego. + + The ROAD group held several face-face meetings between the November + 1991 (Santa Fe) and March 1992 (San Diego) IETF meetings. This + included several times at the Santa Fe IETF meeting, December 1991 in + Reston VA, January 1992 in Boston (in conjunction with the IAB + architecture workshop), and January 1992 in Arizona). There was also + much discussion by electronic mail. + + The group produced numerous documents, which have variously been made + available as Internet-Drafts or RFCs (see Bibliography in Appendix + D). + + As follow-up, the ROAD co-chairs reported to the IETF plenary in + March 1992 in San Diego. Plus, several specific ROAD-related + activities took place during the IETF meeting that week. + + The Ford/Gross presentation served as a preliminary report from the + ROAD group. The basic thrust was: + + 1. The Internet community needs a better way to deal with current + addresses (e.g., hierarchical address assignments for routing + aggregation to help slow Class B exhaustion and routing table + + + +Gross & Almquist [Page 8] + +RFC 1380 ROAD November 1992 + + + explosion). Classless Inter-Domain Routing (CIDR; also called + "supernetting") was recommended. CIDR calls for: + + - The development of a plan for hierarchical IP address + assignment for aggregation in routing, + + - Enhanced "classless" Inter-domain protocols (i.e., carry + address masks along with IP addresses), + + - Inter-Domain routing "Usage documents" for using addressing + and routing plan with the enhanced inter-domain protocols, + and for interacting with IGPs. + + 2. The Internet community needs bigger addresses for the Internet + to stem IP address exhaustion. The ROAD group explored several + approaches in some depth. Some of these approaches were discussed + at the San Diego IETF. However, a final recommendation of a + single approach did not emerge. + + 3. The Internet community needs to focus more effort on future + directions for Internet routing and advanced Internet layer + features. + + Other ROAD-related activities at the San Diego IETF meeting included: + + - Monday, 8:00 - 9:00 am, Report from the ROAD group on + "Internet Routing and Addressing Considerations", + + - Monday, 9:30-12:00pm, Geographical Addressing and Routing + (during NOOP WG session), + + - Monday, 1:30-3:30pm, Preliminary discussion of a CIDR routing + and addressing plan (during ORAD session), + + - Tuesday, 1:30-6:00pm, Internet Routing and Addressing BOF (to + discuss ROAD results and to explore approaches for bigger Internet + address space), + + - Wednesday, 1:30-3:30pm, CIDR Supernetting BOF (joint with BGP + WG), + + - Thursday, 4:00-6:00pm, Summary of ROAD activities in San Diego + followed by open plenary discussion. + + The slides for the Monday presentation (Ford92), slides for the + Thursday summary (and notes in the Chair's message) (Gross92), and + notes for the other sessions are contained in the Proceedings of the + Twenty-Third IETF (San Diego). + + + +Gross & Almquist [Page 9] + +RFC 1380 ROAD November 1992 + + +4. SETTING DIRECTIONS FOR THE IETF + +4.1 The Need For Interim Solutions + + Solutions to the problems of advanced Internet layer functionality + are far from being well understood. While we should certainly + encourage research in these areas, it is premature to start an + engineering effort for an Internet layer which would solve not only + the scaling problems but also those other issues. + + Plus, most approaches to the problem of IP address space exhaustion + involve changes to the Internet layer. Such approaches mean changes + changes to host software that will require us to face the very + difficult transition of a large installed base. + + It is therefore not likely that we can (a) develop a single solution + for the near-term scaling problems that will (b) also solve the + longer-term problems of advanced Internet-layer functionality, that + we can (c) choose, implement and deploy before the nearer-term + problems of Class B exhaustion or routing table explosion confront + us. + + This line of reasoning leads to the inevitable conclusion that we + will need to make major enhancements to IP in (at least) two stages. + + Therefore, we will consider interim measures to deal with Class B + address exhaustion and routing table explosion (together), and to + deal with IP address exhaustion (separately). + + We will also suggest that the possible relation between these nearer- + term measures and work toward advanced Internet layer functionality + should be made an important consideration. + +4.2 The Proposed Phases + + The IESG recommends that we divide the overall course of action into + several phases. For lack of a better vocabulary, we will term these + "immediate", "short-term", mid-term", and "long-term" phases. But, + as the ROAD group pointed out, we should start all the phases + immediately. We cannot afford to act on these phases consecutively! + + In brief, the phases are: + + - "Immediate". These are configuration and engineering actions that + can take place immediately without protocol design, development, or + deployment. There are a number of actions that can begin + immediately. Although none of these will solve any of the problems, + they can help slow the onset of the problems. + + + +Gross & Almquist [Page 10] + +RFC 1380 ROAD November 1992 + + + The IESG specifically endorses: + + 1) the need for more conservative address assignment + policies, + 2) alignment of new address assignment policies with any new + aggregation schemes, + 3) efforts to reclaim unused Class B addresses, + 4) installation of more powerful routers by network operators + at key points in the Internet, and + 5) careful attention to topology engineering. + + - "Short-term". Actions in this phase are aimed at dealing with + Class B exhaustion and routing table explosion. These problems are + deemed to be quite pressing and to need solutions well before the IP + address exhaustion problem needs to be or could be solved. In this + timeframe, changes to hosts can *not* be considered. + + - "Mid-term". In the mid-term, the issue of IP address exhaustion + must be solved. This is the most fundamental problem facing the IP + architecture. Depending on the expected timeframe, changes to host + software could be considered. Note: whatever approach is taken, it + must also deal with the routing table explosion. If it does not, + then we will simply be forced to deal with that problem again, but in + a larger address space. + + - "Long-term". Taking a broader view, the IESG feels that advanced + Internet layer functionality, like QOS support and resource + reservation, will be crucial to the long-term success of the Internet + architecture. + + Therefore, planning for advanced Internet layer functionality should + play a key role in our choice of mid-term solutions. + + In particular, we need to keep several things in mind: + + 1) The long-term solution will require replacement and/or + extension of the Internet layer. This will be a significant + trauma for vendors, operators, and for users. Therefore, it is + particularly important that we either minimize the trauma involved + in deploying the sort-and mid-term solutions, or we need to assure + that the short- and mid-term solutions will provide a smooth + transition path for the long-term solutions. + + 2) The long-term solution will likely require globally unique + endpoint identifiers with an hierarchical structure to aid + routing. Any effort to define hierarchy and assignment mechanisms + for short- or mid-term solutions would, if done well, probably + have long-term usefulness, even if the long-term solution uses + + + +Gross & Almquist [Page 11] + +RFC 1380 ROAD November 1992 + + + radically different message formats. + + 3) To some extent, development and deployment of the interim + measures will divert resources away from other important projects, + including the development of the long-term solution. This + diversion should be carefully considered when choosing which + interim measures to pursue. + +4.3 A Solution For Routing Table Explosion -- CIDR + + The IESG accepted ROAD's endorsement of CIDR [Fuller92]. CIDR solves + the routing table explosion problem (for the current IP addressing + scheme), makes the Class B exhaustion problem less important, and + buys time for the crucial address exhaustion problem. + + The IESG felt that other alternatives (e.g., C#, see Solen92) did not + provide both routing table aggregation and Class B conservation at + comparable effort. + + CIDR will require policy changes, protocol specification changes, + implementation, and deployment of new router software, but it does + not call for changes to host software. + + The IESG recommends the following course of action to pursue CIDR in + the IETF: + + a. Adopt the CIDR model described in Fuller92. + + b. Develop a plan for "IP Address Assignment Guidelines". + + The IESG considered the creation of an addressing plan to be an + operational issue. Therefore, the IESG asked Bernhard Stockman + (IESG Operational Requirements Area Co-Director) to lead an effort + to develop such a plan. Bernhard Stockman is in a position to + bring important international input (Stockman92) into this effort + because he is a key player in RIPE and EBONE and he is a co-chair + of the Intercontinental Engineering Planning Group (IEPG). + + A specific proposal [Gerich92] has now emerged. [Gerich92] + incorporates the views of the IETF, RIPE, IEPG, and the Federal + Engineering Planning group (FEPG). + + c. Pursue CIDR extensions to BGP in the BGP WG. + + This activity stated at the San Diego IETF meeting. A new BGP + specification, BGP4, incorporating the CIDR extensions, is now + available for public comment [Rekhter92a]. + + + + +Gross & Almquist [Page 12] + +RFC 1380 ROAD November 1992 + + + d. Form a new WG to consider CIDR-related extensions to IDRP + (e.g., specify how run IDRP for IP inter-domain routing). + + e. Give careful consideration to how CIDR will be deployed in the + Internet. + + This includes issues such as how to maintain address aggregation + across non-CIDR domains and how CIDR and various IGPs will need to + interact. Depending on the status of the combined CIDR + activities, the IESG may recommend forming a "CIDR Deployment WG", + along the same lines as the current BGP Deployment WG. + +4.4 Regarding "Bigger Internet Addresses" + + In April-May 1992, the IESG reviewed the various approaches emerging + from the ROAD group activities -- e.g., "Simple CLNP" [Callon92a], + "IP Encaps" [Hinden92], "CNAT" [Callon92b], and "Nimrod" + [Chiappa91]. + + (Note: These were the only proposals under serious consideration in + this time period. Other proposals, namely "The P Internet Protocol + (PIP)" [Tsuchiya92b] and "The Simple Internet Protocol (SIP)" + [Deering92] have since been proposed. Following the San Diego IETF + deliberations in March, "Simple CLNP" evolved into "TCP and UDP with + Bigger Addresses (TUBA)", and "IP Encaps" evolved into "IP Address + Encapsulation (IPAE)" [Hinden92].) + + The "Simple CLNP" approach perhaps initially enjoyed more support + than other approaches. + + However, the consensus view in the IESG was that the full impact of + transition to "Simple CLNP" (or to any of the proposed approaches) + had not yet been explored in sufficient detail to make a final + recommendation possible at this time. + + The feeling in the IESG was that such important issues as + + - impact on operational infrastructure, + - impact on current protocols (e.g., checksum computation + in TCP and UDP under any new IP-level protocol), + - deployment of new routing protocols, + - assignment of new addresses, + - impact on performance, + - ownership of change control + - effect of supporting new protocols, such as for address + resolution, + - effect on network management and security, and + - the costs to network operators and network users who must + + + +Gross & Almquist [Page 13] + +RFC 1380 ROAD November 1992 + + + be trained in the architecture and specifics of any new + protocols needed to be explored in more depth before a + decision of this magnitude should be made. + + At first the question seemed to be one of timing. + + At the risk of oversimplifying some very wide ranging discussions, + many in the IESG felt that if a decision had to be made + *immediately*, then "Simple CLNP" might be their choice. However, + they would feel much more comfortable if more detailed information + was part of the decision. + + The IESG felt there needed to be an open and thorough evaluation of + any proposed new routing and addressing architecture. The Internet + community must have a thorough understanding of the impact of + changing from the current IP architecture to a new one. The + community needs to be confident that we all understand which approach + has the most benefits for long-term internet growth and evolution, + and the least impact on the current Internet. + + The IESG considered what additional information and criteria were + needed to choose between alternative approaches. We also considered + the time needed for gathering this additional information and the + amount of time remaining before it was absolutely imperative to make + this decision (i.e., how much time do we have before we are in danger + of running out of IP addresses *before* we could deploy a new + architecture?). + + This led the IESG to propose a specific set of selection criteria and + information, and specific milestones and timetable for the decision. + + The next section describes the milestones and timetable for choosing + the approach for bigger Internet addresses. + + The selection criteria referenced in the milestones are contained in + Appendix B. + +4.5 Milestones And Timetable For Making a Recommendation for "Bigger + Internet Addresses" + + In June, the IESG recommended that a call for proposals be made, with + initial activities to begin at the July IETF in Boston, and with a + strict timetable for reaching a recommendation coming out of the + November IETF meeting [Gross92a]. + + Eventually, the call for proposals was made at the July meeting + itself. + + + + +Gross & Almquist [Page 14] + +RFC 1380 ROAD November 1992 + + + A working group will be formed for each proposed approach. The + charter of each WG will be to explore the criteria described in + Appendix B and to develop a detailed plan for IESG consideration. + + The WGs will be asked to submit an Internet-Draft prior to the + November 1992 IETF, and to make presentations at the November IETF. + The IESG and the IETF will review all submitted proposals and then + the IESG will make a recommendation to the IAB following the November + 1992 IETF meeting. + + Therefore, the milestones and timetable for the IESG to reach a + recommendation on bigger Internet addresses are: + + July 1992 -- Issue a call for proposals at the Boston IETF meeting + to form working groups to explore separate approaches for bigger + Internet addresses. + + August-November 1992 -- Proposed WGs submit charters, create + discussion lists, and begin their deliberations by email and/or + face- to-face meetings. Redistribute the IESG recommendation + (i.e., this memo). Public review, discussion, and modification as + appropriate of the "selection criteria" in Appendix B. + + October 1992 -- By the end of October, each WG will be required to + submit a written description of the approach and how the criteria + are satisfied. This is to insure that these documents are + distributed as Internet-Drafts for public review well before the + November IETF meeting. + + November 1992 -- Each WG will be given an opportunity to present + its findings in detail at the November 1992 IETF meeting. Based + on the written documents, the presentations, and public + discussions (by email and at the IETF), the IESG will forward a + recommendation to the IAB after the November IETF meeting. + +5. SUMMARY + + The problems of Internet scaling and address exhaustion are + fundamentally important to the continued health of the global + Internet, and to the long-term success of such programs as the U.S. + NREN and the European EBONE. Finding and embarking on a course of + action is critical. However, the problem is so important that we + need a deep understanding of the information and criteria described + in Appendix B before a decision is made. + + With this memo, the IESG re-affirms its earlier recommendation to the + IAB that (a) we move CIDR forward in the IETF as described in section + 4.3, and (b) that we encourage the exploration of other proposals for + + + +Gross & Almquist [Page 15] + +RFC 1380 ROAD November 1992 + + + a bigger Internet address space according to the timetable in section + 4.5. + +Appendix A. FOR MORE INFORMATION + + To become better acquainted with the issues and/or to follow the + progress of these activities: + + - Please see the documents in the Bibliography below. + + - Join the Big-Internet mailing list where the general issues + are discussed (big-internet-request@munnari.oz.au). + + - Any new WG formed will have an open mailing list. Please feel + free to join each as they are announced on the IETF mailing + list. The current lists are: + + PIP: pip-request@thumper.bellcore.com + TUBA: tuba-request@lanl.gov + IPAE: ip-encaps-request@sunroof.eng.sun.com + SIP: sip-request@caldera.usc.edu + + - Attend the November IETF in Washington D.C. (where the WGs + will report and the IESG recommendation will begin formulating + its recommendation to the IAB). + + Note: In order to receive announcements of: + + - future IETF meetings and agenda, + - new IETF working groups, and + - the posting of Internet-Drafts and RFCs, + + please send a request to join the IETF-Announcement mailing list + (ietf-announce-request@nri.reston.va.us). + +Appendix B. INFORMATION AND SELECTION CRITERIA FOR "BIGGER INTERNET + ADDRESSES" + + This section describes the information and criteria which the IESG + felt that any new routing and addressing proposal should supply. As + the community has a chance to comment on these criteria, and as the + IESG gets a better understanding of the issues relating to selection + of a new routing and addressing architecture, this section may be + revised and published in a separate document. + + It is expected that every proposal submitted for consideration should + address each item below on an point-by-point basis. + + + + +Gross & Almquist [Page 16] + +RFC 1380 ROAD November 1992 + + +B.1 Description of the Proposed Scheme + + A complete description of the proposed routing and addressing + architecture should be supplied. This should be at the level of + detail where the functionality and complexity of the scheme can be + clearly understood. It should describe how the proposal solves the + basic problems of IP address exhaustion and router resource overload. + +B.2 Changes Required + + All changes to existing protocols should be documented and new + protocols which need to be developed and/or deployed should be + specified and described. This should enumerate all protocols which + are not currently in widespread operational deployment in the + Internet. + + Changes should also be grouped by the devices and/or functions they + affect. This should include at least the following: + + - Protocol changes in hosts + - Protocol changes in exterior router + - Protocol changes in interior router + - Security and Authentication Changes + - Domain name system changes + - Network management changes + - Changes required to operations tools (e.g., ping, trace- + route, etc.) + - Changes to operational and administration + procedures + + The changes should also include if hosts and routers have their + current IP addresses changed. + + The impact and changes to the existing set of TCP/IP protocols should + be described. This should include at a minimum: + + - IP + - ICMP + - DNS + - ARP/RARP + - TCP + - UDP + - FTP + - RPC + - SNMP + + The impact on protocols which use IP addresses as data should be + specifically addressed. + + + +Gross & Almquist [Page 17] + +RFC 1380 ROAD November 1992 + + +B.3 Implementation Experience + + A description of implementation experience with the proposal should + be supplied. This should include the how much of the proposal was + implemented and hard it was to implement. If it was implemented by + modifying existing code, the extent of the modifications should be + described. + +B.4 Large Internet Support + + The proposal should describe how it will scale to support a large + internet of a billion networks. It should describe how the proposed + routing and addressing architecture will work to support an internet + of this size. This should include, as appropriate, a description of + the routing hierarchy, how the routing and addressing will be + organized, how different layers of the routing interact (e.g., + interior and exterior, or L1, L2, L3, etc.), and relationship between + addressing and routing. + + The addressing proposed should include a description of how addresses + will be assigned, who owns the addresses (e.g., user or service + provider), and whether there are restrictions in address assignment + or topology. + +B.5 Syntax and semantics of names, identifiers and addresses + + Proposals should address the manner in which data sources and sinks + are identified and addressed, describe how current domain names and + IP addresses would be used/translated/mapped in their scheme, how + proposed new identifier and address fields and semantics are used, + and should describe the issues involved in administration of these id + and address spaces according to their proposal. The deployment plan + should address how these new semantics would be introduced and + backward compatibility maintained. + + Any overlays in the syntax of these protocol structures should be + clearly identified and conflicts resulting from syntactic overlay of + functionality should be clearly addressed in the discussion of the + impact on administrative assignment. + +B.6 Performance Impact + + The performance impact of the new routing and addressing architecture + should be evaluated. It should be compared against the current state + of the art with the current IP. The performance evaluation for + routers and hosts should include packets-per-second and memory usage + projections, and bandwidth usage for networks. Performance should be + evaluated for both high speed speed and low speed lines. + + + +Gross & Almquist [Page 18] + +RFC 1380 ROAD November 1992 + + + Performance for routers (table size and computational load) and + network bandwidth consumption should be projected based on the + following projected data points: + + -Domains 10^3 10^4 10^5 10^6 10^7 10^8 + -Networks 10^4 10^5 10^6 10^7 10^8 10^9 + -Hosts 10^6 10^7 10^8 10^9 10^10 10^11 + +B.7 Support for TCP/IP hosts than do not support the new architecture + + The proposal should describe how hosts which do not support the new + architecture will be supported -- whether they receive full services + and can communicate with the whole Internet, or if they will receive + limited services. Also, describe if a translation service be + provided between old and new hosts? If so, where will be this be + done. + +B.8 Effect on User Community + + The large and growing installed base of IP systems comprises people, + as well as software and machines. The proposal should describe + changes in understanding and procedures that are used by the people + involved in internetworking. This should include new and/or changes + in concepts, terminology, and organization. + +B.9 Deployment Plan Description + + The proposal should include a deployment plan. It should include the + steps required to deploy it. Each step should include the devices + and protocols which are required to change and what benefits are + derived at each step. This should also include at each step if hosts + and routers are required to run the current and proposed internet + protocol. + + A schedule should be included, with justification showing that the + schedule is realistic. + +B.10 Security Impact + + The impact on current and future security plans should be addressed. + Specifically do current security mechanisms such as address and + protocol port filtering work in the same manner as they do today, and + what is the effect on security and authentication schemes currently + under development. + +B.11 Future Evolution + + The proposal should describe how it lays a foundation for solving + + + +Gross & Almquist [Page 19] + +RFC 1380 ROAD November 1992 + + + emerging internet problems such as security/authentication, mobility, + resource allocation, accounting, high packet rates, etc. + +Appendix C. BIBLIOGRAPHY + +-Documents and Information from IETF/IESG: + + [Ford92] Ford, P., and P. Gross, "Routing And Addressing + Considerations", Proceedings of the Twenty-Third IETF, March 1992. + + [Gross92] Gross, P., "Chair's Message and Minutes of the Open IETF + Plenary", Proceedings of the Twenty-Third IETF, March 1992. + + [Gross92a] Gross, P., "IESG Deliberations on Routing and Addressing", + Electronic mail message to the Big-Internet mailing list, June 1992. + +-Documents directly resulting from the ROAD group: + + [Fuller92] Fuller, V., Li, T., Yu, J., and K. Varadhan, + "Supernetting: an Address Assignment and Aggregation Strategy", RFC + 1338, BARRNet, cisco, Merit, OARnet, June 1992. + + [Hinden92] Hinden, B., "New Scheme for Internet Routing and + Addressing (ENCAPS)", Email message to Big-Internet mailing list, + March 16, 1992. + + [Callon92a] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A + Simple Proposal for Internet Addressing and Routing", RFC 1347, DEC, + June 1992 + + [Deering92] Deering, S., "City Codes: An Alternative Scheme for OSI + NSAP Allocation in the Internet", Email message to Big-Internet + mailing list, January 7, 1992. + + [Callon92b] CNAT + +-Related Documents: + + [Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP Address + Encapsulation (IPAE): A Compatible version of IP with Large + Addresses", Work in Progress, June 1992. + + [Deering92b] Deering, S., "The Simple Internet Protocol", Big- + Internet mailing list. + + [Stockman92] Karrenberg, D., and B. Stockman, "A Proposal for a + Global Internet Addressing Scheme", Work in Progress, May 1992. + + + + +Gross & Almquist [Page 20] + +RFC 1380 ROAD November 1992 + + + [Rekhter92] Rekhter, Y., and T. Li, "Guidelines for IP Address + Allocation", Work in Progress, May 1992. + + [Rekhter92b] Rekhter, Y., and T. Li, "The Border Gateway Protocol + (Version 4)", Work in Progress, September 1992. + + [Rekhter92c] Rekhter, Y., and P. Gross, "Application of the Border + Gateway Protocol", Work in Progress, September 1992. + + [Gerich92] Gerich, E., "Guidelines for Management of IP Address + Space", RFC 1366, Merit, October 1992. + + [Solen92] Solensky, F., and F. Kastenholz, "A Revision to IP Address + Classifications", Work in Progress, March 1992. + + [Wang92] Wany, Z., and J. Crowcroft, "A Two-Tier Address Structure + for the Internet: A Solution to the Problem of Address Space + Exhaustion", RFC 1335, University College London, May 1992. + + [Callon91] Callon, R., Gardner, E., and R. Colella, "Guidelines for + OSI NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, + July 1991. + + [Tsuchiya92a] Tsuchiya, P., "The IP Network Address Translator + (NAT): Preliminary Design", Work in Progress, April 1991. + + [Tsuchiya92b] Tsuchiya, P., "The 'P' Internet Protocol", Work in + Progress, May 1992. + + [Chiappa91] Chiappa, J., "A New IP Routing and Addressing + Architecture", Work in Progress, July 1991. + + [Clark91] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, + "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, + ISI, UCDavis, December 1991. + +Security Considerations + + Security issues are discussed in sections 4.4, B.2, B.10, and B.11. + + + + + + + + + + + + +Gross & Almquist [Page 21] + +RFC 1380 ROAD November 1992 + + +Authors' Addresses + + Phillip Gross, IESG Chair + Advanced Network & Services + 100 Clearbrook Road + Elmsford, NY + + Phone: 914-789-5300 + EMail: pgross@ans.net + + + Philip Almquist + Stanford University + Networking Systems + Pine Hall 147 + Stanford, CA 94305 + + Phone: (415) 723-2229 + EMail: Almquist@JESSICA.STANFORD.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gross & Almquist [Page 22] +
\ No newline at end of file |