========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0178.txt Running out of Internet addresses? -- TCP/IP list http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8813.mm.www/0121.html http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8813.mm.www/0144.html http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8813.mm.www/0156.html http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8813.mm.www/0178.html http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8813.mm.www/0180.html http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8813.mm.www/0237.html http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8813.mm.www/0244.html ------------------------------------------------------------------------- Roy Smith (25 November 1988): Has anybody made any serious estimates of how long it will be before we run out of 32-bit IP addresses? (Silly question; I'm sure a very great amount of thought has been given to it by many people.) With the proliferation of such things as diskless workstations, each of which has its own IP address (not to mention terminal multiplexors which eat up one IP address per tty line!), it seems like it won't be too long before we just plain run out of addresses. Yes, I know that 2^32 is a hell of a big number, but it seems like we won't get anywhere near that number of assigned addresses before we effectively run out because most nets are sparsely populated. My little bit of wire, for example, has 256 allocated addresses yet I'm only actually using 30 or so. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network" ------------------------------------------------------------------------- CERF (27 Nov 1988): Roy, As you noted, the allocations are often larger than the actual host count because of the way net numbers must be bound to a chunk of address space in the 32 bit formats available. We should be worried about this and should be thinking about how to expand the available address space. Possibilities include adopting ISO IP numbering (variable length - non-trivial), introducing a 64 bit format (a new IP version number would probably be needed), adding an extended address option (awkward, I suspect), others? Vint Cerf ------------------------------------------------------------------------- Frank Kastenholz (28 Nov 88): A quick perusal of my copy of Internet Numbers indicates that there are a fair number of assigned addresses that are not connected to the Internet - perhaps these addresses could be reclaimed - there is one class A, about 40 class B and I have not counted how many class C addresses that are not connected. This is not a long term solution, but if a crunch comes quickly then it may be a temporary solution that would last long enough to get a proper solution done. Frank Kastenholz Eastman Kodak ------------------------------------------------------------------------- CERF (29 Nov 1988): Jon, The way I read it, there are 127 possible class A nets, 16,383 class B nets, roughly 2M+ class C nets, and a bunch (2**28 - 1) of broadcast addresses. The large number of class C nets available should have been sufficient, but we are experiencing some difficulty dealing with large numbers of nets at the IP gateway level (table and routing update sizes). Subnetting works better with class B network format, because there is some room for subnet and host address space. Reparsing the class C address space might be a helpful step towards making more nets effectively available. Vint ------------------------------------------------------------------------- postel (29 Nov 88): Vint: You are correct about the number of network numbers, 126 class A, 16K class B, and 2M class C. This small address space may be come a problem in a few years, in the mean time is there going to be a solution to the routing problem so that we can have gateways that will route to more than 500 networks? --jon. ------------------------------------------------------------------------- John Romkey (30 Nov 88, ToasterNet) In article <207@logicon.arpa> Makey@LOGICON.ARPA (Jeff Makey) writes: >With 4.2 million network numbers, 115 new network numbers could be >registered every DAY, and it would still take 100 years to exhaust >them all. It seems that there really isn't a problem in the >foreseeable future. Ah, they said that about addresses spaces so many times...it is to cry. I want to see a protocol address space large enough to handle a node in each household appliance, each piece of electronic equipment, and several extras per household, office and vehicle. Traffic lights on the Internet. Stray toasters. And enough addresses left over to scatter hosts across the inner solar system. I'm not very worried about IP running out of addresses here because I'm pretty sure that by the time we start doing all this we'll have learned enough new things about protocols and the devices we're communicating with that we'll have scrapped TCP/IP and gone on to new horizons. Same thing goes for ISO (which there is not a whole lot of 'practical experience' in, anyway). I have a small piece of internet in my dining room. It's not connected to the rest of the world yet (give me another few months), but soon it will spread through the rest of the house. And you can buy a toaster with a microprocessor in it from Sears. No ethernet, yet. - john -- - john romkey romkey@asylum.uucp romkey@xx.lcs.mit.edu romkey@asylum.sf.ca.us Find the cost of freedom, buried in the ground Mother Earth will swallow you, lay your body down. ------------------------------------------------------------------------- Amanda Walker (1 Dec 88, Re: ToasterNet) In article <1010@asylum.sf.ca.us>, romkey@asylum.sf.ca.us (John Romkey) writes: > I want to see a protocol address space large enough to handle a node > in each household appliance, each piece of electronic equipment, and > several extras per household, office and vehicle. Traffic lights on > the Internet. Stray toasters. And enough addresses left over to > scatter hosts across the inner solar system. This reminds me of a remark Gurshuran Sidhu made at an Apple networking conference a couple years ago. He described Ethernet addresses as having been "designed to be intergalactically unique." The biggest problem, I think, is that 32 bits (or 48, or whatever) is certainly big enough to serve as a *physical* addressing scheme, but we keep chopping up addresses so that we can have a *logical* addressing scheme. I mean, we have a Class C address, and we've got a whopping four hosts. That's 1.5% utilization. Of course, it's nice to be able to add hosts as we get them, and subnetting makes contiguous blocks A Good Thing, but it still means that the address space is sparsely populated if you think of it as a physical address space. One advantage that I see IP having over OSI (from what I understand about OSI addressing, anyway), is that the encoding scheme is very simple, thus giving some of the advantages of both physical and logical addressing. I remember the NCP/TCP switchover. It will be a lot harder the next time... -- Amanda Walker ...!uunet!lts!amanda / lts!amanda@uunet.uu.net InterCon, 11732 Bowman Green Drive, Reston, VA 22090 -- "The best way to predict the future is to invent it." -- N. Negroponte ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0203.txt Internet Activities Board Summary of Internet Architecture Discussion January 8-9, 1991 1. INTRODUCTION The Internet Activities Board (IAB) met with the Internet Engineering Steering Group (IESG) on January 8-9, 1991 at the USC Information Sciences Institute in Marina del Rey, CA. The meeting devoted the afternoon of the first day and the morning of the second day to an extended discussion of the future directions for Internet architecture. This document reports on this architecture discussion, which was led by Dave Clark. The minutes of the rest of the meeting are reported elsewhere. 2. DEFINING THE PROBLEM The first afternoon was spent trying to define the problems to be solved. Clark began the discussion with a presentation of his view of the key issues; his slides are reproduced in Appendix A. Each of his topic slides (7-12) were then discussed in turn. 2.1 The Multi-Protocol Internet [Slide 7] The discussion began by setting a timeframe for evolution of the Internet and the TCP/IP protocol suite. This timeframe determines the importance of several issues, in particular routing and addressing. It was accepted that OSI is not yet here, and the general feeling was that it will not be for some time. A question: does OSI lead or follow current technology? Alternative scenarios were: 1. OSI and TCP/IP both live forever, 2. TCP/IP fades, 3. OSI fades, 4. Next Generation replaces both. Debate ensued over the merit of evolving two protocol suites in tandem; some advocated friendly competition, while others called it a waste of effort which could lead to the demise of both. One alternative discussed was to redirect IAB/IETF efforts to emphasize OSI, devoting all our resources to making OSI a reality. Such actions could include profiling standards, merging standards, and fixing broken OSI standards. However, it was observed that the IAB can only have direct influence over protocols that it controls; an effort based on profiling other protocols is not likely to be successful. Here is a sample of comments on this topic, lightly paraphrased: * "The answer will come from the grass roots; people won't switch unless the old suite breaks or the new one has more features". * "Are we asking the wrong question? We're facing really heterogeneous networks, and must include variety in our thinking". * "The IAB can exert more leadership over the (only) suite that it controls". * "Even productive competition may be a diversion of effort; we may be getting too complex". * "If the goal is interoperation, the world must agree on the protocol basis; right now that means TCP/IP". * "I prefer TCP/IP because * prefer the [development and standardization] process [of the IAB/IETF]". * "I am sympathetic to the concern about dilution of effort, but * doubt that there is really a tradeoff; it will be different people". The concensus most nearly supported the continuation of parallel development of both TCP/IP and OSI suites. 2.2 Routing and Addressing [Slide 8] The problems of routing and addressing may be strongly affected by the rise of commercial common carrier networks. Some of the scaling and topology problems we experience today will look different as access control and topology become important aspects of the interconnection of commercial service providers. The target size of the Internet is an important consideration. One viewpoint expressed was that commercial common carriers will dominate, so we only have to wait for them to solve our problems of routing and addressing. However, the more widely held viewpoint was that, while the topology may eventually be whatever the common carriers give us, we cannot count on their providing us the complete service we want. The Internet must be seen as a large and diverse system, and the evolving architecture must be able to deal with combined public/private Internet with a very large address space. Currently there are many different grades of service, rather than one uniform service. It was suggested that a package transportation service is a better service analogy than the telephone system. Thus, the telephone system offers a homogeneous service, while planes, ships, trains all transport packages but offer different grades of service. Such a diverse infrastructure is needed in internetting. It seemed likely that some policy-based routing will be necessary. If we assume that the Internet architecture will continue in use indefinitely, then we need flexibility. Multicast was a controversial topic. Currently there are no applications available that can make use of its facilities. However, there are some future uses of multicast, including routing, mailing lists, and mass distributions. 2.3 Getting BIG [Slide 9] Getting big presents several obstacles. The IAB's past X.500 deployment planning effort was discussed as an example of the problems that can arise. The problem was partly that X.500 is an international standard, hard to adapt. It was suggested that testing new services like X.500 in the Internet can be very valuable, but it is possible only when there is government funding: "For success in applications testing, you need to find a sugar daddy". We need more tools for applications -- IPC, RPC, authentication -- but unfortunately funding for applications development is largely missing. It is important to distinguish research from infrastructure development. 2.4 Dealing with Divestiture [Slide 10] A number of points were made. * The introduction of commercial services and the need for accounting will impact the protocols. * We need to develop a variety of means for measurement and accounting; pricing can be determined later. * Charging may lead to protocol changes to minimize costs, and the consequences are unpredictable. * There is no difference in the mechanics of accounting information collection between a connection-oriented and a connectionless network. However, billing on a per-packet basis in a datagram network could lead to very high overhead. * There is a need for authentication, to prevent fraud. * The ability to share a common link between two or more administrations is needed. 2.5 New Services [Slide 11] Video is an important new service. Video is defined here as a point to point frame-oriented delay-sensitive service. There is a need to do this in a few years, just ahead of the 200MIPs multimedia workstation. Distributed computing and transaction protocols need to be developed. There is an authentication problem in an operating system when a transaction just appears at a host. One problem with running real distributed applications in the Internet has been the need to set up a lot of configuration information at each end. It was also observed that even so simple a distributed application as the DNS does not work very well, so we need to do a lot more work on distributed application tools. 2.6 Security [Slide 12] We need more sophistated models of authentication. Application relays make it hard to build new applications. 3. ARCHITECTURAL SOLUTIONS It was intended that the second part of the discussion would home in on some solutions. However, the group was far from a concensus on most issues. Therefore, the time was spent in detailed viewpoint presentations by a number of the participants. 3.1 Vint Cerf Cerf opened with a list of assertions about the future of the Internet. 1. It is less important that a particular technical prediction actually occurs than it is that the architecture makes it POSSIBLE. 2. All technologies are eventually overtaken by new ones. Must accomodate PEAK requirements, and must also be prepared for some technologies to linger long past their peak. 3. The number of "terminations" (e.g., IP addresses) per person varies from .001 to 1000. 4. Total terminations ~ P/4 * 3 * 10, where P = number of persons = 250M, 3 corresponds to home + 2 workers, and the last factor of 10 is for safety. Implies terminations ~ 2*10**9 for US, 36*10**9 for the world. Note that the phone system has extremely high fan-out, Internet fan-out is much lower. Can (will? should?) this change? 5. The routing problem is a function of the number of networks and the topology (hierarchy). Suppose we separate HOST# from NET#, and place NET# into a hierarchical structure with provision for "break-out". Would 32 bits of NET# be enough to cover the administrative overhead of delegated assignment of address space? Strawman: NET# 32 HOST# 32 where NET# is hierarchical, and HOST# is perhaps globally unique. [Debate on this was postponed.] 6. Hosts incapable of supporting DNS and other core requirements must ultimately be abandoned to their fate (when can we stop catering to them?). Backward compatibility need not be absolute; a rational window of new and old technology should be defined. Within each protocol suite, there must be a "central, core" set of protocols that defines the network architecture. The question was raised: At what level should multi-protocols exist: IP, Mail, Postscript? Cerf continued with a proposed list of requirements, and attempted to gather from the group a general sense of agreement or uncertainty about each one (noted in square brackets). 1. Must support more than one protocol suite operating concurrently. It is NOT required that they interwork with each other. Some common applications might be usefully interworked. [Much discussion]. 2. Must be able to accomodate transmission bandwidths 2.4Kbps (?) to over 10 Gbps. [Not universal agreement; perhaps lower end should be increased.] 3. Must accomodate new switching and transmission media wherever possible (e.g., SMDS; ISDN; BISDN; Frame Relay; optically- switched networks; color-multiplexed, tuned-laser nets, and radio technology). [Agreed] 4. Must accomodate an address space for 36*10**9 terminations, 1*10**9 networks. NET# 32 HOST# 32 [Needs debate] 5. Must accomodate private and public network components. [Agreed] 6. Must support (at least, not inhibit) collection of statistics for accounting, billing. [Agreed: need example billing and reconciliation scenarios, and need reverse charging. Need debate: IP "charge code" option, authenticable charge codes. Question: in what level of architecture do these features show up??] 7. Must support administratively-restricted connectivity. May be at different layers. + Security constraints (IPSO) + Closed/partially open "user groups" + DNS "tailoring" (non-uniform configuration)? + Router configuration tables (e.g., NSFNET configuration) [Needs discussion.] 8. Must support several classes of service. (Pick a few to start, e.g., "guaranteed bandwidth", "bounded delay", and figure out how they might work. What if not supportable by all networks?) [General agreement] 9. Must provide for end-to-end authenticated and/or secure (private) communication. + Application level, so that authentication/privacy survives across application-level relay. + Transport level? + SNMP + Routing Protocols + DNS/X.500? + Playback-immune authentication [General agreement] 10. Support host mobility. Initiate communications FROM "mobile" host => temporary binding of IP address (PPP, SLIP). EASY CASE (?). Receive communications when mobile (or at destination) => dynamic tracking of mobile address. HARD! Would dynamic name/address binding suffice? How to authenticate DNS update? Delay and responsiveness? (Some network technologies make it easy). [Timescale is an issue. Maybe not at high speed? (Rate of change of connectivity is the big issue). What about military applications?] 3.2 Christian Huitema Huitema saw the biggest problem in the Internet as one of getting big, or rather, "getting wide". Topology is moving to multiple backbones and multiple registries. To scale to the sizes we are considering, a fully dynamic routing process is impossible. What is needed is a directory of address to network translations and routing info. Flooding of routing information should be replaced by a route server, which can either hold pre-computed routes or compute routes as needed. 3.3 Noel Chiappa Security is the key to the future evolution of the Internet. The solution to this problem will dictate the architecture of the rest of the system. 3.4 Bob Hinden Hinden commented on each of the topic slides. 1. Multi-Protocol Internet It would be nice to have one protocol suite, but we must live with both TCP/IP and OSI. A useful strategy might be to feed TCP/IP protocol developments into OSI process (e.g., BGP -> IDRP). 2. Routing and Addressing + Need 1 to 2 orders of magnitude growth. + Addresses should be identifiers, logically distinct from routes. + We will have to impose a hierarchical structure to handle growth. A 3-tier topology (backbone, regional, private) is sufficient, but it must provide for arbitrary interconnections. + Policy: Source controlled. Backbone, regional, private networks will support distinct policies (where they provide parallel service). + Mobile host support would be desirable. + Multicasting will not be useful until there are real applications. 3. Getting Big Applications are badly needed. + Make email good enough for commerce. + Desktop conferencing with video. + Bulletin board paradigm: it is powerful and should be exploited more. + Information collection (Knowbots?) + Video retrieval and libraries. + Distributed simulation. 4. Divestiture + Does not believe common carriers will provide universal service ("the Cheriton conjecture"); we will still need to do internetting. + Need accounting, not billing. 5. New Services Video is very important. 6. Security The network needs to protect itself: control protocols need security. The network should provide an authentication service. All other security needed by an application can be end-to-end. 3.5 Russ Hobby Hobby emphasized the need for new applications. Tools are needed for building distributed applications, including RPC and standard presentation formats. Both personal communication and "virtual computer" applications need work. There is a pressing need to recruit a set of experts and secure funding for them. 3.6 Joyce Reynolds Reynolds enumerated a list of needed user services. There is a need to international coordination and for more publicity. A network information services infrastructure and yellow pages are needed. Issues of copyright and intellectual property need to be explored. 3.7 Dave Crocker Crocker identified the need for upper layer development. There is a missing skill set in the IETF, presentation and applications development. There is a need to begin hiding the complexity of the network. 3.8 Tony Lauck Lauck presented many points. 1. Architecture is more than the protocols, it is addressing. 2. Relays are a necessary evil, because of history, pragmatics, and especially corporate security policies. Better Internet security will result in fewer relays. The IAB should work to limit the growth of relays. 3. There is not chance to constrain the development of multiple protocol suites; they are here today. Beware of problems of testing interoperability, with exponential combinations at various layers. 4. The size of the Internet is not a big issue. 10**9? 10**11? 10**12? 5. In large networks, addresses, routes, and topology must be related for reasonable performance -- log(n) vs. n. Hierarchy is sub-optimal, but at least it is possible, and will allow the construction of large networks. 6. Policy routing is all solutions with no questions. 7. Support for mobile hosts is needed, to make them more useful for personal work. 8. Multicast has marginal value, could be dangerous. 9. Phase out fragmentation, it's a mistake in IP that OSI copied. 10. The network should support devices ranging from small thermostats to large supercomputers. 11. Charging is important because without it there is little motivation to develop new applications. The ban on commercial use also restricts innovation. 12. Must have controls for limited sharing of links. Hard problem is to keep this simple. 13. Transaction processing standards are complex and farther along in OSI. 14. Distributed processing is coming (slowly) in OSI. We should work with existing efforts in these applications. 15. End node cannot be the only point for security. Mis- configuration is a real danger and the Internet should be able to defend itself. 16. Global authentication is most important part of distributed processing. 3.9 Ross Callon Callon discussed the coexistence of multiple protocol suites, starting from a series of questions: 1. What is meta-architecture for a multi-protocol Internet? 2. Does the concept of a "pure suite" exist? For example, the Internet includes other defacto standards like NFS and Postscript. 3. Might it make sense to fill the holes in one suite using protocols from another suite? 4. This does not break the notion of distinct TCP/IP and OSI protocol suites, but it might be a good idea to break it. The idea of merely sharing the links and letting the rest of the protocol stack be different defeats interoperability. He proposed to chip away at the differences by sharing: routing, user agents, directories (DNS-X.500 merge), mail protocols (SMTP exchange of X.400 format), ODA and RDI, and EDI. This sharing would unify the architecture, save some effort, and enhance interoperability. 3.10 Lyman Chapin The Internet will change with the introduction of commercial carriers. A multi-protocol-suite Internet is currently a necessity, although this is not best architectural choice. OSI efforts really need the input of the IETF community. There is the very real possibility that the IETF can have profound impact on the course of OSI protocols. Chapin summarized the possibilities in the following diagram: | _______ | | TCP |----------------------> |_______| | | ______|____ | |"new stuff"| | "Future" |___________| | | | _______ V | | OSI |----------------------> |_______| | 3.11 Steve Kent Kent offered ideas on the internet security architecture. 1. Do we put security in only the endpoints? "Hosts will always be the best defense or the weakest link". 2. Site administrators erect perimeter defenses; architecture needs to include them. Now that hosts are being managed by users, managers are increasingly unable to administer individual computers, so they use using perimeter defense. 3. Need both end security services and also some functions in intermediate system, e.g., accounting and billing. 4. Security is ultimately linked to routing and addressing. 5. He dislikes application level relays, and there are also some security problems. Where does security go in the protocol stack? In the application there is too much duplication, and presentation syntax is a problem if security is in the applications. 6. Global authentication would be a Good Thing. 4. WRAP-UP Clark led a final high-level wrap up. He saw three alternative futures: 1. Relays dominate the world. X.400 becomes the only ubiquitous protocol, while IP/CLNP are used only locally. X.400 and X.500 become generalized to accommodate other applications. Clark rejects this as the "only" solution. 2. Commercial carriers dominate. Routing is handled entirely inside the common carriers; this is the "Cheriton Conjecture". We must accept this as an ultimate possibility. 3. Heterogeneity dominates. Can it be global? The group felt a need to build a future that accommodates these diverse visions, even if the complex solution ends up not being needed. The IAB is in a position to influence the future, and should work towards the preferable outcomes. The IAB felt that vision 1 is a nightmare. However, it will exist to a limited extent, so application level gateways should be architected into the system. Vision 2 is a possibility the IAB must deal with. Vision 3 is the most general, and constitutes the basis for a plan. Further discussion is needed, and the IAB planned an "architectural summit". There was lots of interest in an architecture summit. Participation will be limited to the IAB and IESG and all participants should come prepared with papers. This is tentatively scheduled for June 11-13, 1991. _________________________________________________________________ APPENDIX A: Dave Clark Introduction Slide 1 WHITHER THE INTERNET? OPTIONS FOR ARCHITECTURE IAB/IESG -- Jan 1990 David D. Clark _____________________________________________________________ Slide 2 SETTING THE TOPIC OF DISCUSSION Goals: * Establish a common frame of understanding for IAB, IESG and the Internet community. * Understand the set of problems to be solved. * Understand the range of solutions open to us. * Draw some conclusions, or else "meta-conclusions". _________________________________________________________________ Slide 3 SOME CLAIMS -- MY POSITION We have two different goals: * Make it possible to build "The Internet" * Define a protocol suite called Internet Claim: These goals have very different implications. The protocols are but a means, though a powerful one. Claim: If "The Internet" is to succeed and grow, it will require specific design efforts. This need will continue for at least another 10 years. Claim: Uncontrolled growth could lead to chaos. Claim: A grass-roots solution seems to be the only means to success. Top-down mandates are powerless. _________________________________________________________________ Slide 4 OUTLINE OF PRESENTATION 1) The problem space and the solution space. 2) A set of specific questions -- discussion. 3) Return to top-level questions -- discussion. 4) Plan for action -- meta discussion. Try to separate functional requirements from technical approach. Understand how we are bounded by our problem space and our solution space. Is architecture anything but protocols? _________________________________________________________________ Slide 5 WHAT IS THE PROBLEM SPACE? Routing and addressing: How big, what topology, and what routing model? Getting big: User services, what technology for host and nets? Divestiture of the Internet: Accounting, controlling usage and fixing faults. New services: Video? Transactions? Distributed computing? Security: End node or network? Routers or relays? _________________________________________________________________ Slide 6 BOUNDING THE SOLUTION SPACE How far can we migrate from the current state? * Can we change the IP header (except to OSI)? * Can we change host requirements in mandatory ways? * Can we manage a long-term migration objective? - Consistent direction vs. diverse goals, funding. Can we assume network-level connectivity? * Relays are the wave of the future (?) * Security a key issue; along with conversion. * Do we need a new "relay-based" architecture? How "managed" can/must "The Internet" be? * Can we mandage or constrain connectivity? What protocols are we working with? One or many? _________________________________________________________________ Slide 7 THE MULTI-PROTOCOL INTERNET "Making the problem harder for the good of mankind." Are we migrating, interoperating, or tolerating multiple protocols? * Not all protocol suites will have same range of functionality at the same time. * "The Internet" will require specific functions. Claim: Fundamental conflict (not religion or spite): * Meeting aggressive requirements for the Internet * Dealing with OSI migration. Conclusion: One protocol must "lead", and the others must follow. When do we "switch" to OSI? Consider every following slide in this context _________________________________________________________________ Slide 8 ROUTING and ADDRESSING What is the target size of "The Internet"? * How do addresses and routes relate? * What is the model of topology? * What solutions are possible? What range of policy routing is required? * BGP and IDRP are two answers. What is the question? * Fixed classes, or variable paths? * Source controlled routing is a minimum. How seamless is the needed support for mobile hosts? * New address class, rebind to local address, use DNS? Shall we push for Internet multicast? _________________________________________________________________ Slide 9 GETTING BIG -- AN OLD TITLE (Addressing and routing was on previous slide...) What user services will be needed in the next 10 years? * Can we construct a plan? * Do we need architectural changes? Is there a requirement for dealing better with ranges in speed, packet sizes, etc. * Policy to phase out fragmentation? What range of hosts (things != Unix) will we support? _________________________________________________________________ Slide 10 DEALING WITH DIVERSTITURE The Internet is composed of parts separately managed and controlled. What support is needed for network charging? * No architecture implies bulk charges and re-billing, pay for lost packets. * Do we need controls to supply billing id or routing? Requirement: we must support links with controlled sharing. (Simple form is classes based on link id.) * How general? Is there an increased need for fault isolation? (I vote yes!) * How can we find managerst to talk to? * Do we need services in hosts? _________________________________________________________________ Slide 11 NEW SERVICES Shall we support video and audio? Real time? What %? * Need to plan for input from research. What quality? * Target date for heads-up to vendors. Shall we "better" support transactions? * Will TCP do? VMTP? Presentation? Locking? What application support veneers are coming? * Distributed computing -- will it actuall happen? * Information networking? _________________________________________________________________ Slide 12 SECURITY Can we persist in claiming the end-node is the only line of defense? * What can we do inside the network? * What can ask the host to do? Do we tolerate relays, or architect them? Can find a better way to construct security boundaries? Do we need global authentication? Do we need new host requirements: * Logging. * Authentication. * Management interfaces. + Phone number or point of reference. ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0017.txt Frank and Frank -- 5 August 1991 -- B-I --------------------------------------- Network Working Group F. Solensky INTERNET-DRAFT F. Kastenholz Clearpoint Research Corp. August, 1991 Definition of Class E IP Addresses Status of this Memo This Internet Draft document will be submitted to the RFC editor for a standards document. Comments and suggestions are welcome and may be sent to the authors. Distribution of this memo is unlimited. Abstract This memo presents an extension to the method of classifying and assigning IP network numbers. It is intended to provide an temporary work-around to the imminent exhaustion of Class B network numbers until new architectures are developed [1]. It is a product of a "birds-of-a-feather" discussion held on July 21, 1991 at the twenty- first IETF conference held in Atlanta, GA. It should be noted that this document does NOT address the limitations inherent in the current routing architectures and technology. Specifically, the issue of scaling is not addressed. Background During the latter part of the 1980's, an ever-increasing number of organizations came to realize the advantage and importance of allowing their computer systems to interconnect with other systems and networks around the globe. While this is usually seen as a positive trend, it has not been without its drawbacks. One of the more immediate problems that this sudden growth has presented is a continuing heavy demand for Class B network numbers. While there are still a very large number of Class C addresses available, few organizations expect that their connectivity needs will be satisfied within the limitations of 254 IP addresses. The level of demand for Class B addresses can be illustrated by a short analysis of the data available. In the period between August 1990 and June 1991, the number of assigned Class B network numbers grew from 2533 to 5654 [2,3]. This averages out to an annual growth rate of over 123%. If this trend were to continue, the pool of available Class B network numbers would be depleted by October 1992. Solensky, Kastenholz [Page 1] INTERNET DRAFT AUGUST, 1991 While the authors acknowledge that a logistic or "s-shaped" curve would be a more realistic model, a projection based on this assmption would not be realistic until we have clearly passed the inflection point on the curve - the point at which the curve starts to climb less rapidly towards its upper limit. The data available at this time suggests that this leveling off has not yet occured: the annual growth rate in the allocation of Class B network numbers between 1983 and mid-1990 was only 78% [4], indicating that the growth rate is continuing to increase. Class E Network Numbers The entire Class E address space will be used for the assignment of new IP network numbers. Within the 28 bits available in Class E addresses, the first sixteen will define the network number and the remaining twelve will be the local address, as illustrated below. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class E address This approach has the advantage of allowing a more practical network size than the Class C address space (4094 addresses as compared to 254) while reducing the probability that large amounts of numbers would remain unused within the network. The network number 255.255.240.0 is reserved so that it does not conflict with the address reserved for IP broadcasts (255.255.255.255). Revisions to IP Address Classes A and C. The space for both Class A and C network numbers will be reduced. The low half of these address ranges - network number fields starting with "0" - will continue to be used in their present form, as illustrated. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Revised Class A address Solensky, Kastenholz [Page 2] INTERNET DRAFT AUGUST, 1991 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 0| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Revised Class C address The upper half of these classes will be redesignated as classes F and G. These are illustrated below. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class F address 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class G address This reduces the number of networks in each class to 126 and 1048574 respectively. It should be noted, however, the demand for numbers in these network classes has not been nearly as great as that for Class B. The reason for this is that by reserving the upper half of these address ranges, there will be sufficient numbering space available to develop alternative network number classifications should the need arise in the near future. This may include the restoration of their prior interpretations. For the sake of completeness, Class B and D addresses are also illustrated. The use of Class D or multicast addresses is specified in [5]. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class B address Solensky, Kastenholz [Page 3] INTERNET DRAFT AUGUST, 1991 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 0| multicast address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class D address Conclusions It must be emphasized that this is intended only to be a work-around to the problem. It is by no means a "solution". While it defines a network classification that is four times the size of the original Class B space, this will only survive only two years if current growth rates continue. By that time, it is expected that the increased amount of network connectivity which has been exhibiting similar growth rates [4,6] will cause the computational intensity of keeping track of these routes to require an entirely different routing and addressing architecture for the Internet such as the one described in [5]. References: [1] "A New IP Routing and Addressing Architecture", J. Noel Chiappa. [2] "Internet Numbers", S. Kirkpatrick, M. Stahl, M. Recker, RFC 1166, SRI International, July 1990. [3] Internet Monthly Report, A. Westine [ed], June, 1991. [4] "Continued Internet Growth", Frank Solensky, Proceedings of the Eighteenth Internet Engineering Task Force, July 30-August 3, 1990. pages 59-61. [5] "Host Extentions for IP Multicasting", S. Deering, RFC 1112, SRI International, August 1989. [6] "Growth of the Internet", Mike St. Johns, Proceedings of the Thirteenth Internet Engineering Task Force, April 11-14, 1989, pages 244-248. Solensky, Kastenholz [Page 4] INTERNET DRAFT AUGUST, 1991 Authors' Address: Frank Solensky Frank Kastenholz Clearpoint Research Corp. 35 Parkwood Drive Hopkinton, MA 01748 Phone: (508) 435-2000 Email: solensky@clearpoint.com, kasten@clearpoint.com Solensky, Kastenholz [Page 5] ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0133.txt IAB Minutes -- http://info.internet.isi.edu:80/IAB/IABmins.911010 ----------------------------------------------------------------- Internet Activities Board Meeting Minutes -- October 10, 1991 FOREWORD This document contains minutes of the meeting of the Internet Activities Board (IAB) held on October 10, 1991 at the Fairmont Hotel (during the Interop '91 conference) in San Jose, CA. The meeting agenda will be found in Appendix A. The attendees were: IAB Members: Bob Braden, ISI Hans-Werner Braun, SDSC Vint Cerf, CNRI Lyman Chapin, BBN David Clark, MIT Phill Gross, ANS Steve Kent, BBN Tony Lauck, DEC Barry Leiner, ADS Dan Lynch, Interop Jon Postel, ISI IESG Members: Robert Hinden, BBN D. Crocker, DEC Russ Hobby, UC, Davis Phil Almquist, Barrnet Guests: Bob Aiken, NSF Paul Mockapetris, DARPA Steve Hardcastle-Kille, UCL Yakov Rekhter, IBM Scribe: Kim Claffy, SDSC/UCSD [...] 2. ARCHITECTURAL RETREAT -- RESULTS AND PLANS 2.1 Routing and Addressing Cerf: There is a critical need to put together a small task group to generate at least one feasible proposal for large-scale Routing and Addressing in the Internet. Its output will be a contribution to an anticipated IETF WG, which will review the issues and converge on a plan for updating Internet routing and addressing. The group specified that minutes from this task group's meetings must be freely available, and its work results would be available as an Internet Draft. The target of this group would be to define a feasible solution by March 1992, in time for the San Diego IETF. After some discussion on the structure and makeup of the task group and the division of the leadership responsibilities, the consensus was that there should be three specific separate leadership roles: meeting chairperson, document editor, and "floor manager" to coordinate the activities. NEW ACTION: Cerf: Talk to principals and convene first meeting of Routing & Addressing task group. [...] ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0018.txt Frank and Frank -- 15 March 1992 -- B-I ---------------------------------------- Network Working Group F. Solensky INTERNET-DRAFT F. Kastenholz Updates: 791, 904, 1122 Clearpoint Research Corp. March 1992 A Revision to IP Address Classifications Status of this Memo This Internet Draft document will be submitted to the RFC editor as a standards document. Comments and suggestions are welcome and may be sent to the Big-Internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. Abstract This memo presents an extension to the method of classifying and assigning IP network numbers. It is intended to provide a work- around to the imminent exhaustion of assignable Class B network numbers by defining the format of Class C-sharp (C#) IP addresses, consuming the upper half of the existing Class C numbering space. The manner in which these changes impact existing systems is also discussed. It is a product of a "birds-of-a-feather" (BoF) discussion held on July 31, 1991 at the twenty-first IETF conference in Atlanta, GA and subsequent discussions on the mailing list. It should be noted that this document does NOT address the limitations inherent in the current routing architectures and technology that are discussed in [1] and [2]. These must wait until new architectures are developed. Specifically, the issue of scaling is not addressed. Background During the latter part of the 1980's, an ever-increasing number of organizations came to realize the advantage and importance of allowing their computer systems to interconnect with other systems and networks around the globe. This has both caused and reinforced the tremendous growth in the size of the Internet during this period. While this is usually seen as a positive trend, it has not been without its drawbacks. One of the more immediate problems that this sudden growth has presented is a continuing heavy demand for Class B network numbers. Of the three classes of IP network numbers, Class A (which can support up to 16,777,214 unique host identifier addresses within the Solensky, Kastenholz [Page 1] INTERNET DRAFT March, 1992 same network number), B (up to 65,532), and C (up to 254), the Class B network numbers are being assigned at the highest rate. While there are still a very large number of Class C network numbers available, few moderate-sized organizations expect that their connectivity needs will be satisfied within the limitations of 254 IP addresses, particularly if subnetting is being used. The level of demand for Class B address assignments can be illustrated by a short analysis of the data available. In the period between July 1990 and January 1992, the number of assigned Class B network numbers grew from 2533 to 6883 [4,9]; the latter figure representing just over 42% of the total available Class B network numbers. This increase averages out to an annual growth rate of over 73.7%. If this exponential trend were to continue, the pool of available Class B network numbers would be depleted by March 1993. While the authors acknowledge that a logistic or "s-shaped" curve would be a more realistic model, a projection based on this assumption would not be realistic until we have clearly passed the inflection point on the curve - the point at which the curve starts to climb less rapidly towards its upper limit. The data available at this time suggests that this leveling off has not yet occured to any significant degree: the annual growth rate in the allocation of Class B network numbers between 1983 and mid-1990 was a nearly identical 78% [8]. Whatever the exact shape of the curve, the conclusion that severe problems will erupt as a result of the exhaustion of the Class B network numbers is inescapable. The obvious corollary is that a short-term fix is necessary until the more fundamental problems referred to above can be solved. This document contains that fix. Class C-sharp Network Numbers The upper half of the Class C address space -- addresses with a prefix of '1101' -- will be used for the assignment of new Class C- sharp (C#) IP network numbers*. Within the 28 bits available in Class C# addresses, the first sixteen will define the network number and the remaining twelve will be the local address, as illustrated below. This would correspond to the IP address that fall into the range 208.0.0.0 through 223.255.255.255. * The musically inclined may appreciate the mnemonic device: the two address classes that are least likely to be further subdivided correspond to the white keys on a piano that do not have black keys a half-step above them: B and E. However, one needs to be careful not to read too much into these names since, as stated earlier, this methodology does not address the issue of scaling. Solensky, Kastenholz [Page 2] INTERNET DRAFT March, 1992 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class C-sharp address The Class C# network with an all-zero network field (IP addresses 208.0.0.0 through 208.0.15.255) will be reserved to indicate host addresses within the local network. It was felt that splitting the network and local address fields into these particular sizes met some of the more important design objectives: * The number of networks created by this division - over 65,000 - should be sufficient to meet the needs of the immediate future while other long-term solutions are being developed. The alternative of using fewer bits in the network portion of the address (including 4096 additional Class B-sized networks) had been considered but generally dismissed since the smaller count of new network numbers would allow proportionally less time to develop and deploy a replacement Internet architecture. * Many sites that are currently requesting Class B numbers do not come close to fully utilizing the address space and could easily use something a little smaller. The size of a local network in this address class - 4094 hosts in an unsubnetted environment - is large enough to be useful to many organizations without being so large that it becomes sparsely populated. It also provides a local field large enough to be separated into useful subnet and host numbers fields: the "regular" Class C addresses lack this feature. This is particularly important now that the use of variable-sized subnet masks within a given network is practical. * The creation of this new address class should sufficiently reduce the demand for the remaining Class B network numbers so that their assignment can be limited to larger sites. Another benefit of this division, while not of great import but nevertheless noteworthy, is that it keeps the division of the network and local addresses fields on nybble boundaries and thereby easier to pick out the individual fields when displayed in hexadecimal notation. The dotted-decimal notation used to express addresses does not need to be changed: one can simply refer to a block of addresses. The proposal to continue the current practice of allocating a space whose prefix started with all 1's and ended with a 0 (i.e. allocate Solensky, Kastenholz [Page 3] INTERNET DRAFT March, 1992 the prefix '11110' for Class E addresses and defining addresses with a prefix of '11111' as a reserved "Class F" space) had been considered. The problem with doing so, however, is that this practice demonstrates the law of diminishing returns: the processing overhead of separating any IP address into its network and local address fields gets increasingly complex while shrinking the reserved address space into a less useful portion - just over 3% - of the total. Another alternative that was discussed was to use the entire Class E address space in this manner and assign the upper halves of both Class A and C address spaces as new reserved address spaces. There are a number of compelling arguments against this approach: * Routers that do not explicitly recognize Class C# addresses would still be able to forward packets, since the destination address would be interpreted as belonging to a Class C network. Class E destination addresses would have to be ignored by these same routers, causing these new networks to be able to communicate with only those parts of the Internet that recognized the new address. * It had been argued that announcing the presence of a class C# address to an older router by announcing 16 consecutively-numbered Class C addresses will exacerbate the routing overhead problem in the backbone nets. However, the backbone routers can just as easily be modified to recognize the aggregatability of '1101' addresses as they can be to recognize '1111' addresses. by a trivial modification: they simply have to use a mask of FFFFF000 for the C# addresses. Routers that are not on the backbone and are not suffering from excessive numbers of routes need not be changed at all. * It has been argued that using the Class E space would be preferable to the C# space because it would be a greater incentive for vendors/authors to update their IP software to support classless routing. However, there are many boxes out there whose IP software is no longer supported, or whose owners will never get around to updating their software even if it is available. Using the Class C# address space is far more consistent with the dictum to "be conservative in what you send and liberal in what you accept from others" [6]. Exterior Gateway Protocol (EGP) The changes to the address formats described in this memo suggest some modifications to the Exterior Gateway Protocol [5]. We describe how the Class C# addresses are to be represented within the EGP messages and a methodology by which neighboring systems can reduce Solensky, Kastenholz [Page 4] INTERNET DRAFT March, 1992 the length of the routing table update messages. In order to keep the length of protocol messages down to a minimum, EGP generally represents the IP network and host numbers as variable length fields using the fewest number of bytes necessary. A Class A network number, for example, is stored in a one-byte field. The recipient of the message examines the first couple of bits of the field to determine the field's length. When a host address is specified in the message instead, the recipient will have already determined the network number; the length of this field is simply set to the number of bytes needed to complete the address. Within the EGP 'NR Poll' message, the IP Source Network number is always stored in a three-byte field. The original specification describes this field as a single byte network number followed by two bytes of zero when the network falls within the Class A address space and two bytes of network number followed by one byte of zero for Class B network numbers. This recommendation would simply rephrase the definition so that this field contains the network number, left justified and zero filled. The 'Network Reachability' (NR) message of EGP also needs to be modified when forwarding information about Class C# networks in a more substantial manner. The Gateway IP address field is long enough to hold the local portion of the address for the corresponding address class (three bytes for Class A addresses, two bytes within a Class B network, one byte for Class C). Similarly, the Network address field is of sufficient length to contain the network number that can be reached by the router whose indicated by the Gateway IP address. While keeping the message length down is desirable, it becomes far more difficult to parse the message if these fields were to become non-byte aligned. For this reason, the Gateway IP address field will, for Class C# addresses, be two full bytes in length, zero-filled on the right to maintain byte alignment. The Network address field for Class C# addresses will be three bytes long, zero filled on the left. This will remove the need for additional shift operations when reassembling a Class C# address from the message: the third byte of an address is restored through a logical OR operation between the final byte of the Gateway IP address field and the first byte of the Network address field Using these modifications, EGP neighbors that both recognize Class C# addresses will not have much trouble interoperating. However, it is desirable for the neighbor systems to be able to know beforehand if the other will be able to recognize the aggregation of the C# network numbers or if the destination network needs to be described to a less up-to-date router as sixteen separate Class C networks that happen to be consecutively numbered. Solensky, Kastenholz [Page 5] INTERNET DRAFT March, 1992 A reasonably straightforward means to determine this is to use a new code value in the Neighbor Acquisition message. A code value of 5 would indicate to the recipient that the sender recognizes this new address class. If the neighbor is cognizant of Class C# addresses, it responds with a Confirm response (type 3, code 1) and moves into "Down" state; otherwise, it is expected to send a Refuse response due to what it believes to be an invalid command (type 3, code 2, status 7) or an Error response on a bad EGP header (type 8, reason 1) and returns to the "Idle" state. Upon receiving this rejection, the originating system becomes aware that the receipent does not recognize the aggregation of Class C# addresses and can fall back on sending the traditional Request command (type 3, code 0). If this second attempt is successful, the Class C# networks that are to be announced into the neighboring autonomous system will have to be described as sixteen different Class C networks. This process of receiving an error indication and forming a new request has the effect of creating an additional state. It is labeled as "Aqsn-2" in the state-machine diagram that follows. +-------+ | |<--------------------------------+-------------+ +----->| Idle |-----------------------------+ A A | | |<---------------+ Request| | | | +-------+ A | | | | | A |Cease | |Cease |Cease | Start| |Cease |Refuse | | | | V | | V | | | +-------+ Refuse +-------+ +-------+ Up +-------+ | | |----------->| | | |------>| | | | Aqsn | |Aqsn-2 | | Down | Down | Up | | | |--------+ | | | |<------| | | +-------+ Confirm| +-------+ +-------+ +-------+ | | | | |Confirm A | | |Stop |Stop V | V | | | |Cease-ack V +-----(---+----------+ |Stop |Stop | +-------+ Stop| | | | | | V V V +------| Cease |<-------------+------------------+-------------+ | | +-------+ Domain Name Servers Another consideration that needs to be addressed is the impact this change will have on various Domain Name Servers. Current implementations make the assumption that the While it would take relatively little time to add sixteen individual NS records, this Solensky, Kastenholz [Page 6] INTERNET DRAFT March, 1992 could easily cause the files to become extraordinarily large shortly after this address class becomes official. This is not considered to be the optimal solution: more specific ones are beyond the scope of this document. Conclusions It must be emphasized that the use of Class C# network addresses is intended only to be a work-around to the immediate problem. It is by no means a solution. While it defines a new class of address numbers that allows four times the number of networks of the original Class B space, this scheme will survive less than three years if current growth rates continue. By that time, it is expected that the increased amount of network connectivity which has been exhibiting similar growth rates [7,8] will cause the computational intensity of keeping track of these routes to require an entirely different routing and addressing architecture for the Internet such as one of the solutions outlined in [1]. This change also points out the necessity of having hosts not pry into address formats. It is plausible to deploy a new network number format if only the routers have to be changed; doing so in a world where most types of host software have to be changed as well is clearly problematic. References: [1] "The IP Addressing Issue", J. Noel Chiappa, Internet Draft, October, 1990. [2] "Towards the Future Architecture", D. Clark, L. Chapin, V. Cerf, R. Braden, RFC 1287, SRI International, December 1991. [3] "Host Extentions for IP Multicasting", S. Deering, RFC 1112, SRI International, August 1989. [4] "Internet Numbers", S. Kirkpatrick, M. Stahl, M. Recker, RFC 1166, SRI International, July 1990. [5] "Exterior Gateway Protocol Formal Specification", D.L. Mills, RFC 904, SRI International, April 1984. [6] "Transmission Control Protocol", J. Postel, RFC 793, SRI International, August 1980. [6] "Growth of the Internet", Mike St. Johns, Proceedings of the Thirteenth Internet Engineering Task Force, April 11-14, 1989, pages 244-248. Solensky, Kastenholz [Page 7] INTERNET DRAFT March, 1992 [7] "Continued Internet Growth", Frank Solensky, Proceedings of the Eighteenth Internet Engineering Task Force, July 30-August 3, 1990. pages 59-61. [8] Internet Monthly Report, A. Westine [ed], September, 1991. Authors' Address: Frank Solensky Frank Kastenholz Clearpoint Research Corp. 35 Parkwood Drive Hopkinton, MA 01748 Phone: (508) 435-2000 Email: solensky@clearpoint.com, kasten@clearpoint.com Solensky, Kastenholz [Page 8] ========= ========= ========= ========= ========= ========= ========= http://www.rfc-editor.org/rfc/rfc1335.txt Network Working Group Z. Wang Request for Comments: 1335 J. Crowcroft University College London May 1992 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion 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 RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for the Internet. This is an "idea" paper and discussion is strongly encouraged. Introduction Address space exhaustion is one of the most serious and immediate problems that the Internet faces today [1,2]. The current Internet address space is 32-bit. Each Internet address is divided into two parts: a network portion and a host portion. This division corresponds the three primary Internet address classes: Class A, Class B and Class C. Table 1 lists the network number statistics as of April 1992. Total Allocated Allocated (%) Class A 126 48 54% Class B 16383 7006 43% Class C 2097151 40724 2% Table 1: Network Number Statistics (April 1992) If recent trends of exponential growth continue, the network numbers in Class B will soon run out [1,2]. There are over 2 million Class C network numbers and only 2% have been allocated. However, a Class C network number can only accommodate 254 host numbers which is too small for most networks. With the rapid expansion of the Internet and drastic increase in personal computers, the time when the 32-bit address space is exhausted altogether is also not too distant [1-3]. Recently several proposals have been put forward to deal with the Wang & Crowcroft [Page 1] RFC 1335 Two-Tier Address Structure for the Internet May 1992 immediate problem [1-4]. The Supernetting and C-sharp schemes attempt to make the Class C numbers more usable by re-defining the way in which Class C network numbers are classified and assigned [3,4]. Both schemes require modifications to the exterior routing algorithms and global coordination across the Internet may be required for the deployment. The two schemes do not expand the total number of addresses available to the Internet and therefore can only be used as a short-term fix for next two or three years. Schemes have also been put forwarded in which the 32-bit address field is replaced with a field of the same size but with different meaning and the gateways on the boundary re-write the address when the packet crossed the boundary [1,2,5]. Such schemes, however, requires substantial changes to the gateways and the exterior routing algorithm. In this paper, we present an alternative solution to the problem of address space exhaustion. The "Dual Network Addressing (DNA)" scheme proposed here is based on a two-tier address structure and sharing of addresses. It requires no modifications to the exterior routing algorithms and any networks can adopt the scheme individually at any time without affecting other networks. The Scheme The DNA scheme attempts to reduce the waste in using the Internet addresses. A useful analogy to our scheme is the extension system used in the telephone system. Many large organizations usually have extensive private telephone networks for internal use and at the mean time hire a limited number of external lines for communications with the outside world. In such a telephone system, important offices may have direct external lines and telephones in the public areas may be restricted to internal calls only. The majority of the telephones can usually make both internal calls and external calls. But they must share a limited number of external lines. When an external call is being made, a pre-defined digit has to be pressed so that an external line can be allocated from the poll of external lines. In the DNA scheme, there are two types of Internet addresses: Internal addresses and External addresses. An internal address is an Internet address only used within one network and is unique only within that network. An interface with an internal address can only communicate with another interface with an internal address in the same network. An external address is unique in the entire Internet and an interface with an external address can communicate directly to another interface with an external address over the Internet. All current Internet addresses are external addresses. In effect, the external addresses form one global Internet and the Wang & Crowcroft [Page 2] RFC 1335 Two-Tier Address Structure for the Internet May 1992 internal addresses form many private Internets. Within one network, the external addresses are only used for inter-network communications and internal addresses for intra-network communications. An External Address Sharing Service (EASS) is needed to manage the sharing of external addresses. An EASS server reserves a number of external addresses. When a machine that only has an internal address wants to communicate a machine with an external address in other networks, it can send a request to an EASS server to obtain a temporary external address. After the use, the machine can return the external address to the EASS server. We believe that, with the DNA scheme, a network can operate with a limited number of external addresses. The reasons are as follows: * In most networks, the majority of the traffic is confined to its local area networks. This is due the nature of networking applications and the bandwidth constraints on inter-network links. * The number of machines which act as Internet servers, i.e., running programs waiting to be called by machines in other networks, is often limited and certainly much smaller than the total number of machines. These machines include mail servers, domain name servers, ftp archive servers, directory servers, etc. * There are an increasingly large number of personal machines entering the Internet. The use of these machines is primarily limited to their local environment. They may also be used as "clients" such as ftp and telnet to access other machines. * For security reasons, many large organizations, such as banks, government departments, military institution and some companies, may only allow a very limited number of their machines to have access to the global Internet. The majority of their machines are purely for internal use. In the DNA scheme, all machines in a network are assigned a permanent internal address and can communicate with any machines within the same network. The allocation of external addresses depends on the functions of the machines and as a result it creates three-level privileges: * machines which act as servers or used as central computing infrastructure are likely to have frequent communications with other networks therefore they may require external addresses all the time. These machines are allocated Wang & Crowcroft [Page 3] RFC 1335 Two-Tier Address Structure for the Internet May 1992 permanent external addresses. * machines which are not allowed to communicate with other networks have no external addresses and can only communicate with machines within their own network. * the rest of the machines share a number of external addresses. The external addresses are allocated by the EASS server on request. These machines can only used as clients to call machines in other networks, i.e., they can not be called by machines in other networks. A network can choose any network number other than its external network number as its internal network number. Different networks can use the same network number as their internal number. We propose to reserve one Class A network number as the well-known network number for internal use. The Advantages The DNA scheme attempts to tackle the problem from the bottom of the Internet, i.e., each individual network, while other schemes described in the first section deal with the problem from the top of the Internet, i.e., gateways and exterior routing algorithms. These schemes, however, do not need to be consider as mutually exclusive. The DNA scheme has several advantages: * The DNA scheme takes an evolutionary approach towards the changes. Different networks can individually choose to adopt the scheme at any time only when necessary. There is no need for global coordination between different networks for their deployment. The effects of the deployment are confined to the network in which the scheme is being implemented, and are invisible to exterior routing algorithms and external networks. * With the DNA scheme, it is possible for a medium size organization to use a Class C network number with 254 external addresses. The scheme allows the current Internet to expand to over 2 million networks and each network to have more than 16 million hosts. This will allow considerable time for a long-term solution to be developed and fully tested. * The DNA scheme requires modifications to the host software. However, the modifications are needed only in those networks which adopt the DNA scheme. Since all existing Class A and B networks usually have sufficient external addresses for all their machines, they do not need to adopt the DNA scheme, and therefore Wang & Crowcroft [Page 4] RFC 1335 Two-Tier Address Structure for the Internet May 1992 need no modifications at all to their software. The networks which need to use the DNA scheme are those new networks which are set up after the Class A and B numbers run out and have to use a Class C number. * The DNA scheme makes it possible to develop to a new addressing scheme without expanding the 32-bit address length to 64-bit. With the two-tier address structure, the current 32-bit space can accommodate over 4 billion hosts in the global Internet and 100 million hosts in each individual network. When we move to a classless multi-hierarchic addressing scheme, the use of external addresses can be more efficient and less wasteful and the 32-bit space can be adequate for the external addresses. * When a new addressing scheme has been developed, all current Internet addresses have to be changed. The DNA scheme will make such a undertaking much easier and smoother, since only the EASS servers and those have permanent external addresses will be affected, and communications within the network will not be interrupted. The Modifications The major modifications to the host software is in the network interface code. The DNA scheme requires each machine to have at least two addresses. But most of the host software currently does not allow us to bind two addresses to one physical interface. This problem can be solved by using two network interfaces on each machine. But this option is too expensive. Note the two interfaces are actually connected to the same physical network. Therefore, if we modify the interface code to allow two logical interfaces to be mapped onto one single physical interface, the machine can then use both the external address and the internal address with one physical interface as if it has two physical interfaces. In effect, two logical IP networks operate over the same physical network. The DNA scheme also has implications to the DNS service. Many machines will have two entries in the local name server. The DNS server must examine the source address of the request and decide which entry to use. If the source address matches the well-known internal network number, it passes the internal address of the domain name. Otherwise, the name server passes the external address. An EASS server is required to manage the sharing of the external addresses, i.e., to allocate and de-allocate external addresses to the machines which do not have permanent external addresses. This service can be provided by using the "Dynamic Host Configuration Protocol (DHCP)" [6]. Wang & Crowcroft [Page 5] RFC 1335 Two-Tier Address Structure for the Internet May 1992 Many hosts do an inverse lookup of incoming connections. Therefore, it is desirable the entry in the DNS server be updated whenever a new external address is allocated. This will also allow an machine which currently has a temporary external address to be called by other machines. The updating of the entry in the DNS server can be done more easily if the EASS server and DNS server are co-located. Acknowledgements We would like to thank J. K. Reynolds for the network statistics, and V. Cerf, C. Topolcic, K. McCloghrie, R. Ullmann and K. Carlberg for their useful comments and discussion. References [1] Chiappa, N., "The IP Addressing Issue", work in progress, October 1990. [2] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UC Davis, December 1991. [3] Solensky, F., and F. Kastenholz, "A Revision to IP Address Classifications", work in progress, March 1992. [4] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", work in progress, March 1992. [5] Tsuchiya, P., "The IP Network Address Translator", work in progress, March 1991. [6] Droms, R., "Dynamic Host Configuration Protocol", work in progress, March 1992. Wang & Crowcroft [Page 6] RFC 1335 Two-Tier Address Structure for the Internet May 1992 Security Considerations Security issues are not discussed in this memo. Authors' Addresses Zheng Wang Dept. of Computer Science University College London London WC1E 6BT, UK EMail: z.wang@cs.ucl.ac.uk Jon Crowcroft Dept. of Computer Science University College London London WC1E 6BT, UK EMail: j.crowcroft@cs.ucl.ac.uk Wang & Crowcroft [Page 7] ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0019.txt Paul Francis (Tsuchiya) -- 19 May 1992 -------------------------------------- Pip: The `P' Internet Protocol Paul F. Tsuchiya Bellcore tsuchiya@thumper.bellcore.com May 19, 1992 1.0 Purpose of this draft Pip is an IP protocol that scales, encodes policy, and is high speed. The purpose of this draft is to explain the basic concepts behind Pip so that people can start thinking about potential pitfalls. I am proposing Pip as an alternative to the two "medium term" proposals that emerged from the Road (Routing and Addressing) group to deal with the dual IP problems of scaling and address depletion. Because this proposal, which represents new ideas, is competing with old (and therefore well thought-out) ideas, I wish to circulate it (and get the process started) as quickly as possible, albeit in not as complete a form as I would like. I expect to have a complete proposal by the beginning of September. There will be a plenary presentation and a BOF covering this material at the Boston meeting of IETF. 2.0 Pip General Pip has the following features: 1. Pip carries multiple address types in a common format. As such, it is beneficial for transition from one address to another, and for future evolution (of routing techniques as well as of addressing schemes). 2. The Pip address is completely general (multiple levels of hierarchy, expands to any number of systems). 3. The Pip address is compact-it grows with the number of systems. 4. The Pip address efficiently encodes policy (source-based) routes, both in "long form" (explicit path) and "short form" (path identifier). 5. Because the Pip address can be a path identifier (multi-layer if de- sired, like the ATM VCI/VPI), Pip can be used in a connection-orient- ed fashion (this paper only briefly touches on mechanisms for controlling connections). 6. The Pip address includes multicasting (potentially substantially more sophisticated than what is for IP multicast numbers, for instance, hier- archical multicast). 7. Pip efficiently encodes QOS (Quality-of-Service) information. 8. The routing table lookup with Pip is well-bounded (by the depth of the address hierarchy). 9. Pip accommodates "multiple defaults" routing from (multi-homed) stub domains. 10. Pip allows intra-domain routing and hosts to operate with no notion of the "inter-domain" parts of their address, if desired. This is equiva- lent to current IP hosts and intra-domain routers not needing to know their own network number. 11. Pip accommodates tunneling across transit domains. 12. By virtue of 8 and 9, Pip accommodates separation of interior and ex- terior routing. 13. Pip simplifies handling mobile systems (by having flat network layer identifiers). In short, Pip is a "next generation" protocol, intended to allow the internet to evolve over the foreseeable future. One of the design philosophies behind Pip is that it encodes all "routing" information (what is traditionally spread over the address and QOS fields) in a single structure (the Routing Directive). The rules for parsing the structure are simple on one hand, but provide a rich set of routing functions. Therefore, it is possible to build a single forwarding engine that will accommodate many different types of routing styles, including traditional hierarchical addresses, policy, source route, and virtual circuit. This way, the forwarding engine can be built in hardware and can remain constant even while internet routing evolves. Another design philosophy behind Pip is that it delays the definition of how internet packet should be composed and interpreted. The meaning of addresses and QOS information are dynamically determined by information in Directory Services, distributed protocols such as routing protocols, and MIBs, rather than in a protocol specification. Current internet protocols have continuously been moving towards this philosophy, but with header formats that are not conducive to late semantic definition. Pip facilitates late semantic definition of the internet protocol header. This on one hand makes it easier to evolve the internet incrementally, but requires that all systems (hosts, routers, and directory servers) be a little smarter, and that algorithms be a little more complex. This, in a nutshell, is the trade-off being made by Pip. ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0066.txt MEMO: see the reverse UK domain style; "UK.AC.RUTHERFORD.IBM-B" --------------------------------------------------------------- From: Paul Bryant Subject: So you like NSAPS? To: iptag@UK.AC.JNT PB660 IPTAG/92/23 SCIENCE AND ENGINEERING RESEARCH COUNCIL RUTHERFORD APPLETON LABORATORY CENTRAL COMPUTING DEPARTMENT NSAPs P Bryant May 19, 1992 -------------------------------------------------------------- 1 NSAPS This paper surveys how NSAPS are being/will be/may be used with a view to deciding on the use of NSAPS within the CLNS project. The survey is not exhaustive and in some cases the documents may be out of date. Comments are invited and a definitive scheme will follow. 2 Notes on the tables Field lengths suffixed by "x" are in octets otherwise they are decimal digits. Values are enclosed in "(" ")" and are in hexadecimal or decimal depending on the field length suffix. 3 Notes on the use of NSAPs in CLNS NSAPs are used for routing (ISO DP 10589). For this purpose the ID or identifier field is used for ES-IS (end system to router) routing and the preceding 2 octets (area field) is recommended to be left unallocat- ed and eventually used for optimising routing within a routing domain. The NSAP up to the area field is used for IS-IS routing. ISO DP 10589 requires binary encoding. The above two requirements mean that the UK JNT scheme for CONS cannot be used. First, it uses decimal encoding and secondly it does not re- quire the structure demanded by ISO DP 10589. In the case of Rutherford, where the NSAP address for CONS is highly structured and spread over the available NSAP space, there is no hope of utilising it for CNLS. ISO TR 9575 defines 3 levels of routing: * Area - a set of ESs and ISs - this is routed using the ID octets which may well be a MAC address. * Routing Domain - a set of areas connected with IS-IS connections but sharing the same intra-domain routing protocol. This could be a site or a country depending on organisational considerations. * Administrative domain - a set of Routing Domains under single manage- ment. This could be a set of sites or a set of countries. 4 US Gosip US Gosip defines the format below. +-----------+--------------------------------------+ |IDP | DSP | +----+------+----------------------------+----+----+ |AFI | IDI | HO-DSP | ID | SEL| +----+------+----+----+------+----+------+ | | | | |DFI | AA | Rsvd | RD | Area | | | +----+------+----+----+------+----+------+----+----+ | 1x | 2x | 1x | 3x| 2x | 2x| 2x | 6x| 1x| |(47)|(0005)|government wide us | |(47)|(0006)|delegated for DOD use only | +-----+-----+----+----+------+----+------+----+----+ IDP - Initial Domain Part DSP - Domain specific Part AFI - Authority and Format Identifier - defined by OSI IDI - Initial Domain Identifier - allocated by BSI HO - High Order DFI - DSP Format identifier - defined by GOSSIP AA - Administrative Authority - allocated by owner of the IDI Rsvd- Always useful in time of trouble RD - Routing Domain Identifier - allocated by owner of the AA Area- Area identifier - used to help routing ID - System Identifier - follows ISO DP 10589 SEL - NSAP Selector - follows ISO DP 10598 5 ISO 3848/Addendum 2 ISO 3848 defines the format below which is the basis for most schemes of interest. +--------------------------------------------+ |IDP | DSP | +-----------+-------------------+------+-----+ |AFI | IDI | HO-DSP | ID | SEL | +----+------+-------------------+------+-----+ |1x |2x | ? |1-8x | 1x | +----+------+-------------------+------+-----+ All elements in a Routing Domain have the same length ID. All elements in an area usually have the same area address (IDP+HO-DSP) and thus IS systems can easily identify destinations within the area which are routed on ID. If not in the area then the maximum number of digits from the IDP+HO-DSP are matched to route to another IS. (There is some doubt as to whether this statement is true and that a complete match is required). IDP+HO-DSP must be globally unique. 6 OSI NSAP Allocation in the Internet (RFC 1237) The Internet proposal follows US Gosip. +-----------+--------------------------------------+ |IDP | DSP | +----+------+----------------------------+----+----+ |AFI | IDI | HO-DSP | ID | SEL| +----+------+----+----+------+----+------+ | | | | |DFI | AA | Rsvd | RD | Area | | | +----+------+----+----+------+----+------+----+----+ | 1x | 2x | 1x | 3x| 2x | 2x| 2x | 6x| 1x| |(47)|(0005)|(80)| | | | | | | +-----+-----+----+----+------+----+------+----+----+ I have not found out the use of the Domain Format Identifier but suspect that it allows alternative encodings. 7 ANSI X3S3.3 The ANSI formal follows US Gosip apart from the IDP and IDI. +----+------+----------------------------------------+ |IDP | IDI | DSP | +----+------+-----+-----+------+----+------+----+----+ | | | DFI | ORG | Rsvd | RD | Area | ID | Sel| +----+------+-----+-----+------+----+------+----+----+ | 1x | 2x | 1x | 3x | 2x | 2x| 2x | 6x| 1x| |(39)|(840F)| | | | | | | | +----+------+-----+-----+------+----+------+----+----+ This is identical to US GOSSIP apart from IDP/IDI and the renaming of AA as ORG. I do not know what the significance of renaming AA (administra- tive Authority) as ORG (organisation) is. 8 ECMA TR/44, RFC 1195 These documents define the 9 low order octets of the DSP +--------+-----------+--------+ | SNID | SNADD | NSEL | +--------+-----------+--------+ | 2x | 6x | 1x | +--------+-----------+--------+ NSEL=Network Selector - indicates transport layer to select for a given TPDU and is used in OSI IS-IS routing protocol. Why "area" is renamed as SNID, ID as SNADD and SEL as NSEL is not known but NSAPS seem to be a topic where renaming of fields is a popular activity. 9 RARE WG4 recommendations RARE WG4 have defined the formal below. +---------+----------------------------+ |IDP | DSP | +----+----+--------------+-------------+ |AFI | IDI| CDP | CDSP| +----+----+------+-------+-------------+ | | | CFI | CDI | | +----+----+------+-------+-------------+ |1x | 3 |1 (1) | 3 | <=31| |(38)| | (2) | 5 | <=29| | | | (3) | 9 | <=25| | | | | | | |1x | 2x |1 (1) | 3 | <=12x| |(39)| | (2) | 5 | <=11x| | | | (3) | 7 | <=10x| +----+----+------+-------+-------------+ CDP - Country Domain Part CDSP- Country Domain Specific Part CFI - Country Format Identifier CDI - Country Domain identifier Note: it is unclear why the (39) DSP is limited to 14 rather than 17 octets. A second WG4 paper defines the DSP as being a pure addressing hierarchy and omits mention of the CI and CDI. Both papers were written in late 1990 before CLNS became a cult and may be out of date. This paper also mentions the use of ISO DP 10589 as being under develop- ment. 10 Norway CLNS project +-----------+---------------------------------------+ |IDP | DSP | +----+------+--------------+------------------------+ |AFI | IDI | CDP | CDSD | +----+------+------+-------+-------------+-----+----+ | | | CFI | CDI | |ID |NSEL| +----+------+------+-------+-------------+-----+----+ |1x | 2x |1 (1) | 3 | rest |6x |1x | |(39)|(578F)| (2) | 5 | | | | | | | (3) | 7 | | | | | | | (4) | 1 | | | | +----+------+------+-------+-------------+-----+----+ Norway follows WG4 with the addition of a CFI of 4 with CDI of 1. AFI is 39. The terminal 7 octets are 6 for a LAN address and 1 for a network selector NSEL which follows US GOSSIP. 11 Holland CLNS project +-----------+--------------------------------------+ |IDP | DSP | +----+------+-------------+------------------------+ |AFI | IDI | CDP | CDSD | +----+------+------+------+----+----+------+-------+ | | | CFI +CDI | SFI| SDI| ASDI| | +----+------+------+------+----+----+------+-------+ |1x | 3 | 4 | 1 | 4 | 1 | rest | |(38)|(528) | (1 100) | | | (0) | | |1x | 2x | | | | | | |(39)|(528F)| (1 100) | | | (0) | | +----+------+-------------+----+----+------+-------+ SFI -SURFnet format identifier allocated by SURFnet. SDI -SURFnet domain identifier (site) allocated by SURFnet. ASDI - Additional SURFnet domain identifier allocated by SURnet - re- served. If SFI=0 SDI maps an organisation to a number. If SFI=1 SDI is a number that maps onto a network (?). The "rest" is allocated locally. 12 UK CONS +----------+--------------------------------------------+ |IDP | DSP | +----+-----+--------------+----+---------+--------------+ |AFI | IDI | CFI | CDI | ID | SiteCode|SiteAllocation| +----+-----+------+-------+----+---------+--------------+ |1x | 3 |1 | 3 | 2 | 3-6 | rest | |(38)|(826)|(1) | (100) |(00)| | | +----+-----+------+-------+----+---------+--------------+ UK follows roughly WG4 with AFI of 38, CFI of 1 digit containing 1 and CDI of 3 digits containing 100. The CDSD contains 3 fields. First a 2 digit reserved for future use. Second is a variable length site code of between 3 and 6 digits. Third a variable length field allocated by the site. 13 Germany CLNS project +----+------+----------------------------------------------+ |IDP | IDI | DSP | +----+------+------+-----+-----+-----+----+------+----+----+ | | |DE-BT | FI1 | RI |Rsvd | RD | Area | ID | Sel| +----+------+------+-----+-----+-----+----+------+----+----+ | 1x | 2x | 2x | 1x | 1x | 2x | 2x| 2x | 6x| 1x| |(39)|(376F)|(3100)|(01) | | | | | | | +----+------+------+-----+-----+-----+----+------+----+----+ | | |DE_BT | FI1 | RI | RD |FI2 | | +----+------+------+-----+-----+-----+----+----------------+ | 1x | 2x | 2x | 1x | 1x | 2x | 1x | 10x | |(39)|(376F)|(3100)|(02) | | | | | +----+------+------+-----+-----+-----+----+------+----+----+ FI - Format Identifier RI - Regional Identifier RD - Routing Identifier Germany defines two formats The first follows ANSI X3S3.3 with the exception that the DFI and ORG fields are replaced with DE-BT of two octets containing 3100, FI1 of one octet of 01 and R1 of one octet which is a region code. Rsvd is 0. RD defines the site (presumably within the region. The second is for CONS where Rsvd, ID, Sel are replaced by a single field presumably allocated by the site. 14 DECNET Phase V NSAP used for transition. One assumes that after transition this format will become redundant. +-----------+--------------------------------+ |IDP | | +----+------+--------------------------------+ |AFI | IDI | DSP | +----+------+----------------------+----+----+ | | | Loc Area | ID | Sel| +----+------+----------------------+----+----+ | 1x | 4x | 2x | 6x| 1x| |(47)|(0020)|(0013) area 19 | DA |(20)| +----+------+----------------------+----+----+ NSAP for DECNET Phase V after transition (proposal from Dave Kelsey). DA = DECNET phase IV address = AA000400nnnn nnnn = area*1024+node number SEL = 20 hex DECNET transport and session control = 21 OSI transport +-----------+------------------------------------+ |IDP | | +----+------+------------------------------------+ |AFI | IDI | DSP | +----+------+------------------+-----------------+ | | |Pre-DSP | CDSP | +----+------+---+-----+----------------+---+-----+ | | |CFI|CDI | |LocArea|ID | Sel | +----+------+---------+--------+-------+---+-----+ | 1x | 2x | 1 |3 | 0-6x | 2x | 6x| 1x | |(39)|(826F)|(1)|(107)| | | |(21) | +----+-----+----+-----+--------+-------+---+-----+ The CDSP is converted between CFI - Country Format Identifier CDI - Country Domain Identifier ID is recommended to be the ethernet address In this scheme each site or ISO CLNS routing domain is defined by up to 6 octets. This should probably be a site code and could follow the current JNT CONS scheme although codes with odd numbers of digits would have to be padded to an even number. Alternatively all codes could be 3 octets - but see discussion below. 15 NORDUNET Follows US GOSSIP and Internet draft OSI NSAP address format. +-----------+------------------------------------------------+ |IDP | | +----+------+------------------------------------------------+ |AFI | IDI | DSP | +----+------+----+---------+------+---------+----+------+----+ | | |DFI | AA |Revd |RD |Area|System|NSEL| +----+------+----+---------+------+---------+----+------+----+ | 1x | 4x | 1x | 3x | 2x | 2x | 2x| 6x | 1x | |(47)|(0023)|(00)| (00000n)|(0000)| | | | | |NORDUnet backbone (000001)| | (0001) |(01)|MacAdd| | |DK (UNI-C) (000002)| | | |IPAddr| | |FI (FUNET) (000003)| | | |or | | |IS (SURIS) (000004)| | site | |some- | | |NO (UNINETT) (000005)| | | |thing | | |SE (SUNET) (000006)| | | |else | | |NORDUnet DECnet transition| | | | | | | (000007)| | (0001) |DA |MacAdd|SEL | +--------------------------+------+---------+----+------+----+ 16 Switzerland (SWITCH/WG2/DP-91-1)) Switzerland uses the ISO DCC scheme +----------+----------------------------+ |IDP | DSP | +----+-----+--------------+-------------+ |AFI | IDI | CHDP | CHDSP| +----+-----+------+-------+-------------+ | | | CHFI |CHDI | | +----+-----+------+-------+-------------+ |1x | 3 |2 (11)| 2 | <=31| Large organisations |(38)|(756)|2 (21)| 4 | <=29| Intermediate | | |2 (31)| 8 | <=25| Small | | | | | | |1x | 2x |1x(11)| 1x | <=15x| Large organisations |(39)|(756)|1x(21)| 2x | <=14x| Intermediate | | |1x(31)| 4x | <=12x| Small | | |1x(80)| 3x | <=13x| US Gosip DSP users +----+-----+------+-------+-------------+ CHDI - Swiss Domain Identifier CHFI - Swiss Format Identifier The format is compatible with the use of the 9 low order octets with ECMA 117. Switch expect to use CHFI = 11 and CHDI = 11 17 Practical considerations DEC recommend that the ID field is the MAC address of the ES. Their routers provide a means for an ES indicating its MAC address to the IS thus requiring no table maintenance for ESs. Indications are that ISs from other suppliers may not include this facility. A network can be split into a set of "routing domain confederations" within a routing domain. The significance is that the structure within such a confederation is private to the confederation. This reduces the size of the tables needed within the ISs and reduces routing information traffic. In the case of Europe you could consider a department being a confederation within a site, a site being a confederation within a country and a country being a confederation within European. It would appear that there is advantage in a confederation equating with a single IDP HO-DSP combination although there will be many exceptions - for example to take account of DECNET phase IV. A corollary is that a "site code" will be needed for the backbone. The code 0000 is suggested. Apologies to those familiar with JIPS who may find such a comment obvious. Extending this concept a "site code" will be needed (or rather exists) for the European backbone. This code has been donated/loaned from the NORUNET 47 series and GB will need to obtain such a site code for its international IS. The code in use in the CLNS WG4 pilot is: 47.0023.0000.0001.0000.0001.0001.xxxx.xxxx.xxxx.00 Practical experience with JIPS and the above considerations indicate that the CLNS project should follow the JIPS structure with a site being a confederation with a single connection to a backbone confederation of completely interconnected ISs. There should be an international IS form- ing part of an international confederation which may or may not be completely interconnected depending on topological considerations. 18 Comment The options for NSAPs for the CLNS project are limited. The use of an AFI of 47 is essential if the DECNET community is to be accommodated. The use of the AFI should be on an interim basis pending the completion of the transition from DECNET phase IV to phase V. A very rough estimate is that it will be needed for two years. On the longer term an AFI of 47 or 39 could be used. 39 has advantages as it follows the philosophy of NSAPs being structured on a country basis. The use of 47 would involve the application for an address space on the lines adopted by NORDUnet. On a world wide basis this would merely lead to an alternative set of country codes. The reason for NORDUnet's decision is to follow RFC1237 which in turn follows US Gosip. However Country Code (DCC) subdomain will be common in the international Inter- net." and goes on to refer to the ANSI X3 proposal. It is an interesting argument as to whether 47 or 39 should be used and on balance I prefer 39. The choice will only be apparent in retrospect when we see if products depend on which is chosen. There is no option but to follow ISO DP 10598 in structuring the NSAP into essentially two parts - AFI+IDI+HO-DSP for IS-IS routing and ID for ES-IS routing. Routers are unlikely to work with any other scheme. The SEL field does not take part in routing. An "area" would seem to relate best to a site although there seems no good reason why a site should not be composed of a number of areas - it probably depends on local circumstances. The "routing domain" and "administrative domain" could relate to GB although it could be argued that the world wide academic networks (or just European networks) could be an administrative domain. In principle the structure of the ID field is a local matter except that its length has to be uniform within the routing domain. The popular choice for the length of ID (1<=ID<=8) is 6 octets since it is antici- pated that this will contain the MAC address of the end system. This goes counter to the view that an NSAP should be independent of the underlying protocols - but ISO DP 10598 already undermines this philoso- phy by overtly using the structure of the NSAP for routing. To go against this may be to put the UK in a unique and lonely position. We have the situation where the best choice depends on the availability of products. Thus it is recommended that the ID should be 6 octets and a weak recommendation that it contain the MAC address. It is understood that JNT has obtained an allocation for the binary DCC scheme (39 region) which is 1107 hex (2 octets). Thus we cannot follow UK Gosip and are left with 2 octets for the site (or AA field) rather than 3. The current site JNT codes defined in "UK Academic Community OSI Requirements Note 6" could be used which, apart from 4 or so codes, are 4 or less digits which may be padded to 2 octets. Following US GOSSIP the next 2 octets are reserved and the RD field of 1 octet could be used for subdividing a site into several routing domains. This leads to the structure illustrated below. +-----------+-------------------------------------------+ |IDP | | +----+------+-------------------------------------------+ |AFI | IDI | DSP | +----+------+-------------------------+-----------------+ | | |Pre-DSP | CDSP | +----+------+---+-----+----+------+---+----+-------+----+ | | |CFI|CDI |site|Rsvd |RD |Area|ID |Sel | +----+------+---------+----+------+---+----+-------+----+ | 1x | 2x | 1 |3 | 2x| 2x |2x | 2x | 6x | 1x | |(39)|(826F)|(1)|(107)| |(0000)| | |MAC add|(21)| +----+-----+----+-----+----+------+---+----+-------+----+ ========= ========= ========= ========= ========= ========= ========= http://www.rfc-editor.org/rfc/rfc1338.txt Network Working Group V. Fuller Request for Comments: 1338 BARRNet T. Li cisco J. Yu MERIT K. Varadhan OARnet June 1992 Supernetting: an Address Assignment and Aggregation Strategy 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 discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. Table of Contents Acknowledgements ................................................. 2 1. Problem, goal, and motivation ................................ 2 2. Scheme plan .................................................. 3 2.1. Aggregation and its limitations ............................ 3 2.2. Distributed network number allocation ...................... 5 3. Cost-benefit analysis ........................................ 6 3.1. Present allocation figures ................................. 7 3.2. Historic growth rates ...................................... 8 3.3. Detailed analysis .......................................... 8 3.3.1. Benefits of new addressing plan .......................... 9 3.3.2. Growth rate projections .................................. 9 4. Changes to Inter-Domain routing protocols .................... 11 4.1. General semantic changes ................................... 11 4.2. Rules for route advertisement .............................. 11 4.3. How the rules work ......................................... 13 4.4. Responsibility for and configuration of aggregation ........ 14 5. Example of new allocation and routing ........................ 15 5.1. Address allocation ......................................... 15 5.2. Routing advertisements ..................................... 17 6. Transitioning to a long term solution ........................ 18 Fuller, Li, Yu, & Varadhan [Page 1] RFC 1338 Supernetting June 1992 7. Conclusions .................................................. 18 8. Recommendations .............................................. 18 9. Bibliography ................................................. 19 10. Security Considerations ...................................... 19 11. Authors' Addresses ........................................... 19 Acknowledgements The authors wish to express their appreciation to the members of the ROAD group with whom many of the ideas contained in this document were inspired and developed. 1. Problem, Goal, and Motivation As the Internet has evolved and grown over in recent years, it has become painfully evident that it is soon to face several serious scaling problems. These include: 1. Exhaustion of the class-B network address space. One fundamental cause of this problem is the lack of a network class of a size which is appropriate for mid-sized organization; class-C, with a maximum of 254 host addresses, is too small while class-B, which allows up to 65534 addresses, is to large to be widely allocated. 2. Growth of routing tables in Internet routers beyond the ability of current software (and people) to effectively manage. 3. Eventual exhaustion of the 32-bit IP address space. It has become clear that the first two of these problems are likely to become critical within the next one to three years. This memo attempts to deal with these problems by proposing a mechanism to slow the growth of the routing table and the need for allocating new IP network numbers. It does not attempt to solve the third problem, which is of a more long-term nature, but instead endeavors to ease enough of the short to mid-term difficulties to allow the Internet to continue to function efficiently while progress is made on a longer- term solution. The proposed solution is to hierarchically allocate future IP address assignment, by delegating control of segments of the IP address space to the various network service providers. It is proposed that this scheme of allocating IP addresses be undertaken as soon as possible. It is also believed that the scheme will suffice as a short term strategy, to fill the gap between now Fuller, Li, Yu, & Varadhan [Page 2] RFC 1338 Supernetting June 1992 and the time when a viable long term plan can be put into place and deployed effectively. It is believed that this scheme would be viable for at least three (3) years, in which time frame, a suitable long term solution would be expected to be deployed. Note that this plan neither requires nor assumes that already assigned addresses will be reassigned, though if doing so were possible, it would further reduce routing table sizes. It is assumed that routing technology will be capable of dealing with the current routing table size and with some reasonably-small rate of growth. The emphasis of this plan is on significantly slowing the rate of this growth. This scheme will not affect the deployment of any specific long term plan, and therefore, this document will not discuss any long term plans for routing and address architectures. 2. Scheme Plan There are two basic components of this addressing and routing scheme: one, to distribute the allocation of Internet address space and two, to provide a mechanism for the aggregation of routing information. 2.1. Aggregation and its limitations One major goal of this addressing plan is to allocate Internet address space in such a manner as to allow aggregation of routing information along topological lines. For simple, single-homed clients, the allocation of their address space out of a service provider's space will accomplish this automatically - rather than advertise a separate route for each such client, the service provider may advertise a single, aggregate, route which describes all of the destinations contained within it. Unfortunately, not all sites are singly-connected to the network, so some loss of ability to aggregate is realized for the non simple cases. There are two situations that cause a loss of aggregation efficiency. o Organizations which are multi-homed. Because multi-homed organizations must be advertised into the system by each of their service providers, it is often not feasible to aggregate their routing information into the address space any one of those providers. Note that they still may receive their address allocation out of a service provider's address space (which has other advantages), but their routing information must still be explicitly advertised by most of their service providers (the exception being that if the site's allocation comes out of its least-preferable service provider, then that Fuller, Li, Yu, & Varadhan [Page 3] RFC 1338 Supernetting June 1992 service provider need not advertise the explicit route - longest-match will insure that its aggregated route is used to get to the site on a non-primary basis). For this reason, the routing cost for these organizations will typically be about the same as it is today. o Organizations which move from one service provider to another. This has the effect of "punching a hole" in the aggregation of the original service provider's advertisement. This plan will handle the situation by requiring the newer service provider to advertise a specific advertisement for the new client, which is preferred by virtue of being the longest match. To maintain efficiency of aggregation, it is recommended that organizations which do change service providers plan to eventually migrate their address assignments from the old provider's space to that of the new provider. To this end, it is recommended that mechanisms to facilitate such migration, including improved protocols and procedures for dynamic host address assignment, be developed. Note that some aggregation efficiency gain can still be had for multi-homed sites (and, in general, for any site composed of multiple, logical IP network numbers) - by allocating a contiguous block of network numbers to the client (as opposed to multiple, independently represented network numbers) the client's routing information may be aggregated into a single (net, mask) pair. Also, since the routing cost associated with assigning a multi-homed site out of a service provider's address space is no greater than the current method of a random allocation by a central authority, it makes sense to allocate all address space out of blocks assigned to service providers. It is also worthwhile to mention that since aggregation may occur at multiple levels in the system, it may still be possible to aggregate these anomalous routes at higher levels of whatever hierarchy may be present. For example, if a site is multi-homed to two NSFNet regional networks both of whom obtain their address space from the NSFNet, then aggregation by the NSFNet of routes from the regionals will include all routes to the multi-homed site. Finally, it should also be noted that deployment of the new addressing plan described in this document may (and should) begin almost immediately but effective use of the plan to aggregate routing information will require changes to some Inter-Domain routing protocols. Likewise, deploying the supernet-capable Inter- Domain protocols without deployment of the new address plan will not allow useful aggregation to occur (in other words, the Fuller, Li, Yu, & Varadhan [Page 4] RFC 1338 Supernetting June 1992 addressing plan and routing protocol changes are both required for supernetting, and its resulting reduction in table growth, to be effective.) Note, however, that during the period of time between deployment of the addressing plan and deployment of the new protocols, the size of routing tables may temporarily grow very rapidly. This must be considered when planning the deployment of the two plans. Note: in the discussion and examples which follow, the network+mask notation is used to represent routing destinations. This is used for illustration only and does not require that routing protocols use this representation in their updates. 2.2. Distributed allocation of address space The basic idea of the plan is to allocate one or more blocks of Class-C network numbers to each network service provider. Organizations using the network service provider for Internet connectivity are allocated bitmask-oriented subsets of the provider's address space as required. Note that in contrast to a previously described scheme of subnetting a class-A network number, this plan should not require difficult host changes to work around domain system limitations - since each sub-allocated piece of the address space looks like a class-C network number, delegation of authority for the IN- ADDR.ARPA domain works much the same as it does today - there will just be a lot of class-C network numbers whose IN-ADDR.ARPA delegations all point to the same servers (the same will be true of the root delegating a large block of class-Cs to the network provider, unless the delegation just happens to fall on a byte boundary). It is also the case that this method of aggregating class-C's is somewhat easier to deploy, since it does not require the ability to split a class-A across a routing domain boundary (i.e., non-contiguous subnets). It is also worthy to mention that once Inter-Domain protocols which support classless network destinations are widely deployed, the rules described by the "supernetting" plan generalize to permit arbitrary super/subnetting of the remaining class-A and class-B address space (the assumption being that classless Inter-Domain protocols will either allow for non-contiguous subnets to exist in the system or that all components of a sub-allocated class-A/B will be contained within a single routing domain). This will allow this plan to continue to be used in the event that the class-C space is exhausted before implementation of a long-term solution is deployed (there may, however, be further implementation considerations before doing this). Fuller, Li, Yu, & Varadhan [Page 5] RFC 1338 Supernetting June 1992 Hierarchical sub-allocation of addresses in this manner implies that clients with addresses allocated out of a given service provider are, for routing purposes, part of that service provider and will be routed via its infrastructure. This implies that routing information about multi-homed organizations, i.e., organizations connected to more than one network service provider, will still need to be known by higher levels in the hierarchy. The advantages of hierarchical assignment in this fashion are a) It is expected to be easier for a relatively small number of service providers to obtain addresses from the central authority, rather than a much larger, and monotonically increasing, number of individual clients. This is not to be considered as a loss of part of the service providers' address space. b) Given the current growth of the Internet, a scalable and delegatable method of future allocation of network numbers has to be achieved. For these reasons, and in the interest of providing a consistent procedure for obtaining Internet addresses, it is recommended that most, if not all, network numbers be distributed through service providers. 3. Cost-benefit analysis This new method of assigning address through service providers can be put into effect immediately and will, from the start, have the benefit of distributing the currently centralized process of assigning new addresses. Unfortunately, before the benefit of reducing the size of globally-known routing destinations can be achieved, it will be necessary to deploy an Inter-Domain routing protocol capable of handling arbitrary network+mask pairs. Only then will it be possible to aggregate individual class-C networks into larger blocks represented by single routing table entries. This means that upon introduction, the new addressing plan will not in and of itself help solve the routing table size problem. Once the new Inter-Domain routing protocol is deployed, however, an immediate drop in the number of destinations which clients of the new protocol must carry will occur. A detailed analysis of the magnitude of this expected drop and the permanent reduction in rate of growth is given in the next section. In should also be noted that the present method of flat address allocations imposes a large bureaucratic cost on the central address Fuller, Li, Yu, & Varadhan [Page 6] RFC 1338 Supernetting June 1992 allocation authority. For scaling reasons unrelated to address space exhaustion or routing table overflow, this should be changed. Using the mechanism proposed in this paper will have the happy side effect of distributing the address allocation procedure, greatly reducing the load on the central authority. 3.1. Present Allocation Figures A back-of-the-envelope analysis of "network-contacts.txt" (available from the DDN NIC) indicates that as of 2/25/92, 46 of 126 class-A network numbers have been allocated (leaving 81) and 5467 of 16256 class-B numbers have been allocated, leaving 10789. Assuming that recent trends continue, the number of allocated class-B's will continue to double approximately once a year. At this rate of grown, all class-B's will be exhausted within about 15 months. Fuller, Li, Yu, & Varadhan [Page 7] RFC 1338 Supernetting June 1992 3.2. Historic growth rates MM/YY ROUTES MM/YY ROUTES ADVERTISED ADVERTISED ------------------------ ----------------------- Feb-92 4775 Apr-90 1525 Jan-92 4526 Mar-90 1038 Dec-91 4305 Feb-90 997 Nov-91 3751 Jan-90 927 Oct-91 3556 Dec-89 897 Sep-91 3389 Nov-89 837 Aug-91 3258 Oct-89 809 Jul-91 3086 Sep-89 745 Jun-91 2982 Aug-89 650 May-91 2763 Jul-89 603 Apr-91 2622 Jun-89 564 Mar-91 2501 May-89 516 Feb-91 2417 Apr-89 467 Jan-91 2338 Mar-89 410 Dec-90 2190 Feb-89 384 Nov-90 2125 Jan-89 346 Oct-90 2063 Dec-88 334 Sep-90 1988 Nov-88 313 Aug-90 1894 Oct-88 291 Jul-90 1727 Sep-88 244 Jun-90 1639 Aug-88 217 May-90 1580 Jul-88 173 Table I : Growth in routing table size, total numbers Source for the routing table size data is MERIT 3.3. Detailed Analysis There is no technical cost and minimal administrative cost associated with deployment of the new address assignment plan. The administrative cost is basically that of convincing the NIC, the IANA, and the network service providers to agree to this plan, which is not expected to be too difficult. In addition, administrative cost for the central numbering authorities (the NIC and the IANA) will be greatly decreased by the deployment of this plan. To take advantage of aggregation of routing information, however, it is necessary that the capability to represent routes as arbitrary network+mask fields (as opposed to the current class-A/B/C distinction) be added to the common Internet inter- domain routing protocol(s). Fuller, Li, Yu, & Varadhan [Page 8] RFC 1338 Supernetting June 1992 3.3.1. Benefits of the new addressing plan There are two benefits to be had by deploying this plan: o The current problem with depletion of the available class-B address space can be ameliorated by assigning more- appropriately sized blocks of class-C's to mid-sized organizations (in the 200-4000 host range). o When the improved inter-domain routing protocol is deployed, an immediate decrease in the number routing table entries followed by a significant reduction in the rate growth of routing table size should occur (for default-free routers). 3.3.2. Growth rate projections Currently, a default-free routing table (for example, the routing tables maintained by the routers in the NSFNET backbone) contains approximately 4700 entries. This number reflects the current size of the NSFNET routing database. Historic data shows that this number, on average, has doubled every 10 months between 1988 and 1991. Assuming that this growth rate is going to persist in the foreseeable future (and there is no reason to assume otherwise), we expect the number of entries in a default-free routing table to grow to approximately 30000 in two(2) years time. In the following analysis, we assume that the growth of the Internet has been, and will continue to be, exponential. It should be stressed that these projections do not consider that the current shortage of class-B network numbers may increase the number of instances where many class-C's are used rather than a class-B. Using an assumption that new organizations which formerly obtained class-B's will now obtain somewhere between 4 and 16 class-C's, the rate of routing table growth can conservatively be expected to at least double and probably quadruple. This means the number of entries in a default-free routing table may well exceed 10,000 entries within six months and 20,000 entries in less than a year. Under the proposed plan, growth of the routing table in a default-free router is greatly reduced since most new address assignment will come from one of the large blocks allocated to the service providers. For the sake of this analysis, we assume prompt implementation of this proposal and deployment of the revised routing protocols. We make the initial assumption that any initial block given to a provider is sufficient to satisfy its needs for two years. Fuller, Li, Yu, & Varadhan [Page 9] RFC 1338 Supernetting June 1992 Since under this plan, multi-homed networks must continue to be explicitly advertised throughout the system (according to Rule#1 described in section 4.2), the number multi-homed routes is expected to be the dominant factor in future growth of routing table size, once the supernetting plan is applied. Presently, it is estimated that there are fewer than 100 multi- homed organizations connected to the Internet. Each such organization's network is comprised of one or more network numbers. In many cases (and in all future cases under this plan), the network numbers used by an organization are consecutive, meaning that aggregation of those networks during route advertisement may be possible. This means that the number of routes advertised within the Internet for multi-homed networks may be approximated as the total number of multi-homed organizations. Assuming that the number of multi-homed organization will double every year (which may be a over-estimation, given that every connection costs money), the number of routes for multi-homed networks would be expected to grow to approximately 800 in three years. If we further assume that there are approximately 100 service providers, then each service provider will also need to advertise its block of addresses. However, due to aggregation, these advertisements will be reduced to only 100 additional routes. We assume that after the initial two years, new service providers combined with additional requests from existing providers will require an additional 50 routes per year. Thus, the total is 4700 + 800 + 150 = 5650. This represents an annual grown rate of approximately 6%. This is in clear contrast to the current annual growth of 150%. This analysis also assumes an immediate deployment of this plan with full compliance. Note that this analysis assumes only a single level of route aggregation in the current Internet - intelligent address allocation should significantly improve this. Clearly, this is not a very conservative assumption in the Internet environment nor can 100% adoption of this proposal be expected. Still, with only a 90% participation in this proposal by service providers, at the end of the target three years, global routing table size will be "only" 4700 + 800 + 145 + 7500 = 13145 routes -- without any action, the routing table will grow to approximately 75000 routes during that time period. Fuller, Li, Yu, & Varadhan [Page 10] RFC 1338 Supernetting June 1992 4. Changes to Inter-Domain routing protocols In order to support supernetting efficiently, it is clear that some changes will need to be made to both routing protocols themselves and to the way in which routing information is interpreted. In the case of "new" inter-domain protocols, the actual protocol syntax changes should be relatively minor. This mechanism will not work with older inter-domain protocols such as EGP2; the only ways to interoperate with old systems using such protocols are either to use existing mechanisms for providing "default" routes or b) require that new routers talking to old routers "explode" supernet information into individual network numbers. Since the first of these is trivial while the latter is cumbersome (at best -- consider the memory requirements it imposes on the receiver of the exploded information), it is recommended that the first approach be used -- that older systems to continue to the mechanisms they currently employ for default handling. Note that a basic assumption of this plan is that those organizations which need to import "supernet" information into their routing systems must run IGPs (such as OSPF[RFC1267]) which support classless routes. Systems running older IGPs may still advertise and receive "supernet" information, but they will not be able to propagate such information through their routing domains. 4.1. Protocol-independent semantic changes There are two fundamental changes which must be applied to Inter- Domain routing protocols in order for this plan to work. First, the concept of network "class" needs to be deprecated - this plan assumes that routing destinations are represented by network+mask pairs and that routing is done on a longest-match basis (i.e., for a given destination which matches multiple network+mask pairs, the match with the longest mask is used). Second, current Inter-Domain protocols generally do not support the concept of route aggregation, so the new semantics need to be implemented mechanisms that routers use to interpret routing information returned by the Inter-Domain protocols. In particular, when doing aggregation, dealing with multi-homed sites or destinations which change service providers is difficult. Fortunately, it is possible to define several fairly simple rules for dealing with such cases. 4.2. Rules for route advertisement 1. Routing to all destinations must be done on a longest-match basis only. This implies that destinations which are multi- homed relative to a routing domain must always be explicitly announced into that routing domain - they cannot be summarized Fuller, Li, Yu, & Varadhan [Page 11] RFC 1338 Supernetting June 1992 (this makes intuitive sense - if a network is multi-homed, all of its paths into a routing domain which is "higher" in the hierarchy of networks must be known to the "higher" network). 2. A routing domain which performs summarization of multiple routes must discard packets which match the summarization but do not match any of the explicit routes which makes up the summarization. This is necessary to prevent routing loops in the presence of less-specific information (such as a default route). Implementation note - one simple way to implement this rule would be for the border router to maintain a "sink" route for each of its aggregations. By the rule of longest match, this would cause all traffic destined to components of the aggregation which are not explicitly known to be discarded. Note that during failures, partial routing of traffic to a site which takes its address space from one service provider but which is actually reachable only through another (i.e., the case of a site which has change service providers) may occur because such traffic will be routed along the path advertised by the aggregated route. Rule #2 will prevent any real problem from occurring by forcing such traffic to be discarded by the advertiser of the aggregated route, but the output of "traceroute" and other similar tools will suggest that a problem exists within the service provider advertising the aggregate, which may be confusing to network operators (see the example in section 5.2 for details). Solutions to this problem appear to be challenging and not likely to be implementable by current Inter-Domain protocols within the time-frame suggested by this document. This decision may need to be revisited as Inter-Domain protocols evolve. An implementation following these rules should also make the implementation be generalized, so that arbitrary network number and mask are accepted for all routing destinations. The only outstanding constraint is that the mask must be left contiguous. Note that the degenerate route 0.0.0.0 mask 0.0.0.0 is used as a default route and MUST be accepted by all implementations. Further, to protect against accidental advertisements of this route via the inter-domain protocol, this route should never be advertised unless there is specific configuration information indicating to do so. Fuller, Li, Yu, & Varadhan [Page 12] RFC 1338 Supernetting June 1992 Systems which process route announcements must also be able to verify that information which they receive is correct. Thus, implementations of this plan which filter route advertisements must also allow masks in the filter elements. To simplify administration, it would be useful if filter elements automatically allowed more specific network numbers and masks to pass in filter elements given for a more general mask. Thus, filter elements which looked like: accept 128.32.0.0 accept 128.120.0.0 accept 134.139.0.0 accept 36.0.0.0 would look something like: accept 128.32.0.0 255.255.0.0 accept 128.120.0.0 255.255.0.0 accept 134.139.0.0 255.255.0.0 deny 36.2.0.0 255.255.0.0 accept 36.0.0.0 255.0.0.0 This is merely making explicit the network mask which was implied by the class-A/B/C classification of network numbers. 4.3. How the rules work Rule #1 guarantees that the routing algorithm used is consistent across implementations and consistent with other routing protocols, such as OSPF. Multi-homed networks are always explicitly advertised by every service provider through which they are routed even if they are a specific subset of one service provider's aggregate (if they are not, they clearly must be explicitly advertised). It may seem as if the "primary" service provider could advertise the multi-homed site implicitly as part of its aggregate, but the assumption that longest-match routing is always done causes this not to work. Rule #2 guarantees that no routing loops form due to aggregation. Consider a mid-level network which has been allocated the 2048 class-C networks starting with 192.24.0.0 (see the example in section 5 for more on this). The mid-level advertises to a "backbone" 192.24.0.0/255.248.0.0. Assume that the "backbone", in turn, has been allocated the block of networks 192.0.0.0/255.0.0.0. The backbone will then advertise this aggregate route to the mid-level. Now, if the mid-level loses internal connectivity to the network 192.24.1.0/255.255.255.0 (which is part of its aggregate), traffic from the "backbone" to the mid-level to destination 192.24.1.1 will follow the mid-level's advertised route. When that traffic gets to the mid-level, however, the mid-level *must not* follow the route Fuller, Li, Yu, & Varadhan [Page 13] RFC 1338 Supernetting June 1992 192.0.0.0/255.0.0.0 it learned from the backbone, since that would result in a routing loop. Rule #2 says that the mid-level may not follow a less-specific route for a destination which matches one of its own aggregated routes. Note that handling of the "default" route (0.0.0.0/0.0.0.0) is a special case of this rule - a network must not follow the default to destinations which are part of one of it's aggregated advertisements. 4.4. Responsibility for and configuration of aggregation The AS which owns a range of addresses has the sole authority for aggregation of its address space. In the usual case, the AS will install manual configuration commands in its border routers to aggregate some portion of its address space. As AS can also delegate aggregation authority to another AS. In this case, aggregation is done in the other AS by one of its border routers. When an inter-domain border router performs route aggregation, it needs to know the range of the block of IP addresses to be aggregated. The basic principle is that it should aggregate as much as possible but not to aggregate those routes which cannot be treated as part of a single unit due to multi-homing, policy, or other constraints. One mechanism is to do aggregation solely based on dynamically learned routing information. This has the danger of not specifying a precise enough range since when a route is not present, it is not always possible to distinguish whether it is temporarily unreachable or that it does not belong in the aggregate. Purely dynamic routing also does not allow the flexibility of defining what to aggregate within a range. The other mechanism is to do all aggregation based on ranges of blocks of IP addresses preconfigured in the router. It is recommended that preconfiguration be used, since it more flexible and allows precise specification of the range of destinations to aggregate. Preconfiguration does require some manually-maintained configuration information, but not excessively more so than what router administrators already maintain today. As an addition to the amount of information that must be typed in and maintained by a human, preconfiguration is just a line or two defining the range of the block of IP addresses to aggregate. In terms of gathering the information, if the advertising router is doing the aggregation, its administrator knows the information because the aggregation ranges are assigned to its domain. If the receiving domain has been granted the authority to and task of performing aggregation, the information would be known as part of the agreement to delegate aggregation. Given that it is common practice that a network administrator learns Fuller, Li, Yu, & Varadhan [Page 14] RFC 1338 Supernetting June 1992 from its neighbor which routes it should be willing to accept, preconfiguration of aggregation information does not introduce additional administrative overhead. 5. Example of new allocation and routing 5.1. Address allocation Consider the block of 2048 class-C network numbers beginning with 192.24.0.0 (0xC0180000 and ending with 192.31.255.0 (0xC01FFF00) allocated to a single network provider, "RA". A "supernetted" route to this block of network numbers would be described as 192.24.0.0 with mask of 255.248.0.0 (0xFFF80000). Assume this service provider connects six clients in the following order (significant because it demonstrates how temporary "holes" may form in the service provider's address space): "C1" requiring fewer than 2048 addresses (8 class-C networks) "C2" requiring fewer than 4096 addresses (16 class-C networks) "C3" requiring fewer than 1024 addresses (4 class-C networks) "C4" requiring fewer than 1024 addresses (4 class-C networks) "C5" requiring fewer than 512 addresses (2 class-C networks) "C6" requiring fewer than 512 addresses (2 class-C networks) In all cases, the number of IP addresses "required" by each client is assumed to allow for significant growth. The service provider allocates its address space as follows: C1: allocate 192.24.0 through 192.24.7. This block of networks is described by the "supernet" route 192.24.0.0 and mask 255.255.248.0 C2: allocate 192.24.16 through 192.24.31. This block is described by the route 192.24.16.0, mask 255.255.240.0 C3: allocate 192.24.8 through 192.24.11. This block is described by the route 192.24.8.0, mask 255.255.252.0 C4: allocate 192.24.12 through 192.24.15. This block is described by the route 192.24.12.0, mask 255.255.252.0 C5: allocate 192.24.32 and 192.24.33. This block is described by Fuller, Li, Yu, & Varadhan [Page 15] RFC 1338 Supernetting June 1992 the route 192.24.32.0, mask 255.255.254.0 C6: allocate 192.24.34 and 192.24.35. This block is described by the route 192.24.34.0, mask 255.255.254.0 Note that if the network provider uses an IGP which can support classless networks, he can (but doesn't have to) perform "supernetting" at the point where he connects to his clients and therefore only maintain six distinct routes for the 36 class-C network numbers. If not, explicit routes to all 36 class-C networks will have to be carried by the IGP. To make this example more realistic, assume that C4 and C5 are multi- homed through some other service provider, "RB". Further assume the existence of a client "C7" which was originally connected to "RB" but has moved to "RA". For this reason, it has a block of network numbers which are allocated out "RB"'s block of (the next) 2048 class-C network numbers: C7: allocate 192.32.0 through 192.32.15. This block is described by the route 192.32.0, mask 255.255.240.0 For the multi-homed clients, we will assume that C4 is advertised as primary via "RA" and secondary via "RB"; C5 is primary via "RB" and secondary via "RA". To connect this mess together, we will assume that "RA" and "RB" are connected via some common "backbone" provider "BB". Graphically, this simple topology looks something like this: Fuller, Li, Yu, & Varadhan [Page 16] RFC 1338 Supernetting June 1992 C1 192.24.0.0 -- 192.24.7.0 \ _ 192.32.0.0 - 192.32.15.0 192.24.0.0/255.255.248.0 \ / 192.32.0.0/255.255.240.0 \ / C7 C2 +----+ +----+ 192.24.16.0 - 192.24.31.0 \| | | | 192.24.16.0/255.255.240.0 | | _ 192.24.12.0 - 192.24.15.0 _ | | | | / 192.24.12.0/255.255.252.0 \ | | C3 -| |/ C4 \| | 192.24.8.0 - 192.24.11.0 | RA | | RB | 192.24.8.0/255.255.252.0 | |___ 192.24.32.0 - 192.24.33.0 ___| | /| | 192.24.32.0/255.255.254.0 | | C6 | | C5 | | 192.24.34.0 - 192.24.35.0 | | | | 192.24.34.0/255.255.254.0 | | | | +----+ +----+ \\ \\ 192.24.12.0/255.255.252.0 (C4) || 192.32.12.0/255.255.252.0 (C4) || 192.24.32.0/255.255.254.0 (C5) || 192.32.32.0/255.255.192.0 (C5) || 192.32.0.0/255.255.240.0 (C7) || 192.32.0.0/255.248.0.0 (RB) || 192.24.0.0/255.248.0.0 (RA) || || VV VV +--------------- BACKBONE PEER BB ---------------+ 5.2. Routing advertisements To follow rule #1, RA will need to advertise the block of addresses that it was given and C7. Since C4 and C5 are multi-homed, they must also be advertised. Advertisements from "RA" to "BB" will be: 192.24.12.0/255.255.252.0 primary (advertises C4) 192.24.32.0/255.255.254.0 secondary (advertises C5) 192.32.0.0/255.255.240.0 primary (advertises C7) 192.24.0.0/255.248.0.0 primary (advertises remainder of RA) For RB, the advertisements must also include C4 and C5 as well as it's block of addresses. Further, RB may advertise that C7 is unreachable. Advertisements from "RB" to "BB" will be: 192.24.12.0/255.255.252.0 secondary (advertises C4) 192.24.32.0/255.255.254.0 primary (advertises C5) 192.32.0.0/255.248.0.0 primary (advertises remainder of RB) Fuller, Li, Yu, & Varadhan [Page 17] RFC 1338 Supernetting June 1992 To illustrate the problem alluded to by the "note" in section 4.2, consider what happens if RA loses connectivity to C7 (the client which is allocated out of RB's space). In a stateful protocol, RA will announce to BB that 192.32.0.0/255.255.240.0 has become unreachable. Now, when BB flushes this information out of its routing table, any future traffic sent through it for this destination will be forwarded to RB (where it will be dropped according to Rule #2) by virtue of RB's less specific match 192.32.0.0/255.248.0.0. While this does not cause an operational problem (C7 is unreachable in any case), it does create some extra traffic across "BB" (and may also prove confusing to a network manager debugging the outage with "traceroute"). A mechanism to cache such unreachability information would help here, but is beyond the scope of this document (such a mechanism is also not implementable in the near-term). 6. Transitioning to a long term solution This solution does not change the Internet routing and addressing architectures. Hence, transitioning to a more long term solution is not affected by the deployment of this plan. 7. Conclusions We are all aware of the growth in routing complexity, and the rapid increase in allocation of network numbers. Given the rate at which this growth is being observed, we expect to run out in a few short years. If the inter-domain routing protocol supports carrying network routes with associated masks, all of the major concerns demonstrated in this paper would be eliminated. One of the influential factors which permits maximal exploitation of the advantages of this plan is the number of people who agree to use it. It is hoped that having the IAB and the Internet society bless this plan would go a long way in the wide deployment, and hence benefit of this plan. If service providers start charging networks for advertising network numbers, this would be a very great incentive to share the address space, and hence the associated costs of advertising routes to service providers. 8. Recommendations The NIC should begin to hand out large blocks of class-C addresses to network service providers. Each block must fall on bit boundaries and should be large enough to serve the provider for two years. Fuller, Li, Yu, & Varadhan [Page 18] RFC 1338 Supernetting June 1992 Further, the NIC should distribute very large blocks to continental and national network service organizations to allow additional levels of aggregation to take place at the major backbone networks. Service providers will further allocate power-of-two blocks of class-C addresses from their address space to their subscribers. All organizations, including those which are multi-homed, should obtain address space from their provider (or one of their providers, in the case of the multi-homed). These blocks should also fall on bit boundaries to permit easy route aggregation. To allow effective use of this new addressing plan to reduce propagated routing information, appropriate IETF WGs will specify the modifications needed to Inter-Domain routing protocols. Implementation and deployment of these modifications should occur as quickly as possible. 9. Bibliography [RFC1247] Moy, J, "The OSPF Specification Version 2", January 1991. 10. Security Considerations Security issues are not discussed in this memo. 11. Authors' Addresses Vince Fuller BARRNet Pine Hall 115 Stanford, CA, 94305-4122 email: vaf@Stanford.EDU Tony Li cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, CA 94025 email: tli@cisco.com Jessica (Jie Yun) Yu Merit Network, Inc. 1071 Beal Ave. Ann Arbor, MI 48109 email: jyy@merit.edu Fuller, Li, Yu, & Varadhan [Page 19] RFC 1338 Supernetting June 1992 Kannan Varadhan Internet Engineer, OARnet 1224, Kinnear Road, Columbus, OH 43212 email: kannan@oar.net Fuller, Li, Yu, & Varadhan [Page 20] ========= ========= ========= ========= ========= ========= ========= http://www.rfc-editor.org/rfc/rfc1347.txt Network Working Group Ross Callon Request for Comments: 1347 DEC June 1992 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing Status of the Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. 1 Summary The Internet is approaching a situation in which the current IP address space is no longer adequate for global addressing and routing. This is causing problems including: (i) Internet backbones and regionals are suffering from the need to maintain large amounts of routing information which is growing rapidly in size (approximately doubling each year); (ii) The Internet is running out of IP network numbers to assign. There is an urgent need to develop and deploy an approach to addressing and routing which solves these problems and allows scaling to several orders of magnitude larger than the existing Internet. However, it is necessary for any change to be deployed in an incremental manner, allowing graceful transition from the current Internet without disruption of service. [1] This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This involves a gradual migration from the current Internet Suite (which is based on Internet applications, running over TCP or UDP, running over IP) to an updated suite (based on the same Internet applications, running over TCP or UDP, running over CLNP [2]). This approach is known as "TUBA" (TCP & UDP with Bigger Addresses). This paper describes a proposal for how transition may be accomplished. Description of the manner in which use of CLNP, NSAP addresses, and related network/Internet layer protocols (ES-IS, IS-IS, and IDRP) allow scaling to a very large ubiquitous worldwide Internet is outside of the scope of this paper. Originally, it was thought that any practical proposal needed to address the immediate short-term problem of routing information explosion (in addition to the long-term problem of scaling to a worldwide Internet). Given the current problems caused by excessive routing information in IP backbones, this could require older IP-based systems to talk to other older IP-based systems over intervening Internet backbones which did not support IP. This in turn would require either translation of IP packets into Callon [Page 1] RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992 CLNP packets and vice versa, or encapsulation of IP packets inside CLNP packets. However, other shorter-term techniques (for example [3]) have been proposed which will allow the Internet to operate successfully for several years using the current IP address space. This in turn allows more time for IP-to-CLNP migration, which in turn allows for a much simpler migration technique. The TUBA proposal therefore makes use of a simple long-term migration proposal based on a gradual update of Internet Hosts (to run Internet applications over CLNP) and DNS servers (to return larger addresses). This proposal requires routers to be updated to support forwarding of CLNP (in addition to IP). However, this proposal does not require encapsulation nor translation of packets nor address mapping. IP addresses and NSAP addresses may be assigned and used independently during the migration period. Routing and forwarding of IP and CLNP packets may be done independently. This paper provides a draft overview of TUBA. The detailed operation of TUBA has been left for further study. 2 Long-Term Goal of TUBA This proposal seeks to take advantage of the success of the Internet Suite, the greatest part of which is probably the use of IP itself. IP offers a ubiquitous network service, based on datagram (connectionless) operation, and on globally significant IP addresses which are structured to aid routing. Unfortunately, the limited 32-bit IP address is gradually becoming inadequate for routing and addressing in a global Internet. Scaling to the anticipated future size of the worldwide Internet requires much larger addresses allowing a multi-level hierarchical address assignment. If we had the luxury of starting over from scratch, most likely we would base the Internet on a new datagram internet protocol with much larger multi-level addresses. In principle, there are many choices available for a new datagram internet protocol. For example, the current IP could be augmented by addition of larger addresses, or a new protocol could be developed. However, the development, standardization, implementation, testing, debugging and deployment of a new protocol (as well as associated routing and host-to-router protocols) would take a very large amount of time and energy, and is not guaranteed to lead to success. In addition, there is already such a protocol available. In particular, the ConnectionLess Network Protocol (CLNP [1]) is very similar to IP, and offers the required datagram service and address flexibility. CLNP is currently being deployed in the Internet backbones and regionals, and is available in vendor products. This proposal does not actually require use of CLNP (the main content of this proposal is a graceful migration path from the current IP to a new IP offering a larger address space), Callon [Page 2] RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992 but use of CLNP will be assumed. This proposal seeks to minimize the risk associated with migration to a new IP address space. In addition, this proposal is motivated by the requirement to allow the Internet to scale, which implies use of Internet applications in a very large ubiquitous worldwide Internet. It is therefore proposed that existing Internet transport and application protocols continue to operate unchanged, except for the replacement of 32-bit IP addresses with larger addresses. The use of larger addresses will have some effect on applications, particularly on the Domain Name Service. TUBA does not mean having to move over to OSI completely. It would mean only replacing IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would run on top of CLNP. The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses. Operation of this updated protocol suite will be very similar to the current operation. For example, in order to initiate communication with another host, a host will obtain a internet address in the same manner that it normally does, except that the address would be larger. In many or most cases, this implies that the host would contact the DNS server, obtain a mapping from the known DNS name to an internet address, and send application packets encapsulated in TCP or UDP, which are in turn encapsulated in CLNP. This long term goal requires a specification for how TCP and UDP are run over CLNP. Similarly, DNS servers need to be updated to deal with NSAP addresses, and routers need to be updated to forward CLNP packets. This proposal does not involve any wider-spread migration to OSI protocols. TUBA does not actually depend upon DNS for its operation. Any method that is used for obtaining Internet addresses may be updated to be able to return larger (NSAP) addresses, and then can be used with TUBA. 3 Migration Figure 1 illustrates the basic operation of TUBA. Illustrated is a single Internet Routing Domain, which is also interconnected with Internet backbones and/or regionals. Illustrated are two "updated" Internet Hosts N1 and N2, as well as two older hosts H1 and H2, plus a DNS server and two border routers. It is assumed that the routers internal to the routing domain are capable of forwarding both IP and CLNP traffic (this could be done either by using multi-protocol routers which can forward both protocol suites, or by using a different set of routers for each suite). Callon [Page 3] RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992 ................ ................ . H1 . . Internet . . .-R1-. . . H2 . . Backbones . . DNS . . . . . . and . . N1 . . . . . . Regionals . . N2 .-R2-. . ................ ................ Key DNS DNS server H IP host N Updated Internet host R Border Router Figure 1 - Overview of TUBA Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup. Thus, suppose that host N1 wants to communicate with host H1. In this case, N1 asks its local DNS server for the address associated with H1. In this case, since H1 is a older (not-updated) host, the address available for H1 is an IP address, and thus the DNS response returned to N1 specifies an IP address. This allows N1 to know that it needs to send a normal old-style Internet suite packet (encapsulated in IP) to H1. Suppose that host N1 wants to communicate with host N2. In this case, again N1 contacts the DNS server. If the routers in the domain have not been updated (to forward CLNP), or if the DNS resource record for N2 has not been updated, then the DNS server will respond with a normal IP address, and the communication between N1 and N2 will use IP (updated hosts in environments where the local routers do not handle CLNP are discussed in section 6.3). However, assuming that the routers in the domain have been updated (to forward CLNP), that the DNS server has been updated (to be able to return NSAP addresses), and that the appropriate resource records for NSAP addresses have been configured into the DNS server, then the DNS server will respond to N1 with the NSAP address for N2, allowing N1 to know to use Callon [Page 4] RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992 CLNP (instead of IP) for communication with N2. A new resource record type will be defined for NSAP addresses. New hosts ask for both the new and old (IP address) resource records. Older DNS servers will not have the new resource record type, and will therefore respond with only IP address information. Updated DNS servers will have the new resource record information for the requested DNS name only if the associated host has been updated (otherwise the updated DNS server again will respond with an IP address). Hosts and/or applications which do not use DNS operate in a similar method. For example, suppose that local name to address records are maintained in host table entries on each local workstation. When a workstation is updated to be able to run Internet applications over CLNP, then the host table on the host may also be updated to contain updated NSAP addresses for other hosts which have also been updated. The associated entries for non-updated hosts would continue to contain IP addresses. Thus, again when an updated host wants to initiate communication with another host, it would look up the associated Internet address in the normal manner. If the address returned is a normal 32-bit IP address, then the host would initiate a request using an Internet application over TCP (or UDP) over IP (as at present). If the returned address is a longer NSAP address, then the host would initiate a request using an Internet application over TCP (or UDP) over CLNP. 4 Running TCP and UDP Over CLNP TCP is run directly on top of CLNP (i.e., the TCP packet is encapsulated directly inside a CLNP packet - the TCP header occurs directly following the CLNP header). Use of TCP over CLNP is straightforward, with the only non-trivial issue being how to generate the TCP pseudo-header (for use in generating the TCP checksum). Note that TUBA runs TCP over CLNP on an end-to-end basis (for example, there is no intention to translate CLNP packets into IP packets). This implies that only "consenting updated systems" will be running TCP over CLNP; which in turn implies that, for purposes of generating the TCP pseudoheader from the CLNP header, backward compatibility with existing systems is not an issue. There are therefore several options available for how to generate the pseudoheader. The pseudoheader could be set to all zeros (implying that the TCP header checksum would only be covering the TCP header). Alternatively, the pseudoheader could be calculated from the CLNP header. For example, the "source address" in the TCP pseudoheader could be replaced with two bytes of zero plus a two byte checksum run on the source NSAP address length and address (and similarly for the destination address); the "protocol" could be replaced by the destination address selector value; and the "TCP Length" could be calculated from the CLNP Callon [Page 5] RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992 packet in the same manner that it is currently calculated from the IP packet. The details of how the pseudoheader is composed is for further study. UDP is transmitted over CLNP in the same manner. In particular, the UDP packet is encapsulated directly inside a CLNP packet. Similarly, the same options are available for the UDP pseudo- header as for the TCP pseudoheader. 5 Updates to the Domain Name Service TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses. This resource record allows mapping from DNS names to NSAP addresses, and will contain entries for systems which are able to run Internet applications, over TCP or UDP, over CLNP. The presence of a "long-address" resource record for mapping a particular DNS name to a particular NSAP address can be used to imply that the associated system is an updated Internet host. This specifically does not imply that the system is capable of running OSI protocols for any other purpose. Also, the NSAP address used for running Internet applications (over TCP or UDP over CLNP) does not need to have any relationship with other NSAP addresses which may be assigned to the same host. For example, a "dual stack" host may be able to run Internet applications over TCP over CLNP, and may also be able to run OSI applications over TP4 over CLNP. Such a host may have a single NSAP address assigned (which is used for both purposes), or may have separate NSAP addresses assigned for the two protocol stacks. The "long-address" resource record, if present, may be assumed to contain the correct NSAP address for running Internet applications over CLNP, but may not be assumed to contain the correct NSAP address for any other purpose. The backward translation (from NSAP address to DNS name) is facilitated by definition of an associated resource record. This resource record is known as "long-in-addr.arpa", and is used in a manner analogous to the existing "in-addr.arpa". Updated Internet hosts, when initiating communication with another host, need to know whether that host has been updated. The host will request the address-class "internet address", entry-type "long-address" from its local DNS server. If the local DNS server has not yet been updated, then the long address resource record will not be available, and an error response will be returned. In this case, the updated hosts must then ask for the regular Internet address. This allows updated hosts to be deployed in environments in which the DNS servers have not yet been updated. An updated DNS server, if asked for the long-address Callon [Page 6] RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992 corresponding to a particular DNS name, does a normal DNS search to obtain the information. If the long-address corresponding to that name is not available, then the updated DNS server will return the resource record type containing the normal 32-bit IP address (if available). This allows more efficient operation between updated hosts and old hosts in an environment in which the DNS servers have been updated. Interactions between DNS servers can be done over either IP or CLNP, in a manner analogous to interactions between hosts. DNS servers currently maintain entries in their databases which allow them to find IP addresses of other DNS servers. These can be updated to include a combination of IP addresses and NSAP addresses of other servers. If an NSAP address is available, then the communication with the other DNS server can use CLNP, otherwise the interaction between DNS servers uses IP. Initially, it is likely that all communication between DNS servers will use IP (as at present). During the migration process, the DNS servers can be updated to communicate with each other using CLNP. 6 Other Technical Details 6.1 When 32-Bit IP Addresses Fail Eventually, the IP address space will become inadequate for global routing and addressing. At this point, the remaining older (not yet updated) IP hosts will not be able to interoperate directly over the global Internet. This time can be postponed by careful allocation of IP addresses and use of "Classless Inter-Domain Routing" (CIDR [3]), and if necessary by encapsulation (either of IP in IP, or IP in CLNP). In addition, the number of hosts affected by this can be minimized by aggressive deployment of updated software based on TUBA. When the IP address space becomes inadequate for global routing and addressing, for purposes of IP addressing the Internet will need to be split into "IP address domains". 32-bit IP addresses will be meaningful only within an address domain, allowing the old IP hosts to continue to be used locally. For communications between domains, there are two possibilities: (i) The user at an old system can use application layer relays (such as mail relays for 822 mail, or by Telnetting to an updated system in order to allow Telnet or FTP to a remote system in another domain); or (ii) Network Address Translation can be used [4]. 6.2 Applications which use IP Addresses Internally There are some application protocols (such as FTP and NFS) which pass around and use IP addresses internally. Migration to a larger address space (whether based on CLNP or other protocol) will require either that these applications be limited to local use (within an "IP address domain" in which 32-bit IP addresses are meaningful) or be updated to either: (i) Use larger network Callon [Page 7] RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992 addresses instead of 32-bit IP addresses; or (ii) Use some other globally-significant identifiers, such as DNS names. 6.3 Updated Hosts in IP-Only Environments There may be some updated Internet hosts which are deployed in networks that do not yet have CLNP service, or where CLNP service is available locally, but not to the global Internet. In these cases, it will be necessary for the updated Internet hosts to know to initially send all Internet traffic (or all non-local traffic) using IP, even when the remote system also has been updated. There are several ways that this can be accomplished, such as: (i) The host could contains a manual configuration parameter controlling whether to always use IP, or to use IP or CLNP depending upon remote address; (ii) The DNS resolver on the host could be "lied to" to believe that all remote requests are supposed to go to some particular server, and that server could intervene and change all remote requests for long-addresses into requests for normal IP addresses. 6.4 Local Network Address Translation Network Address Translation (NAT [4]) has been proposed as a means to allow global communication between hosts which use locally-significant IP addresses. NAT requires that IP addresses be mapped at address domain boundaries, either to globally significant addresses, or to local addresses meaningful in the next address domain along the packet's path. It is possible to define a version of NAT which is "local" to an addressing domain, in the sense that (locally significant) IP packets are mapped to globally significant CLNP packets before exiting a domain, in a manner which is transparent to systems outside of the domain. NAT allows old systems to continue to be used globally without application gateways, at the cost of significant additional complexity and possibly performance costs (associated with translation or encapsulation of network packets at IP address domain boundaries). NAT does not address the problem of applications which pass around and use IP addresses internally. The details of Network Address Translation is outside of the scope of this document. 6.5 Streamlining Operation of CLNP CLNP contains a number of optional and/or variable length fields. For example, CLNP allows addresses to be any integral number of bytes up to 20 bytes in length. It is proposed to "profile" CLNP in order to allow streamlining of router operation. For example, this might involve specifying that all Internet hosts will use an NSAP address of precisely 20 bytes in length, and may specify which optional fields (if any) will be present in all CLNP packets. This can allow all CLNP packets transmitted by Internet Callon [Page 8] RFC 1347 TUBA: A Proposal for Addressing and Routing June 1992 hosts to use a constant header format, in order to speed up header parsing in routers. The details of the Internet CLNP profile is for further study. 7 References [1] "The IAB Routing and Addressing Task Force: Summary Report", work in progress. [2] "Protocol for Providing the Connectionless-Mode Network Service", ISO 8473, 1988. [3] "Supernetting: An Address Assignment and Aggregation Strategy", V.Fuller, T.Li, J.Yu, and K.Varadhan, March 1992. [4] "Extending the IP Internet Through Address Reuse", Paul Tsuchiya, December 1991. 8 Security Considerations Security issues are not discussed in this memo. 9 Author's Address Ross Callon Digital Equipment Corporation 550 King Street, LKG 1-2/A19 Littleton, MA 01460-1289 Phone: 508-486-5009 Email: Callon@bigfut.lkg.dec.com Callon [Page 9] ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0091.txt Zhen Wang -- 12 June 1992 -- B-I --------------------------------- The Extended Internet Protocol (EIP) So far, three proposals have been put forward as the long-term solutions for Internet adressing and routing: Nimrod, Pip and CLNP. All of the them require that the current IP to be replaced by a completely new "IP". However, as I have said in a previous message that IP really is the cornerstone of the current Internet, replacing it with a new "IP" requires fundamental changes to all aspects of the Internet (eg. routing, routers, hosts, ARP, RARP, ICMP, TCP, UDP, DNS, FTP). Migrating to a new "IP" in effect creates a new "Internet". The development and deployment of such a new "Internet" would take a very large amount of time and effort. To ensure interoperability between old and new systems during the transition period, the updated hosts and subnet routers have to run two sets of protocols in parallel. An updated host also has to determine whether the destination host has been updated or not at the beginning of a connection. Here we present a solution called Extended Internet Protocol (EIP). EIP does not propose any new addressing schemes but a framework in which any addressing schemes, such as those proposed in Nimrod, Pip, NSAP, and CityCodes, can be accommodated. The goal of EIP is to maintain maximum backward compatibility with current IP. It can substantially reduce the modifications to current systems and ease the difficulties in transition. EIP has a number of very desirable features: 1) EIP expands the address space, yet maintains maximum backward compatibility with current IP. 2) EIP can accommodate different addressing and routing architec- tures such as fixed or variable length addresses, multi-level addressing, hierarchical routing and policy routing. It cane be used as a vehicle for any new addressing and routing architec- tures. 3) EIP requires minor modification to the host IP software (ie. a new option), to the DNS (ie. a new resource record type), and to FTP (ie. a command). 4) EIP requires no changes to all assigned IP addresses and subnet structures in local are networks. 5) EIP requires no modifications to ARP, RARP, ICMP, TCP/UDP check- sum. In the note, IP refers to the current Internet Protocol and EIP refers to the Extended Internet Protocol (EIP is pronounced as "ape" - a step forward in the evolution:-). The goal of EIP is to provide maximum flexibility to accommodate any new addressing scheme and at the meantime maintain maximum backward compatibility with current IP. EIP can be viewed as an extended version of IP. Before we describe the EIP header format, let us first look at the evolution from IP to EIP. EIP is developed from IP by: 1) Creating a new IP option to hold the Source and Destination Net- work IDs. 2) Treating the current IP Source and Destination Addresses as the Source and Destination Host IDs. 3) Using Host IDs only for communications within the same network. An EIP addresses have two parts: the EIP Host ID and the EIP Network ID. The Network ID identifies a particular network and the Host ID identifies a particular host on the network. The current 32-bit IP address space is used for the Host ID only. A new IP option called "EIP Option" is created to hold the Network ID. Using an option to encode the Network ID is the key idea behind the EIP; it provides a flexible way of accommodating arbitrary addressing schemes while maintaining maximum backward compatibility. Because EIP follows the syntax of IP, the modifications required to current Internet systems are greatly reduced. The semantics of the Network ID encoded in the EIP Option are deter- mined by the addressing scheme used and is not discussed in this paper. Since EIP Option has a variable length, the Network ID can accommodate any addressing schemes. It can be a fixed length node ID, or a fixed length path ID, or a variable length backbone-oriented hierarchical address, or a variable length policy source route, or a routing directive. In fact, it allows multiple addressing schemes co-existence, which may be used for experimenting new addressing schemes in the future. The EIP Option format is illustrated in Figure 1. COPY CLASS NUMBER LENGTH DESCRIPTION ---- ----- ------ ------ ----------- 1 0 10 var EIP EIP Option: Type=138 +--------+--------+--------+--------//---------+----------//------------+ |10001010| length | type | Source Network ID | Destination Network ID | +--------+--------+--------+--------//---------+----------//------------+ Figure 1: EIP Option Format The field "type" specifies the addressing scheme used thus determines how the Network IDs should be interpreted. The fields "Source Net- work ID" and "Destination Network ID" hold the Source Network ID and the Destination Network ID. The EIP packet header consists of the minimal IP header, the EIP Option and other Options. The actual format is shown in Figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Host ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Host ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EIP Option | Other Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: EIP Header Format The EIP header differs from the IP header in only two aspects. First, the EIP header has the EIP Option which always follows the minimal IP header. The "Source Network ID" and the "Destination Net- work ID" fields in the EIP Option are used to identify the source and the destination networks. Second, the "Source Host ID" and "Destina- tion Host ID" fields in the EIP header, which correspond to the "Source Address" and "Destination Address" fields in the IP header, are only used to identify the the source and the destination hosts on the respective networks. Other fields in the EIP headers are identi- cal to the corresponding fields in the IP header. For communications within the same network, there is no need to include the Network IDs in the packet. Therefore, the EIP Option which contains the Source Network ID and the Destination Network ID is included in the packet only when the packet is destined to a remote network. In other words, in EIP, when the Source Network ID and the Destination Network ID are omitted in the packet header, it is assumed, by default, that they are both equal to the local net- work. This is an important feature of EIP which ensures the compati- bility of IP and EIP within one network. When EIP is in place, an IP host si able to communicate with any hosts within the same network without any changes. In fact, IP and EIP have a identical header when they are used within one network. The IP header can be viewed as a special case of the EIP header, ie. when communications take place within one network. A full EIP address consists of a Network ID and a Host. However, Network IDs and Host IDs are always manipulated in separate forms. The clear separation of the Network ID and the Host ID in EIP has its advantages: 1) It maintains full compatibility between IP hosts and EIP hosts for communications within one network. Any IP hosts can communi- cate with any EIP hosts in the same network without any modifi- cations 2) It allows the Network IDs to be manipulated more easily When a backbone-based hierarchical addressing scheme is used, a network may have to change its Network ID when its higher level backbone network has been changed and the hosts have to determine which Network ID should be used when their networks have access to more than one backbone network. Now let us look at the modifications to the IP systems that are needed for transition to EIP. Because of the similarity between the EIP and IP, the amount of modifications needed to current systems are substantially reduced. 1) Network Numbers: Each network has to be assigned a new EIP Network ID based on the addressing scheme used. The mapping between the IP network numbers and the EIP Network IDs can be used for translation service (see below). 2) Host Numbers: There is no need for assigning EIP Host IDs. All existing hosts can use their current IP addresses as their EIP Host IDs. New machines may be allocated any number from the 32-bit Host ID space since the structure posed on IP addressing is no longer necessary. However, during the transition, allocation of EIP Host IDs should still follow the IP addressing rule, so that the EIP Host IDs are still globally unique and can still be interpreted as IP addresses. This will allow a more gradual transition to EIP (see below). 3) Translation Service: During the transition period when the EIP Host IDs are still unique, an address translation service can be pro- vided to IP hosts that need communicate with hosts in other net- works. All IP hosts should use the translation server as their default router to outside world. When the translation server receives a packet, it obtains the Destination Network ID by looking up in the mapping table between IP network numbers and EIP Network IDs. The translation server then adds the EIP option with Source and Destination Network IDs into the packet and forwards to the border router. The translation service only applies to out-going packets from IP hosts. There is no need for translation for any in-coming packets. The border routers may act as the translation servers (see below). 4) Border Routers: The new EIP Option has to be implemented and rout- ing has to be done based on the Network ID in the EIP Option. The border routers may be used to provide the translation service dur- ing the transition period. When a border router receive a packet without EIP Option, it looks up the Destination Network ID from the mapping table between IP network numbers and EIP Network IDs. The border router then adds the EIP Option and forwards the packet. 5) Subnet Routers: No modifications are required during the transition period when EIP Host IDs (which equals to the IP addresses) are still globally unique. A subnet router can still determine, by treating the EIP Host ID as the IP addresses, whether a packet is destined to remote networks or not and forward correctly. However, subnet routers eventually have to implement the EIP Option and carry out routing based on Network IDs when EIP Host IDs are no longer globally unique. 6) Hosts: The new EIP Option has to be implemented and routing has to be done based on the Network ID in the EIP Option, or based on the Host ID and subnet mask if subnetting is used. 7) DNS: A new resource record (RR) type "N" has to be added for EIP Network IDs. The RR type "A", currently used for IP addresses, can still be used for EIP Host IDs. RR type "N" entries have to be added and RR type "PTR" to be updated. All other entries remain unchanged. 8) ARP/RARP: No modifications are required. The ARP and RARP are used for mapping between EIP Host IDs and physical addresses. 9) ICMP: No modifications are required. 10) TCP/UDP Checksum: No modifications are required. The pseudo header includes the EIP Source and Destination IDs instead of the source and destination IP addresses. 11) FTP: The "DATA Port (Port)" command has to pass both the EIP Net- work and Host IDs. This command, which specifies a data port other than the default one, is not needed under normal circumstances thus it may be possible to disable this command. ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0092.txt IESG Chair -- 17 June 1992 -- B-I ---------------------------------- Internet-Draft Phill Gross June 1992 IESG Chair IESG Deliberations on Routing and Addressing CONTENTS 1. ABSTRACT 2. ACKNOWLEDGEMENTS 3. BACKGROUND 3.1 The IAB Architecture Retreat 3.2 The Santa Fe IETF 3.3 The ROAD Group 3.4 The San Diego IETF 4. SETTING DIRECTIONS FOR THE IAB/IETF 4.1 Course of Action for CIDR 4.2 Regarding "Bigger Internet Addresses" 4.3 Information and Criteria For "Bigger Internet Addresses" 4.4 Milestones And Timetable For Making a Recommendation for "Bigger Internet Addresses" 5. SUMMARY 6. FOR MORE INFORMATION 7. BIBLIOGRAPHY 1. ABSTRACT This note gives preliminary results from IESG deliberations on Internet routing and addressing issues. It provides a brief background of the ROAD group and related activities in the IETF. It also provides a preliminary report on how the IESG will recommend various routing and addressing issues be pursued in the IAB/IETF. A more complete IESG report and set of recommendations is in preparation. 2. 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. In particular, this preliminary note draws heavily from the fuller IESG report (in preparation, Philip Almquist Editor), which will serve as a recommendation to the IAB. Bob Hinden supplied the original text for the "Criteria For Bigger Internet Addresses" section below. I used an annotated bibliography prepared by Lyman Chapin as the basis for the bibliography in this note. 3. BACKGROUND 3.1 The IAB Architecture Retreat In July 1991, the IAB held a special workshop to consider critical issues in the IP architecture. Of particular concern were problems related to 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. 3.2 The Santa Fe IETF At the November 1991 Santa Fe IETF meeting, the BGP WG began a concerted exploration of the issues of route aggregation using address masks in BGP. The BGP WG decided to form a separate subgroup to pursue solutions. 3.3 The ROAD Group At the Santa Fe IETF, the initially separate IAB and IETF activities were combined into a special effort, the "Routing and Addressing (ROAD) Group", to look at the key IP issues of scaling in routing and addressing. In brief, the issues involved: - Class B address exhaustion - Routing table explosion - IP address space exhaustion The ROAD group was instructed to report back to the IETF at the San Diego (March 1992). The specific guidelines included minimizing changes to hosts, must be incrementally deployable, and must provide support for 10^^9 networks. The ROAD group was not a traditional open IETF working group. It was always presumed that this one-time special group 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 (including several times at the Santa Fe IETF meeting, December 1991 in Reston Va, January 1992 in Boston, and January 1992 in Arizona). There was also much discussion by electronic mail. The group produced numerous documents, which will be made available as Internet-Drafts or RFCs (see Bibliography below. These documents are currently available by anonymous FTP from gated.cornell.edu in directory pub/road.). 3.4 The San Diego IETF As follow-up, the ROAD co-chairs (Peter Ford/LANL and Phill Gross/ANS) 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, pending a more complete report still in preparation (Brim92). 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 explosion). Classless Inter-Domain Routing (CIDR; also called "supernetting") was recommended. CIDR calls for: - 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. These included "Simple CLNP" (Callon92a), "IP Encaps" (Hinden92), "CNAT" (Callon92b), and "Nimrod" (Chiappa91). 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 features. Other ROAD-related activities at the San Diego IETF meeting included: - Monday, 8:00 - 9:00 am, Presentation by Peter Ford and Phill Gross, "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 (by Phill Gross), 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 IAB/IETF 4.1 Course of Action for CIDR The IESG accepted ROAD's endorsement of CIDR. The IESG felt that other alternatives (eg, C#, see Solen92) not did provide both aggregation and Class B conservation at comparable effort. The IESG recommends the following course of action to pursue CIDR in the IETF: a. Publish the CIDR overview and guidance document (Fuller92) b. Hold a BOF at the Boston IETF meeting in July 1992 (and, if necessary, form a followup WG) to 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). Stockman will lead a BOF at the July IETF. This BOF will factor in discussions and proposals at prior RIPE and IEPG meetings. A specific proposal (Rekhter92) has now become the focus of this effort. c. Pursue CIDR extensions to BGP in the BGP WG This activity has already begun at the San Diego IETF meeting. A document has been distributed on the BGP WG mailing list, and should be released as an Internet-Draft prior to the Boston IETF meeting. d. Form a new WG to consider CIDR-related extensions to IDRP (eg, specify how run IDRP for IP inter-domain routing) A proposal for this WG has already been submitted to the IESG. The IESG expects this WG to be able to hold its first meeting at the Boston IETF. 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. Some of these issues will be considered in the WGs already mentioned. However, depending on the outcome of the combined CIDR activities at the Boston IETF, the IESG may recommend forming a "CIDR Deployment WG", along the same lines as the current BGP Deployment WG. 4.2 Regarding "Bigger Internet Addresses" The IESG reviewed the various approaches described by the ROAD group -- e.g., "Simple CLNP" (Callon92a), "IP Encaps" (Hinden92), "CNAT" (Callon92b), and "Nimrod" (Chiappa91). The "Simple CLNP" approach has potential advantages and perhaps 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 at this time. The feeling in the IESG was that such important issues as - impact on operational infrastructure, - deployment of new routing protocols, - assignment of new addresses, - effect of supporting new protocols, such as for addres 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 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, but they would feel much more comfortable if more detailed information was part of the decision. Then, after exploring Simple CLNP in more depth, an attempt to develop a better understanding, the IESG became concerned that the significant changes required in hosts would make the transition complex, not "simple". For example, an ostensibly simple transition scheme has been proposed for Simple CLNP -- install dual stacks in all new hosts and eventualy decommision the IP stack. But the IESG was concerned that this lack of support for the very large installed base of older unconverted IP hosts might lead to partitioning the Internet into 2 classes -- the newer CLNP-only hosts and older IP-only hosts. Given this limited understanding of the potential complexity, the IESG felt that additional information was needed about Simple CLNP. During the period to gather more information about Simple CLNP, we felt that we have everything to gain by also exploring other alternatives than might, in fact, turn out to be simpler or longer lasting. We need to evaluate any proposed new routing and addressing architecture to insure that there is a thorough understanding of the impact to changing from the current IP architecture to a new one. We need to be confident that we understand which approach has the most benefits for long term internet growth and the least impact on the current Internet. The IESG considered what additional information and criteria was 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 course of action for choosing the approach for bigger Internet addresses by the November IETF meeting. The next section describes the selection criteria, and the following section describes the milestones and timetable for making an IESG recommendation at the November 1992 IETF. 4.3 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. 4.3.1 Description of 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. 4.3.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: - Host Changes - Exterior Router Changes - Interior Router Changes - Domain Name System Changes - Network Management Changes - Operations Tools Changes 4.3.4 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. The performance evaluation for routers and hosts should include packets-per-second and memory usage projections, and bandwidth usage for networks. Performance 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^^9 10^^10 4.3.5 Large Internet Support The proposal should describe how it will scale to support a large internet of 10^^9 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 and who owns the addresses (e.g. user or service provider). 4.3.6 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. 4.3.7 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. A schedule should be included, with justification showing that the schedule is realistic. 4.4 Milestones And Timetable For Making a Recommendation for "Bigger Internet Addresses" The IESG recommends that a call for proposals be made, with initial activities to begin at the July IETF and with a very strict timetable for reaching a recommendation coming out of the November IETF meeting. A working group will be formed for each proposed approach. The charter of each WG will be to explore the criteria described in section 4.3 and develop a detailed plan for IESG consideration. The WGs will have their first meeting at the July 1992 IETF meeting in Boston. The WGs will be asked to submit an Internet-Draft prior to the November 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 by December 1992. Therefore, the firm milestones and timetable for the IESG to reach a recommendation on bigger Internet addresses are: June 1992 -- Issue a call for proposals to form working groups to explore separate approaches for bigger Internet addresses. Distribute the "selection criteria" for public review. July 1992 -- Convene proposed WGs at the Boston IETF meeting. The "selection criteria" will be discussed publicly, and modified as appropriate. July-November 1992 -- WGs continue deliberations by email and/or face- face meetings. October 1992 -- Each WG will be required to submit a written description of the approach and how the criteria are satisfied. These documents must be distributed as Internet-Drafts for public review 30 days prior to the November IETF meeting to be considered. November 1992 -- Each WG will be given an opportunity to present its findings in detail at the November 1992 IETF meeting. December 1992 -- 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. 5. SUMMARY The problems of Internet scaling and address exhaustion are fundamentally important to the continued health of the 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 the depth of information described in section 4.3 before a decision is made. Pending the outcome of further discussion of this note (eg, in the IESG, the big-internet list, and in the IAB), the IESG will move CIDR forward as described in section 4.1, and will issue a call for proposals for a bigger Internet address space with the intent to begin immediately implementing the timetable in section 4.4. 6. 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 (the ROAD group documents will soon be issued as Internet-Drafts or RFCs). - Join the Big-Internet mailing list (big-internet-request@munnari.oz.au), where the general issues have been, and will continue to be, discussed. - Each separate new WG formed will have an open mailing list. Please feel free to join each as they are announced on the IETF mailing list. - Attend the July IETF in Boston (where the WGs will first meet) and the November IETF in Washington DC (where the WGs will report and the IESG recommendation will be formulated). 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 mailing list (ietf-request@isi.edu). 7. BIBLIOGRAPHY -Documents and Information from IETF/IESG: [Ford92] "Routing And Addressing Considerations", Peter Ford and Phill Gross, Proceedings of the Twenty-Third IETF, March 1992. [Gross92] Chair's Message and Minutes of the Open IETF Plenary, Phill Gross, Proceedings of the Twenty-Third IETF, March 1992. [Almq92] "IESG Recommendations on Routing and Addressing", IESG (Philip Almquist editor), in preparation, (current draft May 3, 1992) -Documents directly resulting from the ROAD group [Fuller92] "Supernetting: an Address Assignment and Aggregation Strategy", Vince Fuller, Tony Li, Jessica Yu, and Kannan Varadhan (March 9, 1992). [Hinden92] "New Scheme for Internet Routing and Addressing (ENCAPS)", Bob Hinden (March 16, 1992). [Callon92a] "A Simple CLNP-based Proposal for Internet Addressing and Routing", Ross Callon (April 2, 1992). [Deering92] "City Codes: An Alternative Scheme for OSI NSAP Allocation in the Internet", Steve Deering (January 7, 1992). [Brim92] "Summary Report from the Routing and Addressing (ROAD) Group", Scott Brim (Editor), preliminary draft (April 3, 1992) [Callon92b] CNAT -Related Documents [Stockman92] "A Proposal for a Global Internet Addressing Scheme", Daniel Karrenberg and Bernhard Stockman, Internet-Draft (May 28, 1992). [Rekhter92] "Guidelines for IP Address Allocation", Y. Rekhter and T. Li, Internet-Draft (May 1992). [Solen92] "A Revision to IP Address Classifications", F. Solensky and F. Kastenholz (March 1992). [Wang92] "A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion", Z. Wang and J. Crowcroft, RFC 1335 (May 1992). [Callon91] "Guidelines for OSI NSAP Allocation in the Internet", Ross Callon, Ella Gardner, and Richard Colella, RFC 1237 (July 1991). [Tsuchiya92a] NAT, Internet-Draft [Tsuchiya92b] "The P Internet Protocol (PIP)", Internet-Draft. [Chiappa91] "NIMROD", Internet-Draft ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0020.txt J. Noel Chiappa -- 18 Jun 1992 ------------------------------ An Introduction To NAT J. Noel Chiappa NAT (network address translator) refers to a class of schemes for solving 2 of the three problems of Internet routing and addressing, as laid out in [Chiappa90]. The two in question are the exhaustion of class B IP network numbers, and the eventual exhaustion of the IP 32-bit address space itself. In considering NAT, it is necessary to bear in mind that when the second happens, there are only two possible solutions: switch to a larger addresses, which means a different packet format (which might be CLNP), or make the addresses non-globally unique, which is NAT. This note contains a general discussion of NAT, and an etymology of potential NAT variants. There are many, many different variations on the NAT idea. The common theme in all of them is that the each packet no longer contains, throughout the lifetime of the packet, a single, globally unique, network address. In other words, the IP address in the packet is no longer globally unique, but has to be interpreted in some local context. The general idea is that the IP address space is partitioned into a "local" and "global" portions, the meaning of addresses within each being local to any given AS. In any given AS, physical networks and hosts inside the AS are assigned addresses from the local portion in the existing way, and existing IGP's route traffic among them. Hosts outside the AS which need to communicate with hosts inside the AS are temporarily assigned addresses within the global portion on a demand basis. Border routers on the boundary of each AS must contain mapping tables which translate from the address assignments in one AS to those in the neighbouring addresses; these translations must be made not only on addresses in packet headers, but in addresses carried as data in packets (a moderately long list of cases). The mechanism whereby these mapping tables get created is not discussed here, but usually involves wire-tapping DNS transactions and modifying the contents. However, all this low level mechanism is far from a complete solution to the problem, and must be accompanied by yet more mechanism at a higher level, as pointed out in [Chiappa90]. Given a system consisting of a large number of AS's, there must still be some way to pass around information as to the topological relationship of these AS's, and to make choices as to how to route traffic through the mesh of AS's. This system is what we call routing. Large routing systems generally need structured names for the places where hosts can be attached to the network; we call these names addresses. They need the names for obvious reasons; it's hard to get traffic to a place if you don't have some way of indicating which place you want the traffic to go to. The structure is necessary to make the job of routing easier in a large network. [Chiappa91] Thus, it is clear that a large scale routing and addressing system must exist above the NAT boxes in order to make them actually useful in a large system. Many of the different variations in the basic NAT idea come from the different routing and addressing systems that people 'mix in' to come up with a workable overall system. There are several axes along which NAT schemes can be divided. In one, what is important is whether the addresses are local only in the end-AS's (i.e. where the hosts are), or in all AS's, including transit. Divided this way, there are two main classes of NAT schemes. In the first, the packets contain a locally significant address only in the end-AS, and contains (somewhere in the packet) a globally significant one elsewhere (i.e. in the backbones). In the second, none of the addresses in the packet is globally unique, but only local to each AS (even where the packet only transits three, a source, long-haul and destination). I call these the "end-map" and "hop-map" variations. Some schemes could be deployed in either variant, and are called "all-map". From the security aspect, end-map is preferable, since for all of its lifetime outside the source AS, the packet contains a globally unique ID, which security mechansims will find extremely useful. Another important dividing line is whether what the 32-bit address in the end-AS's is mapped into in transit AS's is the same size or not. The importance here is obvious; if it is the same length, all addresses in the packet, including those carried as data, can be modified in situ; if the length is different, a more complex scheme is needed. Systems which map straight across from 32 bits to 32 bits I will call "flat-map", systems which map into a larger space are called "large-map", and systems which can use either scheme are called "vari-map". An apparent advantage of doing large-map is that it removes the 32-bit limit on the maximum number of destinations that can be simultaneously active in a transit AS. Realize, however, that if the mappings operate on source-destination pairs, instead of source and destination separately, then this effectively increases the address space to 64 bits [actually, the size is (64 - log2(average_number_destinations_active_per_source))], removing the 32-bit limit. However, large-map is almost certainly required for end-map variants, since 32-bit addresses will soon be non-globally unique, and global dynamic allocation of 64-bit pairs is probably infeasible. For hop-map, flat-map is easier, particularly since the 64-bit pair system would make large transit nets feasible, albeit probably at the cost of making aggregation more difficult. The following is a brief survey of all the variants I have been able to think up, broken down into the three classes mentioned in the first classification scheme; i.e. end-map, hop-map, and all-map. Some include the routing and high level addressing architecture which would go with them, others do not. Those which do not would obviously need one. Note also that these are simply general classifications; many contain sub-variations, usually of flat-map and large-map. Time does not permit exploring the subvariants in detail at this point. End-Map Variants E-NAT: Class E addresses are introduced, and assigned to various networks in the system. Clearly, within AS's which contain these numbers, the hosts have to be able to deal with them. In other AS's, however, these class E addresses may prove a problem to some hosts; a NAT box could translate them into a range of acceptable addresses within the existing A, B or C space. The overall routing and addressing uses the existing system. A-NAT: Very similar to the one above, but the new address type introduced is the A# variant. This variant is probably not useful, since all hosts can already deal with A# addresses, and only old internal routers, a negligible population, would benefit. M-NAT: Another similar variant, where the overall routing system is modified to use either arbitrary masks, or kempei addresses, or any system where the allocation of addresses does not conform to the existing A, B and C classes. S-NAT: In this variant, introduced by Paul Tsuchiya, each local AS boundary router attached to the backbone is assigned a static piece of the global part of the address space, and inbound addresses for traffic to this end-AS uses addresses in that reserved space. C-NAT: This is one possible way CLNP might be deployed. There is a clear deployment path for CLNP with straight mapping between IP addresses and CLNP addresses, but when the IP address space is used up this variant would map from locally assigned IP addresses to globally unique CLNP addresses. I-NAT: This variant would use the Open Routing routing protocol to route among AS's; the high level addressing structure would simply be AS number, and the high level address scheme would simply be the local IP address extended by the AS number. Hop-Map Variants L-NAT: In this variant, introduced by Van Jacobsen, the global unique identifier is the domain name. Since this identifier is not a topological address, suitable for routing, perhaps another address might also be defined which takes over this role. As the packet passes from AS to AS, the bottom bits of the asssigned address in the destination AS remain the same, allowing aggregation of translations, reducing the potential for 'hot-spots' in 32-bit translation tables. All-Map Variants N-NAT: This version was postulated in [Chiappa91]. The existing IP address field explicitly becomes a host identifier, and an entirely new routing and addressing system is deployed. When the 32-bit identifier space is used up, NAT translations are used to make the 32-bit identifiers local. There are two sub-variants; one flat-map and one large-map. In the flat-map variant, the mapping would probably be be from end-end, as opposed to hop by hop, and in the middle the packet would be identified by a mapping from the source-destination pair to a flow. In the large-map variant, the local 32-bit identifer would map into a larger (perhaps 64-bit) B-NAT: This is very similar to the system above, except instead of using Nimrod for the routing system, BGP (or ISO descendant thereof) is used. An extended address format would have to be defined. U-NAT: Again, very similar to the system above, except instead of using Nimrod for the routing system, the Unified Routing scheme of Estrin, et al would be used. As that document defines no extended address, an extended address format would have to be defined. ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0094.txt Dave Crocker -- 25 June 1992 -- B-I ----------------------------------- IP Address Encapsulation Folks, Bob Hinden and I have been working with a few others to develop a proposal to support larger IP addresses while protecting the installed base of systems, software, training, etc., as much as possible. We had planned to develop a complete first-draft specification before subjecting it to general community review, but the metabolic rate of community discussion and pressure has increased too quickly. As a consequence, we've just submitted a draft of a preliminary proposal to the Internet Drafts directory. It should be accessible tomorrow. We feel that the proposal document contains the essential meat of the specification, although we all understand that it is the details that make a specification succeed or fail. We hope to release a version of the full specification in less than 2 weeks. To whet your appetites, I am including the Summary section of the proposal document. The full document is about 20 pages: draft-crocker-ip-encaps-00.txt. SUMMARY The Internet currently is seeking a means of providing for long-term growth by increasing the amount of address space that is available for hosts and by decreasing the amount of table storage that is required for routers. One solution to these problems is a direct upgrade to a new version of IP. Another is to switch to use of a new protocol such as CLNP which has provisions for a larger and more hierarchical address space. Both require very substantial disruption to the IP installed base. This proposal describes an alternative which minimizes overall disruption and, in fact, entirely eliminates a significant portion of it. A current IP addresss is defined to be used within its own 32-bit IP address space. This proposal labels such a space an _IP Addressing Commonwealth_. The proposed extension specifies a means of connecting such environments by using additional addressing bits, while retaining current usage of the original 32-bit format. The basic proposal is to define the addressing enhancements to IP so that they are carried as IP data and therefore are invisible to all current IP hosts and routers, except those that have been modified to understand the new format. Hence only participating end system hosts and special routers at the borders of Addressing Commonwealths need to understand the new formats. This scheme is called _IP Address Encapsulation_ (_IPAE_). Key benefits of this proposal are: Routers interior to Addressing Commonwealths _never_ need to be modified. Hosts do not have to change their 32-bit IP address _ever_. Hosts which communicate only within their local addressing commonwealth will require no changing _ever_. _All_ IP-related functionality, such as multicasting, is retained without modification. _All_ of the Internet's investment in staff training, including procedures, formats and terminology is retained. Changes to support IPAE only require acquisition of small amounts of additional procedures, formats and terminology. _All_ operational support software will continue to function within a commonwealth. The current routing table size problems and routing computation problems are alleviated as soon as the first transition step is deployed. Hosts are not required to support IPAE directly until the Internet is closer to running out of IP addresses, and then only for hosts wishing full Internet connectivity. That is, existing hosts will be supported without any changes for a long time. This document is in the form of a summary of a preliminary specification and represents work-in-progress to describe the new protocols and the changes needed to effect a transition to the new addressing and routing scheme. This version of the proposal is intended to provide detail about goals and framework, with enough specification to make the basis of the proposal concrete. However, most of the formal specification that ultimately will be required is left for a later version. ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0001.txt Lyman Chapin: Wed, 1 Jul 1992 ====================== B-I == A summary of the IAB's proposals in response to the work of the ROAD group During its meeting in Kobe, Japan on June 18 and 19, the IAB reviewed the draft report of the ROAD group concerning the problems of "running out of IP network numbers" and "Internet routing table size explosion", and a companion report from the IESG of "IESG Deliberations on Routing and Addressing". The IAB's analysis of the many possibilities suggested by these two reports led it to the following conclusions, which are docu- mented in an internet-draft entitled "IP Version 7": 1) The ROAD group's work, compiled over a period of four months, makes it very clear that the problems of too few IP addresses and too many Internet routes are real and immediate, and represent a clear and present danger to the future successful growth of the worldwide Internet. The IAB was therefore unable to agree with the IESG recommendation to pursue an additional six-month program of further analysis before deciding on a plan for dealing with the ROAD problems. The detailed design, engineering, and deployment work must begin now, and it is therefore imperative that the efforts of the Internet community be focussed on a common goal. 2) The IETF should aggresively pursue the work to engineer CIDR ("classless inter-domain routing", described in RFC 1338), including the extensions to the inter-AD routing protocols to support variable-length masks/prefixes, and the associated address administration paradigm. 3) Since CIDR postpones, but does not prevent, the eventual exhaustion of the 32-bit IP address space, the IETF should also aggressively pursue a detailed technical and organizational plan for using CLNP (the OSI internetwork protocol defined by the ISO 8473 standard, which uses 160-bit addresses) as the basis for a new version of IP (which we have dubbed "IP version 7"), succeeding over time the current version of IP (version 4) in the Internet. An initial description of how CLNP could be used for this purpose within the current TCP/IP architecture and with the existing Internet applications is described in RFC 1347. 4) CLNP has larger addresses than IP, but like IP it lacks features that are expected to be necessary to support future Internet appli- cations and services. The IAB therefore also encourages the pursuit of research in areas such as policy-based routing, route preallocation and cacheing, and deterministic end-to-end QOS mainten- ance (for real-time and other delay-variance sensitive traffic). It is important to understand that (3) above does NOT mean "adopting OSI" or "migrating to OSI" or "converting the Internet to use GOSIP protocols". The IAB recommends only that a new version of IP (IPv7), with much wider addresses and a more extensible header, be based on the existing CLNP. IPv7 is intended to be deployed within the current Internet TCP/IP architecture, not as part of an "OSI stack". There are, of course, many issues that must be resolved before CIDR and IPv7 can actually be deployed in the operational Internet. No one should imagine that there is not still a great deal of work to be done, notwith- standing the efforts that have already been expended by several of the IETF working groups and by the members of the ROAD group over the past year. In recommending that the ROAD problems be addressed by a combination of CIDR, IPv7, and further research, the IAB has deliberately chosen NOT to recommend any of the possible alternatives, so as to present a single focal point for the community consisting of what we believe to be the best technical solutions to the problems. This should not be construed as a blanket "condemnation" of the alternative proposals that have been floated in various parts of the IETF. However, we believe that the normal IETF process of "let a thousand [proposals] bloom", in which the "right choice" emerges gradually and naturally from a dialectic of deployment and experimentation, would in this case expose the community to too great a risk that the Internet will drown in its own explosive success before the process had run its course. The IAB does not take this step lightly, nor without regard for the Internet traditions that are unavoidably offended by it. We look forward to a lively discussion of these conclusions during the upcoming IETF meeting in Boston. - Lyman Chapin IAB chair ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0003.txt Steve Deering -- Tue, 22 Sep 1992 -- B-I ========================================= SIP I'd like to offer another candidate for IPv7. It's called SIP (Simple Internet Protocol), or CLNPv2 :-). One philosophy behind SIP is that the IP model of globally-unique addresses, hierarchically-structured for efficient routing, is fundamentally sound. IP addressing and routing works fine, but the addresses aren't quite long enough and not quite hierarchical enough to scale the Internet up to, say, thousands of internet-addressable devices in every office, every residence, and every vehicle in the world. SIP addresses are 64 bits long, and are sufficient for an internet that big. Another philosophy behind SIP is the RISC philosophy: the SIP header is much simpler than the IP header (not to mention the CLNP header or the Pip header), to facilitate high-performance implementation and to increase the likelihood of correct implementation. Here are some excerpts from the draft SIP specification (currently under construction), that describe the basic features of SIP. Information on how to fetch the current draft are given at the end of this message. ------------------------------------------------------------------------ SIP Header Format ----------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Payload Type | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hop Limit 8-bit unsigned integer. Decremented by 1 by each system that forwards the packet. Packet is discarded if Hop Limit is decremented to zero. Payload Type 8-bit selector. Identifies the type of payload, e.g., TCP. Payload Length 16-bit unsigned integer. Length of payload, i.e., the data following the SIP header, in octets. Source Address & 64 bits each. See "SIP Addressing" section. Destination Address Notes: - The SIP header is the same size (20 octets) as the IPv4 header without options. - There are no SIP options. Additional information that must be conveyed to routers in special cases, such as security label information, may be inserted between the SIP header and the next-higher-layer header (e.g., TCP), using a distinguished Payload Type value to indicate the presence of the additional information. (As part of the additional information, there must be included another Payload Type field, to identify the next-higher-layer protocol. See the "Source Routing Protocol" section, below, for an example.) - Still undecided: whether or not an additional 32-bit field should be added to the SIP header to achieve 64-bit alignment (as it is, the two address fields can be 64-bit aligned by making sure the packet starts at an odd-word address, where word = 32 bits). The extra 32 bits, if added, would be used for classifying packets deserving of special handling, e.g., non-default quality of service or real-time service. On the other hand, the transport-layer port fields may be adequate for performing any such classification. (One possibility would be simply to remove the port fields from TCP & UDP and put them in the SIP header, like XNS.) Packet Size Issues ------------------ SIP requires that every link in the internet have an MTU of 500 octets or more. On any link that cannot convey a 500-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below SIP. From each link to which a system is directly attached, the system must be able to accept packets as large as that link's MTU. SIP systems are expected to implement Path MTU Discovery [RFC-1191], in order to discover and take advantage of paths with MTU greater than 500 octets. However, a minimal SIP implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 500 octets, and omit implementation of Path MTU Discovery. Path MTU Discovery requires support both in the SIP layer and in the packetization layers. A system that supports Path MTU Discovery at the SIP layer may serve packetization layers that are unable to adapt to changes of the path MTU. Such packetization layers must limit themselves to sending packets no longer than 500 octets, even when sending to destinations that are on the same subnet. (Note: Those parts of the RFC-1191 procedures that involve use of a table of MTU "plateaus" do not apply to SIP, because the SIP version of the "Datagram Too Big" message always identifies the exact MTU to be used.) SIP Addressing -------------- SIP addresses are 64 bits (8 octets) long. The notation for writing SIP addresses is 16 hexadecimal digits, with a dot after the 4th digit and optional dots after any subsequent digit. Examples: 1234.56789ABCDEF0 1234.56789ABC.DEF0 1234.567.89AB.CDE.F0 There are two classes of address: unicast and multicast. Multicast addresses are identified as such by hex FF in the high-order octet; unicast addresses have values other than hex FF in the high-order octet. Unicast Addresses Unicast addresses are globally unique within a SIP internet, i.e., no two interfaces have the same address. A single interface may have multiple unicast addresses. With each of a system's unicast addresses, the system associates a "subnet mask" that indicates which part of the address is the subnet prefix (those bits with a 1 in the corresponding position in the mask) and which part is the interface identifier within the subnet (those bits with 0 in the corresponding position in the mask). Hosts are ignorant of any further structure in the address. Routers may be aware of shorter prefixes of an address that identify higher-level clusters in the hierarchical addressing plan; that knowledge is in the form of additional masks (with fewer 1 bits), rather than any "wired-in" knowledge of what bit boundaries are significant in the addressing hierarchy. Within any hierarchical component of a unicast address, the value zero is reserved to mean "unspecified". This specification does not further constrain the structure of unicast addresses. Appendix A suggests one possible structure. SIP Source Routing Protocol --------------------------- A Payload Type of 3 in a SIP header indicates the presence of this Source Routing header, immediately following the SIP header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Payload Type | Num Addrs | Next Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Address[1] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Address[2] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Address[Num Addrs] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that this header is not examined until the packet reaches the system identified in the SIP Destination Address field (unlike the IP source route options). The 32-bit Reserved field is present to make the source route addresses have the same 64-bit alignment as the addresses in the SIP header. loose source routing only -- can't enforce strict source routing if subnets are allowed to transparently span multiple links. description to be done Design Rationale ---------------- ... Fields present in IPv4, but absent in SIP: Version Not needed; SIP identified by new link-layer type code. Header Length Not needed; SIP header length is fixed (no options). Precedence & Type of Service Not used; transport-layer Port fields (or perhaps an additional to-be-defined 32-bit field in the SIP header) may be used for classifying packets at a granularity finer than host-to-host, as required for special handling. Identification, Flags, and Fragment Offset Not needed; SIP does not do fragmentation. Time to Live SIP uses Hop Limit instead, to provide protection from routing loops. Transport protocols are expected to provide their own protection against long-lived packets. Header Checksum Not used; transport pseudo-header checksum protects destinations from accepting corrupted packets. ... Transport and Upper-Layer Issues -------------------------------- - bigger addresses - must include the basic SIP header, excluding Hop Limit, in transport-layer checksums - if a source routing header is present, the originating transport layer must use last address in source route, rather than SIP destination address, in its checksum - UDP checksum is no longer optional - transport must do own enforcement of max packet lifetime (or rather, recognize and tolerate very old packets) - must do path-MTU discovery, and be capable of adapting outgoing packet size in response to changes of PMTU (or always send packets <= 500 octets) - change of ICMP error report format - no TOS, Ident, or options to be passed across IP service interface - need new SIP+TCP header compression algorithm - DNS changes: new address type - need a SIP MIB Appendix A - Suggested Unicast Address Structure ------------------------------------------------ The following two hierarchical formats are suggested for SIP unicast addresses: (1) metro-based addresses +-------+-------+-------+-------+-------+-------+-------+-------+ | country + | site ID | intra-site | | metro ID | | part | +-------+-------+-------+-------+-------+-------+-------+-------+ 2 octets 4 octets 2 octets country + Identifies a metropolitan area. Internally metro ID structured into a country part and a metro part, with a varying boundary between those two parts. (Each country gets a power-of-two sized and aligned block of metro IDs, sufficient for the projected number of metro areas in that country.) site ID Flat identifier of a site within or near a metro area, where a "site" may be, for example, a corporate or government site, a campus, or household. A site ID "belongs" to the administrators of a particular site, rather than to a particular SIP service provider, so that it does not change if the site changes its provider, as long as the change is within the same metro area. intra-site part Identifies an interface within a site. Internally structured into a subnet ID and an interface ID, with a varying boundary between those two parts. (Each subnet gets a power-of-two sized and aligned block of interface IDs, sufficient for the projected number of interfaces in that subnet.) Large sites may obtain multiple site IDs, if needed. The subnet mask for a metro-based address has 1 bits covering all positions from the high-order bit of the country ID to the low-order bit of the subnet ID within the intra-site part. The details and consequences of metro-based addressing and routing are described in a separate document. (2) provider-based addresses +-------+-------+-------+-------+-------+-------+-------+-------+ | country + | subscriber ID intra-subscriber | | provider ID | part | +-------+-------+-------+-------+-------+-------+-------+-------+ 2 octets 6 octets country + Identifies a SIP service provider. Internally provider ID structured into a country part and a provider part, with a varying boundary between the two parts. (Each country gets a power-of-two sized and aligned block of provider IDs, sufficient for the projected number of providers in that country.) Trans-national providers obtain a separate provider ID in each country that they serve. subscriber ID Identifies a subscriber of a particular provider. Internally hierarchically structured for efficient routing within the provider's facilities. intra-subscriber Identifies an interface within a subscriber's part facilities. Internally hierarchically structured for efficient routing within the subscriber's facilities. The last two components of the intra-subscriber part are a subnet ID and an interface ID, with a varying boundary between those two parts. (Each subnet gets a power-of-two sized and aligned block of interface IDs, sufficient for the projected number of interfaces in that subnet.) The boundary between the subscriber ID and the intra-subscriber part is a private matter between the provider and the subscriber. The subnet mask for a provider-based address has 1 bits covering all positions from the high-order bit of the country part to the low-order bit of the subnet ID within the intra-subscriber part. Both country + metro IDs and country + provider IDs are assigned from the same 16-bit space, so that both metro-based and provider-based addressing may be supported in the same internet. ------------------------------------------------------------------------ (end of excerpts) The current draft-in-progress may be fetched by anonymous FTP from host parcftp.xerox.com, file pub/net-research/sip-spec. It includes information on: - the format of SIP multicast addresses. - changes required to ICMP and IGMP for SIP. - a scheme for tunneling (encapsulation) in SIP, which is intended to support delivery to mobile hosts and to re-homed domains, among other purposes. Since encapsulation increases the size of a SIP packet, possibly exceeding the path MTU, the tunneling protocol includes a simple fragmentation and reassembly capability. (Be warned that the document does not yet have page numbers, pretty formatting, or much in the way of explanation/justification of the design choices.) Regarding transition from IPv4 to SIP, the technical issues are basically the same as transitioning to CLNP, as described in the TUBA document (RFC-1347). Thus, if the costs of the TUBA approach (adding a new internet layer in parallel with IP on all hosts and routers) does not rule out CLNP as a candidate for IPv7, nor should it rule out SIP. I believe that SIP occupies a significantly different point in the solution space than IPAE, CLNP, PIP, or NAT. (It is somewhat similar to the proposal by R. Ullmann, published as draft-ullmann-ipv7-00.txt in the internet-drafts repositories. For some reason, that proposal has not seen much, if any, discussion on this list.) I would very much appreciate your comments on SIP. Steve Deering ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0089.txt IMR -- March 1993 -- http://www.isi.edu/in-notes/imr/imr9303.txt ---------------------------------------------------------------- THE NEW WORLD ORDER The November 1992 IETF meeting adopted the outline of a new organizational structure for the IAB/IETF, to accomodate continued growth and new consituencies. This outline was documented in RFC- 1396 ["The Process for Organization of Internet Standards Working Group (POISED)", S. Crocker, RFC-1396, January 1993]. The Board of Trustees of the Internet Society accepted the revisions in December 1992, and transition to the new plan began. One of the key effects of this change (known colloquially as the "New World Order" or NWO) is to install a nominations process to select new IAB and IESG members. IAB and IESG members will serve 2 year terms, with half of the positions on each board subject to re-selection each year. The Internet Society Board of Trustees will review and ratify the new IAB nominations, and the IAB will review and ratify the new IESG nominations. Following the November IETF meeting, a Nomination Committee was selected by a random drawing from volunteering IETF attendees. Jeff Case served as the chair. Roughly half of the existing members of the IAB and IESG put their positions up for renomination; the other half will continue to serve with a remaining term of one year. At the Thursday evening open plenary session of the IETF meeting in Columbus Ohio, the Nomination Committee reported its results. The "old" IAB was able to caucus in person and by telephone, and approved the new IESG nominations. The ISOC Board of Trustees was able to approve the new IAB members via email. Hence, the NWO is now fully in effect. ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0004.txt Christian Huitema, Steve Deering, Bob Hinden, Dave Crocker: Fri, 4 Jun 1993 ==================================================================== B-I == SIP & IPAE groups to merge and shuffle chairs With Christian Huitema's election as IAB chair and the extra workload that that entails, he has decided to resign as co-chair of the SIP Working Group. With the approval of the Internet Area ADs, Bob Hinden will be taking his place as co-chair (with Steve Deering) of the SIP group. This also seems an appropriate time to terminate the separate IPAE Working Group, chaired by Dave Crocker, and have its work taken over by the SIP group, since IPAE has evolved into being the SIP transition and implementation group. This will require a modification of the SIP WG charter, which will be submitted to the IESG for approval. Christian, Steve, Bob, and Dave ========= ========= ========= ========= ========= ========= ========= ftp://ftp.ietf.org/ietf/93jul/ipdecide-minutes-93jul.txt Christian Huitema, Steve Deering, Bob Hinden, Dave Crocker: Fri, 4 Jun 1993 ==================================================================== B-I == SIP & IPAE groups to merge and shuffle chairs With Christian Huitema's election as IAB chair and the extra workload that that entails, he has decided to resign as co-chair of the SIP Working Group. With the approval of the Internet Area ADs, Bob Hinden will be taking his place as co-chair (with Steve Deering) of the SIP group. This also seems an appropriate time to terminate the separate IPAE Working Group, chaired by Dave Crocker, and have its work taken over by the SIP group, since IPAE has evolved into being the SIP transition and implementation group. This will require a modification of the SIP WG charter, which will be submitted to the IESG for approval. Christian, Steve, Bob, and Dave ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0002.txt Phill Gross -- Tue, 07 Sep 1993 -- IETF-Announce ================================================ A Direction for IPng At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide BOF", on the process and progress of the IPng activities. ("IPng" stands for "IP, the next generation". The IPDecide BOF was chaired by Brian Carpenter. Minutes are available in the IETF directories, with the file name .) The IPDecide BOF explored several facets of the IPng process, such as - "What is the basis for choosing the next generation IP (i.e., what are the technical requirements and decision criteria)." - "With the advent of CIDR and new, more stringent address assignment policies, are we comfortable that we truly understand the level of urgency?" - "Should the IETF or the marketplace make the final IPng decision". The BOF was held in a productive atmosphere, but did not achieve what could be called a clear consensus among the assembled attendees. In fact, despite its generally productive spirit, it did more to highlight the lack of a firm direction than to create it. The IPDecide BOF was followed the next evening by the open IESG plenary. During this session, the IESG and the assembled attendees discussed the IPng issues and seemed to arrive at a consensus based on the following set of bullets presented by the IETF chair: - "The IETF needs to move toward closure on IPng." That is, the IETF should take active steps toward a technical decision, rather than waiting for the "marketplace" to decide. - "The IESG has the responsibility for developing an IPng recommendation for the Internet community." That is, the IESG should provide leadership and take specific actions to help move the IETF toward a technical decision. - "The procedures of the recommendation-making process should be open and published well in advance by the IESG." - "As a part of the process, the IPng WGs may be given new milestones and other guidance to aid the IESG." - "There should be ample opportunity for community comment prior to final IESG recommendation (e.g., there will be an extended Last Call)." A Direction For IPng Building on this consensus, I'd like to announce a set of specific directions in the IESG that I hope will move us toward timely resolution of many of the key IPng issues. The IESG will establish a temporary, ad hoc, "area" to deal specifically with IPng issues. The charter for this new IESG area is to develop a recommendation on which, if any, of the current proposals should be adopted as the "next IP". This recommendation will be submitted to the IESG and to the Internet community for review. Following an adequate period of review to surface any community concerns, the IESG will issue a final IPng recommendation. All of the current IPng-related working groups will be moved immediately into this new area. This new area will be headed by two co-Area Directors from within the IESG. I have asked Allison Mankin (NRL), current Transport Services AD, and Scott Bradner (Harvard), current Operational Requirements AD, to serve as co-AD's for this temporary area. I am very pleased to report that they have agreed to take this important assignment. (Because this is expected to be a temporary assignment, Scott and Allison will also continue to serve in their current IESG positions during this period.) All IETF Areas are now expected to have Area Directorates. For the IPng Area, a Directorate will be especially important to bring additional viewpoints into the process. Therefore, I am asking that, as their first action, Scott and Allison form a specific IPng Directorate to act as a direction-setting and preliminary review body. The IPng process will continue to be completely open, and therefore reports and meeting notes from any IPng Directorate meetings will be published in timely fashion. Issues Toward IPng Resolution Two important issues need resolution immediately before we can expect progress toward an IPng recommendation: - What is the scope of the effort? That is, should IPng be limited to solving the well known scaling and address exhaustion issues; or should IPng also include advanced features such as resource reservation for real-time traffic? The argument in favor of considering advanced features is that migration to a new IP is (hopefully, only!) a once-in-a-generation occurance, and therefore all advanced features should at least be considered. Arguments opposed to considering advanced features include the fact that we may not have time for this level of effort before the scaling and address exhaustion problems confront us, and that we may not have the necessary understanding and experience to make all the correct choices at this time. - What is the available timeframe? That is, before we can even begin to make an informed decision about the scope, we need a better understanding of the urgency and time constraints facing us. Factors that affect the available time include the current rate of address assignments (which can give us an estimate of when we are currently projected to run out of addresses), the current policies governing address assignment (which can give us an understanding of how policies affect the assignment and utilization rates), the impact of CIDR aggregation, the development time for IPng, and the time needed to field and migrate to the new IPng. Therefore, I am asking the new AD's and the Directorate to start immediately the following specific activities to help guide their ultimate IPng recommendation: 1. Develop an understanding of the available timeframe, covering at least the following issues: - Review Internet growth metrics, such as the current address assignment and utilization rates. Develop an understanding of how the new address assignment policies impact the assignment and utilization rates. - Review the expected impact of CIDR address aggregation. Develop an understanding of the expected savings due to CIDR aggregation. - Develop new technical guidelines for classless Internet addressing. Specific examples include guidelines for how to utilize variable length subnet masks, and how to utilize currently unused Class A and B addresses in a classless fashion in hosts and routers. - Develop a strong understanding of the time required for the development, fielding, and migration for a new IP. - Based on all the above issues, (a) develop an estimate for how long we have to to develop and deploy an IPng. This could be a set of estimates based on best/worst case estimates for how each of the above factors will affect the available timeframe. (b) Consider whether more stringent assignment policies might provide additional time. If so, recommend such policies. (c) make a recommendation on whether it is worthwhile to mount a serious effort to reclaim addresses and/or to renumber significant portions of the Internet. 2. Based on an informed judgement of the time constraints above, make a recommendation regarding the scope for IPng, i.e., should IPng consider scaling issues only or advanced topics also. 3. Based on the scope and time constraints, develop a clear and concise set of technical requirements and decision criteria for IPng. These should include, but not be limited to, the criteria outlined in the IESG statement (RFC1380). 4. Based on the decision criteria, scope, and time constraints, make a recommendation on which of the current IPng candidates to accept, if any. Finally, I am asking Scott and Allison to make a detailed report at the opening plenary of the next IETF meeting in November on the status of setting up their new area, and on their progress toward organizing the above work items. In particular, the status of the work items on timeframe should be fully reported. This will be followed by regular progress reports to the Internet community, at IETF meetings and in other appropriate forums. Please join me in giving Scott and Allison our full cooperation, and in thanking them for accepting this daunting assignment. I feel confident that we will now make significant progress on the important IPng issues facing the Internet community. Phill Gross IETF/IESG Chair ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0005.txt Phill Gross -- Thu, 14 Oct 1993 -- IETF-Announce ================================================== IESG Handling of IPng documents The IESG has determined how documents from the IPng candidates will be treated when they are submitted to the IESG for publication as RFCs. 1. All IPng-related documents will be submitted for publication as RFCs in normal fashion; that is, as soon as the working group and the area directorate recommends that the IESG review them for publication. All IPng-related RFCs will be published with Experimental status. All IPng-related RFCs will remain in Experimental status until a single IPng is selected. 2. At some point, one IPng shall be selected, and it will be moved onto the standards track as defined in RFC1310 (or its successor). An Applicability Statement will be prepared to assign a status of "Recommended" as the Common IPng for Internet interoperability. 3. Once a "Common IPng" protocol has been selected, the other (former) IPng candidates will be treated in normal fashion. That is, they may eventually be moved to Historic status, or, if recommended by the working group and area directorate, they may be moved onto the standards track. However, because there can be only one level three protocol with a status of "Recommended as the Common IPng for Internet interoperability", an Applicability Statement must be prepared that clearly distinguishes between the subject protocol and the "Recommended Common IPng". Phill Gross IETF Chair ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0006.txt Scott Bradner and Allison Mankin, Co-Area Directors October 1993 ========================================================== B-I = IPNG Area Report sob@harvard.edu mankin@cmf.nrl.navy.mil The IPNG Area is a temporary area in the IESG charged with managing the "IP the next generation" process. This is the first of area reports we will issue approximately monthly to keep the IETF informed about our progress. We will give a presentation describing the Area and the IPng process that we will be pursuing. This is scheduled for Monday morning of the Houston IETF. We will make the announcement of the directorate membership before then (soon), and we hope that many of the directorate members will be around during that plenary session. A 60 minute time period is reserved for questions and discussion following the presentation. Following the question session will be 10-minute updates on each of the IPng proposals. We invited a group of internetters to meet with us for an "advice meeting". This took place at SIGCOMM, in San Francisco, on September 17. The purpose of this IPNG meeting was to give us a kind of focus group, to let us discuss the IPNG area and the potential IPNG directorate informally and in a preliminary manner. The group that met was purposely not an early version of the IPNG directorate, nor was the meeting conducted in as structured a way as we expect of the directorate meetings, i.e. no minutes were taken. Several results came from this meeting: - The directorate should not include IESG or IAB members. - An IETF WG, Address Lifetime Expectations (ALE), was formed, whose mission is to quantify the lifetime of internet address space. Frank Solensky will chair. - Our generalized task is to develop a plan for the Internet future--it will have milestones at different times depending on the actual growth that occurs. The participants were: Scott Bradner, Harvard University Ross Callon, Wellfleet Jon Crowcroft, University College London John Curran, NEARnet Steve Deering, Xerox PARC Paul Francis, Bellcore Dave Katz, Cisco Tony Li, Cisco Allison Mankin, Naval Research Lab Greg Minshall, Novell Craig Partridge, BBN/Stanford University Frank Solensky, FTP Software Lixia Zhang, Xerox PARC The agenda we started with follows: draft agenda - IPng think session Sept. 17 1993 introductions review charge to IPng area additions to charge? mergermania SIPP... white papers < 10 page views from various people on IPng proposals & views of problems Noel, John Curran, TUBA, SIPP ... FYI for the community: IPng area procedures directorate meetings on and off record (minutes or not) telechats face to face at ietf special meetings mailing list public vs private archives standards sequence advance all to experimental when ready after decision, advance one onto track as recommended (move to required eventually?) after delay, others can move to elective parts can move to recommended if good AS directorate issues/suggestions how about IESG members? what WGs are needed? chair suggestions, warnings CIDR issues who knows BSD code? address assignment procedures var length subnets timeframe scope criteria decide consensus building/outreach factors to look at if the sky is not falling flow congestion accounting security advanced policies presentation at IETF in Nov. report to ietf mailing list? ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0021.txt IETF Nov 1993 ------------- ftp://ftp.ietf.org/ietf-online-proceedings/93nov/area.and.wg.reports/ipng/area.ipng.93nov.txt P. Internet Protocol Working Group (PIP) and Simple Internet Protocol Working Group (SIP) The PIP and SIP Working Groups have combined their efforts and the working groups will be merged into a new working group called Simple Internet Protocol Plus (SIPP). The two working groups met in two combined sessions co-chaired by Steve Deering, Paul Francis, and Bob Hinden. At the first session Steve Deering presented an overview of the SIP/PIP Merger. This included the motivation behind the merger, benefits of the merger, and described the new features of SIPP. The purpose of the merger is to keep the simplicity and transition features of SIP and to benefit from the advanced routing capabilities of Pip---while making them easier to use and to understand. ---- ftp://ftp.ietf.org/ietf-online-proceedings/93nov/area.and.wg.reports/ipng/pip/sip-pip-minutes-93nov.txt Nov 1993 CURRENT_MEETING_REPORT_ Reported by Robert Hinden/Sun Microsystems Minutes of the Joint Sessions of the SIP and PIP Working Groups These minutes are based on the notes taken by Christian Huitema and Bob Hinden. The Simple Internet Protocol Working Group (SIP) and the P. Internet Protocol Working Group held two joint sessions. The first session was on Monday, November 1. The second session was held on November 4. Both sessions were carried on the Internet Multicast. The agenda distributed prior to the meeting was reviewed and updated for the meeting. SIPP Merger Overview (Steve Deering) The purpose of the merger is to keep the simplicity and transition features of SIP and the advanced routing capabilities of Pip---while making them easier to use and to understand. The mailing lists have been merged, and Bob Hinden is writing a charter for the merged group. This has resulted in some changes in the specifications, and in some terminologies. The changed terms are: SIP --> SIPP system --> node anyone address --> cluster address Source route header --> Routing header The new terminology: o The uniqueness scope of an address; for example the uniqueness scope of the loopback address is just one single node. o The routing scope of an address, which is generally global to the Internet, but can sometimes be restricted e.g., for a ``local use address.'' Routing scope is always less than uniqueness scope, but not necessarily equal to it. ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0007.txt Scott Bradner -- Tue, 7 Dec 1993 -- B-I ======================================= IETF IP: next generation area (IPng) chairs Allison Mankin (NRL) Scott Bradner (Harvard University) IPng White Paper Solicitation 1. Introduction The IP: next generation (IPng) area in the IETF is soliciting white papers on topics related to the IPng requirements and selection criteria. All interested parties are invited to submit white papers detailing any specific requirements that they feel an IPng must fulfill or any factors that they feel might sway the IPng selection. An example of the former might be a submission by a representative of a utility company detailing the scaling and addressing features which would be required to service future inclusion of utility meters on the network. An example of the other case might be a paper outlining the potential effect on IPng of some sections of the future network connectivity being provided via wireless networks. At this time, we are not accepting white papers that evaluate specific IPng proposals. This type of document will be accepted after the various proposal documents are deemed to be clear and complete. All white papers will be reviewed in a process described below. As a result of these reviews, each white paper will receive the focused attention of the IPng directorate and the community. The white papers will be used as resource materials by the IPng Area working groups, the directorate, the external review board and the area directors, during the selection process. The deadline for the submission of these white papers is February 1, 1994, though early submission is encouraged. Submit white papers, general or topic questions, and so on, to ipng-wp@harvard.edu. 2. Document Review Process All submitted documents will first be reviewed for clarity by members of the IPng directorate and the external review board. This review may produce suggestions to the author on areas of the document where there may be some confusion as to the meaning. Authors are urged to consider any such suggestions as constructive and to reexamine their text in light of the suggestions. A separate technical review will then be done of the white paper. This review will be conducted within the context of the document. That is, the review still will not make value judgments on the white papers, but will assess technical feasibility. This review may also produce suggestions to the author. The document will be submitted as an Internet-Draft after these reviews have been completed and after whatever (if any) revisions that the author decides to make. After a suitable period of time these documents will be submitted as informational RFCs unless withdrawn by the author. These documents will comprise a part of the historical record of the IPng process. 3. Document Format Requirements All white papers must follow the format requirements listed in RFC1543 and must not exceed 10 pages in length. (The relevant portion of RFC1543 is included in this document as Appendix A.) They should not include the 'status of memo' or 'distribution' sections; these will be added when the documents are posted as Internet Drafts. The reference version of the document must be in ASCII as is current practice with all RFCs. A PostScript version of the document may be submitted in addition to the ASCII version. 4.Outline for IPng Requirements and Concerns White Papers This section details the white paper outline to be followed by someone who would like to express an opinion about the various factors involved in the IPng definition and selection process. Since these documents will be used as resource material by the various IPng working groups, the directorate, the external review board and the area directors, they should be well-focused and give specific references to data supporting their points. Each white paper should begin with an executive summary of the important points of the document. This executive summary should not exceed 1/2 page in length. The white paper should then address the issue or issues that the author feels should be understood during the IPng process. The total document should not exceed 10 pages in length. An author may submit more than one white paper if he or she feels that the level of detailed discussion on each topic warrants it. 4.1 Engineering considerations In past discussions the following issues have been raised as relevant to the IPng selection process. This list is in no particular order. Any or all of these issues may be addressed as well as any other topic that the author feels is germane, but do not exceed the 10 page limit, please. Scaling - What is a reasonable estimate for the scale of the future data networking environment? The current common wisdom is that IPng should be able to deal with 10 to the 12th nodes. Timescale - What are reasonable time estimates for the IPng selection, development and deployment process or what should the timeframe requirements be? This topic is being evaluated by the ALE working group and a copy of all white papers that express opinions about these topics will be forwarded to that group. Transition and deployment - Transition from the current version to IPng will be a complex and difficult process. What are the issues that should be considered The TACIT working group will be discussing these issues and a copy of all white papers that express opinions about these topics will be forwarded to that group. Security - What level and type of security will be required in the future network environment? What features should be in an IPng to facilitate security? Configuration, administration and operation - As networks get larger and more complex, the day to day operational aspects become ever more important. What should an IPng include or avoid in order to minimize the effect on the network operators? Mobile hosts - How important is the proliferation of mobile hosts to the IPng selection process? To what extent should features be included in an IPng to assist in dealing with mobile hosts? Flows and resource reservation - As the data networks begin to get used for an increasing number of time-critical processes, what are the requirements or concerns that affect how IPng should facilitate the use of resource reservations or flows? Policy based routing - How important is policy based routing? If it is important, what types of policies will be used? What requirements do routing policies and potential future global architectures of the Internet bring to IPng? How do policy requirements interact with scaling? Topological flexibility - What topology is anticipated for the Internet? Will the current general topology model continue? Is it acceptable (or even necessary) to place significant topological restrictions on interconnectivity of networks? Applicability - What environment / marketplace do you see for the application of IPng? How much wider is it than the existing IP market? Datagram service - Existing IP service is "best effort" and based on hop-by-hop routed datagrams. What requirements for this paradigm influence the IPng selection? Accounting - How important a consideration should the ability to do accounting be in the selection of an IPng? What, if any, features should be included in an IPng to support accounting functions? Support of communication media - IPv4 can be supported over most known types of communications media. How important is this same flexibility to an IPng? Robustness and fault tolerance - To the extent that the Internet built from IPv4 has been highly fault tolerant, what are ways that IPng may avoid inadvertant decrease in the robustness (since some things may work despite flaws that we do not understand well). Comment on any other ways in which this requirement may affect the IPng. Technology pull - Are there technologies that will pull the Internet in a way that should influence IPng? Can specific strategies be developed to encompass these? Action items - suggested charges to the directorate, working groups or others to support the concerns or gather more information needed for a decision. Appendix A - Formatting Rules (from RFC1543) Note: there are a set of NROFF formatting macros for the following format. Please contact ipng-wp@harvard.edu if you would like to get a copy. 3a. ASCII Format Rules The character codes are ASCII. Each page must be limited to 58 lines followed by a form feed on a line by itself. Each line must be limited to 72 characters followed by carriage return and line feed. No overstriking (or underlining) is allowed. These "height" and "width" constraints include any headers, footers, page numbers, or left side indenting. Do not fill the text with extra spaces to provide a straight right margin. Do not do hyphenation of words at the right margin. Do not use footnotes. If such notes are necessary, put them at the end of a section, or at the end of the document. Use single spaced text within a paragraph, and one blank line between paragraphs. Note that the number of pages in a document and the page numbers on which various sections fall will likely change with reformatting. Thus cross references in the text by section number usually are easier to keep consistent than cross references by page number. ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0008.txt Allison Mankin -- Wed, 27 April 1994 -- B-I =========================================== IPng Update This is a quick update on the status of the IETF IPng effort. Since the creation of the IPng area late last year we have been focused on two primary tasks; developing a reasonable estimate of the projected lifetime for the IPv4 address space and producing a draft requirements document. The IPv4 Address Expectations Working Group (ALE), chaired by Frank Solensky and Tony Li reported during a session held at the IETF meeting in Seattle that their current estimate was that the IPv4 address supply would be exhausted in the year 2008 ( plus or minus 3 years), assuming no changes in the basic rate of growth in the demand for addresses. Clearly, if there were a request for a very large block (many millions) of addresses, it would affect this estimate. The Transition and Coexistence Including Testing (TACIT) working group, chaired by Atul Bansal and Geoff Huston had its first meeting in Seattle. This group will focus on the long term transition and coexistence issues and will define recommendations for testing IPng specifications and implementations. Of course, the working groups for each of the IPng candidates have been busy and did meet in Seattle to further refine the details of their proposals. The IPng Requirements BOF, chaired by Frank Kastenholz and Jon Crowcroft, has produced a draft of an IPng requirements document. The current draft is a refinement of an initial document by Frank Kastenholz and Craig Partridge. It reflects input from a number of the white papers that the IPng area solicited with RFC1550 and comments from the IPng directorate. The requirements draft is ready for public comment. It has been published as an internet-draft (draft-kastenholz-ipng-criteria-01.txt). We need as many comments as possible by May 10. All interested persons (that should be just about all reading this message) should take a look at this document and, if you have comments or suggestions, send them to the big-internet list. (Send a note to big-internet-request@munnari.oz.au to subscribe.) You should also take a look at the RFC1550 white papers, they have been published as internet drafts. Look for any internet draft with "ipng" in its filename. All of these documents are available at you favorite internet-drafts site and from hsdndev.harvard.edu in pub/ipng/wp for anonymous ftp. Hsdndev also allows gopher access. The IPng directorate mailing list archives and directorate teleconference minutes are also available from hsdndev. We urge you to take a look at these documents and records. Let us know on the big-internet list or in private mail what you think. This is an effort that will effect us all and anyone who can help make the result better or the transition easier is encouraged to participate. Appended to this update is the area status report from the Seattle IETF meeting. Scott & Allison IETF 29 IP: Next Generation Area Report Seattle, Washington Scott Bradner Allison Mankin Meetings of 4 IP: Next Generation working group, 3 BOFs, and an open IPng directorate meeting were held during the 29th IETF meeting in Seattle, Washington. Address Extension by IP Option Utilisation BOF (AEIOU) Reported by Peter Ford Chair Brian Carpenter Brian Carpenter presented the aeiou proposal (draft-carpenter-aeiou-00.txt) and there was a lively discussion. Most people felt that aeiou would work and could, with effort, be developed into a viable stop-gap solution. There was one significant technical issue, the impact of option analysis on local router performance. The main debate was whether the savings in work and time to implement and deploy aeiou compared to a full IPng solution were significant and worthwhile. There was a range of views on this. The conclusion was not to propose an aeiou working group at this time, but to document the proposal (possibly as an Informational RFC) to keep it in reserve for future eventualities. Interested people should contact brian@dxcoms.cern.ch. Address Lifetime Expectations WG (ALE) Reported by Tony Li Chairs: Tony Li , Frank Solensky The ALE WG met to discuss its projections and future mechanisms for improving the lifetime of the address space. Our current projections were presented and subsequent discussion ensued. As a result, ALE will also begin to track routing table sizes. We have volunteers to collect data for us. We discussed address efficiency and have a volunteer to produce a document on improving address space efficiency. RFC 1597 was presented, and was thought to be very helpful. We discussed the timetable for IPng, but were unable to come to any reasonable conclusions due to uncertainty about the deployment of CIDR and the explosion of the routing tables. Common Architecture for Next-Generation IP WG (CATNIP) Reported by Robert Ullmann Chair (pro tem) Robert Ullmann WG meeting was chaired pro-tem by Robert Ullmann, as Vladimir Sukonnik was unable to attend. Robert did a small soapbox on the proper scope of the IPng proposals. This was followed by discussion of a number of minor technical issues identified recently on the CATNIP list. Several IPX related issues were left uncertain. The issue of TUBA TCP and UDP checksums to be discussed with the TUBA WG. DNS issues to be resolved in a near future revision of the Collela/Manning draft which will be used by both TUBA and CATNIP. Fragment translation was discussed, with the differring semantics between CLNP, IPv4, and SIPP making it less useful than would be expected. IPNG Requirements WG (NGREQS) Reported by Frank Kastenholz Chairs Jon Crowcroft , Frank Kastenholz The working group had a number of presentations from members of the community who are experts in particular technical areas. These included Mike StJohns on Security, Greg Minshall on Mobility, Dave Clark on Network Services, Lixia Zhang on RSVP, Mark Handly on AVT, Peter Ford on Backbones, and John Curran on Market Needs. The intent was to give the group background information on these particular areas and their specific needs -- similar to the White Papers solicited by the Directorate. The working group then proceeded into a lively and spirited debate on the various criteria. The community suggested many significant improvements which are still being digested by the chairs and authors. One important improvement that seemed to have great support from the community was that the requirements should be strengthened amd made firmer -- fewer "should allows" and the like and more "musts". SIPP WG Reported by Bob Hinden Chair Bob Hinden March 1994 IETF The SIPP working group held a implementors meeting on Sunday afternoon and two working group sessions on Wednesday and Thursday. Bob Hinden presented a summary of recent working group activities. This included that the SIPP charter had been approved, the SIPP Whitepaper had been completed on time, a summary of the SIPP specifications which had been completed since the last IETF meeting, and the SIPP specifications which were submitted to the IPng area directors for publication as experimental RFC's. Also presented was the announcement that Mosaic pages had been created for the SIPP working group. These can be found at http://town.hall.org Jim Bound presented a summary of the implementors meeting. A number of SIPP implementors had attended and several refinements had been made to some of the SIPP options based on implementation experience. These changes will be documented in an update to the SIPP specification. Steve Deering presented an overview of the changes from last fall's SIP spec to the current SIPP specification. This included details on the layout of the Flow ID. Ramesh Govindan and Sue Thompson presented the current approach for dealing with auto configuration and discovery. This resolved the issues that were outstanding with the current drafts. New specifications will be published. Bob Gilligan presented an overview of IPAE. This resulted in a discussion of some of the details of IPAE and uncovered a bug. There was general agreement that IPAE needs to be simplified. This will be worked on and the specification will be updated. The Transition and Coexistence including Testing (TACIT) BOF Reported by Geoff Huston Chairs: Geoff Huston Atul Bansal The BOF discussed the issues relating to transition and coexistence in general terms as they relate to the constituency of the Internet, and also discussed the specific issues relating to potential IPng transition environments. The view was expressed that the characteristics and potential timeframe of transition, coexistence and testing processes will be greatly influenced through the interplay of market forces within the Internet, and that any IPng transition plan should recognise these motivations and provide ample levels opportunity identification to encourage the broad Internet constituency to subscribe to the transition process (and therefore undertake to meet the associated deployment costs of such transition). The group decided to recommend to the IPNG Area Directoriate to form a Working Group to explore the generic issues of the IPng transition process and gather experience from previous technology transition that have occured both within the Internet and within related networking technologies. A draft charter was reviewed, with the view that this Working Group work would contribute to the IETF IPng process by identifying these issues and reviewing IPng transition plans at the appropriate phase of the IPng process. TCP and UDP with Big Addresses (TUBA) WG Reported by Peter Ford Chairs Peter Ford Mark Knopper Dave Marlow presented an update on the status of CLNP multicast. His Internet Draft is intended to be multicast routing protocol independent, and was presented from the ES viewpoint. Discussion ensued as to whether the complexity of the network-to-data-link address mapping protocol was worthwhile. The "extra hop" problem is widely viewed as being a show-stopper and Dave presented an approach to address this problem and will be updating the ID to reflect this. Lyman Chapin updated the group on the electronic availability of the pertinent ISO standards. Lyman is now comfortable posting these documents as I-Ds and the network layer protocols (CLNP, IS-IS, ES-IS and IDRP) will all be published by the end of the Seattle IETF. Dino Farinacci gave a short presentation on the status of Protocol Independent Multicasting (PIM) in the IDMR working group. He noted there would be little difficulty in using PIM for multicast routing of CLNP. Ross Callon presented his work on flows in CLNP. In this scheme the source NSEL is used to demultiplex flows between a single host pair. The size of this field (eight bits) was a source of controversy and there was concern that using the Source NSEL might cause to non-TUBA CLNP entitities. Dave Piscitello gave an overview of the current TUBA transition document. Bob Brenner from GTE gave an overview of Cellular Packet Data Network (CDPD). CDPD is using CLNP as an underlying protocol, but it can support mobile hosts that are either CLNP or IP speakers. ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0009.txt Scott Bradner -- Sun, 26 Jun 1994 -- B-I ========================================= IPng ADs request Picking up on something that Noel mentioned in a posting a while back, we would like to request that a particular issue be discussed. One thing that seems to have been missing in the recent extensive discussions about address size options is a understanding of whether the transport level 'name' should be the same as the internetwork level 'name', as they are with the current IPv4 "address", or be different in some way. In IPv4 the transport name is: The question referrs to the two IP address fields. Different people seem to often be making different assumptions about the answer to this question in recent notes, with the result that a lot of the discussion was not as productive as it could have been, due to inconsistant terminology. If it is possible to reach consensus on this issue, it will almost certainly make it easier to reach consensus on some of the other open issues regarding "addresses". Note that it is not necessary to assume that the names in question are either fixed or variable length. Obviously, whether you have one or two is related to the details of what each would look like, but it should be possible to consider this without getting diverted by the contentious issue of fixed/variable. Please address the following questions: 1/ are the transport and internetwork level names the same thing? 2/ if not, are they totally different or is the transport level name part of the internetwork level name? Scott & Allison ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0010.txt Png Area Directors Thu, 7 Jul 1994 ==================================== IPng ADs Wish to Gauge Consensus on Address Length Requirements Hi, TUBA, SIPP, CATNIP, BIG-INTERNET, and IETF: This message is one last pre-Toronto recommendation attempt to gauge the extent of consensus on one of the IPng issues. We apologize for duplications. We wanted to reach a wide audience. Steve Deering's message "Chicago Meeting -- Possible Changes to SIPP" to the SIPP list a while back elicited quite a bit of discussion on various lists (both SIPP and big-internet and in other venues) about the length of "address" required for an IPng. We have also had considerable discussion within the directorate. At this time it would appear to us that there is considerable consensus that a fixed length, topologically structured, hierarchical address 16 bytes in length is reasonable for an IPng (that is meets the needs of the very very large-scale Internet). We understand that we are being a bit vague in using the term "address" in light of the question we asked two weeks ago. For the purposes of this request, please assume that the transport level and internet level names are the same. Some hold the view that 16 bytes is larger than would be required for any imaginable Internet structure in the future and that an 8 byte address is all that is required. There seems to be a stronger, but still minority, view that, for various reasons, a variable length address, one that could be smaller or larger than 16 bytes, would meet the needs better for the future of the Internet. Much of the discussion on the lists has revolved around the relative efficiency of processing fixed and variable length addresses. We would like to assess the consensus just on the length for the future Internet, instead of discussing efficiency any more at this time. We want to make sure that we have understood consensus on meeting the needs of the very very large Internet. Therefore, this message is to ask people what present or future rationale they see for one of: 8 byte fixed length address. 16 byte fixed length address. longer than 16 byte fixed length address now. only 16 byte length addresses now but ability to lengthen the address later. To amplify a bit more, we are especially interested in your views on the address length's ability to offer: routing aggregation power topological flexibility adminstrative manageability At this point the consensus among the IPng directorate and on several of the mailing lists seems fairly clear (a 16 byte length address is good for those things). This is a good time to bring forward your remaining views about the requirements for address length for IPng. Thank you, Scott and Allison ========= ========= ========= ========= ========= ========= ========= http://rms46.vlsm.org/3/0090.txt ESG -- 11 April 1996 -- ftp://ftp.ietf.org/iesg/iesg.96-04-11 -------------------------------------------------------------- Note of Apprecation: The IESG commended Scott Bradner and Allison Mankin for the outstanding job they performed as co-Area Directors of the IPNG Area, and thanked them for taking on the job. Scott and Allison: take two cookies out of petty cash :-) ========= ========= ========= ========= ========= ========= ========= http://www.bbiw.net/articles/ROAD.article.txt 17 September 1992 The ROAD to a New IP* by David H. Crocker, Brandenburg Consulting Copyright ? 1992 by Interop Company TCP and IP have been in full operational use since 1983. There are tens of thousands of IP networks and perhaps millions of users. By any reasonable measure, IP counts as a massive suc cess. Unfortunately, the phenomenal number of users is stressing the design limits of IP: the 32-bit IP Host Address space simply is too small for long-term growth -- although it was more than ample when chosen, 15 years ago. This article explores the nature of the limitation and the efforts to move from the current IP version 4 to a new IP version 7. (Versions numbers 5 and 6 have been used elsewhere.) Disclaimer #1: This topic has recently engendered significant debating and politicking within the Internet community, including a crisis of confidence that has shaken the core of IETF, this summer. This article attempts to present the technical issues independent of the political and emotional concerns, hoping to aid the reader in considering the nature of the trade-offs offered by various proposals. It is essential that the choice be made by an informed Internet community, since the choice will not be easy or obvious, but it will affect the future of the Internet. General online discussion about this topic is conducted on the mailing list: big-internet@munnari.oz.au but the reader is reminded to subscribe by sending to big- internet-request. Disclaimer #2: The author of this article is an author of one of the proposals. Disclaimer #1 notwithstanding, the author will attempt to avoid the temptation to indulge his certain bias towards his own excellent proposal... Is there really a problem? An address space of 32-bits allows reference to billions of hosts. (Well, actually host interfaces.) Since current consumption of IP addresses is only in the realm of one or a few million, it might appear that there is no pressing concern. In fact, there are two different problems. One is an immediate crisis and the other is likely to become one within a few years. The first is the size of the information base that must be maintained within IP routers, for making data-forwarding decisions. The latter is simple exhaustion of the IP address space. Internet growth is approximately 100% every 12 months. While growth in North America has slowed, growth in Europe is explosive and the Pacific Rim is starting a similar curve. All of this is within the usual markets of business and technical users. If new markets open, such as use of IP in consumer products, a significant fraction of the world's population become candidates for IP addresses. Note that IP, with subnet addressing, divides an address into: Network : Sub-network : Host And uses the Class A/B/C mechanism, mixed with address masks, to vary where the boundaries occur between these sub-fields. All of this fits within 32 bits and network numbers are assigned sequentially, with no relationship between any two network numbers, producing a "flat" address space. No matter what games are played within those bits, there is a limit to the maximum number of addresses that can be assigned. Routing table size In the Internet backbone, routers are required to know about all of the networks that can be reached. These routers do not have to know about the different sub-networks or hosts, but they do need to know about each and every network in the entire Internet. This is due to the "flat" address space of IP network numbering. The fact that two networks are topological neighbors and that packets to the two may travel most of the Internet using the same path is of no benefit when constructing routing tables. The two network numbers are unrelated, requiring calculation of routes for both of them. The computational cost of calculating these paths separately has become a serious burden. So a way needs to be found to aggregate table entries. This requires a fundamental change in the nature of IP network addresses, from the current, flat style, to one that has some useful structure. The usual assumption is that a hierarchical scheme will be most appropriate. Address space While there is no topological information in the encoding of IP network numbers, there is a scheme for distinguishing "large" networks from smaller ones, via the Class A, B, and C mechanism. The most popular addresses are Class B, since they permit reasonably large networks and there are a substantial number (approximately 32,000) of such network numbers available. Very few Class A addresses are possible and Class C addresses are useful only for the smallest networks. Hence, the first wall that IP will hit is an exhaustion of Class B address. While there may be a way to get around this wall, the second wall, assignment of all possible IP addresses, eventually will be encountered. There is debate about the urgency of these 2 walls. However, it appears that modifications to the assignment of Class B addresses, and modifications to backbone router protocols, will allow deferral of the first concern. To expand the IP address space, enough bits need to be added to allow for reasonable administration and for a scheme which provides some meaningful assistance in relating topological neighbors. For example, a datagram from Japan destined for Stanford University and another from Japan destined for Berkeley ought to travel most of the same path along the Internet, and most of the routers along the way ought to need one -- not two -- entries in their routing tables. This is only possible if some portion of the two addresses is the same. As long as we've got this thing open... IP works well, but improvement always is possible. One line of thought is that this forced change to addressing provides an opportunity to repair or improve other aspects to IP. For exam ple, the space available for IP options sometimes is viewed as too constrained. Similarly, the mechanism for specifying con straints upon handling (Type of Service) have never been viewed as adequate and have not seen significant use. The remainder of this article considers the challenges of balanc ing competing concerns, the selection process that is being pur sued, and the nature of the routing-, addressing- and header format-related issues. It ends with a very brief summary of the major proposals that are before the Internet community. The article is frankly cursory in discussing most of the issues. The current debate ranges wide and deep, in considering fundamental aspects of the IP infrastructure. There is a great deal of activity and a great many messages, Internet Drafts and RFCs. This article attempts to summarize the issues and proposed solutions, but the reader is encouraged to join the relevant mail ing lists and read the relevant documents. Trading immediacy for carefulness Opinions about the timing of total address space exhaustion vary between 2 years and 20 years. However, a plausible, near-term estimate is 5 years. This means that the Internet has until 1997 to develop, test and install a new addressing scheme. Conservative project management thinking would attend the dif ficulties of fielding an entirely new technology in such a large community and would seek to have the new scheme fully deployed in 3-4 years. This leaves very little time to develop and test a solution. As those who create and distribute products and services well know, the basic development of a capability is often the smallest part of an effort. Testing, manufacturing, training and instal lation often consume considerable time and resources. By any reasonable measure, it will take 2-3 years to deploy a solution. This leaves us with only 1-2 years to develop, test and stabilize a solution. A choice needs to be made immediately. This creates a difficult pressure between immediacy and inno vation. Some of the alternatives being considered sound quite appealing, but have minimal or fluid specifications, no oper ational experience, and may represent significant differences from current IP experience. The challenge, for these alter natives, is to demonstrate that the degree of benefit that will accrue from choosing them is sufficiently great to justify the risk of delaying their deployment. Or else, to convince the community that no extra time is required. The challenge for the "simpler" and more conservative alternatives is to convince the community that they offer fundamental safety and cost-effec tiveness. The biggest danger is one of "creeping feature-ism" with more and more requirements being added to the project. It is easy to succumb to this, since we do not get many opportunities to change the infrastructure. However, each additional requirement makes the total task that much more complicated and risky. At a minimum, it virtually guarantees delays before the total package of changes can be deployed into the Internet. Technically the only clear requirement is to enhance IP's routing and addressing structure. Everything else is beyond the immediate crisis. Previous efforts Concern about IP address exhaustion and routing table size explosion has created a sense of crisis within the IETF commu nity. Almost 2 years ago, a special effort, called the ROAD (ROuting and ADdressing) group was formed to consider solutions. It gravitated towards one option, but did not see quick adoption of its recommendation. But time had passed and urgency grew. There has been pressure to select a solution immediately, without extensive exploration and development of options. The Internet Engineering Steering Group (IESG) divided the concerns into short- term, mid-term and long-term. Class-B exhaustion and routing table size explosion fall into the first category. IP address space exhaustion falls into the mid-term timeframe. The IESG feels that other issues of general enhancement to IP, such as quality of service, security/authentication, mobility, resource allocation, accounting, and high packet rates can been deferred for "long term" consideration. There is reasonable consensus that the proposal called Classless Inter-Domain Routing (CIDR) [2] will be adequate for the near- term, by modifying usage of current IP addresses. However, some conservative members of the community advise against relying entirely upon this one option and suggest that the "mid-term" option be developed with all due speed, in case CIDR proves inadequate. This would suggest that deployment needs to start during 1994! However, the IESG felt that none of the options being discussed this past Spring was sufficiently well specified to allow an adequate analysis of its capabilities. So, the IESG has called for a review at the November, 1992 IETF meeting, with analysis according to a published set of criteria developed by the IESG, using community input. [3] The contenders will make presentations at the IETF meeting and the IESG will later issue its recommendation. With luck, a considerable degree of community preference will have developed by that time. Otherwise, the IESG decision may suffer inadequate community support. Evaluation Criteria The IESG list divides into the following categories: ? Changes Required: What is the basic technical work that must be done, to modify IP-related software to support a proposed alternative? This includes direct modification or replacement to the IP module, itself, in hosts and routers, but also includes concern for changes to directory, network management, and security services. In general, it is expected that support software will need to be modified, as will various operations and administration procedures. It should be noted that any change, no matter how small, requires that a new address format be supported. This well may be the most significant impact, and it is unavoidable. Note that protocol modules above IP, such as TCP and UDP, need to be able to pass the larger addresses to the IP module, as do user applications. In fact some applications, such as FTP and NFS, currently use IP addresses and will need changing. ? Implementation Experience: Simply put, what is the empirical evidence that supports the viability and appropriateness of the alternative? ? Large Internet Support: A goal of supporting 109 networks and 1010 hosts is cited. A proposed alternative needs to describe how its addressing structure will support these and what effect it will have upon routing architectures and tables. An essential concern is the way in which addresses will be administered. If IP addresses are to be sufficient for truly global communications, how will each user obtain their address? ? Performance Impact: IP has demonstrated a remarkable robustness for application in increasingly high-speed networks. There is, then, concern about the performance cost of any changes in IP. A proposed alternative will need to explore this issue carefully. ? Support for Unchanged IP Hosts: Changes cause incompat ibilities. Even if all systems eventually move to the new scheme, there will be a transition period. Related experience suggests that such a period will be extended, possibly on the order of 10 or more years. Hence, there is a concern for the interoperation between systems using the new scheme and systems continuing to use the current IP infrastructure. A proposed alternative needs to discuss its support for "late adopters". ? Impact on Installed Base of Users: Amidst the wide-ranging concerns for technical factors, it is easy to miss the likely impact of this change upon the people who work with IP technology, ranging from developers and network admin istrators, to customer support and sales staff. They repre sent a massive investment in training and expertise. The extent to which an alternative affects that training needs to be discussed. ? Deployment Plan: Since systems will not convert to a new scheme instantaneously a proposal needs to detail the methods by which the Internet and its constituents will convert to its use. ? Future Evolution: To what extent does an alternative support continued evolution of the IP fabric, into the arena of long- term issues mentioned above? Design considerations Routing protocols, and the theories of route calculation, remain a specialized topic with relatively few contributors. There has been significant effort in this area, recently, with the develop ment of OSPF, IS-IS, IDPR, IDRP and BGP. Happily, the current crisis does not seem to require major changes to these new protocols. The key requirement to facilitate large-scale routing is that addresses of Internet neighbors be related in a manner which allows reducing the number of table entries, for distant routers. This is generally agreed to require some sort of addressing hierarchy, such that the hierarchy relates to the "dominant" topological hierarchy. A hierarchy is a tree- structured orientation, yet networks permit "mesh" attachments between any two nodes. Hence, networks usually are not organized as strict hierarchies. However political, economic, and management constraints do tend to cause network interconnections to follow a hierarchy. In the United States, for example, users tend to attach to their organization's backbone, which in turn tends to attach to inter-organization providers. These may also subdivide into regional and long-haul carriers. In addition to the routing-related constraint upon design of the new address space, global administration and end-system uniqueness are requirements. The new addresses must be globally unique, as are the current IP addresses. There also is some debate about the distinction between addressing an end-system machine (or process) versus the current style of addressing the network interface of an end-system. Global administration requires a distributed basis for dividing the space, so that different places can assign unique addresses. Experience with administration of the Domain Name System suggests that hierarchical delegation of assignment authority is best. Any of the schemes that require more than 32 bits for addressing forces a change to the header format. Proposals range from simply modifying the current IP header to accommodate the additional bits, up to a complete re-working of the header, according to more modern views of efficiency and modularity. Styles of addressing A number of approaches to large-scale addressing are being discussed: ? Association-based: Curiously, one approach to solving this problem suggests that end systems continue to use 32-bit addresses, but that the network should consider them to refer to "associations" or end-system pairs, like a "connection id" in a virtual circuit protocol. At any given moment, it is unlikely that there will 4 billion IP-based "discussions" going on, so that the 32-bit address space may be large enough for uniqueness in identifying simultaneous conversations. This approach suggests retaining the current address field, but using it for such association ids, with routers performing address translation of an id into a series of routing decisions. This presumes some mechanism for establishing a temporary relationship between an id and a route. ? ID-based: Somewhat similar to Association-based, this uses long-term, globally-unique IDs which specify individual end- systems. IDs for neighboring end-systems may be entirely unrelated. Hence, these IDs are a form of end-system name, rather than address. Addressing information, used to develop a routing sequence, would be derived dynamically. This is felt to be particularly friendly in supporting mobile hosts, but there also is a question about placing a "name" into every IP datagram along with still-necessary addressing information. ? Provider-based: In the realm of classic global addressing, provider-based addresses would identify an end-system in terms of its attachment (or, more precisely, in terms of the end- system's network's attachment) to a given network service provider. For administrative ease, provider identification probably would be subdivided according to the country in which the provider is present. This leaves open the issue of referencing providers that are multi-national. The major criticism to provider-based addressing is that user networks would be required to change their addresses whenever they changed providers. There is concern that this might reduce competition. ? Geography-based: Also offered as a classic approach, geographic addresses are gobally unique, but specify the end- system (network) strictly in terms of its geographic location, on the theory that a geographic hierarchy is a reasonable approximation of the global Internet's major topology. Originally proposed by Steve Deering, of Xerox PARC who called them city codes, the major concern about geographic addressing is determination of the final provider to which the target end- system (network) is attached. The current proposal calls for inter-connection facilities, called Metropolitan Internet eXchanges (MIX) for the "last hop" hand-off to the target provider. ? Source-routed: Proposed by Dave Clark of MIT, a type of addressing which uses route fragments would specify a sequence of addresses. The concatenated sequence would be a kind of source route, but with large granularity, rather than specifying each hop along the way. This is spiritually related to the current Loose Source Route IP option. Proposals This article has discussed the nature of the impending and current problems, the process that will be used to evaluate proposals, and the types of technical choices that seem to be plausible. The remainder of this article briefly summarizes the major proposals that have been offered. It is remarkable that every single one of these alternatives appears to be entirely reasonable, according to a legitimate set of criteria. They have competent specifications and appear to be technically viable, on their own. For all that, the proposals are quite different, since they attend to different concerns. Hence, the Internet community is facing an extremely difficult decision. It cannot simply choose based upon the credibility of the people who are proponents or upon "political" concerns. The community needs to determine what factors are most significant to it. Once it does that, the technical choice is likely be straightforward. EIP Extended IP (EIP) was proposed by Zhen Wang, of University College London, and simply creates a new IP option which specifies the additional addressing bits that are needed.[7] There has been some debate about the performance impact of IP options, in routers, and in general, this proposal has not been the subject of sustained consideration within the IETF, though it represents the smallest imaginable change to the current IP format. IPAE IP Address Encapsulation (IPAE) has been proposed by Bob Hinden, of Sun Microsystems, and Dave Crocker, of The Branch Office. It retains the current IP format, but defines a mini-layer above IP and below the transport layer (TCP or UDP).[4] This mini-layer contains the new, larger global addresses for the source and the destination. Each commonwealth has its own 32-bit IP address space, within which the current 32-bit IP address behavior is retained. When the Internet runs out of 32-bit addresses, however, only those systems which have converted to full IPAE format will be able to communicate both within their commonwealth and to other commonwealths. IPAE addresses are likely to be proposed as a 12-octet hybrid of provider-based and geographic-based form with classic IP addresses in the last 4 octets. Discussion by the IPAE working group is on the mailing list: ip-encaps@sunroof.eng.sun.com SIP Simple IP (SIP) is a recent idea by Steve Deering. It retains IP, but make it simpler. It removes those IP fields that seem to be of little benefit, and retains those that clearly are needed. It proposes an 8-octet extended address, along geography/provider lines. Transition would fall into the category of "dual stack" in that an end-system and intervening routers would have to support old IP and new SIP, in order to talk with all hosts. CLNP Simple CLNP is the gist of the recommendation from the original ROAD group was to replace IP with ISO's Connectionless Network Layer Protocol, CLNP. This would have required use of other lower-layer OSI protocol's, but TCP, UDP, and the rest of the upper layers of the Internet protocols would be retained. The presumed strength of this proposal is its use of an international standard and the existence of some installed base. However, there is no operational TCP over CLNP and the conversion effort is not well understood. Classic 20-octet NSAP addresses were proposed. TUBA TCP/UDP over Bigger Addresses (TUBA) is being renamed to TCP/UDP on CLNP Addressed Networks (TUCAN) in order to place a reference to CLNP in its name. Written technical work has been provided by Ross Callon, of Digital Equipment Corp., and it proposes a conversion which is derived from CLNP but with changes appropriate for Internet usage.[1] Further details are provided by Dave Piscitello, of Bellcore.[5] The benefits of this approach are the same as for simple CLNP. One of its departures is use of ID-based addressing. Transition will require a "dual stack" operation, as discussed above. Discussion is on the mailing list: tuba@lanl.gov PIP The 'P' IP (PIP) has beeneveloped by Paul Tsuchiya, of Bellcore, and is a completely new internetworking protocol.[6] Header fields are divided into independent sections, such as for routing, versus handling. Transition requires dual stack operation. Very active discussion by the PIP working group is on the mailing list: pip@thumper.bellcore.com Nimrod New Routing and Addressing (Nimrod) is a routing architecture framework being developed by Noel Chiappa. It concerns itself less with header formats and more with basic issues in routing and derivative addressing structures. An addresses would be a hierarchical series of fields, derived from the "bottom" of the topology. Also supported would be end-point identifiers, along the lines of ID-based addressing. Summary This last section is decidedly not titled "Conclusions" because it is not possible to make any, yet. This section attempts a capsule description of the nature of the major proposals available to the Internet. It should be noted, however, that the specific addressing architecture proposals, with each header format proposal, could be replaced, so that some permutations and combinations may be worth considering. In any event, an undoubtedly biased summary of the options is: ? PIP is the most radical and offers the greatest opportunity for long-term functional enhancements. By virtue of its great changes and lack of any operational experience, it also offers the greatest risk. ? Nimrod is not tied to a specific format proposal, so that it may be possible to add a Nimrod routing and addressing scheme to PIP, TUBA or IPAE, if it can be developed and tested in time. ? TUBA pursues use of an existing protocol which is functionally similar to IP but already contains larger addresses. It is, however, also pursuing changes to those addresses. The primary strength of TUBA is its relationship to a well- documented international standard; its greatest weakness is its differences in detail from IP, beyond the necessary addressing differences. ? IPAE preserves current IP formats and software, imposing incremental changes only on those systems desiring full Internet connectivity. Its strength is the amount of software and training that will be retained. Its weakness is its apparent change to the Internet addressing model, by imposing a routing barrier between commonwealths. ? SIP preserves the gist of the current IP formats which are known to be needed and otherwise only changes the size of addresses. The strength of SIP is its apparent simplicity and familiarity; its weakness is its newness and lack of operational experience. References IETF rules prohibit the citation of documents contained in the volatile Internet Drafts directory of the Internet Repository, which is replicated in various places around the Internet. Nonetheless, it may be the only location for some of the docu ments cited here (with inadequate information). On the other hand, the reader may find that RFCs have since been issued for such documents. [1] Callon, R., "TCP/UDP over Bigger Addresses (TUBA)", Request for Comments 1347, Network Information Center, SRI International, Menlo Park, CA, May 1992. [2] "Supernetting: an Address Assignment and Aggregation Strategy", Vince Fuller, Tony Li, Jessica Yu, and Kannan Varadhan (March 9, 1992). [3] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing". [4] Hinden, R. and D. Crocker, "A Proposal for IP Address Encapsulation (IPAE): A Compatible Version of IP with Large Addresses". To be re-issued as "IP Address Encapsulation (IPAE): A Compatible Version of IP with Large Addresses" and "IPAE Implementation & Transition". [5] Piscitello, D., "Use of ISO CLNP in TUBA Environments". [6] Tsuchiya, P., "The 'P' Internet Protocol". [7] Wang, Z., "EIP: The Extended Internet Protocol a long-term solution to Internet address exhaustion". _______________________________ * This is a draft of an article to appear in Connections: The Interoperability Report