INTERNET DRAFT Criteria for Choosing IP Version 7 (IPv7) 14 December 1992 Craig Partridge BBN Systems and Technologies craig@aland.bbn.com Frank Kastenholz FTP Software, Inc 2 High Street North Andover, Mass 01845-2620 USA kasten@ftp.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Internet Draft IPv7 Criteria December 1992 Draft. This is a working document only, it should neither be cited nor quoted in any formal document. This document will expire before 19 June 1993. Distribution of this document is unlimited. Please send comments to criteria@ftp.com or the authors. Partridge & KastenholzExp. 19 June 1993 [Page 1] Internet Draft IPv7 Criteria December 1992 1. Introduction This note attempts to codify and organize the criteria to be used in evaluating the protocols being proposed for adoption as IP Version 7. The criteria presented are culled from several sources, including "IP Version 7" [1], "IESG Deliberations on Routing and Addressing" [2], "Towards the Future Internet Architecture" [3], and the ongoing discussions held on the Big-Internet mailing list and the mailing lists devoted to the individual IPv7 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 better engineering of, e.g., routing protocols, or we should develop IPv7 now. This question is not addressed in this document. 1.1. Change Log At the Washington D.C. IETF meeting, a BOF was held during which this document was discussed. The following changes have been made to reflect that discussion. (1) The list has been changed from an ordered list of criteria, where each criterion was considered "more important" than those that followed to a split into two groups: (A) those criteria which the new IP "must" have, where "must" is defined by agreeing that a new IPv7 will not be accepted or deployed unless it fullfills all the "must" requirements; and (B) those criteria which it would be desirable to have in the new IP but are not a pre-requisite for deployment. This change has engendered most of the editorial work on the document. Most notably, references to "ordered lists" had to be reworded, and the document needed to be re-organized to have must and should subsections. (2) A section called "General Principles" has been added to the beginning of the document. This section contains Partridge & KastenholzExp. 19 June 1993 [Page 2] Internet Draft IPv7 Criteria December 1992 those items discussed that are hard to quantify as criteria for the protocol, yet which we believe are essential to the future success of IPv7 and the Internet as a whole. (3) Discussion at the BOF made it clear that it would be desirable to refine the criteria into questions that could be used to help distinguish proposals. The goal of these questions is not to grade proposals, and determine which one becomes IPv7, but rather to help elucidate the various ways that the different proposals try to meet the criteria. A beginning of this process, in the form of a section of detailed questions has been added to the end of the document. (4) A MUST criterion for "documents being on-line and owned by the IETF" has been added per the BOF. (5) Per the BOF, the section on accounting has been deleted. (6) Several criteria were mentioned at the BOF but we could find no reasonable definition of them. Place-holders for these criteria are given, but no discussion of them is given. We hope that these place-holders will stimulate discussion on the mailing list. If not, they will be deleted. (7) The IP Checksum was made a non-goal. There has been sufficient discussion on the big-i mailing list to suggest that it does not provide significant data protection. (8) Some typos were fixed. Some additional explanatory text has been added. (9) Additional parts added to the "Configuration, Administration, and Operation" section per the discussion at the BOF. (10) The "Scale" criterion has been expanded per the BOF to address 10**12 nodes and requesting a description of the performance as the limit is reached. Partridge & KastenholzExp. 19 June 1993 [Page 3] Internet Draft IPv7 Criteria December 1992 (11) Robust Service includes a mention of Hostile attacks and Byzantine failures. Partridge & KastenholzExp. 19 June 1993 [Page 4] Internet Draft IPv7 Criteria December 1992 2. Goals We believe that by developing a list of criteria for evaluating proposals for IP version 7 (IPv7), 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. This set of criteria originally began as an ordered list, with the goal of ranking the importance of various criteria. However, after discussion it became clear that the criteria list actually could be more simply characterized as falling into two groups: those criteria which had to be met by any proposed IPv7 before anyone felt that IPv7 should be deployed; and those criteria which it would be useful, but not essential, for an IPv7 to meet. The current criteria are presented in this form. 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. In determining the relative order of the various criteria, we have had two guiding principles. First, IPv7 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 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 IPv7. At minimum, this second point implies that there must be a straightforward way to transition systems from IPv4 to IPv7. But it also strongly suggests that IPv7 should offer features that IPv4 does not; new features provide a motivation to deploy IPv7 more quickly. Partridge & KastenholzExp. 19 June 1993 [Page 5] Internet Draft IPv7 Criteria December 1992 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. Partridge & KastenholzExp. 19 June 1993 [Page 6] Internet Draft IPv7 Criteria December 1992 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 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. 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 recently rebelled at changing from SNMPv1 to SNMPv1+Security with SNMPv2+Security on the horizon. The community chose to delay deployment of SNMPv1+Security until SNMPv2 is done. Partridge & KastenholzExp. 19 June 1993 [Page 7] Internet Draft IPv7 Criteria December 1992 Author's Note We believe that this section covers the "Long Life" criterion discussed in the Washington D.C. IETF BOF. 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 IPv7, with its attendant distruptions of service, etc. These problems can be solved much more simply with more router-thrust, balkanization of the Internet, and so on. We believe that there must be positive, functional or operational, benefits to switching to IPv7. In other words, IPv7 must be able to live for a long time AND it must allow the Internet to prosper and to grow. Partridge & KastenholzExp. 19 June 1993 [Page 8] Internet Draft IPv7 Criteria December 1992 5. Criteria This section enumerates the criteria against which the IP Version 7 proposals will 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. 5.1. MUSTs The following criteria were deemed by an IETF BOF session to be absolutely essential. Any new IP protocol must meet all of these criteria before it is deployed. The standard for making a criteria a must requirement was that we would refuse to deploy a candidate IPv7 that failed to meet just one must requirement, EVEN IF THE CURRENT IPV4 INTERNET IS COLLAPSING DUE TO ROUTING CONGESTION. 5.1.1. Scale CRITERION The IPv7 Protocol must scale to allow the identification and addressing of 10**12 end systems. The IPv7 Protocol, and its associated routing protocols and architecture must allow for up to 10**9 individual networks. The routing schemes must scale with the number of constituent networks at a rate that is much less than linear. DISCUSSION The whole purpose of the IPv7 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. Partridge & KastenholzExp. 19 June 1993 [Page 9] Internet Draft IPv7 Criteria December 1992 In any proposal, Particular attention should be paid to describing the routing hierarchy, how the routing and addressing will be organized, how different layers of the routing interact, and 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. Placement This criterion is the essential problem motivating the transition to IPv7. If the proposed protocol does not satisfy this criteria, there is no point in considering it. 5.1.2. Topological Flexibility CRITERION The routing architecture and protocols of IPv7 must allow for many different network topologies. 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. Furthermore, since we expect that IPv7 will allow for many more levels of hierarchy than are allowed under IPv4, we can expect very "tall" and very "short" topologies as well. 5.1.3. Robust Service CRITERION The network service and its associated routing and control protocols must be robust. Partridge & KastenholzExp. 19 June 1993 [Page 10] Internet Draft IPv7 Criteria December 1992 DISCUSSION Murphy's Law applies to networking. Any proposed IPv7 protocol must be well-behaved in the face of malformed packets, mis-information, and occasional failures of links, routers and hosts. IPv7 should perform gracefully in response to willful management and configuration mistakes (i.e. service outages should be minimized). Putting this requirement another way, IPv7 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. We note that IPv4 is reasonably robust and any proposed IPv7 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. Placement Due to its size, complexity, decentralized administration, brain-dead 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. 5.1.4. Transition CRITERION The protocol must have a straightforward transition plan from the current IPv4. DISCUSSION A smooth, orderly, transition from IPv4 to IPv7 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 Partridge & KastenholzExp. 19 June 1993 [Page 11] Internet Draft IPv7 Criteria December 1992 change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible. Rather IPv7 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. However, 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 IPv7 must be minimized. (A good target is that running a mixed IPv4-IPv7 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. IPv7 schemes which maximize stability and connectivity in mixed IPv4-IPv7 networks are preferred. Finally, it may be necessary that multiple IPv7 protocols coexist on the network during the testing and evaluation periods. Transition plans must address this issue. The transition plan must address the following general areas of the Internet's infrastructure: o Host Protocols and Software o Router Protocols and Software o Security and Authentication o Domain Name System o Network Management o Operations Tools (e.g., Ping and Traceroute) o Operations and Administration procedures The impact on protocols which use IP addresses as data (e.g. DNS, 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. Partridge & KastenholzExp. 19 June 1993 [Page 12] Internet Draft IPv7 Criteria December 1992 Placement If the transition scheme is painful, no one will transition. But we should only transition if the protocol we transition to solves the scaling problems and is useful to use. 5.1.5. Media CRITERION The protocol must work across an internetwork of many differnet 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 both media supporting switched and permanent circuits. DISCUSSION The joy of IP is that it works over just about anything. That ease of adding new technologies, and continuing to operate with old technologies must be maintained. We believe this range of speed is right for the next twenty years, though it may be we should require terabit performance at the high-end. 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. 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 IPv7 address) is required. We note that this is an aspect of mobility. By work, we mean we have hopes that a stream of IPv7 datagrams (whether from one source, or many) can come close to filling the link at high speeds, but also scales gracefully to low speeds. Placement The protocol must be general. It must operate over all of the media that IPv4 operates over today. A general goal of the Internet is ubiquity. Besides all of the common Partridge & KastenholzExp. 19 June 1993 [Page 13] Internet Draft IPv7 Criteria December 1992 media available today, there are all sorts of "legacy" systems which we would like to connect to IPv7 and these systems might have odd media. Furthermore, there are all sorts of difficult corners of the world which ought to be connected to the Ubiquitous Internet but the medium to get into such corners is "odd" (one example mentioned at the Washington D.C. IETF was to use ELF to connect to submerged submarines -- ELF has a "speed" on the order of <10 characters per second) 5.1.6. 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. 5.1.7. 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. Partridge & KastenholzExp. 19 June 1993 [Page 14] Internet Draft IPv7 Criteria December 1992 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. Placement The placement of this criterion as a "must" is in response to the pressures of the user community, who are crying out for easier to use IP. 5.1.8. Allow Secure Operation CRITERION The protocol should not preclude secure operation. DISCUSSION We need to be sure that we have not created a network that is a cracker's playground. In order to meet the Robustness criterion, some elements of what is commonly shrugged off as "security" are needed; e.g. to prevent a villan 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. 5.1.9. Unique Naming CRITERION IPv7 must assign all IP-Layer objects in the global, Partridge & KastenholzExp. 19 June 1993 [Page 15] Internet Draft IPv7 Criteria December 1992 ubiquitous, Internet unique names. DISCUSSION We use the term "Name" in this criterion synonymously with the term "End Point Identifier" as used in the NIMROD proposal, or as IP Addresses uniquely identify interfaces/hosts in IPv4. The authors are not convinced that this ought to be a criterion of the protocol. We feel that it may in fact be a part of a solution to other criteria and as such, is not a criterion of its own. The BOF expressed a very strong desire to include this criterion and we are placing it here in the hope that it will stimulate discussion on the subject. 5.1.10. Access CRITERION The protocols that define IPv7, its associated protocols (similar to ARP and ICMP in IPv4) and the routing protocols (e.g. OSPF, BGP, and RIP in IPv4) must be freely available in the same fashion that RFCs are: namely in ASCII format, obtainable by anonymous FTP, and freely reproducible without copyright restrictions. 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 IPv7. 5.2. SHOULDs The following criteria were deemed by an IETF BOF session to be of lesser importance than the preceeding ones. Every attempt should be made by protocol designers to satisfy these Partridge & KastenholzExp. 19 June 1993 [Page 16] Internet Draft IPv7 Criteria December 1992 criteria, however, deployment would not be held up, waiting for one of these criteria to be met. Some of the criteria represent technologies which are only now starting to move from the research world to the engineering and development world. Other criteria were demoted to this level for reasons that are unclear to the authors. In particular, the authors firmly believe that multicasting and extensibility are actually requirements that no IPv7 should be without. To reflect the decisions at the DC meeting, these criteria have been demoted to this section, but the authors may, after further reflection, move them back into the must category in the future. 5.2.1. Addressing CRITERION The protocol must allow for both unicast and multicast addressing. Part of the multicast capability is a requirement to be able to send to "all IP hosts on THIS network". 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 IPv7. 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 IPv7. There's no good reason for IPv7 to send to all hosts on a subnet when it only wishes to send to all IPv7 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 should not be lost in the transition to IPv7. Partridge & KastenholzExp. 19 June 1993 [Page 17] Internet Draft IPv7 Criteria December 1992 The ability to restrict the range of a broadcast or multicast to specific networks is also important. It should be noted that addressing -- specifically the syntax and semantics of addresses -- has a great impact on the scalability of the architecture. Placement 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. Author's Note The Washington D.C. BOF did not come down firmly that multicast should be a MUST, however the authors believe it to be essential. 5.2.2. 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. 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 IPv7 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. Placement We believe that this criterion should be a "MUST" simply because we can not predict very well what the future will bring so the protocol must be able to deal with the future -- whatever it is. Partridge & KastenholzExp. 19 June 1993 [Page 18] Internet Draft IPv7 Criteria December 1992 Author's Note The Washington D.C. BOF did not come down firmly that extensibility should be a MUST, however the authors believe it to be essential. 5.2.3. Support for Guaranteed Flows CRITERION The protocol should support guaranteed flows. DISCUSSION 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 IPv7. The IETF multicasts have shown that we can currently support multimedia over internetworks with some hitches. If we can achieve the needed support for guaranteed flows in IPv7, we will dramatically increase its success. 5.2.4. Support for Mobility CRITERION The protocol should support mobile hosts. 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 guaranteed flows, if we can support mobility, IPv7 will have features that will encourage transition. We use a vague definition of "mobility" here. To some people, this means hosts that physically move and remain connected (via some wireless datalink), to others it means disconnecting a host from one spot in the network, connecting it back in another arbitrary spot and Partridge & KastenholzExp. 19 June 1993 [Page 19] Internet Draft IPv7 Criteria December 1992 continuing to work. At this point we expect that the proposals will discuss their own abilities in this general area. 5.2.5. Cost Distribution This is a place-holder from the BOF. 5.2.6. Risk and Maturity This is a place-holder from the BOF. 5.2.7. Performance This is a place-holder from the BOF. 5.3. Explicit Non-Goals This section contains some explicit non-goals of IPv7. A non-goal does not mean that a protocol MUST NOT do something. It means that the authors do not believe that it matters whether the non-goal is in the protocol or not. If a protocol includes one of the non-goals; well, that's cool. If it doesn't; that's cool too. A non-goal might be necessary in order to meet some other criterion, however this is irrelevant to including the non-goal merely for its own sake. Fragmentation The technology exists for path MTU discovery. Presumably, IPv7 will continue to provide this technology. Therefore, we believe that IPv7 Fragmentation and Reassembly, as provided in IPv4, is not necessary. IPv4/IPv7 Communication It is not necessary that IPv4-only and IPv7-only hosts be able to communicate directly with each other. IP Checksum There has been discussion indicating that the IP Checksum does not provide enough error protection to warrant its Partridge & KastenholzExp. 19 June 1993 [Page 20] Internet Draft IPv7 Criteria December 1992 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 IPv7 checksum is not required per-se. Partridge & KastenholzExp. 19 June 1993 [Page 21] Internet Draft IPv7 Criteria December 1992 6. Detailed Questions This section is an initial draft of a list of detailed questions designed to start to help refine our understanding of how each proposal meets the criteria. The questions are written such that there are no right or wrong answers, but rather, that by reading answers to the questions one can develop a better understanding of the tradeoffs chosen by the protocol designers. The questions are grouped according to the criteria they are intended to help readers better understand. Partridge & KastenholzExp. 19 June 1993 [Page 22] Internet Draft IPv7 Criteria December 1992 7. References [1] Internet Architecture Board, IP Version 7, Draft 8, Internet Draft, July, 1992. [2] Gross, P. and P. Almquist, IESG Deliberations on Routing and Addressing, Internet Draft, September 1992. [3] Clark, D., et al, Towards the Future Internet Architecture Network Working Group Request For Comments 1287, 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. Partridge & KastenholzExp. 19 June 1993 [Page 23] Internet Draft IPv7 Criteria December 1992 Table of Contents Status of this Memo .................................... 1 1 Introduction .......................................... 2 1.1 Change Log .......................................... 2 2 Goals ................................................. 5 3 Note on Terminology ................................... 6 4 General Principles .................................... 7 4.1 Architectural Simplicity ............................ 7 4.2 One Protocol to Bind Them All ....................... 7 4.3 Live Long ........................................... 7 4.4 Live Long AND Prosper ............................... 8 5 Criteria .............................................. 9 5.1 MUSTs ............................................... 9 5.1.1 Scale ............................................. 9 5.1.2 Topological Flexibility ........................... 10 5.1.3 Robust Service .................................... 10 5.1.4 Transition ........................................ 11 5.1.5 Media ............................................. 13 5.1.6 Unreliable Datagram Service ....................... 14 5.1.7 Configuration, Administration, and Operation ...... 14 5.1.8 Allow Secure Operation ............................ 15 5.1.9 Unique Naming ..................................... 15 5.1.10 Access ........................................... 16 5.2 SHOULDs ............................................. 16 5.2.1 Addressing ........................................ 17 5.2.2 Extensibility ..................................... 18 5.2.3 Support for Guaranteed Flows ...................... 19 5.2.4 Support for Mobility .............................. 19 5.2.5 Cost Distribution ................................. 20 5.2.6 Risk and Maturity ................................. 20 5.2.7 Performance ....................................... 20 5.3 Explicit Non-Goals .................................. 20 6 Detailed Questions .................................... 22 7 References ............................................ 23 Partridge & KastenholzExp. 19 June 1993 [Page ii]