RFC 1380

IESG Deliberations on Routing and Addressing 💖

okay bestie, this one is RFC 1380 🎀, written in November 1992 by P. Gross (IESG Chair) and P. Almquist (IESG Internet AD) 👑. It lives in the Network Working Group, and its status is that it provides information for the Internet community 📚. It does not specify an Internet standard. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

---

Status Of This Memo 🌸

this memo is just here to share info with the Internet community 💅. it's not a standard, and distribution of it is unlimited, so share away 🫶.

Abstract ✨

this memo recaps the routing and addressing scaling problems in the IP architecture 🧠, and gives a quick background on the ROAD group and related activities in the Internet Engineering Task Force (IETF) 🦋.

it also gives a preliminary report on the deliberations of the Internet Engineering Steering Group (IESG) about how these routing and addressing issues should be pursued in the Internet Architecture Board (IAB)/IETF 👑.

Acknowledgements 🫶

this note is mostly built from two sources: the output of the ROAD group, as reported at the San Diego IETF meeting, and a ton of detailed IESG discussions that happened after that meeting 💜. Zheng Wang, Bob Hinden, Kent England, and Bob Smart gave input for the "Criteria For Bigger Internet Addresses" section below 🙌. Greg Vaudreuil put together the final bibliography, building on earlier bibliographies by Lyman Chapin and ones floating around 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
   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 🌈

honestly? the designers of IP probably had no clue how huge the Internet would get 😭. connections were first meant mostly for mainframe computers at sites doing DARPA-sponsored research 🖥️. now it's on everyone's desktop and creeping into homes 🏠, it's a whole thing in the corporate world, and it's making its way into secondary and even primary schools 🎒. it used to be almost exclusively a U.S. phenomenon, but now it reaches every continent and could soon include network connections in every country 🌍.

the last couple of years, there have been more and more signs that all this success is going to stress the limits of IP unless we take corrective action 🚨. unallocated Class B network numbers are running out fast, and the amount of routing info the Internet carries is getting really taxing for both the routers and the people who manage them 😩. further down the road, we might run out of host addresses or network numbers altogether 💀.

we could dodge all of this by trying to restrict the Internet's growth, but most people would rather have solutions that let growth keep going 💖. good news: those solutions look possible, and honestly our biggest problem is having too many possible solutions, not too few 🤩.

this memo gives a preliminary report of IESG deliberations on how routing and addressing can be pursued in the IAB/IETF 📝.

later sections dig into the problems and possible approaches in more detail 🔍. we'll give a brief overview of the ROAD group and related IETF activities, then talk through possible courses of action in the IETF 🦋. eventually, 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 is facing three growth-related problems right now:

• 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 assigned network numbers and the number configured into the Merit NSFnet routing database have roughly doubled every 12 months 🚀. that led to estimates that, at the current allocation rate and without corrective measures, it will take less than 2 years to allocate all of the currently unassigned Class B network numbers ⏳.

after that, new sites that wanted to connect more hosts than fit in a single Class C (253 hosts) would need to be assigned multiple Class C networks 🧩. that will make the routing table explosion problem (up next!) even worse 💥.

2.1.2. Routing Table Explosion 🫠

as more networks connect to the Internet, the amount of routing info that has to be passed around to keep track of them all keeps growing 📦. this causes two types of problems.

Hardware and Protocol Limits 🖥️

routing protocols have to pass this info around, and routers have to store and use it 🧳. that strains router memory, and it can also eat up a lot of bandwidth when older routing protocols are used (like EGP and RIP, which were designed for a much smaller number of networks) 🐢.

router memory seems to be the most pressing limit 🚨. the routers used in the MILNET already can't handle all of the current routes, and most other service providers have had to periodically upgrade their routers to fit ever-larger amounts of routing info 🛠️. 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 📊. that's probably going to be adequate for the next 12 to 18 months at the current rate of growth ⏰. most vendors have begun, or soon will begin, shipping routers that can handle O(64000) routes, which should be adequate for an additional two years if the Class B Network Number Exhaustion problem above is solved 🎉.

