INTERNET DRAFT Criteria for Choosing IP Version 7 (IPv7) 3 November 1992 Craig Partridge BBN Systems and Technologies 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 Internet Draft IPv7 Criteria November 1992 munnari.oz.au to learn the current status of any Internet Draft. This is a working document only, it should neither be cited nor quoted in any formal document. This document will expire before 8 May 1993. Distribution of this document is unlimited. Please send comments to the author(s). Partridge & Kastenholz Exp. 8 May 1993 [Page 1] Internet Draft IPv7 Criteria November 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. Partridge & Kastenholz Exp. 8 May 1993 [Page 2] Internet Draft IPv7 Criteria November 1992 2. Goals The criteria are presented as an ordered list. We believe that by ordering priorities, it becomes easier to evaluate the various proposals and determining each proposal's relative strengths and weaknesses. Such a mechanism has proven valuable in past efforts; see [4]. We have attempted to state the criteria in the form of goals or requirements and not demand specific engineering solutions. 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 & Kastenholz Exp. 8 May 1993 [Page 3] Internet Draft IPv7 Criteria November 1992 3. Note on Terminology The existing proposals currently tend distinguish between end- point identification of, e.g., individual hosts, and topological addresses of network attachment points. In this note 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 & Kastenholz Exp. 8 May 1993 [Page 4] Internet Draft IPv7 Criteria November 1992 4. Protocol Criteria This section enumerates the criteria against which the IP Version 7 proposals will be evaluated. This is an ordered enumeration. Each criterion is presented in its own section. The first paragraph of each section is a simple, 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 justification for its position in the list. 4.1. Scale CRITERION The IPv7 Protocol must scale to allow the identification and addressing of 10**11 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. Particular attention in any proposal 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. Placement This criteria is the essential problem motivating the transition to IPv7. If the proposed protocol does not satisfy this criteria, there is no point in considering Partridge & Kastenholz Exp. 8 May 1993 [Page 5] Internet Draft IPv7 Criteria November 1992 it. 4.2. Robust Service CRITERION The network service should be robust. DISCUSSION Murphy's Law applies to networking. Any IPv7 proposal 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. Placement If the protocol is not robust, no one will want to transition to it. So this criteria comes above ease of transition. 4.3. 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 change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible. Partridge & Kastenholz Exp. 8 May 1993 [Page 6] Internet Draft IPv7 Criteria November 1992 Rather IPv7 will need to co-exist with IPv4 for some period of time. This may imply that hosts and routers may need to be able to support both IPv4 and IPv7 simultaneously. There may also be single protocol (i.e. IPv4-only and IPv7-only) hosts on the network. If IPv4 and IPv7 are not interoperable, then the need for and use of protocol- translating gateways to enable such hosts to communicate should be examined. In any case, 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. 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, SNMP and FTP) must be specifically addressed. 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. Partridge & Kastenholz Exp. 8 May 1993 [Page 7] Internet Draft IPv7 Criteria November 1992 4.4. Media CRITERION The protocol must work across an internetwork of many differnet LAN, MAN, and WAN media, with individual link speeds ranging from a kilobit 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 say terabits 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 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. 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 We might accept a less flexible protocol if it solves the addressing and routing problems and we can transition to it. But those goals having been achieved, we need to make sure the protocol is general. 4.5. Unreliable Datagram Service CRITERION The protocol must support an unreliable datagram delivery service. Partridge & Kastenholz Exp. 8 May 1993 [Page 8] Internet Draft IPv7 Criteria November 1992 DISCUSSION We like IP's datagram service and it seems to work very well. So we should keep it. Placement Datagram service matters less than being able to get the data from here to there over different media. 4.6. 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. The ability to restrict the range of a broadcast or multicast to specific networks is also important. Placement Multicast addressing is clearly less important than being able to get the data to all end-systems, with the kind of service we prefer. But multicasting is an essential Partridge & Kastenholz Exp. 8 May 1993 [Page 9] Internet Draft IPv7 Criteria November 1992 service, and thus has priority over ease of configuration and cost recovery. 4.7. Configuration, Administration, and Operation CRITERION The protocol must permit easy and largely distributed configuration and operation. Automatic configuration is required. DISCUSSION People complain that IP is hard to manage. We cannot plug and play. We should 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. Placement The previous criteria all deal with essential functions of the protocol itself, without which the protocol would be useless. Thus, this criterion is placed after these functions. 4.8. Accounting CRITERION The protocol must support some means for cost recovery. DISCUSSION Commercial providers need to be able to puzzle out some way to charge for services. Charging based on leased- line capacity as most IP providers do today, is acceptable. Partridge & Kastenholz Exp. 8 May 1993 [Page 10] Internet Draft IPv7 Criteria November 1992 This point does not say that the protocol must support billing or per-packet accounting. It simply says that any design for IPv7 should keep in mind that there are commercial IP providers who have to be able to charge for IP service. Placement If we don't have the right services and if we can not actually configure and operate the protocol, billing for use of the network isn't useful, so this goes below the previous criteria. 4.9. 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 This criterion is primarily concerned with future developments in internetworking technology. The preceeding criteria all deal with current pressing issues. We must address our current problems before we start dealing with tomorrow's; therefore, this criterion is placed after the preceeding criteria. This criterion also is a more general case of the following criterion, in that if extensibility is provided, then the technological advances discussed in Partridge & Kastenholz Exp. 8 May 1993 [Page 11] Internet Draft IPv7 Criteria November 1992 the following criteria can presumably be provided for. Partridge & Kastenholz Exp. 8 May 1993 [Page 12] Internet Draft IPv7 Criteria November 1992 At this point we make a significant break. We go from what we believe to be essential criteria that IPv7 must meet, to strongly desired items. 4.10. 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. Placement At worst, we can consider adding support for guaranteed flows as an extension, so it falls after extensibility. 4.11. 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. Placement We suspect that conferencing and multimedia support from Partridge & Kastenholz Exp. 8 May 1993 [Page 13] Internet Draft IPv7 Criteria November 1992 one's regular office computer is more important than mobility. 4.12. 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. Placement For all that security is important, most sites seem to value it less than functionality. 4.13. Explicit Non-Goals 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. Partridge & Kastenholz Exp. 8 May 1993 [Page 14] Internet Draft IPv7 Criteria November 1992 5. 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 & Kastenholz Exp. 8 May 1993 [Page 15] Internet Draft IPv7 Criteria November 1992 Table of Contents Status of this Memo .................................... 1 1 Introduction .......................................... 2 2 Goals ................................................. 3 3 Note on Terminology ................................... 4 4 Protocol Criteria ..................................... 5 4.1 Scale ............................................... 5 4.2 Robust Service ...................................... 6 4.3 Transition .......................................... 6 4.4 Media ............................................... 8 4.5 Unreliable Datagram Service ......................... 8 4.6 Addressing .......................................... 9 4.7 Configuration, Administration, and Operation ........ 10 4.8 Accounting .......................................... 10 4.9 Extensibility ....................................... 11 4.10 Support for Guaranteed Flows ....................... 13 4.11 Support for Mobility ............................... 13 4.12 Allow Secure Operation ............................. 14 4.13 Explicit Non-Goals ................................. 14 5 References ............................................ 15 Partridge & Kastenholz Exp. 8 May 1993 [Page ii]