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