Human Limits 🙃

the number of routes doesn't just strain the network's physical plant 💻. network operators have found that inter-domain routing protocol mechanisms often need a considerable amount of extra configuration to make packet paths match the policies and desires of the operators 🛠️. as the number of networks increases, that configuration (and the traffic monitoring needed to check whether it was done correctly) gets harder and more time-consuming 😵.

it's not possible to pin down a number of networks (and therefore a timeframe) where human limits will be exceeded 🌫️. still, network operators see this as a significant short-term problem 🙈.

2.1.3. IP Address Exhaustion 🥺

if the current exponential growth rate keeps going 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 never fully run out of IP addresses, since we'll run out of IP network numbers first 🤔.

there's a lot of uncertainty about when we might exceed the limits of the IP address space 🌫️. however, the issue is serious enough that it deserves our earliest attention 👀. it's really important that we develop solutions to this potential problem well before we're in actual danger of running out of addresses ⏰.

2.1.4. Other Internetwork Layer Issues 🌟

the catalog of problems above is pretty complete as far as Internet scaling is concerned, but there are other Internet layer issues that will need to be addressed over the coming years 🔮. these are about advanced functionality and service guarantees in the Internet layer 💅.

any attempt to resolve the Internet scaling problems should 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 🐢

people have suggested a bunch of approaches for how we might slow down the exhaustion of Class B IP addresses 💭. these include:

1. Reclaiming Class B network numbers that have been assigned but are either unused, or used by networks that aren't 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 that are only a little bit too big for a single Class C network number 🍰.

Note: it's 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. Using the Class C address space to form aggregations of a different size than the 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:

More thrust 💪 is the first idea, bestie. We could just admit that routers which need full Internet routing info are going to need a LOT of memory and processing power. ngl that's at best a super short-term move, and we'll always have to deal with this problem in the long run 😩

1. Route servers (a variant of the "More Thrust" solution) 🛰️ Instead of making every router store the complete routing info, we could build mechanisms that offload the work of computing and storing routes onto a server. Routers would request routes from the server as needed (presumably caching to improve performance) 🧚
2. Topology engineering 🗺️ Lots of network providers already design their networks so only a few routers need complete routing info. The rest rely on default routes to reach destinations they don't have explicit routes to. Yes it's inconvenient for operators, but it's a trend that's likely to keep going 💅 It is also the case that network providers could cut down even more on the routers that need full routing info, by accepting some suboptimal routing or by reducing the alternate paths used for backup 🫶
3. 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.
4. Aggregation of routing information 🧩 It's pretty clear that in the long-term, addresses are going to need to be more hierarchical. That lets routes to many networks get collapsed into a single summary route. So the big question is whether aggregation can also be part of the short-term solution. Of the proposals so far, only CIDR could provide aggregation in the short-term. All longer-term proposals should aggregation.

---

1. Additional human resources 🧑‍💻 Network providers could throw more manpower at 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 ✨

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 where a host's domain name is globally unique, but its IP address would be unique only within its local routing domain. These schemes usually involve address translating.
3. Partitioned Internet 🧱 The Internet could be partitioned into areas, so 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 it 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" (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-to-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. Better addressing for current needs 🧭 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 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. Bigger addresses 🚀 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. Future directions 🔭 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) 🗂️

---

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 to host software, which 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 🗓️

okay so the IESG says we should split the whole plan into phases 💅 we don't have fancy vocab for it, so we're calling them "immediate", "short-term", "mid-term", and "long-term". BUT here's the tea 🫖: as the ROAD group pointed out, we should start all the phases right away. We literally cannot do them one after another, bestie 😭

here's the quick lowdown:

• "Immediate". These are configuration and engineering actions that can happen right now without protocol design, development, or deployment 🔧 there are a bunch of things that can kick off today. None of them will solve any of the problems, ngl, but they can help slow the onset of the problems 🐢

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 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, iykyk. 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 short- 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 a 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 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 ⏳ main character energy 👑

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 started at the San Diego IETF meeting. A new BGP specification, BGP4, incorporating the CIDR extensions, is now available for public comment [Rekhter92a] 📣

