INTERNET DRAFT Technical Criteria for Choosing IP:The Next Generation (IPng) draft-kastenholz-ipng-criteria-01.txt 23 March 1994 Frank Kastenholz FTP Software, Inc 2 High Street North Andover, Mass 01845-2620 USA kasten@ftp.com Craig Partridge BBN Systems and Technologies craig@aland.bbn.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.'' Internet Draft IPng Technical Criteria March 1994 To learn the current status of any Internet-Draft, please check the 1id-abstractis.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. This is a working document only, it should neither be cited nor quoted in any formal document. This document will expire before 28 Sep. 1994. Distribution of this document is unlimited. Please send comments to the authors. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 1] Internet Draft IPng Technical Criteria March 1994 1. Introduction This note codifies and organizes the the authors' personal opinions of the criteria that should be used in evaluating the protocols being proposed for adoption as the next generation of IP. 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], the IPng Requirements BOF held at the Washington D.C. IETF Meeting in December of 1992, and the ongoing discussions held on the Big-Internet (big- internet@munnari.oz.au, send requests to join to big-internet- request@munnari.oz.au) mailing list 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 better engineering of, e.g., routing protocols, or we should develop IPng now. This question is not addressed in this document. This note 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. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 2] Internet Draft IPng Technical Criteria March 1994 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. 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 evaluated and a time frame, indicating approximately when a specific criterion, or feature of a criterion, should be available. 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 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 to more end-points and an ever increasing range of bandwidths. Second, it must be possible 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. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 3] Internet Draft IPng Technical Criteria March 1994 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 & Kastenholz Exp. 28 Sep. 1994 [Page 4] Internet Draft IPng Technical Criteria March 1994 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. 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 Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 5] Internet Draft IPng Technical Criteria March 1994 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. 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 more router-thrust, balkanization of the Internet, and so on. 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. 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. 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 Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 6] Internet Draft IPng Technical Criteria March 1994 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. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 7] Internet Draft IPng Technical Criteria March 1994 5. Criteria This section enumerates the criteria against which the IP:The Next Generation 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. 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. 5.1. Scale CRITERION The IPng Protocol must scale to allow the identification and addressing of 10**12 end systems. The IPng Protocol, and its associated routing protocols and architecture must allow for at least 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 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. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 8] Internet Draft IPng Technical Criteria March 1994 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 should 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. 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 strctures, 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 Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 9] Internet Draft IPng Technical Criteria March 1994 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. 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. Time Frame We believe that Toplogical Flexibility is an inherent element of a protocol and therefore should be immediately demonstrable in an IPng proposal. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 10] Internet Draft IPng Technical Criteria March 1994 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 similar 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. 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 Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 11] Internet Draft IPng Technical Criteria March 1994 widely used in the Cable TV Industry and there may be many OC-3 speed lines connecting to central switching elements. 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. 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. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 12] Internet Draft IPng Technical Criteria March 1994 The detrimental effects of failures, errors, and misconfigurations should be localized as much as possible. For example, misconfiguring a workstation's IP Address should not break the routing protocols. Ideally, in the event of misconfigurations, IPng ought 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 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 comission) 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. 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 Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 13] Internet Draft IPng Technical Criteria March 1994 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. 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 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 & Kastenholz Exp. 28 Sep. 1994 [Page 14] Internet Draft IPng Technical Criteria March 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 both media supporting switched and permanent circuits. DISCUSSION The joy of IP is that it works over just about anything. This generality must be preserved. That 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 it may be we should 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 Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 15] Internet Draft IPng Technical Criteria March 1994 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. 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 static, manually configured mappings. 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 (early 1994), ATM seems to be set to become a major network media technology. Any IPng should be designed to operate over ATM. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 16] Internet Draft IPng Technical Criteria March 1994 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 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, Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 17] Internet Draft IPng Technical Criteria March 1994 within IPv4, to send an idempotent datagram, without prearrangement, is extremely valuable (in fact, may be required for some applications such as SNMP) and must be retained. 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. 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. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 18] Internet Draft IPng Technical Criteria March 1994 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. 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. Time Scale A method for plug and play is immediately. We believe that this is an extremely critical area for any IPng as a major complaint of the IP community as a Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 19] Internet Draft IPng Technical Criteria March 1994 whole is the difficulty in administering large IP networks. Furthermore, ease of installation is likely to speed the deployment of IPng. 5.9. 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 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 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] Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 20] Internet Draft IPng Technical Criteria March 1994 - 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. 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. 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. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 21] Internet Draft IPng Technical Criteria March 1994 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 licensing fees for implementing or selling IPng software. 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 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 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 Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 22] Internet Draft IPng Technical Criteria March 1994 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 should 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]. 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 Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 23] Internet Draft IPng Technical Criteria March 1994 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. There are several aspects to extensibility: 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. Headers The content of packet headers should be extensible. As more features and functions are required of IPng, Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 24] Internet Draft IPng Technical Criteria March 1994 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. 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. 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 numberspaces 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. DISCUSSION For many reasons, such as accounting, security and multimedia, it is desireable to treat different packets differently in the network. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 25] Internet Draft IPng Technical Criteria March 1994 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. 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]. Time Frame This should be available within 24 months. 5.15. Support for Mobility CRITERION The protocol should support mobile hosts, networks and internetworks. DISCUSSION Again, mobility is becoming increasingly important. Look Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 26] Internet Draft IPng Technical Criteria March 1994 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 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 continuing to work. At this point we expect that the proposals will discuss their own abilities in this general area. 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 bothe 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 & Kastenholz Exp. 28 Sep. 1994 [Page 27] Internet Draft IPng Technical Criteria March 1994 Time Frame We don't have a clue. 5.16. Control Protocol CRITERION The protocol should 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 (aka 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. Time Frame Support for these functions is required immediately. 5.17. Tunneling CRITERION IPng must support tunneling. DISCUSSION Experience has shown that the ability to tunnel, i.e., carry other, non-IP, network layer protocols over IP, is extraordinarily useful. It allows network-layer protocol developers to conduct research and experiments treating the IP service of the Internet as a simple datagram- oriented datalink layer. This work may be carried out with out disrupting the day-to-day operations of the network. Tunneling also allows non-IP "islands" to interconnect treating the Internet as a simple datalink layer. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 28] Internet Draft IPng Technical Criteria March 1994 Therefore, tunneling is useful from both a production and a R & D perspective and should be supported. Specifically, IPng must be able to tunnel non-Internet network layer protocols such as CLNP and it must be able to tunnel Internet protocols, including but not limited to, IPng and IPv4. Finally, we note that there might not be any features that specifcally need to be added to IPng in order to support tunneling (i.e. one might treat a tunneled simply as another IP client protocol, just like TCP or UDP). If this is the case, then IPng must not prevent tunneling from being performed. Time Frame Some tunneling specifications and 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. 5.18. Explicit Non-Goals This section contains some explicit non-goals of IPng. 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, 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. IP Header Checksum There has been discussion indicating that the IP Checksum Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 29] Internet Draft IPng Technical Criteria March 1994 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. 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. 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. 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. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 30] Internet Draft IPng Technical Criteria March 1994 6. 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. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 31] Internet Draft IPng Technical Criteria March 1994 7. Acknowledgements The authors greatfully acknowledge the assistance and input provided by the many people who have reviewed and commented upon this document. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 32] Internet Draft IPng Technical Criteria March 1994 8. 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. [5] Vecchi, Mario P., IPng Requirements: A Cable Television Industry Viewpoint, Time Warner Cable, January 1994. To Be Published as an Internet Draft. [6] Green, D., P. Irey, D. Marlow, and K. O'Donoghue HPN Working Group Input to the IPng Requirements Solicitation, NSWC-DD, January 1994. To Be Published. [7] Bellovin, S., On Many Addresses per Host, AT&T Bell Laboratories, February 1994. To Be Published. [8] Symington, S., D Wood, and J.M. Pullen, Modelling and Simulation Requirements for IPng, Mitre Corporation and George Mason University, January 1994. To Be Published. [9] Internet Architecture Board, Report of the IAB Workshop on Security in the Internet Architecture, March 1994. To Be Published. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 33] Internet Draft IPng Technical Criteria March 1994 9. Change Log 9.1. 23 March 1994 The following changes were made in response to consultations with Craig Partridge on the changes made on 21 March. (1) Moved the log to the back of the document.... (2) Made autoconfig "mandatory"; pointed out that other issues (registering with DNS, etc) are important but not IP -- IPng must not prevent the development of these technologies. (3) The requirements for mission critical, realtime have been weakened a bit to say something to the effect of "As far as possible, given limitations of underlying technology..." (4) The word Broadcast has been exorcised from where it does not belong in the multicast address section. (5) In the statement on large number spaces, we've stressed thje everything else being equal bit. 9.2. 21 March 1994 The following changes were made in response to the phone teleconference with the IPng directorate earlier today: (1) Change IP:ng to IPng (2) Change title to "Technical Criteria..." (3) Give a pointer to the big-internet mailing list. (4) Some additional text was added to "Architectural Simplicity", describing that some functions are best left to other, non-IP, elements of the stack and in such cases, IP should keep out of the way. (5) The scale requirement has been changed to indicate "at least" 10**9/10**12 and a comment has been added that, interpreting one of the white papers, these could be off by 3 orders of magnitude.... Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 34] Internet Draft IPng Technical Criteria March 1994 (6) The section on Media has been renamed Media Independence. (7) Changed paragraph in the transition section to say that multiple versions of IPng will exist as it evolves, and coexistance of these versions on the net is required. (8) Spelled out Van's name. (9) Timeframe for Media section now requires that ipng support all encapsulations that are currently standardized by the IETF. (10) Auto registration added to Config... (11) Auto config, etc, made an immediate requirement. (12) Changed section title to Multicast Addressing from Addressing. (13) Added mobile networks to the Mobility section -- derived from one of the white papers. (14) Stress that fragmentation is harmful and recommend against it. (15) The IPv4/IPng communication non-requirement has been deleted. (16) Added text on host performance. (17) Added a top-level requirement for tunneling. (18) Added a preference for larger rather than smaller number spaces in Extensibility. (19) Cost explicitly made a parameter of network service that a client may request. (20) Added a requirement for the scale of multicast groups. Also added requirements for "locality" and "directability" of multi/broad-cast. (21) In performance section, say that [5] are considering that connections at OC-3 or better rates might become Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 35] Internet Draft IPng Technical Criteria March 1994 commonplace. (22) IP security must be able to prevent traffic pattern analysi. (23) Broadened network services to indicate that real-time, mission, critical applications are required. (24) Make minor spelling, editorial and grammatical changes. 9.3. 10 March 1994 (1) A new general principle, Cooperative Anarchy, has been added. (2) Cleaned up some of the text in "Forwarding Performance" (3) Clarified the "Time Scale" for "Forwarding Performance" (4) Clarified the "Time Scale" for "Access" (5) Made the "Time Scale" for "Configuration" more rigorous. (6) Added sections for Security Considerations and Acknowledgements (7) Minor editorial changes, fix typos, and the like. 9.4. 9 March 1994 (1) Additional text clarifying the intent of "extensibility" has been added. This covers things like algorithms, packet headers, data structures, and so on. (2) A brief paragraph in "Media" has been added indicating that ATM seems to be set to be a major network technology and IPng should be able to deal with this. (3) More text has been added to the "robust service" section. This text describes a network that suffers more outages, due to increased size, and is the target of more errors, due to increasingly less sophisticated users and requires that the network protects against Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 36] Internet Draft IPng Technical Criteria March 1994 these problems. (4) A statement was made indicating that large diameter networks are possible. (5) Added a pointer to RFC1310 to the Access criterion. (6) A brief discussion of the meaning of Time Frame was added. (7) A high end speed of 500 gig within 10 years is specified in Media. (8) A section on performance has been added (per discussions with DDC). (9) A couple new non-goals have been stated. (10) Additional text describing the unreliable datagram service has been added. (11) Additional descriptive text has been added to the Unique Naming criterion. (12) Additional descrioptions in Media on coexistance with intelligent subnetwork technologies. (13) Reworded "flows" to be "network service". 9.5. 15 February 1994 (1) Deleted the explicit placement paragraphs. Either deleted that text outright or kept it, without a header, or moved the text into the main body of the criterion. (2) Deleted the SHOULD/MUST model. Replaced it with a proposed timescale for which there is an explicit paragraph for each criterion. (3) Added dynamic/automatic routing to multicasts. (4) Extended guaranteed flows to include the resource reservation, tos/qos, and and internet services work. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 37] Internet Draft IPng Technical Criteria March 1994 (5) added a requirement for some of the more useful parts of icmp (ping, redirect, unreachable). 9.6. 9 November 1993 The following changes have been made for the 9 November 1993 version of the document. (1) References to "IP Version 7" or "IPv7" have been changed to IP: The Next Generation or IPng to reflect the IETF's political silliness. (2) The "origin" of the document was changed to be the authors' personal opinions rather than the product of the IETF or other organized (or disorganized) body. (3) Topological flexibility was extended to indicate that constituent organizations should be free to arrange their own internal topologies in any manner they see fit. If hierarchical addressing/topology is used, then these organizations should be able to allocate as many layers of the hierarchy to themselves as they see fit. (4) Robustness is extended to include keeping effects of errors and failures localized. (5) The media section has been extended to state that multiple MAC addressing schemes exist and that a mechanism must be provided to associate an IP Address with the MAC address of its node. No static tables allowed. (6) All IP parameters obtainable at boot time. (7) Multicast has been moved to the MUST section, per our opinions. (8) All specifications must be available as RFCs and freely available and redistributable, per the RFC tradition. This strengthens previous working group positions according to the authors' opinions. (9) Minor editorial changes have been made, spelling and grammar errors were fixed, additional explanatory text added. Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 38] Internet Draft IPng Technical Criteria March 1994 9.7. 9 September 1993 The following changes have been made for the 9 September 1993 version of the document. This version was not published. (1) Multi-protocol co-existence was added in the Media section. (2) Minor editorial changes have been made, spelling and grammar errors were fixed, additional explanatory text added. 9.8. 14 December 1992 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 IPng will not be accepted or deployed unless it fulfills 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 those items discussed that are hard to quantify as criteria for the protocol, yet which we believe are essential to the future success of IPng 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 Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 39] Internet Draft IPng Technical Criteria March 1994 determine which one becomes IPng, 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. (11) Robust Service includes a mention of Hostile attacks and Byzantine failures. , Partridge & Kastenholz Exp. 28 Sep. 1994 [Page 40] Internet Draft IPng Technical Criteria March 1994 Table of Contents Status of this Memo .................................... 1 1 Introduction .......................................... 2 2 Goals ................................................. 3 3 Note on Terminology ................................... 4 4 General Principles .................................... 5 4.1 Architectural Simplicity ............................ 5 4.2 One Protocol to Bind Them All ....................... 5 4.3 Live Long ........................................... 5 4.4 Live Long AND Prosper ............................... 6 4.5 Co-operative Anarchy ................................ 6 5 Criteria .............................................. 8 5.1 Scale ............................................... 8 5.2 Topological Flexibility ............................. 10 5.3 Performance ......................................... 11 5.4 Robust Service ...................................... 12 5.5 Transition .......................................... 14 5.6 Media Independence .................................. 15 5.7 Unreliable Datagram Service ......................... 17 5.8 Configuration, Administration, and Operation ........ 18 5.9 Allow Secure Operation .............................. 20 5.10 Unique Naming ...................................... 21 5.11 Access ............................................. 22 5.12 Multicast Addressing ............................... 22 5.13 Extensibility ...................................... 24 5.14 Network Service .................................... 25 5.15 Support for Mobility ............................... 26 5.16 Control Protocol ................................... 28 5.17 Tunneling .......................................... 28 5.18 Explicit Non-Goals ................................. 29 6 Security Considerations ............................... 31 7 Acknowledgements ...................................... 32 8 References ............................................ 33 9 Change Log ............................................ 34 9.1 23 March 1994 ....................................... 34 9.2 21 March 1994 ....................................... 34 9.3 10 March 1994 ....................................... 36 9.4 9 March 1994 ........................................ 36 9.5 15 February 1994 .................................... 37 9.6 9 November 1993 ..................................... 38 9.7 9 September 1993 .................................... 39 9.8 14 December 1992 .................................... 39 Partridge & Kastenholz Exp. 28 Sep. 1994 [Page xli] ---- Frank Kastenholz FTP Software 2 High Street North Andover Mass USA 01845 508-685-4000