diff options
Diffstat (limited to 'doc/rfc/rfc1726.txt')
| -rw-r--r-- | doc/rfc/rfc1726.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc1726.txt b/doc/rfc/rfc1726.txt new file mode 100644 index 0000000..857e724 --- /dev/null +++ b/doc/rfc/rfc1726.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group C. Partridge +Request for Comments: 1726 BBN Systems and Technologies +Category: Informational F. Kastenholz + FTP Software + December 1994 + + Technical Criteria for Choosing + IP The Next Generation (IPng) + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document was submitted to the IPng Area in response to RFC 1550. + Publication of this document does not imply acceptance by the IPng + Area of any ideas expressed within. Comments should be submitted to + the big-internet@munnari.oz.au mailing list. This RFC specifies + criteria related to mobility for consideration in design and + selection of the Next Generation of IP. + +Table of Contents + + 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Note on Terminology . . . . . . . . . . . . . . . . . . . 4 + 4. General Principles. . . . . . . . . . . . . . . . . . . . 4 + 4.1 Architectural Simplicity. . . . . . . . . . . . . . . . . 4 + 4.2 One Protocol to Bind Them All . . . . . . . . . . . . . . 4 + 4.3 Live Long . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.4 Live Long AND Prosper . . . . . . . . . . . . . . . . . . 5 + 4.5 Co-operative Anarchy. . . . . . . . . . . . . . . . . . . 5 + 5. Criteria. . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.2 Topological Flexibility . . . . . . . . . . . . . . . . . 8 + 5.3 Performance . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.4 Robust Service. . . . . . . . . . . . . . . . . . . . . . 10 + 5.5 Transition. . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.6 Media Independence. . . . . . . . . . . . . . . . . . . . 13 + 5.7 Unreliable Datagram Service . . . . . . . . . . . . . . . 15 + 5.8 Configuration, Administration, and Operation. . . . . . . 16 + 5.9 Secure Operation. . . . . . . . . . . . . . . . . . . . . 17 + 5.10 Unique Naming . . . . . . . . . . . . . . . . . . . . . . 18 + 5.11 Access. . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.12 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 20 + + + +Partridge and Kastenholz [Page 1] + +RFC 1726 IPng Technical Criteria December 1994 + + + 5.13 Extensibility . . . . . . . . . . . . . . . . . . . . . . 21 + 5.13.1 Algorithms. . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.13.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.13.3 Data Structures . . . . . . . . . . . . . . . . . . . . . 22 + 5.13.4 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.14 Network Service . . . . . . . . . . . . . . . . . . . . . 22 + 5.15 Support for Mobility. . . . . . . . . . . . . . . . . . . 24 + 5.16 Control Protocol. . . . . . . . . . . . . . . . . . . . . 25 + 5.17 Private Networks. . . . . . . . . . . . . . . . . . . . . 25 + 6. Things We Chose Not to Require. . . . . . . . . . . . . . 26 + 6.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 26 + 6.2 IP Header Checksum. . . . . . . . . . . . . . . . . . . . 26 + 6.3 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 27 + 6.4 Network Management. . . . . . . . . . . . . . . . . . . . 27 + 6.5 Accounting. . . . . . . . . . . . . . . . . . . . . . . . 27 + 6.6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 6.6.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.6.2 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.6.3 QOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.6.4 Feedback. . . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.6.5 Stability . . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.6.6 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . 29 + 8. Security Considerations . . . . . . . . . . . . . . . . . 30 + 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . 30 + 10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . 31 + +1. Introduction + + This version of this memo was commissioned by the IPng area of the + IETF in order to define a set of criteria to be used in evaluating + the protocols being proposed for adoption as the next generation of + IP. + + The criteria presented here were culled from several sources, + including "IP Version 7" [1], "IESG Deliberations on Routing and + Addressing" [2], "Towards the Future Internet Architecture" [3], the + IPng Requirements BOF held at the Washington D.C. IETF Meeting in + December of 1992, the IPng Working Group meeting at the Seattle IETF + meeting in March 1994, the discussions held on the Big-Internet + mailing list (big-internet@munnari.oz.au, send requests to join to + big-internet-request@munnari.oz.au), discussions with the IPng Area + Directors and Directorate, and the mailing lists devoted to the + individual IPng efforts. + + This document presumes that a new IP-layer protocol is actually + desired. There is some discussion in the community as to whether we + can extend the life of IPv4 for a significant amount of time by + + + +Partridge and Kastenholz [Page 2] + +RFC 1726 IPng Technical Criteria December 1994 + + + better engineering of, e.g., routing protocols, or we should develop + IPng now. This question is not addressed in this document. + + We would like to gratefully acknowledge the assistance of literally + hundreds of people who shared their views and insights with us. + However, this memo is solely the personal opinion of the authors and + in no way represents, nor should it be construed as representing, the + opinion of the ISOC, the IAB, the IRTF, the IESG, the IETF, the + Internet community as a whole, nor the authors' respective employers. + +2. Goals + + We believe that by developing a list of criteria for evaluating + proposals for IP The Next Generation (IPng), the IETF will make it + easier for developers of proposals to prioritize their work and + efforts and make reasoned choices as to where they should spend + relatively more and less time. Furthermore, a list of criteria may + help the IETF community determine which proposals are serious + contenders for a next generation IP, and which proposals are + insufficient to the task. Note that these criteria are probably not + sufficient to make final decisions about which proposal is best. + Questions such as whether to trade a little performance (e.g., + packets per second routed) for slightly more functionality (e.g., + more flexible routing) cannot be easily addressed by a simple list of + criteria. However, at minimum, we believe that protocols that meet + these criteria are capable of serving as the future IPng. + + This set of criteria originally began as an ordered list, with the + goal of ranking the importance of various criteria. Eventually, the + layout evolved into the current form, where each criterion was + presented without weighting, but a time frame, indicating + approximately when a specific criterion, or feature of a criterion, + should be available was added to the specification. + + We have attempted to state the criteria in the form of goals or + requirements and not demand specific engineering solutions. For + example, there has been talk in the community of making route + aggregation a requirement. We believe that route aggregation is not, + in and of itself, a requirement but rather one part of a solution to + the real problem of scaling to some very large, complex topology. + Therefore, route aggregation is NOT listed as a requirement; instead, + the more general functional goal of having the routing scale is + listed instead of the particular mechanism of route aggregation. + + In determining the relative timing of the various criteria, we have + had two guiding principles. First, IPng must offer an internetwork + service akin to that of IPv4, but improved to handle the well-known + and widely-understood problems of scaling the Internet architecture + + + +Partridge and Kastenholz [Page 3] + +RFC 1726 IPng Technical Criteria December 1994 + + + to more end-points and an ever increasing range of bandwidths. + Second, it must be desirable for users and network managers to + upgrade their equipment to support IPng. At a minimum, this second + point implies that there must be a straightforward way to transition + systems from IPv4 to IPng. But it also strongly suggests that IPng + should offer features that IPv4 does not; new features provide a + motivation to deploy IPng more quickly. + +3. Note on Terminology + + The existing proposals tend distinguish between end-point + identification of, e.g., individual hosts, and topological addresses + of network attachment points. In this memo we do not make that + distinction. We use the term "address" as it is currently used in + IPv4; i.e., for both the identification of a particular endpoint or + host AND as the topological address of a point on the network. We + presume that if the endpoint/ address split remains, the proposals + will make the proper distinctions with respect to the criteria + enumerated below. + +4. General Principles + +4.1 Architectural Simplicity + + In anything at all, perfection is finally attained not + when there is no longer anything to add, but when there + is no longer anything to take away. + + Antoine de Saint-Exupery + + We believe that many communications functions are more appropriately + performed at protocol layers other than the IP layer. We see + protocol stacks as hourglass-shaped, with IPng in the middle, or + waist, of the hourglass. As such, essentially all higher-layer + protocols make use of and rely upon IPng. Similarly IPng, by virtue + of its position in the "protocol hourglass" encompasses a wide + variety of lower-layer protocols. When IPng does not perform a + particular function or provide a certain service, it should not get + in the way of the other elements of the protocol stack which may well + wish to perform the function. + +4.2 One Protocol to Bind Them All + + One of the most important aspects of The Internet is that it provides + global IP-layer connectivity. The IP layer provides the point of + commonality among all of the nodes on the Internet. In effect, the + main goal of the Internet is to provide an IP Connectivity Service to + all who wish it. + + + +Partridge and Kastenholz [Page 4] + +RFC 1726 IPng Technical Criteria December 1994 + + + This does NOT say that the Internet is a One-Protocol Internet. The + Internet is today, and shall remain in the future, a Multi-Protocol + Internet. Multi-Protocol operations are required to allow for + continued testing, experimentation, and development and because + service providers' customers clearly want to be able to run protocols + such as CLNP, DECNET, and Novell over their Internet connections. + +4.3 Live Long + + It is very difficult to change a protocol as central to the workings + of the Internet as IP. Even more problematic is changing such a + protocol frequently. This simply can not be done. We believe that it + is impossible to expect the community to make significant, non- + backward compatible changes to the IP layer more often than once + every 10-15 years. In order to be conservative, we strongly urge + protocol developers to consider what the Internet will look like in + 20 years and design their protocols to fit that vision. + + As a data point, the SNMP community has had great difficulty moving + from SNMPv1 to SNMPv2. Frequent changes in software are hard. + +4.4 Live Long AND Prosper + + We believe that simply allowing for bigger addresses and more + efficient routing is not enough of a benefit to encourage vendors, + service providers, and users to switch to IPng, with its attendant + disruptions of service, etc. These problems can be solved much more + simply with faster routers, balkanization of the Internet address + space, and other hacks. + + We believe that there must be positive functional or operational + benefits to switching to IPng. + + In other words, IPng must be able to live for a long time AND it must + allow the Internet to prosper and to grow to serve new applications + and user needs. + +4.5 Co-operative Anarchy + + A major contributor to the Internet's success is the fact that there + is no single, centralized, point of control or promulgator of policy + for the entire network. This allows individual constituents of the + network to tailor their own networks, environments, and policies to + suit their own needs. The individual constituents must cooperate + only to the degree necessary to ensure that they interoperate. + + + + + + +Partridge and Kastenholz [Page 5] + +RFC 1726 IPng Technical Criteria December 1994 + + + We believe that this decentralized and decoupled nature of the + Internet must be preserved. Only a minimum amount of centralization + or forced cooperation will be tolerated by the community as a whole. + + We also believe that there are some tangible benefits to this + decoupled nature. For example, + + * It is easier to experiment with new protocols and services and then + roll out intermediate and final results in a controlled fashion. + * By eliminating a single point of control, a single point of failure + is also eliminated, making it much less likely that the entire + network will fail. + * It allows the administrative tasks for the network to be more + widely distributed. + + An example of the benefits of this "Cooperative Anarchy" can be seen + in the benefits derived from using the Domain Naming System over the + original HOSTS.TXT system. + +5. Criteria + + This section enumerates the criteria against which we suggest the IP + The Next Generation proposals be evaluated. + + Each criterion is presented in its own section. The first paragraph + of each section is a short, one or two sentence statement of the + criterion. Additional paragraphs then explain the criterion in more + detail, clarify what it does and does not say and provide some + indication of its relative importance. + + Also, each criterion includes a subsection called "Time Frame". This + is intended to give a rough indication of when the authors believe + that the particular criterion will become "important". We believe + that if an element of technology is significant enough to include in + this document then we probably understand the technology enough to + predict how important that technology will be. In general, these + time frames indicate that, within the desired time frame, we should + be able to get an understanding of how the feature will be added to a + protocol, perhaps after discussions with the engineers doing the + development. Time Frame is not a deployment schedule since + deployment schedules depend on non-technical issues, such as vendors + determining whether a market exists, users fitting new releases into + their systems, and so on. + + + + + + + + +Partridge and Kastenholz [Page 6] + +RFC 1726 IPng Technical Criteria December 1994 + + +5.1 Scale + + CRITERION + The IPng Protocol must scale to allow the identification and + addressing of at least 10**12 end systems (and preferably much + more). The IPng Protocol, and its associated routing protocols + and architecture must allow for at least 10**9 individual networks + (and preferably more). The routing schemes must scale at a rate + that is less than the square root of the number of constituent + networks [10]. + + DISCUSSION + The initial, motivating, purpose of the IPng effort is to allow + the Internet to grow beyond the size constraints imposed by the + current IPv4 addressing and routing technologies. + + Both aspects of scaling are important. If we can't route then + connecting all these hosts is worthless, but without connected + hosts, there's no point in routing, so we must scale in both + directions. + + In any proposal, particular attention must be paid to describing + the routing hierarchy, how the routing and addressing will be + organized, how different layers of the routing interact, and the + relationship between addressing and routing. + + Particular attention must be paid to describing what happens when + the size of the network approaches these limits. How are network, + forwarding, and routing performance affected? Does performance + fall off or does the network simply stop as the limit is neared. + + This criterion is the essential problem motivating the transition + to IPng. If the proposed protocol does not satisfy this criteria, + there is no point in considering it. + + We note that one of the white papers solicited for the IPng + process [5] indicates that 10**12 end nodes is a reasonable + estimate based on the expected number of homes in the world and + adding two orders of magnitude for "safety". However, this white + paper treats each home in the world as an end-node of a world-wide + Internet. We believe that each home in the world will in fact be + a network of the world-wide Internet. Therefore, if we take [5]'s + derivation of 10**12 as accurate, and change their assumption that + a home will be an end-node to a home being a network, we may + expect that there will be the need to support at least 10**12 + networks, with the possibility of supporting up to 10**15 end- + nodes. + + + + +Partridge and Kastenholz [Page 7] + +RFC 1726 IPng Technical Criteria December 1994 + + + Time Frame + Any IPng proposal should be able to show immediately that it has + an architecture for the needed routing protocols, addressing + schemes, abstraction techniques, algorithms, data structures, and + so on that can support growth to the required scales. + + Actual development, specification, and deployment of the needed + protocols can be deferred until IPng deployment has extended far + enough to require such protocols. A proposed IPng should be able + to demonstrate ahead of time that it can scale as needed. + +5.2 Topological Flexibility + + CRITERION + The routing architecture and protocols of IPng must allow for many + different network topologies. The routing architecture and + protocols must not assume that the network's physical structure is + a tree. + + DISCUSSION + As the Internet becomes ever more global and ubiquitous, it will + develop new and different topologies. We already see cases where + the network hierarchy is very "broad" with many subnetworks, each + with only a few hosts and where it is very "narrow", with few + subnetworks each with many hosts. We can expect these and other + topological forms in the future. Furthermore, since we expect + that IPng will allow for many more levels of hierarchy than are + allowed under IPv4, we can expect very "tall" and very "short" + topologies as well. + + Constituent organizations of the Internet should be allowed to + structure their internal topologies in any manner they see fit. + Within reasonable implementation limits, organizations should be + allowed to structure their addressing in any manner. We + specifically wish to point out that if the network's topology or + addressing is hierarchical, constituent organizations should be + able to allocate to themselves as many levels of hierarchy as they + wish. + + It is very possible that the diameter of the Internet will grow to + be extremely large; perhaps larger than 256 hops. + + Neither the current, nor the future, Internet will be physically + structured as a tree, nor can we assume that connectivity can + occur only between certain points in the graph. The routing and + addressing architectures must allow for multiply connected + networks and be able to utilize multiple paths for any reason, + including redundancy, load sharing, type- and quality-of-service + + + +Partridge and Kastenholz [Page 8] + +RFC 1726 IPng Technical Criteria December 1994 + + + differentiation. + + Time Frame + We believe that Topological Flexibility is an inherent element of + a protocol and therefore should be immediately demonstrable in an + IPng proposal. + +5.3 Performance + + CRITERION + A state of the art, commercial grade router must be able to + process and forward IPng traffic at speeds capable of fully + utilizing common, commercially available, high-speed media at the + time. Furthermore, at a minimum, a host must be able to achieve + data transfer rates with IPng comparable to the rates achieved + with IPv4, using similar levels of host resources. + + DISCUSSION + Network media speeds are constantly increasing. It is essential + that the Internet's switching elements (routers) be able to keep + up with the media speeds. + + We limit this requirement to commercially available routers and + media. If some network site can obtain a particular media + technology "off the shelf", then it should also be able to obtain + the needed routing technology "off the shelf." One can always go + into some laboratory or research center and find newer, faster, + technologies for network media and for routing. We do believe, + however, that IPng should be routable at a speed sufficient to + fully utilize the fastest available media, though that might + require specially built, custom, devices. + + We expect that more and more services will be available over the + Internet. It is not unreasonable, therefore, to expect that the + ratio of "local" traffic (i.e., the traffic that stays on one's + local network) to "export" traffic (i.e., traffic destined to or + sourced from a network other than one's own local network) will + change, and the percent of export traffic will increase. + + We note that the host performance requirement should not be taken + to imply that IPng need only be as good as IPv4. If an IPng + candidate can achieve better performance with equivalent resources + (or equivalent transfer rates with fewer resources) vis-a-vis IPv4 + then so much the better. We also observe that many researchers + believe that a proper IPng router should be capable of routing + IPng traffic over links at speeds that are capable of fully + utilizing an ATM switch on the link. + + + + +Partridge and Kastenholz [Page 9] + +RFC 1726 IPng Technical Criteria December 1994 + + + Some developments indicate that the use of very high speed point- + to-point connections may become commonplace. In particular, [5] + indicates that OC-3 speeds may be widely used in the Cable TV + Industry and there may be many OC-3 speed lines connecting to + central switching elements. + + Processing of the IPng header, and subsequent headers (such as the + transport header), can be made more efficient by aligning fields + on their natural boundaries and making header lengths integral + multiples of typical word lengths (32, 64, and 128 bits have been + suggested) in order to preserve alignment in following headers. + + We point out that optimizing the header's fields and lengths only + to today's processors may not be sufficient for the long term. + Processor word and cache-line lengths, and memory widths are + constantly increasing. In doing header optimizations, the + designer should predict word-widths one or two CPU generations + into the future and optimize accordingly. If IPv4 and TCP had been + optimized for processors common when they were designed, they + would be very efficient for 6502s and Z-80s. + + Time Frame + An IPng proposal must provide a plausible argument of how it will + scale up in performance. (Obviously no one can completely predict + the future, but the idea is to illustrate that if technology + trends in processor performance and memory performance continue, + and perhaps using techniques like parallelism, there is reason to + believe the proposed IPng will scale as technology scales). + +5.4 Robust Service + + CRITERION + The network service and its associated routing and control + protocols must be robust. + + DISCUSSION + Murphy's Law applies to networking. Any proposed IPng protocol + must be well-behaved in the face of malformed packets, mis- + information, and occasional failures of links, routers and hosts. + IPng should perform gracefully in response to willful management + and configuration mistakes (i.e., service outages should be + minimized). + + Putting this requirement another way, IPng must make it possible + to continue the Internet tradition of being conservative in what + is sent, but liberal in what one is willing to receive. + + + + + +Partridge and Kastenholz [Page 10] + +RFC 1726 IPng Technical Criteria December 1994 + + + We note that IPv4 is reasonably robust and any proposed IPng must + be at least as robust as IPv4. + + Hostile attacks on the network layer and Byzantine failure modes + must be dealt with in a safe and graceful manner. + + We note that Robust Service is, in some form, a part of security + and vice-versa. + + The detrimental effects of failures, errors, buggy + implementations, and misconfigurations must be localized as much + as possible. For example, misconfiguring a workstation's IP + Address should not break the routing protocols. in the event of + misconfigurations, IPng must to be able to detect and at least + warn, if not work around, any misconfigurations. + + Due to its size, complexity, decentralized administration, error- + prone users and administrators, and so on, The Internet is a very + hostile environment. If a protocol can not be used in such a + hostile environment then it is not suitable for use in the + Internet. + + Some predictions have been made that, as the Internet grows and as + more and more technically less-sophisticated sites get connected, + there will be more failures in the network. These failures may be + a combination of simple size; if the size of the network goes up + by a factor of n, then the total number of failures in the network + can be expected to increase by some function of n. Also, as the + network's users become less sophisticated, it can be assumed that + they will make more, innocent and well meaning, mistakes, either + in configuration or use of their systems. + + The IPng protocols should be able to continue operating in an + environment that suffers more, total, outages than we are + currently used to. Similarly, the protocols must protect the + general population from errors (either of omission or commission) + made by individual users and sites. + + Time Frame + We believe that the elements of Robust Service should be available + immediately in the protocol with two exceptions. + + The security aspects of Robust Service are, in fact, described + elsewhere in this document. + + + + + + + +Partridge and Kastenholz [Page 11] + +RFC 1726 IPng Technical Criteria December 1994 + + + Protection against Byzantine failure modes is not needed + immediately. A proposed architecture for it should be done + immediately. Prototype development should be completed in 12-18 + months, with final deployment as needed. + +5.5 Transition + + CRITERION + The protocol must have a straightforward transition plan from the + current IPv4. + + DISCUSSION + A smooth, orderly, transition from IPv4 to IPng is needed. If we + can't transition to the new protocol, then no matter how wonderful + it is, we'll never get to it. + + We believe that it is not possible to have a "flag-day" form of + transition in which all hosts and routers must change over at + once. The size, complexity, and distributed administration of the + Internet make such a cutover impossible. + + Rather, IPng will need to co-exist with IPv4 for some period of + time. There are a number of ways to achieve this co-existence + such as requiring hosts to support two stacks, converting between + protocols, or using backward compatible extensions to IPv4. Each + scheme has its strengths and weaknesses, which have to be weighed. + + Furthermore, we note that, in all probability, there will be IPv4 + hosts on the Internet effectively forever. IPng must provide + mechanisms to allow these hosts to communicate, even after IPng + has become the dominant network layer protocol in the Internet. + + The absence of a rational and well-defined transition plan is not + acceptable. Indeed, the difficulty of running a network that is + transitioning from IPv4 to IPng must be minimized. (A good target + is that running a mixed IPv4-IPng network should be no more and + preferably less difficult than running IPv4 in parallel with + existing non-IP protocols). + + Furthermore, a network in transition must still be robust. IPng + schemes which maximize stability and connectivity in mixed IPv4- + IPng networks are preferred. + + Finally, IPng is expected to evolve over time and therefore, it + must be possible to have multiple versions of IPng, some in + production use, some in experimental, developmental, or evaluation + use, to coexist on the network. Transition plans must address + this issue. + + + +Partridge and Kastenholz [Page 12] + +RFC 1726 IPng Technical Criteria December 1994 + + + The transition plan must address the following general areas of + the Internet's infrastructure: + + Host Protocols and Software + Router Protocols and Software + Security and Authentication + Domain Name System + Network Management + Operations Tools (e.g., Ping and Traceroute) + Operations and Administration procedures + + The impact on protocols which use IP addresses as data (e.g., DNS, + distributed file systems, SNMP and FTP) must be specifically + addressed. + + The transition plan should address the issue of cost distribution. + That is, it should identify what tasks are required of the service + providers, of the end users, of the backbones and so on. + + Time Frame + A transition plan is required immediately. + +5.6 Media Independence + + CRITERION + The protocol must work across an internetwork of many different + LAN, MAN, and WAN media, with individual link speeds ranging from + a ones-of-bits per second to hundreds of gigabits per second. + Multiple-access and point-to-point media must be supported, as + must media supporting both switched and permanent circuits. + + DISCUSSION + The joy of IP is that it works over just about anything. This + generality must be preserved. The ease of adding new + technologies, and ability to continue operating with old + technologies must be maintained. + + We believe this range of speed is right for the next twenty years, + though we may wish to require terabit performance at the high-end. + We believe that, at a minimum, media running at 500 gigabits per + second will be commonly available within 10 years. The low end of + the link-speed range is based on the speed of systems like pagers + and ELF (ELF connects to submerged submarines and has a "speed" on + the order of <10 characters per second). + + By switched circuits we mean both "permanent" connections such as + X.25 and Frame Relay services AND "temporary" types of dialup + connections similar to today's SLIP and dialup PPP services, and + + + +Partridge and Kastenholz [Page 13] + +RFC 1726 IPng Technical Criteria December 1994 + + + perhaps, ATM SVCs. The latter form of connection implies that + dynamic network access (i.e., the ability to unplug a machine, + move it to a different point on the network topology, and plug it + back in, possibly with a changed IPng address) is required. We + note that this is an aspect of mobility. + + By work, we mean we have hopes that a stream of IPng datagrams + (whether from one source, or many) can come close to filling the + link at high speeds, but also scales gracefully to low speeds. + + Many network media are multi-protocol. It is essential that IPng + be able to peacefully co-exist on such media with other protocols. + Routers and hosts must be able to discriminate among the protocols + that might be present on such a medium. For example, on an + Ethernet, a specific, IPng Ethernet Type value might be called + for; or the old IPv4 Ethernet type is used and the first four + (version number in the old IPv4 header) bits would distinguish + between IPv4 and IPng. + + Different media have different MAC address formats and schemes. + It must be possible for a node to dynamically determine the MAC + address of a node given that node's IP address. We explicitly + prohibit using static, manually configured mappings as the + standard approach. + + Another aspect of this criterion is that many different MTUs will + be found in an IPng internetwork. An IPng must be able to operate + in such a multi-MTU environment. It must be able to adapt to the + MTUs of the physical media over which it operates. Two possible + techniques for dealing with this are path MTU discovery and + fragmentation and reassembly; other techniques might certainly be + developed. + + We note that, as of this writing (mid 1994), ATM seems to be set + to become a major network media technology. Any IPng should be + designed to operate over ATM. However, IPng still must be able to + operate over other, more "traditional" network media. + Furthermore, a host on an ATM network must be able to interoperate + with a host on another, non-ATM, medium, with no more difficulty + or complexity than hosts on different media can interoperate today + using IPv4. + + IPng must be able to deal both with "dumb" media, such as we have + today, and newer, more intelligent, media. In particular, IPng + functions must be able to exist harmoniously with lower-layer + realizations of the same, or similar, functions. Routing and + resource management are two areas where designers should pay + particular attention. Some subnetwork technologies may include + + + +Partridge and Kastenholz [Page 14] + +RFC 1726 IPng Technical Criteria December 1994 + + + integral accounting and billing capabilities, and IPng must + provide the correct control information to such subnetworks. + + Time Frame + Specifications for current media encapsulations (i.e., all + encapsulations that are currently Proposed standards, or higher, + in the IETF) are required immediately. These specifications must + include any auxiliary protocols needed (such as an address + resolution mechanism for Ethernet or the link control protocol for + PPP). A general 'guide' should also be available immediately to + help others develop additional media encapsulations. Other, + newer, encapsulations can be developed as the need becomes + apparent. + + Van Jacobson-like header compression should be shown immediately, + as should any other aspects of very-low-speed media. Similarly, + any specific aspects of high-speed media should be shown + immediately. + +5.7 Unreliable Datagram Service + + CRITERION + The protocol must support an unreliable datagram delivery service. + + DISCUSSION + We like IP's datagram service and it seems to work very well. So + we must keep it. In particular, the ability, within IPv4, to send + an independent datagram, without prearrangement, is extremely + valuable (in fact, may be required for some applications such as + SNMP) and must be retained. + + Furthermore, the design principle that says that we can take any + datagram and throw it away with no warning or other action, or + take any router and turn it off with no warning, and have datagram + traffic still work, is very powerful. This vastly enhances the + robustness of the network and vastly eases administration and + maintenance of the network. It also vastly simplifies the design + and implementation of software [14]. + + Furthermore, the Unreliable Datagram Service should support some + minimal level of service; something that is approximately + equivalent to IPv4 service. This has two functions; it eases the + task of IPv4/IPng translating systems in mapping IPv4 traffic to + IPng and vice versa, and it simplifies the task of fitting IPng + into small, limited environments such as boot ROMs. + + Time Frame + Unreliable Datagram Service must be available immediately. + + + +Partridge and Kastenholz [Page 15] + +RFC 1726 IPng Technical Criteria December 1994 + + +5.8 Configuration, Administration, and Operation + + CRITERION + The protocol must permit easy and largely distributed + configuration and operation. Automatic configuration of hosts and + routers is required. + + DISCUSSION + People complain that IP is hard to manage. We cannot plug and + play. We must fix that problem. + + We do note that fully automated configuration, especially for + large, complex networks, is still a topic of research. Our + concern is mostly for small and medium sized, less complex, + networks; places where the essential knowledge and skills would + not be as readily available. + + In dealing with this criterion, address assignment and delegation + procedures and restrictions should be addressed by the proposal. + Furthermore, "ownership" of addresses (e.g., user or service + provider) has recently become a concern and the issue should be + addressed. + + We require that a node be able to dynamically obtain all of its + operational, IP-level parameters at boot time via a dynamic + configuration mechanism. + + A host must be able to dynamically discover routers on the host's + local network. Ideally, the information which a host learns via + this mechanism would also allow the host to make a rational + selection of which first-hop router to send any given packet to. + IPng must not mandate that users or administrators manually + configure first-hop routers into hosts. + + Also, a strength of IPv4 has been its ability to be used on + isolated subnets. IPng hosts must be able to work on networks + without routers present. + + Additional elements of this criterion are: + + * Ease of address allocation. + * Ease of changing the topology of the network within a particular + routing domain. + * Ease of changing network provider. + * Ease of (re)configuring host/endpoint parameters such as + addressing and identification. + * Ease of (re)configuring router parameters such as addressing and + identification. + + + +Partridge and Kastenholz [Page 16] + +RFC 1726 IPng Technical Criteria December 1994 + + + * Address allocation and assignment authority must be delegated as + far 'down' the administrative hierarchy as possible. + + The requirements of this section apply only to IPng and its + supporting protocols (such as for routing, address resolution, and + network-layer control). Specifically, as far as IPng is + concerned, we are concerned only with how routers and hosts get + their configuration information. + + We note that in general, automatic configuration of hosts is a + large and complex problem and getting the configuration + information into hosts and routers is only one, small, piece of + the problem. A large amount of additional, non-Internet-layer + work is needed in order to be able to do "plug-and-play" + networking. Other aspects of "plug-and-play" networking include + things like: Autoregistration of new nodes with DNS, configuring + security service systems (e.g., Kerberos), setting up email relays + and mail servers, locating network resources, adding entries to + NFS export files, and so on. To a large degree, these + capabilities do not have any dependence on the IPng protocol + (other than, perhaps, the format of addresses). + + We require that any IPng proposal not impede or prevent, in any + way, the development of "plug-and-play" network configuration + technologies. + + Automatic configuration of network nodes must not prevent users or + administrators from also being able to manually configure their + systems. + + Time Frame + A method for plug and play on small subnets is immediately + required. + + We believe that this is an extremely critical area for any IPng as + a major complaint of the IP community as a whole is the difficulty + in administering large IP networks. Furthermore, ease of + installation is likely to speed the deployment of IPng. + +5.9 Secure Operation + + CRITERION + IPng must provide a secure network layer. + + DISCUSSION + We need to be sure that we have not created a network that is a + cracker's playground. + + + + +Partridge and Kastenholz [Page 17] + +RFC 1726 IPng Technical Criteria December 1994 + + + In order to meet the Robustness criterion, some elements of what + is commonly shrugged off as "security" are needed; e.g., to prevent + a villain from injecting bogus routing packets, and destroying the + routing system within the network. This criterion covers those + aspects of security that are not needed to provide the Robustness + criterion. + + Another aspect of security is non-repudiation of origin. In order + to adequately support the expected need for simple accounting, we + believe that this is a necessary feature. + + In order to safely support requirements of the commercial world, + IPng-level security must have capabilities to prevent + eavesdroppers from monitoring traffic and deducing traffic + patterns. This is particularly important in multi-access networks + such as cable TV networks [5]. + + Aspects of security at the IP level to be considered include: + + * Denial of service protections [6], + * Continuity of operations [6], + * Precedence and preemption [6], + * Ability to allow rule-based access control technologies [6] + * Protection of routing and control-protocol operations [9], + * Authentication of routing information exchanges, packets, data, + and sources (e.g., make sure that the routing packet came from a + router) [9], + * QOS security (i.e., protection against improper use of network- + layer resources, functions, and capabilities), + * Auto-configuration protocol operations in that the host must be + assured that it is getting its information from proper sources, + * Traffic pattern confidentiality is strongly desired by several + communities [9] and [5]. + + Time Frame + Security should be an integral component of any IPng from the + beginning. + +5.10 Unique Naming + + CRITERION + IPng must assign all IP-Layer objects in the global, ubiquitous, + Internet unique names. These names may or may not have any + location, topology, or routing significance. + + DISCUSSION + We use the term "Name" in this criterion synonymously with the + term "End Point Identifier" as used in the NIMROD proposal, or as + + + +Partridge and Kastenholz [Page 18] + +RFC 1726 IPng Technical Criteria December 1994 + + + IP Addresses uniquely identify interfaces/hosts in IPv4. These + names may or may not carry any routing or topology information. + See [11] for more discussion on this topic. + + IPng must provide identifiers which are suitable for use as + globally unique, unambiguous, and ubiquitous names for endpoints, + nodes, interfaces, and the like. Every datagram must carry the + identifier of both its source and its destination (or some method + must be available to determine these identifiers, given a + datagram). We believe that this is required in order to support + certain accounting functions. + + Other functions and uses of unique names are: + + * To uniquely identify endpoints (thus if the unique name and + address are not the same, the TCP pseudo-header should include + the unique name rather than the address) + * To allow endpoints to change topological location on the network + (e.g., migrate) without changing their unique names. + * To give one or more unique names to a node on the network (i.e., + one node may have multiple unique names) + + An identifier must refer to one and only one object while that + object is in existence. Furthermore, after an object ceases to + exist, the identifier should be kept unused long enough to ensure + that any packets containing the identifier have drained out of the + Internet system, and that other references to the identifier have + probably been lost. We note that the term "existence" is as much + an administrative issue as a technical one. For example, if a + workstation is reassigned, given a new IP address and node name, + and attached to a new subnetwork, is it the same object or not. + This does argue for a namespace that is relatively large and + relatively stable. + + Time Frame + We see this as a fundamental element of the IP layer and it should + be in the protocol from the beginning. + +5.11 Access + + CRITERION + The protocols that define IPng, its associated protocols (similar + to ARP and ICMP in IPv4) and the routing protocols (as in OSPF, + BGP, and RIP for IPv4) must be published as standards track RFCs + and must satisfy the requirements specified in RFC1310. These + documents should be as freely available and redistributable as the + IPv4 and related RFCs. There must be no specification-related + licensing fees for implementing or selling IPng software. + + + +Partridge and Kastenholz [Page 19] + +RFC 1726 IPng Technical Criteria December 1994 + + + DISCUSSION + An essential aspect of the development of the Internet and its + protocols has been the fact that the protocol specifications are + freely available to anyone who wishes a copy. Beyond simply + minimizing the cost of learning about the technology, the free + access to specifications has made it easy for researchers and + developers to easily incorporate portions of old protocol + specifications in the revised specifications. This type of easy + access to the standards documents is required for IPng. + + Time Frame + An IPng and its related protocols must meet these standards for + openness before an IPng can be approved. + +5.12 Multicast + + CRITERION + The protocol must support both unicast and multicast packet + transmission. Part of the multicast capability is a requirement + to be able to send to "all IP hosts on a given subnetwork". + Dynamic and automatic routing of multicasts is also required. + + DISCUSSION + IPv4 has made heavy use of the ability to multicast requests to + all IPv4 hosts on a subnet, especially for autoconfiguration. + This ability must be retained in IPng. + + Unfortunately, IPv4 currently uses the local media broadcast + address to multicast to all IP hosts. This behavior is anti- + social in mixed-protocol networks and should be fixed in IPng. + There's no good reason for IPng to send to all hosts on a subnet + when it only wishes to send to all IPng hosts. The protocol must + make allowances for media that do not support true multicasting. + + In the past few years, we have begun to deploy support for wide- + area multicast addressing in the Internet, and it has proved + valuable. This capability must not be lost in the transition to + IPng. + + The ability to restrict the range of a multicast to specific + networks is also important. Furthermore, it must be possible to + "selectively" multicast packets. That is, it must be possible to + send a multicast to a remote, specific portion or area of the + Internet (such as a specific network or subnetwork) and then have + that multicast limited to just that specific area. Furthermore, + any given network or subnetwork should be capable of supporting + 2**16 "local" multicast groups, i.e., groups that are not + propagated to other networks. See [8]. + + + +Partridge and Kastenholz [Page 20] + +RFC 1726 IPng Technical Criteria December 1994 + + + It should be noted that addressing -- specifically the syntax and + semantics of addresses -- has a great impact on the scalability of + the architecture. + + Currently, large-scale multicasts are routed manually through the + Internet. While this is fine for experiments, a "production" + system requires that multicast-routing be dynamic and automatic. + Multicast groups must be able to be created and destroyed, hosts + must be able to join and leave multicast groups and the network + routing infrastructure must be able to locate new multicast groups + and destinations and route traffic to those destinations all + without manual intervention. + + Large, topologically dispersed, multicast groups (with up to 10**6 + participants) must be supported. Some applications are given in + [8]. + + Time Frame + Obviously, address formats, algorithms for processing and + interpreting the multicast addresses must be immediately available + in IPng. Broadcast and Multicast transmission/reception of + packets are required immediately. Dynamic routing of multicast + packets must be available within 18 months. + + We believe that Multicast Addressing is vital to support future + applications such as remote conferencing. It is also used quite + heavily in the current Internet for things like service location + and routing. + +5.13 Extensibility + + CRITERION + The protocol must be extensible; it must be able to evolve to meet + the future service needs of the Internet. This evolution must be + achievable without requiring network-wide software upgrades. IPng + is expected to evolve over time. As it evolves, it must be able to + allow different versions to coexist on the same network. + + DISCUSSION + We do not today know all of the things that we will want the + Internet to be able to do 10 years from now. At the same time, it + is not reasonable to ask users to transition to a new protocol + with each passing decade. Thus, we believe that it must be + possible to extend IPng to support new services and facilities. + Furthermore, it is essential that any extensions can be + incrementally deployed to only those systems which desire to use + them. Systems upgraded in this fashion must still be able to + communicate with systems which have not been so upgraded. + + + +Partridge and Kastenholz [Page 21] + +RFC 1726 IPng Technical Criteria December 1994 + + + There are several aspects to extensibility: + + 5.13.1 Algorithms + The algorithms used in processing IPng information should be + decoupled from the protocol itself. It should be possible to + change these algorithms without necessarily requiring protocol, + datastructure, or header changes. + + 5.13.2 Headers + The content of packet headers should be extensible. As more + features and functions are required of IPng, it may be + necessary to add more information to the IPng headers. We note + that for IPv4, the use of options has proven less than entirely + satisfactory since options have tended to be inefficient to + process. + + 5.13.3 Data Structures + The fundamental data structures of IPng should not be bound + with the other elements of the protocol. E.g., things like + address formats should not be intimately tied with the routing + and forwarding algorithms in the way that the IPv4 address + class mechanism was tied to IPv4 routing and forwarding. + + 5.13.4 Packets + It should be possible to add additional packet-types to IPng. + These could be for, _e._g., new control and/or monitoring + operations. + + We note that, everything else being equal, having larger, + oversized, number spaces is preferable to having number spaces + that are "just large enough". Larger spaces afford more + flexibility on the part of network designers and operators and + allow for further experimentation on the part of the scientists, + engineers, and developers. See [7]. + + Time Frame + A framework showing mechanisms for extending the protocol must be + provided immediately. + +5.14 Network Service + + CRITERION + The protocol must allow the network (routers, intelligent media, + hosts, and so on) to associate packets with particular service + classes and provide them with the services specified by those + classes. + + + + + +Partridge and Kastenholz [Page 22] + +RFC 1726 IPng Technical Criteria December 1994 + + + DISCUSSION + For many reasons, such as accounting, security and multimedia, it + is desirable to treat different packets differently in the + network. + + For example, multimedia is now on our desktop and will be an + essential part of future networking. So we have to find ways to + support it; and a failure to support it may mean users choose to + use protocols other than IPng. + + The IETF multicasts have shown that we can currently support + multimedia over internetworks with some hitches. If the network + can be guaranteed to provide the necessary service levels for this + traffic, we will dramatically increase its success. + + This criterion includes features such as policy-based routing, + flows, resource reservation, network service technologies, type- + of-service and quality-of-service and so on. + + In order to properly support commercial provision and use of + Internetwork service, and account for the use of these services + (i.e., support the economic principle of "value paid for value + received") it must be possible to obtain guarantees of service + levels. Similarly, if the network can not support a previously + guaranteed service level, it must report this to those to whom it + guaranteed the service. + + Network service provisions must be secure. The network-layer + security must generally prevent one host from surreptitiously + obtaining or disrupting the use of resources which another host + has validly acquired. (Some security failures are acceptable, but + the failure rate must be very low and the rate should be + quantifiable). + + One of the parameters of network service that may be requested + must be cost-based. + + As far as possible, given the limitations of underlying media and + IP's model of a robust internet datagram service, real-time, + mission-critical applications must be supported by IPng [6]. + + Users must be able to confirm that they are, in fact, getting the + services that they have requested. + + Time Frame + This should be available within 24 months. + + + + + +Partridge and Kastenholz [Page 23] + +RFC 1726 IPng Technical Criteria December 1994 + + +5.15 Support for Mobility + + CRITERION + The protocol must support mobile hosts, networks and + internetworks. + + DISCUSSION + Again, mobility is becoming increasingly important. Look at the + portables that everyone is carrying. Note the strength of the + Apple commercial showing someone automatically connecting up her + Powerbook to her computer back in the office. There have been a + number of pilot projects showing ways to support mobility in IPv4. + All have some drawbacks. But like network service grades, if we + can support mobility, IPng will have features that will encourage + transition. + + We use an encompassing definition of "mobility" here. Mobility + typically means one of two things to people: 1) Hosts that + physically move and remain connected (via some wireless datalink) + with sessions and transport-layer connections remaining 'open' or + 'active' and 2) Disconnecting a host from one spot in the network, + connecting it back in another arbitrary spot and continuing to + work. Both forms are required. + + Reference [6] discusses possible future use of IP-based networks + in the US Navy's ships, planes, and shore installations. Their + basic model is that each ship, plane and shore installation + represents at least one IP network. The ship- and plane-based + networks, obviously, are mobile as these craft move around the + world. Furthermore, most, if not all, Naval surface combatants + carry some aircraft (at a minimum, a helicopter or two). So, not + only must there be mobile networks (the ships that move around), + but there must be mobile internetworks: the ships carrying the + aircraft where each aircraft has its own network, which is + connected to the ship's network and the whole thing is moving. + + There is also the requirement for dynamic mobility; a plane might + take off from aircraft carrier A and land on carrier B so it + obviously would want to "connect" to B's network. This situation + might be even more complex since the plane might wish to retain + connectivity to its "home" network; that is, the plane might + remain connected to the ship-borne networks of both aircraft + carriers, A and B. + + These requirements are not limited to just the navy. They apply + to the civilian and commercial worlds as well. For example, in + civil airliners, commercial cargo and passenger ships, trains, + cars and so on. + + + +Partridge and Kastenholz [Page 24] + +RFC 1726 IPng Technical Criteria December 1994 + + + Time Frame + The mobility algorithms are stabilizing and we would hope to see + an IPng mobility framework within a year. + +5.16 Control Protocol + + CRITERION + The protocol must include elementary support for testing and + debugging networks. + + DISCUSSION + An important feature of IPv4 is the ICMP and its debugging, + support, and control features. Specific ICMP messages that have + proven extraordinarily useful within IPv4 are Echo Request/Reply + (a.k.a ping), Destination Unreachable and Redirect. Functions + similar to these should be in IPng. + + This criterion explicitly does not concern itself with + configuration related messages of ICMP. We believe that these are + adequately covered by the configuration criterion in this memo. + + One limitation of today's ICMP that should be fixed in IPng's + control protocol is that more than just the IPng header plus 64 + bits of a failed datagram should be returned in the error message. + In some situations, this is too little to carry all the critical + protocol information that indicates why a datagram failed. At + minimum, any IPng control protocol should return the entire IPng + and transport headers (including options or nested headers). + + Time Frame + Support for these functions is required immediately. + +5.17 Private Networks + + CRITERION + IPng must allow users to build private internetworks on top of the + basic Internet Infrastructure. Both private IP-based + internetworks and private non-IP-based (e.g., CLNP or AppleTalk) + internetworks must be supported. + + DISCUSSION + In the current Internet, these capabilities are used by the + research community to develop new IP services and capabilities + (e.g., the MBone) and by users to interconnect non-IP islands over + the Internet (e.g., CLNP and DecNet use in the UK). + + The capability of building networks on top of the Internet have + been shown to be useful. Private networks allow the Internet to + + + +Partridge and Kastenholz [Page 25] + +RFC 1726 IPng Technical Criteria December 1994 + + + be extended and modified in ways that 1) were not foreseen by the + original builders and 2) do not disrupt the day-to-day operations + of other users. + + We note that, today in the IPv4 Internet, tunneling is widely used + to provide these capabilities. + + Finally, we note that there might not be any features that + specifically need to be added to IPng in order to support the + desired functions (i.e., one might treat a private network protocol + simply as another IP client protocol, just like TCP or UDP). If + this is the case, then IPng must not prevent these functions from + being performed. + + Time Frame + Some of these capabilities may be required to support other + criteria (e.g., transition) and as such, the timing of the + specifications is governed by the other criteria (e.g., immediately + in the case of transition). Others may be produced as desired. + +6. Things We Chose Not to Require + + This section contains items which we felt should not impact the + choice of an IPng. Listing an item here does not mean that a + protocol MUST NOT do something. It means that the authors do not + believe that it matters whether the feature is in the protocol or + not. If a protocol includes one of the items listed here, that's + cool. If it doesn't; that's cool too. A feature might be necessary in + order to meet some other criterion. Our point is merely that the + feature need not be required for its own sake. + +6.1 Fragmentation + + The technology exists for path MTU discovery. Presumably, IPng will + continue to provide this technology. Therefore, we believe that IPng + Fragmentation and Reassembly, as provided in IPv4, is not necessary. + We note that fragmentation has been shown to be detrimental to + network performance and strongly recommend that it be avoided. + +6.2 IP Header Checksum + + There has been discussion indicating that the IP Checksum does not + provide enough error protection to warrant its performance impact. + The argument states that there is almost always a stronger datalink + level CRC, and that end-to-end protection is provided by the TCP + checksum. Therefore we believe that an IPng checksum is not required + per-se. + + + + +Partridge and Kastenholz [Page 26] + +RFC 1726 IPng Technical Criteria December 1994 + + +6.3 Firewalls + + Some have requested that IPng include support for firewalls. The + authors believe that firewalls are one particular solution to the + problem of security and, as such, do not consider that support for + firewalls is a valid requirement for IPng. (At the same time, we + would hope that no IPng is hostile to firewalls without offering some + equivalent security solution). + +6.4 Network Management + + Network Management properly is a task to be carried out by additional + protocols and standards, such as SNMP and its MIBs. We believe that + network management, per se, is not an attribute of the IPng protocol. + Furthermore, network management is viewed as a support, or service, + function. Network management should be developed to fit IPng and not + the other way round. + +6.5 Accounting + + We believe that accounting, like network management, must be designed + to fit the IPng protocol, and not the other way round. Therefore, + accounting, in and of itself, is not a requirement of IPng. However, + there are some facets of the protocol that have been specified to + make accounting easier, such as non-repudiation of origin under + security, and the unique naming requirement for sorting datagrams + into classes. Note that a parameter of network service that IPng + must support is cost. + +6.6 Routing + + Routing is a very critical part of the Internet. In fact, the + Internet Engineering Task Force has a separate Area which is + chartered to deal only with routing issues. This Area is separate + from the more general Internet Area. + + We see that routing is also a critical component of IPng. There are + several criteria, such as Scaling, Addressing, and Network Services, + which are intimately entwined with routing. In order to stress the + critical nature and importance of routing, we have chosen to devote a + separate chapter to specifically enumerating some of the requirements + and issues that IPng routing must address. All of these issues, we + believe, fall out of the general criteria presented in the previous + chapter. + + + + + + + +Partridge and Kastenholz [Page 27] + +RFC 1726 IPng Technical Criteria December 1994 + + + 6.6.1 Scale + + First and foremost, the routing architecture must scale to support + a very large Internet. Current expectations are for an Internet + of about 10**9 to 10**12 networks. The routing architecture must + be able to deal with networks of this size. Furthermore, the + routing architecture must be able to deal with this size without + requiring massive, global databases and algorithms. Such + databases or algorithms would, in effect, be single points of + failure in the architecture (which is not robust), and because of + the nature of Internet administration (cooperative anarchy), it + would be impossible to maintain the needed consistency. + + 6.6.2 Policy + + Networks (both transit and non-transit) must be able to set their + own policies for the types of traffic that they will admit. The + routing architecture must make these policies available to the + network as a whole. Furthermore, nodes must be able to select + routes for their traffic based on the advertised policies. + + 6.6.3 QOS + + A key element of the network service criteria is that differing + applications wish to acquire differing grades of network service. + It is essential that this service information be propagated around + the network. + + 6.6.4 Feedback + + As users select specific routes over which to send their traffic, + they must be provided feedback from the routing architecture. This + feedback should allow the user to determine whether the desired + routes are actually available or not, whether the desired services + are being provided, and so forth. + + This would allow users to modify their service requirements or + even change their routes, as needed. + + 6.6.5 Stability + + With the addition of additional data into the routing system + (i.e., routes are based not only on connectivity, as in IPv4, but + also on policies, service grades, and so on), the stability of the + routes may suffer. We offer as evidence the early ARPANET which + experimented with load-based routing. Routes would remain in flux, + changing from one saturated link, to another, unused, link. + + + + +Partridge and Kastenholz [Page 28] + +RFC 1726 IPng Technical Criteria December 1994 + + + This must not be allowed to happen. If anything, routes should be + even more stable under IPng's routing architecture than under the + current architecture. + + 6.6.6 Multicast + + Multicast will be more important in IPng than it is today in IPv4. + Multicast groups may be very large and very distributed. + Membership in multicast groups will be very dynamic. The routing + architecture must be able to cope with this. + + Furthermore, the routing architecture must be able to build + multicast routes dynamically, based on factors such as group + membership, member location, requested and available qualities of + service, and so on. + +7. References + + [1] Internet Architecture Board, "IP Version 7", Draft 8, Work in + Progress, July, 1992. + + [2] Gross, P., and P. Almquist, "IESG Deliberations on Routing and + Addressing", RFC 1380, IESG Chair, IESG Internet AD, November + 1992. + + [3] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, + "Toward the Future Internet Architecture", RFC 1287, MIT, BBN, + CNRI, USC/Information Sciences Institute, UC Davis, December + 1991. + + [4] Dave Clark's paper at SIGCOMM '88 where he pointed out that the + design of TCP/IP was guided, in large part, by an ordered list of + requirements. + + [5] Vecchi, M., "IPng Requirements: A Cable Television Industry + Viewpoint", RFC 1686, Time Warner Cable, August 1994. + + [6] Green, D., Irey, P., Marlow, D. and K. O'Donoghue, "HPN Working + Group Input to the IPng Requirements Solicitation, RFC 1679, + NSWC-DD, August 1994. + + [7] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T Bell + Laboratories, August 1994. + + [8] Symington, S., Wood, D., and J. Pullen, "Modelling and Simulation + Requirements for IPng", RFC 1667, Mitre Corporation and George + Mason University, August 1994. + + + + +Partridge and Kastenholz [Page 29] + +RFC 1726 IPng Technical Criteria December 1994 + + + [9] Internet Architecture Board, "Report of the IAB Workshop on + Security in the Internet Architecture, RFC 1636, IAB, June 1994. + + [10] Private EMAIL from Tony Li to IPNG Directorate Mailing List, 18 + April 1994 18:42:05. + + [11] Saltzer, J., On the Naming and Binding of Network Destinations", + RFC 1498, M.I.T. Laboratory for Computer Science, August 1993. + + [12] Postel, J., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", STD 7, RFC 793, DARPA, September + 1981. + + [13] EMAIL from Robert Elz to the Big Internet mailing list, + approximately 4 May 1994. + + [14] Chiappa, N., "Nimrod and IPng Technical Requirements", Work in + Progress. + +8. Security Considerations + + Security is not directly addressed by this memo. However, as this + memo codifies goals for a new generation of network layer protocol, + the security provided by such a protocol is addressed. Security has + been raised as an issue in several of the requirements stated in this + memo. Furthermore, a specific requirement for security has been + made. + +9. Acknowledgements + + The authors gratefully acknowledge the assistance and input provided + by the many people who have reviewed and commented upon this + document. + + + + + + + + + + + + + + + + + + +Partridge and Kastenholz [Page 30] + +RFC 1726 IPng Technical Criteria December 1994 + + +10. Authors' Addresses + + Craig Partridge + BBN Systems and Technologies + 10 Moulton St. + Cambridge, MA 02138 + + EMail: craig@aland.bbn.com + + + Frank Kastenholz + FTP Software, Inc. + 2 High St. + North Andover, MA, 01845-2620 USA + + EMail: kasten@ftp.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Partridge and Kastenholz [Page 31] + |