• d. Form a new WG to consider CIDR-related extensions to IDRP (e.g., specify how to 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 be trained in the architecture and specifics of any new protocols needed

...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 🎉

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 ✨

okay bestie, this part is the big-picture stuff 🌸 Internet scaling and address exhaustion are fundamentally important to the continued health of the global Internet, and to the long-term success of programs like the U.S. NREN and the European EBONE 💅 Finding and embarking on a course of action is critical 😭 but the problem is so important that we need a deep understanding of the information and criteria in Appendix B before anyone makes a decision. no shortcuts!! 🧐

With this memo, the IESG re-affirms its earlier recommendation to the IAB. The recommendation is that (a) we move CIDR forward in the IETF as described in section 4.3, and (b) we encourage the exploration of other proposals for a bigger Internet address space according to the timetable in section 4.5 🎀

Appendix A. FOR MORE INFORMATION 📚

if you want to get better acquainted with the issues, or keep up with how these activities are going, here's the tea 🍓

• 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 that gets formed will have an open mailing list. Feel free to join each one as it's 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. That's where the WGs will report, and where the IESG recommendation starts getting shaped into its recommendation to the IAB 🦋

Note: if you want announcements about:

• future IETF meetings and agenda,
• new IETF working groups, and
• the posting of Internet-Drafts and RFCs,

just 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 lays out the info and criteria the IESG feels any new routing and addressing proposal should supply 💡 Since the community gets a chance to comment on these criteria, and since the IESG keeps learning more about picking a new routing and addressing architecture, this section may be revised and published as a separate document.

It is expected that every proposal submitted for consideration should address each item below on a point-by-point basis 🫶

B.1 Description of the Proposed Scheme 💖

A complete description of the proposed routing and addressing architecture should be supplied. It should be at the level of detail where the functionality and complexity of the scheme can be clearly understood 🧠 It should also 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. New protocols that 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 whether 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 🙈

B.3 Implementation Experience 🛠️

A description of implementation experience with the proposal should be supplied. This should include how much of the proposal was implemented and how hard it was to implement. If it was implemented by modifying existing code, the extent of those 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 the different layers of routing interact (e.g., interior and exterior, or L1, L2, L3, etc.), and the 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 how data sources and sinks are identified and addressed. They should describe how current domain names and IP addresses would be used, translated, or mapped in the scheme, and how the proposed new identifier and address fields and semantics are used. They should also describe the issues involved in administering these id and address spaces according to the proposal. The deployment plan should address how these new semantics would be introduced and how backward compatibility would be maintained.

Any overlays in the syntax of these protocol structures should be clearly identified. 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, plus bandwidth usage for networks. Performance should be evaluated for both high speed and low speed lines 🚀

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. That covers whether they get full services and can talk to the whole Internet, or whether they only get limited services. Also, describe if a translation service be provided between old and new hosts? If so, where will this be done? 🌈

B.8 Effect on User Community 👯

The large and growing installed base of IP systems includes people, as well as software and machines. The proposal should describe changes in understanding and in the procedures used by the people involved in internetworking. This should include new and/or changed concepts, terminology, and organization 💜

B.9 Deployment Plan Description 🗺️

The proposal should include a deployment plan, and that plan should include the steps required to deploy it. Each step should include the devices and protocols which are required to change, along with what benefits are derived at each step. This should also include, at each step, whether 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 that are currently under development? this part is serious business 💀

B.11 Future Evolution 🚀

The proposal should describe how it lays a foundation for solving 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.

[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 ✨

okay bestie, the security stuff isn't squished into one spot. it's spread out so you can find the juicy bits where they matter 🔒 security issues are discussed in sections 4.4, B.2, B.10, and B.11. go check those out, they're the real tea 🍵💅

Authors' Addresses 💌

these are the two cuties who wrote it 🧚 here are their contact details, straight from the source:

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

and that's a wrap on RFC 1380 🎀🦋 literally the most iconic protocol doc, obsessed!! 💖