Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12585; 9 Dec 92 0:08 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12581; 9 Dec 92 0:08 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa12295; 9 Dec 92 0:10 EST Received: from uu.psi.com by ftp.com with SMTP id AA05700; Wed, 9 Dec 92 00:07:46 -0500 Received: from fibermux.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA07156; Tue, 8 Dec 92 23:44:14 -0500 Received: from ccrelay.fibermux.com by fibermux.com (4.1/SMI-4.1) id AA03474; Tue, 8 Dec 92 15:28:27 PST Received: from cc:Mail by ccrelay.fibermux.com (1.20/SMTPLink) id A02553; Tue, 08 Dec 92 15:24:19 PST Date: Tue, 08 Dec 92 15:24:19 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: MICHAEL SUNG Message-Id: <9212081524.A02553@ccrelay.fibermux.com> Cc: criteria-request@ftp.com, criteria@ftp.com Subject: subscribe me Please add msung@fibermux.com to the ip7 mailing list. Thanks.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12177; 14 Dec 92 14:19 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12171; 14 Dec 92 14:19 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa12934; 14 Dec 92 14:21 EST Received: by ftp.com id AA23547; Mon, 14 Dec 92 14:02:15 -0500 Date: Mon, 14 Dec 92 14:02:15 -0500 Message-Id: <9212141902.AA23547@ftp.com> To: criteria@ftp.com Subject: new version of the draft Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Hi, I just sent the attached off to the internet-drafts repositories. It reflects the changes that have been discussed at the IETF, along with some other concerns that have been raised (there is a change log near the beginning of the document...) -- Frank Kastenholz o / ------------------------------x----------------------------------------- O \ 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]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13018; 14 Dec 92 15:25 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13010; 14 Dec 92 15:25 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa15532; 14 Dec 92 15:27 EST Received: from nic.near.net by ftp.com with SMTP id AA26415; Mon, 14 Dec 92 15:21:14 -0500 Message-Id: <9212142021.AA26415@ftp.com> To: kasten@ftp.com Cc: criteria@ftp.com Subject: Re: new version of the draft In-Reply-To: Your message of Mon, 14 Dec 92 14:02:15 -0500. <9212141902.AA23547@ftp.com> Date: Mon, 14 Dec 92 15:20:55 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Curran -------- From: Frank Kastenholz Subject: new version of the draft Date: Mon, 14 Dec 92 14:02:15 -0500 Hi, I just sent the attached off to the internet-drafts repositories. It reflects the changes that have been discussed at the IETF, along with some other concerns that have been raised (there is a change log near the beginning of the document...) Looks great. Comments follow. 2. Goals ... 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. Further ranking of the "MUST" criteria is entertaining, but akin to ranking the importance of major organs... the net result is that if any are missing, you lose. Further ranking of the "SHOULD" criteria would be very useful, but may require consensus measuring techniques like show-of-hands or hum-intensity meters. While the discussion should take place on the mailing list, it's probably not possible to achieve an ordered list without a physical meeting. ... 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. We might want to add "ADDRESS DEPLETION." since there appears to be two problems on the horizon, and routing congestion may not be the one to strike first if CIDR is successful. ... - 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. Either add " - Ease of changing geographic attachment point" or state that the ability to reconfigure hosts and routers as described in the following points covers both changing of provider and of geographic attachment point. /John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01005; 16 Dec 92 4:39 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00999; 16 Dec 92 4:39 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa03335; 16 Dec 92 4:41 EST Received: from dxmint.cern.ch by ftp.com with SMTP id AA15769; Wed, 16 Dec 92 04:35:23 -0500 Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06579; Wed, 16 Dec 1992 10:35:12 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA10663; Wed, 16 Dec 92 10:35:02 +0100 Message-Id: <9212160935.AA10663@dxcern.cern.ch> Subject: Re: new version of the draft To: kasten@ftp.com Date: Wed, 16 Dec 92 10:35:00 MET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Cc: criteria@ftp.com In-Reply-To: <9212141902.AA23547@ftp.com>; from "Frank Kastenholz" at Dec 14, 92 2:02 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] Hi, here are some *personal* comments on the December criteria draft. I hope to provide some more formal CERN comments asap. 5.1.9 Unique Naming I agree with the authors that this should not be a selection criterion. Now clearly, if for any proposal, it can be proved that the lack of unique (binary) names actually breaks the network than that proposal is no good. (Maybe we need a criterion "the protocol must not be broken" :-) For the record I raised my hand against this criterion at Washington. 5.2.1 Addressing Why isn't this section headed "multicasting"? I think the discussion should distinguish more clearly "multicasting for service location" from "multicast applications". The former is unnecessary and undesirable (e.g. see the IP over FibreChannel proposal for ARP without multicast) and the latter do not necessarily require multicast at the IP level. So (at the most) this is a SHOULD. 5.2.2 Extensibility Yes. No. My problem is that I don't understand what extensibility means, so I don't know if I need it. I raised the possible criterion of "compatibility with multiprotocol routers" and this was shot down without trace (but I still want it :-). But isn't it one form of extensibility? What are the others? This criterion needs work before I can judge whether it's a MUST, a SHOULD, or null. 5.2.7 Performance (place holder) I would express it as "not significantly slower than IPv4 on the same generation of hardware" and I think it's a MUST. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of | | PIP/EIP, SIP/IPAE, Nimrod, or TUBA. |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03613; 16 Dec 92 10:27 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03607; 16 Dec 92 10:27 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa12372; 16 Dec 92 10:29 EST Received: by ftp.com id AA22366; Wed, 16 Dec 92 10:21:26 -0500 Date: Wed, 16 Dec 92 10:21:26 -0500 Message-Id: <9212161521.AA22366@ftp.com> To: jcurran@nic.near.net Subject: Re: new version of the draft Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: criteria@ftp.com John Thanks for your comments on the criteria draft. > Further ranking of the "SHOULD" criteria would be very useful, but may > require consensus measuring techniques like show-of-hands or hum-intensity > meters. While the discussion should take place on the mailing list, it's > probably not possible to achieve an ordered list without a physical meeting. We'll have to consider this. Right now, I think that some of the criteria are still nebulous enough, and the allocation of some of the criteria as should or must is still not final so we probably want to nail these issues down before we try ordering the shoulds. > We might want to add "ADDRESS DEPLETION." since there appears to be two > problems on the horizon, and routing congestion may not be the one to strike > first if CIDR is successful. done > ... > > - 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. > > Either add " - Ease of changing geographic attachment point" or state that the > ability to reconfigure hosts and routers as described in the following points > covers both changing of provider and of geographic attachment point. I am not exactly sure what you mean here. I _think_ that the points we have enumerated cover what I _think_ it is you want.... -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04417; 16 Dec 92 11:03 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04411; 16 Dec 92 11:03 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa13521; 16 Dec 92 11:05 EST Received: by ftp.com id AA23413; Wed, 16 Dec 92 10:49:39 -0500 Date: Wed, 16 Dec 92 10:49:39 -0500 Message-Id: <9212161549.AA23413@ftp.com> To: brian@dxcern.cern.ch Subject: Re: new version of the draft Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: criteria@ftp.com Brian, Thanks for your comments on the criteria document. > 5.2.1 Addressing > > Why isn't this section headed "multicasting"? It was at one point. I don't recall why we changed it :-) > I think the discussion should distinguish more clearly "multicasting > for service location" from "multicast applications". The former > is unnecessary and undesirable (e.g. see the IP over FibreChannel proposal > for ARP without multicast) and the latter do not necessarily > require multicast at the IP level. > > So (at the most) this is a SHOULD. Craig and I (as we said in the document) believe that multicast is an essential feature for future applications. I admit that we are trying to foretell what will be needed as new and neat applications are developed; that we are going out on a bit of a limb. However, we believe that v7 should represent a significant functional improvement over v4 or else there will be little reason to change. > > 5.2.2 Extensibility > > Yes. No. My problem is that I don't understand what extensibility > means, so I don't know if I need it. I raised the possible > criterion of "compatibility with multiprotocol routers" and this > was shot down without trace (but I still want it :-). But isn't > it one form of extensibility? What are the others? > > This criterion needs work before I can judge whether it's a MUST, > a SHOULD, or null. By extensibility we mean that additional things can be added to the protocol over its lifetime and that these additions can be done in such a way that nodes which are not upgraded to support the addition can still communicate with those that are upgraded. One possible solution to this would be options. I now remember talk at the BOF about "compatibility with multiprotocol routers." I do not think that this is an "extensibility" issue so much as an issue for the media over which IPv7 should operate. In effect, IPv7 must be able to co-exist on any medium that supports multiple protocols (e.g. for Ethernet, it would have its own ether-type value). If it can co-exist on multi-protocol media, then routers ought to be able to determine that a packet is an IPv7 packet and process it accordingly. -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05785; 16 Dec 92 12:18 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05779; 16 Dec 92 12:18 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa16220; 16 Dec 92 12:20 EST Received: from watson.ibm.com by ftp.com with SMTP id AA27268; Wed, 16 Dec 92 12:16:20 -0500 Message-Id: <9212161716.AA27268@ftp.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1719; Wed, 16 Dec 92 12:16:00 EST Date: Wed, 16 Dec 92 12:15:16 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com To: criteria@ftp.com Subject: Criteria for IPv7 In Section 5.1.7 (discussion on Configuration, Administration, and Operation) I would suggest to further partition the issue of configuration into host's autoconfiguration and router's autoconfiguration. As the document stated correctly, the fully automated configuration "is still a topic of research". This is especially true with respect to fully automated configuration of routers. I think that the problem of fully automated configuration of hosts is much less of a research issue. Most of the complexity in autoconfiguration is related not to the size of a network, but to the additional complexity associated router autoconfiguration. To reflect this here is a proposed replacement text for the second paragraph in DISCUSSION part of 5.1.7: "We do note that fully automated configuration, especially the one that covers both hosts and routers is still a topic of research. Our concern is mostly for the host automated configuration." Yakov Rekhter.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01440; 17 Dec 92 3:13 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01434; 17 Dec 92 3:13 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa03111; 17 Dec 92 3:15 EST Received: from dxmint.cern.ch by ftp.com with SMTP id AA20823; Thu, 17 Dec 92 03:11:44 -0500 Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12198; Thu, 17 Dec 1992 09:11:38 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA15064; Thu, 17 Dec 92 09:11:36 +0100 Message-Id: <9212170811.AA15064@dxcern.cern.ch> Subject: Re: new version of the draft To: criteria@ftp.com Date: Thu, 17 Dec 92 9:11:34 MET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN In-Reply-To: <9212161549.AA23413@ftp.com>; from "Frank Kastenholz" at Dec 16, 92 10:49 am X-Mailer: ELM [version 2.3 PL11 CERN 11] Frank, Thanks for the clarifications. I'd like to argue a bit more about whether the need for multicast applications implies a need for multicast IP. We've had non-real-time multicast applications for years, such as LISTSERV on BITNET, and newsgroups. They have the property that the multicast spanning tree is built at application level (and lives in name space rather than address space). They also have the property that (in principle) the same traffic need never flow twice over the same link. Now is there any reasons why real time multicast applications cannot be built the same way? This is a genuine question, I have no prejudice about the answer. (Another argument against multicast at IP level is that ATM will do it better, but that is futuristic.) Brian   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01587; 17 Dec 92 3:42 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01581; 17 Dec 92 3:42 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa03748; 17 Dec 92 3:44 EST Received: from alpha.Xerox.COM by ftp.com with SMTP id AA21082; Thu, 17 Dec 92 03:38:13 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11521>; Thu, 17 Dec 1992 00:37:47 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10782>; Thu, 17 Dec 1992 00:37:38 -0800 To: Brian Carpenter CERN-CN Cc: criteria@ftp.com, deering@parc.xerox.com Subject: Re: new version of the draft In-Reply-To: Your message of "Thu, 17 Dec 92 00:11:34 PST." <9212170811.AA15064@dxcern.cern.ch> Date: Thu, 17 Dec 1992 00:37:38 PST X-Orig-Sender: Steve Deering Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Deering Message-Id: <92Dec17.003738pst.10782@skylark.parc.xerox.com> > ... We've had non-real-time multicast applications > for years, such as LISTSERV on BITNET, and newsgroups. > They have the property that the multicast spanning tree is built > at application level (and lives in name space rather than address > space). They also have the property that (in principle) the same > traffic need never flow twice over the same link. I don't think that is true, in principle or in reality, unless your applications also live in the routers. The MBONE is effectively doing "application level" (at least, not hop-by-hop in the real routers) multicast, and it is been impossible to limit all links to only one tunnel. > (Another argument against multicast at IP level is that ATM will > do it better, but that is futuristic.) What makes you believe that? In what ways can ATM do it better? Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01645; 17 Dec 92 4:10 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01639; 17 Dec 92 4:10 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa04151; 17 Dec 92 4:12 EST Received: from dxmint.cern.ch by ftp.com with SMTP id AA21370; Thu, 17 Dec 92 04:08:42 -0500 Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23730; Thu, 17 Dec 1992 10:08:33 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA03081; Thu, 17 Dec 92 10:08:27 +0100 Message-Id: <9212170908.AA03081@dxcern.cern.ch> Subject: Re: new version of the draft To: criteria@ftp.com Date: Thu, 17 Dec 92 10:08:25 MET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN In-Reply-To: <92Dec17.003738pst.10782@skylark.parc.xerox.com>; from "Steve Deering" at Dec 17, 92 12:37 am X-Mailer: ELM [version 2.3 PL11 CERN 11] Steve and people, In view of what follows I accept multicast support as a valid criterion. For me it's either a SHOULD, or a new category: a DEFERRED MUST (must be a property of the protocol, but not necessarily available at the start of deployment). > > > ... We've had non-real-time multicast applications > > for years, such as LISTSERV on BITNET, and newsgroups. > > They have the property that the multicast spanning tree is built > > at application level (and lives in name space rather than address > > space). They also have the property that (in principle) the same > > traffic need never flow twice over the same link. > > I don't think that is true, in principle or in reality, unless your > applications also live in the routers. The MBONE is effectively > doing "application level" (at least, not hop-by-hop in the real routers) > multicast, and it is been impossible to limit all links to only one > tunnel. OK, so the argument is that to *guarantee* a spanning tree that does not use the same physical link N times, the spanning tree has to be managed by the routers. I think I buy that, thanks. I refrained from citing MBONE because I happen to know how many times the Washington audiocast traffic went up and down the CERN-Amsterdam link :-( > > > (Another argument against multicast at IP level is that ATM will > > do it better, but that is futuristic.) > > What makes you believe that? In what ways can ATM do it better? > I put it in parenthesis because I'm not sure I do believe it. Some ATM experts do, but multicast over ATM is not even standardised. And at best a subset of the Internet will be ATM based. However that's probably not a debate for the criteria list - see the comp.dcom.cell-relay newsgroup for example. Brian   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01641; 17 Dec 92 11:36 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01635; 17 Dec 92 11:36 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa16389; 17 Dec 92 11:38 EST Received: from nic.near.net by ftp.com with SMTP id AA02003; Thu, 17 Dec 92 11:35:00 -0500 Message-Id: <9212171635.AA02003@ftp.com> To: kasten@ftp.com Cc: criteria@ftp.com Subject: Re: new version of the draft In-Reply-To: Your message of Wed, 16 Dec 92 10:21:26 -0500. <9212161521.AA22366@ftp.com> Date: Thu, 17 Dec 92 11:34:38 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Curran -------- From: Frank Kastenholz Subject: Re: new version of the draft Date: Wed, 16 Dec 92 10:21:26 -0500 We'll have to consider this. Right now, I think that some of the criteria are still nebulous enough, and the allocation of some of the criteria as should or must is still not final so we probably want to nail these issues down before we try ordering the shoulds. No problem. > ... > > - 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. > > Either add " - Ease of changing geographic attachment point" > or state that the ability to reconfigure hosts and routers > as described in the following points covers both changing of > provider and of geographic attachment point. I am not exactly sure what you mean here. I _think_ that the points we have enumerated cover what I _think_ it is you want.... My fault for being vague. Okay, we explicitely list the desired properities (i.e. Ease of (re)configuring host address/ids, and router address/ids) but then add another point which appears a motivator for these (i.e. "Ease of changing network provider"). If we are going to delinate the motivations for reconfiguration, we should add "Ease of changing geographic attachment point" since that is also desirable. /John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01429; 18 Dec 92 3:15 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01423; 18 Dec 92 3:15 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa02636; 18 Dec 92 3:17 EST Received: from lager.cisco.com by ftp.com with SMTP id AA28843; Fri, 18 Dec 92 03:11:43 -0500 Received: by lager.cisco.com; Fri, 18 Dec 92 00:11:38 -0800 Date: Fri, 18 Dec 92 00:11:38 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <9212180811.AA15375@lager.cisco.com> To: criteria@ftp.com Cc: kasten@ftp.com Subject: Re: new version of the draft [.... fun with multicasting ...] However, we believe that v7 should represent a significant functional improvement over v4 or else there will be little reason to change. I would submit that impending doom from address space depletion is sufficient motivation in and of itself. 0.5 ;-) Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04036; 18 Dec 92 9:19 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04030; 18 Dec 92 9:19 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa10751; 18 Dec 92 9:21 EST Received: by ftp.com id AA04363; Fri, 18 Dec 92 09:17:26 -0500 Date: Fri, 18 Dec 92 09:17:26 -0500 Message-Id: <9212181417.AA04363@ftp.com> To: tli@cisco.com Subject: Re: new version of the draft Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: criteria@ftp.com, kasten@ftp.com > [.... fun with multicasting ...] However, we > believe that v7 should represent a significant functional improvement > over v4 or else there will be little reason to change. > > I would submit that impending doom from address space depletion is > sufficient motivation in and of itself. 0.5 ;-) One would hope. However, there is another, equally conceivable path: the Internet Balkanizes and that there are various "small" Internets connected together via application-level gateways. Also, if there is a good coexistance/translation scheme that allows IPv4-only hosts to talk to IPv7-only hosts (e.g. via some translating gateway) then why should any given site convert? Why not have everyone else convert? In many ways the Internet is what economists call a Common. Commons are places where everyone can come and use the resources with equal access and equal cost to all. The cost to use a Common is the same regardless of how much of it you use -- sort of like an all you can eat buffet at a restaurant. So, there is every incentive for the users of a Common to consume as much of the Common as they can, just as at the buffet everyone tries to eat as much as they can trying to get more than $10 or whatever worth of food. The concept originated several hundred years ago in small farming villages with what is now called the Town Common. The Town Common was a place where each farmer could bring his cows or sheep or whatever and let them graze. Of course, every farmer did just that, and had his animals graze as much as he could, taking more than their "fair share" and there was nothing that could be done to regulate this over-use. Since each farmer took as much as he could, the Common soon became a barren mud-hole. The Internet is similar. Other than peer pressure, why should I do things that end up 'costing' me when I can figure out some way to get you to pay the cost and let me derive the benefit? If I get everyone to convert to IPv7 but me, and I continue to make use of the IPv4<->IPv7 translating gateways then you have paid the cost of adopting the new IP and I gain the benefit (at no cost to myself) of a ubiquitous Internet. By having new and improved functions available on IPv7, ones that are not available on IPv4, then there now is incentive for me to convert to IPv7. If I convert, I get new functions, if I do not convert, I do not get these functions. This, of course, ignores "peer" pressure by the community which so far has worked at keeping us all good citizens. As the Internet becomes more ubiquitous we will be bringing in people who are less affected by this "peer" pressure, or people who are not indoctrinated into, and believe, the culture. -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05202; 18 Dec 92 10:10 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05196; 18 Dec 92 10:10 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa12400; 18 Dec 92 10:12 EST Received: from mailee.bellcore.com by ftp.com with SMTP id AA06188; Fri, 18 Dec 92 10:05:20 -0500 Received: from gizmo.bellcore.com by mailee.bellcore.com (5.61/1.34) id AA05847; Fri, 18 Dec 92 10:04:52 -0500 Message-Id: <9212181504.AA05847@mailee.bellcore.com> To: kasten@ftp.com Cc: tli@cisco.com, criteria@ftp.com Subject: Friendly Balkanization.... Date: Fri, 18 Dec 92 10:04:50 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: mo@bellcore.com Actually, the "friendly balkanization" that you describe (multiple nets with applications gateways) has been the case for quite some time in specific cases. To wit: The EMail nets have almost always been multi-protocol and mail application gateways have been the norm since at least the mid-late 70s. The most visible clumps in that galaxy include the fully-connected SMTP cloud, the UUCP cloud, the FIDONET cloud, the BITnet cloud, the commercial Email providers clouds, and others more obscure but just as connected. In general, unless one pings a nameserver, one seldom actually knows what vehicles will be involved in delivering a given piece of mail. The Internet DNS does a great service far beyond its direct reach. For "news" applications, USENET and FIDONET are both in there, as are others. Most of these are cross-connected to an amazing degree, and yes, header munging is awful and unclean and should be avoided at all costs, but it works to an equally amazing degree. Now that there are servers which respond to ftp requests sent via EMail, the applications one migh class as "bit-vending" are working trans-protocol universe. Other gateways (FTP/NFS, FTP/FTAM, etc, etc) are happening as well. Admittedly this level of interconnection works best for services where latency can be tolerated, but the Internet Gopher work is busily sewing together lots of interactive but previously-disjoint services under a common service delivery protocol and interface. Adding arbitrary gateways is relatively easy, and gateways exist between Gopher and TELNET-based services, Gopher and FTP, Gopher and WAIS, Gopher and ARCHIE, Gopher and News, and as soon as a service pops up in some other alternate universe of sufficient interest, someone will build the gateway. Note that I'm not claiming any of this is perfect, and given the choice, one would prefer ubiquitous direct interoperability. While it is a grand goal, and one which we should vigorously pursue, it is unattainable any time soon, and given that, the growing web of applications gateways, bridging the transport and semantic gaps between various network fabrics is indeed doing a great service bringing us all together. -Mike O'Dell Bellcore?? Bellcore isn't allowed opinions. Any found here are merely my mad ravings.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08709; 18 Dec 92 13:06 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08703; 18 Dec 92 13:06 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa20054; 18 Dec 92 13:08 EST Received: from MITCHELL.CIT.CORNELL.EDU by ftp.com with SMTP id AA14127; Fri, 18 Dec 92 13:03:40 -0500 Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA11139; Fri, 18 Dec 92 13:03:21 EST Message-Id: <9212181803.AA11139@mitchell.cit.cornell.edu> To: kasten@ftp.com Cc: criteria@ftp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott_Brim@cornell.edu Subject: Re: new version of the draft In-Reply-To: Frank Kastenholz's message of Fri, 18 Dec 1992 09:17:26 -0500. <9212181417.AA04363@ftp.com> Date: Fri, 18 Dec 1992 13:03:20 -0500 X-Orig-Sender: swb@nr-tech.cit.cornell.edu Right on (although not totally appropriate for the criteria list). The commercial providers, at least, will continue to offer translation service as long as it makes them money, which will be a very long time. They will offer application-level gateways for even longer, and even after we run out of globally unique IPv4 addresses, I suspect that the service providers will support IPv4 between their own customers. The force working against balkanization is the introduction of new services and features which can only be run over a common lower layer. I believe there will be plenty of these -- I can't imagine "mail-enabled videoconferencing" for example(!). So balkanization isn't a Solution, but translation/encapsulation services -- the so-called transition period -- will be with us for ages, and any Solution should include efficient ones. Scott   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12899; 18 Dec 92 17:09 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12893; 18 Dec 92 17:09 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa27542; 18 Dec 92 17:11 EST Received: from lager.cisco.com by ftp.com with SMTP id AA25007; Fri, 18 Dec 92 17:07:31 -0500 Received: by lager.cisco.com; Fri, 18 Dec 92 14:07:10 -0800 Date: Fri, 18 Dec 92 14:07:10 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <9212182207.AA12140@lager.cisco.com> To: kasten@ftp.com Cc: criteria@ftp.com, kasten@ftp.com In-Reply-To: (Frank Kastenholz's message of Fri, 18 Dec 92 09:17:26 -0500 <9212181417.AA04363@ftp.com> Subject: new version of the draft Your analysis (BTW, very interesting reading, thanks) leaves out the fact that at the point where we have run out of IPv4 address space, I can no longer expand my IPv4 "island". It also ignores the "momentum factor": if there is demand for IPv7, more products will be created for IPv7. IPv4 will be an extra cost option. At some point it snowballs and IPv7 becomes the default, ubiquitous service. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13565; 21 Dec 92 11:27 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13557; 21 Dec 92 11:27 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa03539; 21 Dec 92 11:30 EST Received: by ftp.com id AA28202; Mon, 21 Dec 92 11:24:39 -0500 Date: Mon, 21 Dec 92 11:24:39 -0500 Message-Id: <9212211624.AA28202@ftp.com> Uto: ericf@atc.boeing.com Subject: Re: IPv7 Selection Criteria Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, criteria@ftp.com, ericf@ftp.com Eric and Noel, I've taken the liberty of moving this to the critertia list. > >> Eric: > >> An interesting viewpoint! A couple of things I want to ask about: > >> * Scalabilty > >>Why is this so high for you guys? Presumably you mostly just care if the > >>network can be big enough for your company? If you intend to be globally > >>connected, and this is important, shouldn't Robustness/Security be higher? > > Scalability and router aggregation is at the top of our criteria list > because these are the primary problems IPv7 are trying to resolve. > Other problem resolutions, we feel, are secondary to this (we concur > with Ullmann's Email messages in this regards). We care > about this matter because the world is "getting smaller" and every > Internet user must be concerned with the continued viability of the > Internet community as a whole if the Internet is to continue to meet > our various parochial needs. I love this answer :-) We must all put the interests of the Internet above any purely local needs (the phrase "enlightened self-interest" comes to mind here). Without a healthy, robust, ubiquitous Internet then TCP/IP is "just another protocol." > > >> * Ease/possibility of transition > >>Everyone should contemplate the fact that this was one of their 'top 2'. If a > >>scheme doesn't have *real* complete interoperability to unmodifed hosts, my > >>prediction is it'll be much less desireable (i.e. "undesireable"). > > We concur. An ultimate solution from our point of view will not ask > currently deployed hosts to be touched in order to function in the > "new world". Since router deployments tend to be two order > of magnitudes smaller in size (at least they are in our network) > we vastly prefer the solution to primarily impact routers, > as opposed to both hosts and routers. We have previously posted a > corporate position dealing with our preferences if there is no alternative > to modifying hosts. However, the key message we wish to send is that > migrational issues are "key" from our viewpoint. From our knothole, > "ease of migration/transition" is among the top two requirements in > importance. I think that this is important. There will always be pockets of IPv4 that never get upgraded for some reason or another and we have to be concerned with these. They ought not be locked out of the Internet. These pockets might, however, provide a less-rich set of functions and services than IPv7 hosts would have. For example, IPv7 could have a robust, strong security function in it. IPv4 does not have such a function (and for the sake of argument, let's assume that one is not developed). The IPv4-only hosts would then not have the security offered by IPv7. > > >> * Last a long time (20 years). > Lasting 20 years is an extremely important goal for IPv7. However, it > seems to us that it is a "warm and fuzzy". Many of its hard criteria are Our latest version of the draft has a section that could, uncharitably, be called "warm and fuzzy goals" which is where this is. -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14047; 21 Dec 92 11:41 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14028; 21 Dec 92 11:41 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa04012; 21 Dec 92 11:43 EST Received: by ftp.com id AA28989; Mon, 21 Dec 92 11:39:34 -0500 Date: Mon, 21 Dec 92 11:39:34 -0500 Message-Id: <9212211639.AA28989@ftp.com> Uto: ericf@atc.boeing.com Subject: Re: IPv7 Selection Criteria Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, criteria@ftp.com, ericf@ftp.com Eric and Noel, I've taken the liberty of moving this to the critertia list. > >> Eric: > >> An interesting viewpoint! A couple of things I want to ask about: > >> * Scalabilty > >>Why is this so high for you guys? Presumably you mostly just care if the > >>network can be big enough for your company? If you intend to be globally > >>connected, and this is important, shouldn't Robustness/Security be higher? > > Scalability and router aggregation is at the top of our criteria list > because these are the primary problems IPv7 are trying to resolve. > Other problem resolutions, we feel, are secondary to this (we concur > with Ullmann's Email messages in this regards). We care > about this matter because the world is "getting smaller" and every > Internet user must be concerned with the continued viability of the > Internet community as a whole if the Internet is to continue to meet > our various parochial needs. I love this answer :-) We must all put the interests of the Internet above any purely local needs (the phrase "enlightened self-interest" comes to mind here). Without a healthy, robust, ubiquitous Internet then TCP/IP is "just another protocol." > > >> * Ease/possibility of transition > >>Everyone should contemplate the fact that this was one of their 'top 2'. If a > >>scheme doesn't have *real* complete interoperability to unmodifed hosts, my > >>prediction is it'll be much less desireable (i.e. "undesireable"). > > We concur. An ultimate solution from our point of view will not ask > currently deployed hosts to be touched in order to function in the > "new world". Since router deployments tend to be two order > of magnitudes smaller in size (at least they are in our network) > we vastly prefer the solution to primarily impact routers, > as opposed to both hosts and routers. We have previously posted a > corporate position dealing with our preferences if there is no alternative > to modifying hosts. However, the key message we wish to send is that > migrational issues are "key" from our viewpoint. From our knothole, > "ease of migration/transition" is among the top two requirements in > importance. I think that this is important. There will always be pockets of IPv4 that never get upgraded for some reason or another and we have to be concerned with these. They ought not be locked out of the Internet. These pockets might, however, provide a less-rich set of functions and services than IPv7 hosts would have. For example, IPv7 could have a robust, strong security function in it. IPv4 does not have such a function (and for the sake of argument, let's assume that one is not developed). The IPv4-only hosts would then not have the security offered by IPv7. > > >> * Last a long time (20 years). > Lasting 20 years is an extremely important goal for IPv7. However, it > seems to us that it is a "warm and fuzzy". Many of its hard criteria are Our latest version of the draft has a section that could, uncharitably, be called "warm and fuzzy goals" which is where this is. -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14198; 21 Dec 92 11:44 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14192; 21 Dec 92 11:44 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa04128; 21 Dec 92 11:47 EST Received: by ftp.com id AA29199; Mon, 21 Dec 92 11:42:40 -0500 Date: Mon, 21 Dec 92 11:42:40 -0500 Message-Id: <9212211642.AA29199@ftp.com> Uto: ericf@atc.boeing.com Subject: Re: IPv7 Selection Criteria Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, criteria@ftp.com, ericf@ftp.com Eric and Noel, I've taken the liberty of moving this to the critertia list. > >> Eric: > >> An interesting viewpoint! A couple of things I want to ask about: > >> * Scalabilty > >>Why is this so high for you guys? Presumably you mostly just care if the > >>network can be big enough for your company? If you intend to be globally > >>connected, and this is important, shouldn't Robustness/Security be higher? > > Scalability and router aggregation is at the top of our criteria list > because these are the primary problems IPv7 are trying to resolve. > Other problem resolutions, we feel, are secondary to this (we concur > with Ullmann's Email messages in this regards). We care > about this matter because the world is "getting smaller" and every > Internet user must be concerned with the continued viability of the > Internet community as a whole if the Internet is to continue to meet > our various parochial needs. I love this answer :-) We must all put the interests of the Internet above any purely local needs (the phrase "enlightened self-interest" comes to mind here). Without a healthy, robust, ubiquitous Internet then TCP/IP is "just another protocol." > > >> * Ease/possibility of transition > >>Everyone should contemplate the fact that this was one of their 'top 2'. If a > >>scheme doesn't have *real* complete interoperability to unmodifed hosts, my > >>prediction is it'll be much less desireable (i.e. "undesireable"). > > We concur. An ultimate solution from our point of view will not ask > currently deployed hosts to be touched in order to function in the > "new world". Since router deployments tend to be two order > of magnitudes smaller in size (at least they are in our network) > we vastly prefer the solution to primarily impact routers, > as opposed to both hosts and routers. We have previously posted a > corporate position dealing with our preferences if there is no alternative > to modifying hosts. However, the key message we wish to send is that > migrational issues are "key" from our viewpoint. From our knothole, > "ease of migration/transition" is among the top two requirements in > importance. I think that this is important. There will always be pockets of IPv4 that never get upgraded for some reason or another and we have to be concerned with these. They ought not be locked out of the Internet. These pockets might, however, provide a less-rich set of functions and services than IPv7 hosts would have. For example, IPv7 could have a robust, strong security function in it. IPv4 does not have such a function (and for the sake of argument, let's assume that one is not developed). The IPv4-only hosts would then not have the security offered by IPv7. > > >> * Last a long time (20 years). > Lasting 20 years is an extremely important goal for IPv7. However, it > seems to us that it is a "warm and fuzzy". Many of its hard criteria are Our latest version of the draft has a section that could, uncharitably, be called "warm and fuzzy goals" which is where this is. -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14291; 21 Dec 92 11:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14283; 21 Dec 92 11:50 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa04216; 21 Dec 92 11:52 EST Received: by ftp.com id AA29439; Mon, 21 Dec 92 11:49:14 -0500 Date: Mon, 21 Dec 92 11:49:14 -0500 Message-Id: <9212211649.AA29439@ftp.com> Uto: ericf@atc.boeing.com Subject: Re: IPv7 Selection Criteria Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, criteria@ftp.com, ericf@ftp.com Eric and Noel, I've taken the liberty of moving this to the critertia list. > >> Eric: > >> An interesting viewpoint! A couple of things I want to ask about: > >> * Scalabilty > >>Why is this so high for you guys? Presumably you mostly just care if the > >>network can be big enough for your company? If you intend to be globally > >>connected, and this is important, shouldn't Robustness/Security be higher? > > Scalability and router aggregation is at the top of our criteria list > because these are the primary problems IPv7 are trying to resolve. > Other problem resolutions, we feel, are secondary to this (we concur > with Ullmann's Email messages in this regards). We care > about this matter because the world is "getting smaller" and every > Internet user must be concerned with the continued viability of the > Internet community as a whole if the Internet is to continue to meet > our various parochial needs. I love this answer :-) We must all put the interests of the Internet above any purely local needs (the phrase "enlightened self-interest" comes to mind here). Without a healthy, robust, ubiquitous Internet then TCP/IP is "just another protocol." > > >> * Ease/possibility of transition > >>Everyone should contemplate the fact that this was one of their 'top 2'. If a > >>scheme doesn't have *real* complete interoperability to unmodifed hosts, my > >>prediction is it'll be much less desireable (i.e. "undesireable"). > > We concur. An ultimate solution from our point of view will not ask > currently deployed hosts to be touched in order to function in the > "new world". Since router deployments tend to be two order > of magnitudes smaller in size (at least they are in our network) > we vastly prefer the solution to primarily impact routers, > as opposed to both hosts and routers. We have previously posted a > corporate position dealing with our preferences if there is no alternative > to modifying hosts. However, the key message we wish to send is that > migrational issues are "key" from our viewpoint. From our knothole, > "ease of migration/transition" is among the top two requirements in > importance. I think that this is important. There will always be pockets of IPv4 that never get upgraded for some reason or another and we have to be concerned with these. They ought not be locked out of the Internet. These pockets might, however, provide a less-rich set of functions and services than IPv7 hosts would have. For example, IPv7 could have a robust, strong security function in it. IPv4 does not have such a function (and for the sake of argument, let's assume that one is not developed). The IPv4-only hosts would then not have the security offered by IPv7. > > >> * Last a long time (20 years). > Lasting 20 years is an extremely important goal for IPv7. However, it > seems to us that it is a "warm and fuzzy". Many of its hard criteria are Our latest version of the draft has a section that could, uncharitably, be called "warm and fuzzy goals" which is where this is. -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14333; 21 Dec 92 11:52 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14327; 21 Dec 92 11:52 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa04267; 21 Dec 92 11:55 EST Received: by ftp.com id AA29579; Mon, 21 Dec 92 11:51:15 -0500 Date: Mon, 21 Dec 92 11:51:15 -0500 Message-Id: <9212211651.AA29579@ftp.com> To: jnc@ginger.lcs.mit.edu, criteria@ftp.com, ericf@ftp.com Subject: Re: IPv7 Selection Criteria Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Sorry about multiple copies in my earlier message. I had a problem in the mail header.... -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15331; 21 Dec 92 12:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15325; 21 Dec 92 12:53 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa06533; 21 Dec 92 12:56 EST Received: from MITCHELL.CIT.CORNELL.EDU by ftp.com with SMTP id AA02493; Mon, 21 Dec 92 12:54:00 -0500 Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA11804; Mon, 21 Dec 92 12:53:40 EST Message-Id: <9212211753.AA11804@mitchell.cit.cornell.edu> To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, criteria@ftp.com, ericf@ftp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott_Brim@cornell.edu Subject: Re: IPv7 Selection Criteria In-Reply-To: Frank Kastenholz's message of Mon, 21 Dec 1992 11:24:39 -0500. <9212211624.AA28202@ftp.com> Date: Mon, 21 Dec 1992 12:53:39 -0500 X-Orig-Sender: swb@nr-tech.cit.cornell.edu >I think that this is important. There will always be pockets of IPv4 >that never get upgraded for some reason or another and we have to be >concerned with these. They ought not be locked out of the Internet. Right. This is what I was trying to say before. It's not just that we have to tolerate these "pockets" (actually they're more like duffel bags) -- the various IPv* plans must not deal with them in just a transition plan, since the transition will never be finished. The bags have to be given more respect than that. Ease of interoperability with IPv4 (allowing for restricted capabilities) should be given higher priority. Scott   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18955; 21 Dec 92 16:20 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18949; 21 Dec 92 16:20 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa13885; 21 Dec 92 16:22 EST Received: from GINGER.LCS.MIT.EDU by ftp.com with SMTP id AA11887; Mon, 21 Dec 92 16:16:03 -0500 Received: by ginger.lcs.mit.edu id AA14255; Mon, 21 Dec 92 16:13:26 -0500 Date: Mon, 21 Dec 92 16:13:26 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9212212113.AA14255@ginger.lcs.mit.edu> To: Scott_Brim@cornell.edu, kasten@ftp.com Subject: Re: IPv7 Selection Criteria Cc: criteria@ftp.com, jnc@ginger.lcs.mit.edu >I think that this is important. There will always be pockets of IPv4 >that never get upgraded for some reason or another and we have to be >concerned with these. They ought not be locked out of the Internet. Right. ... It's not just that we have to tolerate these "pockets" ... the various IPv* plans must not deal with them in just a transition plan, since the transition will never be finished. The bags have to be given more respect than that. Well, if everyone signs onto that, than we can stop most of the debate and all go home, since we've just chosen x-NAT (x as yet to be decided), and nobody's working on NAT anymore (unless Van has been slaving away in silence, knowing what was going to happen and not being able to deal with the rest of us taking for ever to wake up). Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22012; 21 Dec 92 19:11 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22006; 21 Dec 92 19:11 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa21508; 21 Dec 92 19:13 EST Received: from inet-gw-1.pa.dec.com by ftp.com with SMTP id AA17533; Mon, 21 Dec 92 19:09:33 -0500 Received: by inet-gw-1.pa.dec.com; id AA00462; Mon, 21 Dec 92 16:09:13 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA12522; Mon, 21 Dec 92 19:10:19 -0500 Message-Id: <9212220010.AA12522@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: kasten@ftp.com Cc: criteria@ftp.com Subject: Re: new version of the draft In-Reply-To: Your message of "Mon, 14 Dec 92 14:02:15 EST." <9212141902.AA23547@ftp.com> Date: Mon, 21 Dec 92 19:10:19 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: kasten@ftp.com (Frank Kastenholz) To: criteria@ftp.com > 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. ^^^^^^ Isn't the protocol name "IPX"? > Partridge & KastenholzExp. 19 June 1993 [Page 7] You don't have to put the expiration date on every page. If you do, it shouldn't run together.. > 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 ^^^^^^^^^^^^ I don't think ones-of-bits per second is a necessary constraint on the general protocol. Sure, there may be nooks and crannies with very low bandwidth, but special message compression or other special handling is reasonable in such cases. I think you are talking less than 0.1% of the network here and I don't think the next IP has to solve all problems for all people. 99.9%+ of the net will be a minimum of a full voice analog line which is getting to mean 14,400 bps within 5 years. Looking further out, maybe 99.9%+ is at least digital voice which means 56,000 or 64,000. While it is obviously a goodness for the protocol to operate over a wide range, I just can't see this ones-of-bits per second as a MUST. > of gigabits per second. Multiple-access and point-to- > point media must be supported, as must both media > supporting switched and permanent circuits. > 5.1.6. Unreliable Datagram Service > > CRITERION > The protocol must support an unreliable datagram delivery > service. I suppose we all know what this means but it doesn't sound very good and does not say what it means. How about "must support a datagram delivery service unimpeded by 'reliable delivery' mechanisms such as automatic retransmission or duplicate detection". > DISCUSSION > We like IP's datagram service and it seems to work very > > 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 ^^^^^ I think you want to say that you use a "broad" definition of mobility, not vague. > 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 > 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. I'm strongly tempted to just say the fragmentation non-goal is wrong. I suppose it is a little more compicated than that. Sure, with MTU, you might get most of "pure" IPv7 to avoid framentation. But what are you going to do about other protocols (including IPv4) being encapsulated in IPv7? You have no control over how big an XYZ protocol message you get is and in general have no way to reflect MTU discovery information back to the XYZ network. While framentation may be good to avoid, I think the ability to do it is, for practical purposes, a must. Donald   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03801; 22 Dec 92 9:51 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03795; 22 Dec 92 9:50 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa07950; 22 Dec 92 9:53 EST Received: from MITCHELL.CIT.CORNELL.EDU by ftp.com with SMTP id AA29497; Tue, 22 Dec 92 09:49:11 -0500 Received: from [132.236.195.20] by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA12968; Tue, 22 Dec 92 09:48:46 EST Message-Id: <9212221448.AA12968@mitchell.cit.cornell.edu> Date: Tue, 22 Dec 1992 09:48:34 -0500 To: kasten@ftp.com, Noel Chiappa Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott_Brim@cornell.edu X-Sender: swb@nr-tech.cit.cornell.edu Subject: Re: IPv7 Selection Criteria Cc: criteria@ftp.com, jnc@ginger.lcs.mit.edu Noel, we're talking about limited services for the pockets, not about full service which would require NAT. They don't deserve a lot of respect, but you can't assume you will be able to get rid of them with a transition period of less than 10 years. Scott At 16:13 12/21/92 -0500, Noel Chiappa wrote: >Well, if everyone signs onto that, than we can stop most of the debate and all >go home, since we've just chosen x-NAT (x as yet to be decided), and nobody's >working on NAT anymore (unless Van has been slaving away in silence, knowing >what was going to happen and not being able to deal with the rest of us taking >for ever to wake up). > > Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10529; 22 Dec 92 15:40 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10523; 22 Dec 92 15:40 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa21014; 22 Dec 92 15:43 EST Received: from GINGER.LCS.MIT.EDU by ftp.com with SMTP id AA13382; Tue, 22 Dec 92 15:35:01 -0500 Received: by ginger.lcs.mit.edu id AA17719; Tue, 22 Dec 92 15:33:43 -0500 Date: Tue, 22 Dec 92 15:33:43 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9212222033.AA17719@ginger.lcs.mit.edu> To: Scott_Brim@cornell.edu, jnc@ginger.lcs.mit.edu, kasten@ftp.com Subject: Re: IPv7 Selection Criteria Cc: criteria@ftp.com Noel, we're talking about limited services for the pockets, not about full service which would require NAT. They don't deserve a lot of respect, but you can't assume you will be able to get rid of them with a transition period of less than 10 years. Well, what's "limited service"? Does it mean that to get to large portions of the Internet, for *any* service, you have to go through a service level gateway? I.e, once you can no longer map all existing IP hosts into 32 bits (no matter how hard you cram them, Nimrod style or otherwise :-), you either have i) lots of places you can't get to from an old host, or ii) NAT. I think you're likely to get to that place in 10 years, too... Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11202; 22 Dec 92 16:18 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11185; 22 Dec 92 16:18 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa22491; 22 Dec 92 16:20 EST Received: from GINGER.LCS.MIT.EDU by ftp.com with SMTP id AA15206; Tue, 22 Dec 92 16:13:49 -0500 Received: by ginger.lcs.mit.edu id AA17929; Tue, 22 Dec 92 16:13:31 -0500 Date: Tue, 22 Dec 92 16:13:31 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9212222113.AA17929@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: IPv7 Selection Criteria Cc: criteria@ftp.com, ericf@atc.boeing.com >> * Last a long time (20 years). > I agree that it's hard to quantify the lifetime of an architecture. > However, don't you think that this is a critical goal. I.e. wouldn't you > agree we've failed if the thing we pick is obsolete in 5 years? Would you care to offer some examples of concrete tests that can be used to determine whether a spec satisfies this requirement? Perhaps you'd be happier if it said something like "maximizing the system lifetime" as opposed to putting a concrete number on it? I agree, it's hard to have a test. On the other hand, look at the possibility of failing to meet this goal: wouldn't you agree we've failed miserably if the thing we pick is obsolete in 5 years? Projected design lifetime, like robustness, is hard to measure concretely (for many of the same reasons, since to some degree it involves predicting the future), but again, I claim good engineers can do this. Just like you sort of get a feel for what is robust and what is not, you develop the same feel for what kind of design methodology leads to long-lived architectures: "clean design" and "flexibilty" are some things that lead to this. Doing a lot of thinking forward to future needs and possibilities (even if the mechanisms for doing them aren't completely specified in the current specification) is something else. For instance, is capability C met by adding a kludgy bag to the side of mechanism P, or have mechanisms P and Q been reorganized into X,Y, and Z, so that capability C is now provided in a natural and flexible fashion? That's the kind of thing you look for... Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12028; 22 Dec 92 17:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12022; 22 Dec 92 17:01 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa24255; 22 Dec 92 17:04 EST Received: from Mordor.Stanford.EDU by ftp.com with SMTP id AA16845; Tue, 22 Dec 92 16:58:11 -0500 Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA25604; Tue, 22 Dec 92 13:57:50 -0800 Message-Id: <9212222157.AA25604@Mordor.Stanford.EDU> To: Noel Chiappa Cc: criteria@ftp.com, ericf@atc.boeing.com Subject: Re: IPv7 Selection Criteria Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 22 Dec 92 16:13:31 -0500. <9212222113.AA17929@ginger.lcs.mit.edu> Date: Tue, 22 Dec 92 13:57:50 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Noel, I was not challenging the _desire_ for longevity, merely the lack of utility in citing it in a list of criteria to be used by the community "at large". I suspect that we will all generally recognize world peace when we experience it. But how does the desire for the general goal of world peace (well, it _is_ that time of year, after all) get applied when evaluating candidates for presidency, or even the specifics of negotiating a Middle East settlement? In other words, Noel, if we cannot objectify application of the criterion, I believe that the criterion is inherently useless for the task at hand, since we will then just invite "yes it is"/"no it isn't" debates. Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03123; 23 Dec 92 10:09 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03117; 23 Dec 92 10:09 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa10229; 23 Dec 92 10:12 EST Received: from GINGER.LCS.MIT.EDU by ftp.com with SMTP id AA00616; Wed, 23 Dec 92 10:06:54 -0500 Received: by ginger.lcs.mit.edu id AA19718; Wed, 23 Dec 92 10:06:37 -0500 Date: Wed, 23 Dec 92 10:06:37 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9212231506.AA19718@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: IPv7 Selection Criteria Cc: criteria@ftp.com, ericf@atc.boeing.com In other words, Noel, if we cannot objectify application of the criterion, I believe that the criterion is inherently useless for the task at hand In other words, if you can't measure it, it doesn't matter/exist? Sorry if I'm getting snappy, but to me this is the single most important goal of a design of a large, shared, communication system, and to ignore it because it's very hard to measure seems to me insupportable. However, I think your next phrase gives me the clue to what the real disagreement is here, so let's go to that... since we will then just invite "yes it is"/"no it isn't" debates. You and I have clearly have a different model for what is likely to happen with this thing. I doubt we are going to sit down, as an IETF comittee of the whole, with this checklist in hand, and fill it out for each proposal, and either vote on which one to pick, or go with the one with the most check marks, after which we will all happily go work on that one. People who back scheme X, and truly believe in their hearts it is the right thing, simply aren't going to go away because an IETF vote (whatever the heck that is, and whatever the heck it means) went to something else. This is, after all, the whole tradition of the IETF; a group of people who *ignored* a formal vote on what the 'right thing' was, and proceeded to guerrilla deploy their stuff into a major contender. What I see is most likely to happen is that each credible possibilty will be designed, implemented, and deployed in some scale. This is not necessarily a *bad thing*; done right, it can result (albeit at the cost of some expenditure of design/implementation resources) in a better designed thing at the end. (The challenge, as always, is to miminimize the bad feeling between the design teams, and confusion to the outside world, while this process is going on.) In this process, the criteria document more represents advice/input from the user/engineering community to the design teams as to what are perceived to be important goals for successful designs; a requirements document, if you will. In that context, hard to qualify goals like "maximum design lifetime" aren't quite as useless, yes? Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03525; 23 Dec 92 10:26 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03517; 23 Dec 92 10:26 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa10668; 23 Dec 92 10:28 EST Received: from Mordor.Stanford.EDU by ftp.com with SMTP id AA01221; Wed, 23 Dec 92 10:24:08 -0500 Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA15754; Wed, 23 Dec 92 07:23:47 -0800 Message-Id: <9212231523.AA15754@Mordor.Stanford.EDU> To: Noel Chiappa Cc: criteria@ftp.com, ericf@atc.boeing.com Subject: Re: IPv7 Selection Criteria Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 23 Dec 92 10:06:37 -0500. <9212231506.AA19718@ginger.lcs.mit.edu> Date: Wed, 23 Dec 92 07:23:46 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Noel, I think you have correctly identified the point of departure between our reactions to inclusion of the live-long-and-prosper criterion. Mumble. I tend to agree with you that a pronouncement from some august body is unlikely to terminate all other efforts. However, I note that there continues to be a sentiment in favor of having an august body make such a pronouncement. Further, there remains sentiment towards continuing the pattern of milestones and public review (where "review" pertains to commentary about accomplishments and open issues, rather than to declaring a "winner.) In the hearts-and-minds battle, I agree that your favorite criterion is essential to keep. In the public-analysis battle, I think not. Hence, let me suggest explicitly distinguishing those criteria that have clinical benefit, but lack objective assessment, from those whose assessment can be made mechanical. The clinical criteria could be in their own section, some sort of qualification explaining why they are included and how they should be used. Whatcha tink? Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03974; 23 Dec 92 10:41 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03967; 23 Dec 92 10:41 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa11017; 23 Dec 92 10:43 EST Received: from GINGER.LCS.MIT.EDU by ftp.com with SMTP id AA01636; Wed, 23 Dec 92 10:38:32 -0500 Received: by ginger.lcs.mit.edu id AA19933; Wed, 23 Dec 92 10:38:14 -0500 Date: Wed, 23 Dec 92 10:38:14 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9212231538.AA19933@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: IPv7 Selection Criteria Cc: criteria@ftp.com, ericf@atc.boeing.com However, I note that there continues to be a sentiment in favor of having an august body make such a pronouncement. Hmm, be interesting to know just how universal this feeling is. Guess it's probably pretty widespread out there among the poor users who just want their network to work! I can see their side of it though; they have their own work to get on with. Sigh, I guess I'm just an idealist who thinks "our ordinary citizens ... [should] still be fair judges of public matters". Is this sentiment a sign of decay in our "democracy"? I guess not; the circle of people doing the deciding will probably be bigger than ever; it's just the network community as a whole is so much bigger. Well, enough philosophical musing for today! Further, there remains sentiment towards continuing the pattern of milestones and public review (where "review" pertains to commentary about accomplishments and open issues, rather than to declaring a "winner.) Oh, I agree, this stuff is extremely useful to driving progress in the designs, and education among the community at large. Hence, let me suggest explicitly distinguishing those criteria that have clinical benefit, but lack objective assessment, from those whose assessment can be made mechanical. The clinical criteria could be in their own section, some sort of qualification explaining why they are included and how they should be used. Sounds good to me! Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04922; 23 Dec 92 11:20 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04914; 23 Dec 92 11:20 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa12258; 23 Dec 92 11:23 EST Received: from watson.ibm.com by ftp.com with SMTP id AA02803; Wed, 23 Dec 92 11:16:45 -0500 Message-Id: <9212231616.AA02803@ftp.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6339; Wed, 23 Dec 92 11:16:29 EST Date: Wed, 23 Dec 92 11:14:40 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu, dcrocker@mordor.stanford.edu, yakov@watson.ibm.com Cc: criteria@ftp.com, ericf@atc.boeing.com Subject: IPv7 Selection Criteria Ref: Your note of Wed, 23 Dec 92 10:06:37 -0500 In his message to Dave Crocker Noel said: "You and I have clearly have a different model for what is likely to happen with this thing." I think it would be helpful to poll the community for what kind of model is expected. Does the IETF community believe it needs to vote on this topic ? This is actually a break from tradition, as Noel pointed out. In effect, the Internet has *always* been market driven. Further down, Noel said: "People who back scheme X, and truly believe in their hearts is it the right thing, simply aren't going to go away because an IETF vote went to something else." If that is the case, then one may ask about the purpose of the IETF vote. It have been suggested before, that the decision on such an important issue as IPv7 should not be made by an IETF vote, but should rather be left to the marketplace. There will be enough reasons in the end for the marketplace to converge on a single solution. Further down, "The challenge, as always, is to minimize the bad feeling between the design teams, and confusion to the outside world...." May be one way to accomplish this is to say that the IETF *is not* going to vote on IPv7, but would rather leave this to the marketplace. Instead, the IETF would just provide an environment where different proposals for IPv7 would be developed, tested and reviewed. The role of the IETF should also be the place where the "rough edges" of many of the proposals could be worked off. It is unfortunate that presently we have a split into design teams. This split may actually be the root of the problem. It is not clear that this work could not have been done colloboratively instead of competition. Note that there is still a strong role for the criteria. They should reflect the needs of the users of "open systems and networking". People working on proposals should use these to guide their work. Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08487; 23 Dec 92 14:41 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08481; 23 Dec 92 14:41 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa18981; 23 Dec 92 14:44 EST Received: from vela.acs.oakland.edu by ftp.com with SMTP id AA08826; Wed, 23 Dec 92 14:41:26 -0500 Received: from via.ws07.merit.edu by vela.acs.oakland.edu with SMTP id AA10846 (5.65c+/IDA-1.4.4); Wed, 23 Dec 1992 14:41:00 -0500 Date: Wed, 23 Dec 92 14:16:56 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <859.bill.simpson@um.cc.umich.edu> To: criteria@ftp.com Reply-To: bsimpson@morningstar.com Subject: Re: IPv7 Selection Criteria > Hence, let me suggest explicitly distinguishing those criteria that > have clinical benefit, but lack objective assessment, from those > whose assessment can be made mechanical. The clinical criteria could > be in their own section, some sort of qualification explaining why they > are included and how they should be used. > > Whatcha tink? > YES! Add extensible, since the appearance of extensibility doesn't mean that we will have any greater luck in migrating to the extended format than we have of migrating this time. Any claim of extensibility would have to show that there would be *NO* negative effect when such a mechanism is added. That is, a packet either with or without an option would still reach the destination eventually, just not necessarily with the guaranteed flow, for example. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09083; 23 Dec 92 15:01 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09077; 23 Dec 92 15:01 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa19882; 23 Dec 92 15:04 EST Received: from inet-gw-1.pa.dec.com by ftp.com with SMTP id AA09394; Wed, 23 Dec 92 14:58:11 -0500 Received: by inet-gw-1.pa.dec.com; id AA25060; Wed, 23 Dec 92 11:57:53 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA16376; Wed, 23 Dec 92 14:58:57 -0500 Message-Id: <9212231958.AA16376@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: Evaluating the Next Generation Subject: minor point Date: Wed, 23 Dec 92 14:58:57 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp Possibly a sub-item under ease of administration or the like: as mandated in the IAB draft, any IPv7 address scheme needs to have all of the IPv4 address space embedded in it so everyone does't have to apply for new numbers all at once. Dopnald *+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+- Donald E. Eastlake, III 1-508-486-2358(w) dee@skidrow.ljo.dec.com PO Box N, MIT Branch PO dee@ranger.enet.dec.com Cambridge, MA 02139 USA 1-617-244-2679(h)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03633; 24 Dec 92 12:48 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03627; 24 Dec 92 12:48 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa13676; 24 Dec 92 12:50 EST Received: from Mordor.Stanford.EDU by ftp.com with SMTP id AA29378; Thu, 24 Dec 92 12:46:30 -0500 Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA16412; Thu, 24 Dec 92 09:46:09 -0800 Message-Id: <9212241746.AA16412@Mordor.Stanford.EDU> To: yakov@watson.ibm.com Cc: jnc@ginger.lcs.mit.edu, criteria@ftp.com, ericf@atc.boeing.com Subject: Re: IPv7 Selection Criteria Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 23 Dec 92 11:14:40 -0500. <9212231616.AA02803@ftp.com> Date: Thu, 24 Dec 92 09:46:09 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Crocker X-Mts: smtp Yakov, May be one way to accomplish this is to say that the IETF *is not* going to vote on IPv7, but would rather leave this to the marketplace. Instead, the IETF would just provide an environment where different proposals for IPv7 would be developed, tested and reviewed. The role of the IETF should also be the place where the "rough edges" of many of the proposals could be worked off. It is unfortunate that presently This seems to be exactly what is, in fact, happening. The framework, however, is not strictly laissez faire. I believe that the pressure of milestones, coordinated public presentations & demonstrations, and general sense of on-going review within the IETF provides a real-world filter. I consider this to be "letting the market decide" but with the IETF providing leadership to the market process. we have a split into design teams. This split may actually be the root of the problem. It is not clear that this work could not have been done colloboratively instead of competition. Yes, it would be nice. Unfortunately, long history leads one to conclude that groups with very different views of the path to solving a problem do not work well as one group. (Though the general pattern of corss-membership among the IPv7 efforts has been better than I've seen before.) On the other hand, some related efforts, such as upgrading the DNS, seem to involve technical efforts that are not distinctive to any one group. Combining efforts, there, would very much seem to make sense. Note that there is still a strong role for the criteria. They should reflect the needs of the users of "open systems and networking". People working on proposals should use these to guide their work. Yup. That's why I'm hoping the criteria are increasingly objective and easy to apply. Dave   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14399; 28 Dec 92 10:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14389; 28 Dec 92 10:43 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa05937; 28 Dec 92 10:46 EST Received: by ftp.com id AA22929; Mon, 28 Dec 92 10:40:35 -0500 Date: Mon, 28 Dec 92 10:40:35 -0500 Message-Id: <9212281540.AA22929@ftp.com> To: dee@skidrow.ljo.dec.com Subject: Re: minor point Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: Evaluating the Next Generation Donald, I am not sure that this is necessary. I do not believe that everyone will change to IPv7 all at once. It would be a gradual process and you would apply for your IPv7 address when you want to change over. > Possibly a sub-item under ease of administration or the like: as > mandated in the IAB draft, any IPv7 address scheme needs to have all > of the IPv4 address space embedded in it so everyone does't have to > apply for new numbers all at once. -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14411; 28 Dec 92 10:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14391; 28 Dec 92 10:43 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa05939; 28 Dec 92 10:46 EST Received: by ftp.com id AA22921; Mon, 28 Dec 92 10:40:27 -0500 Date: Mon, 28 Dec 92 10:40:27 -0500 Message-Id: <9212281540.AA22921@ftp.com> To: dcrocker@mordor.stanford.edu Subject: Re: IPv7 Selection Criteria Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, criteria@ftp.com, ericf@atc.boeing.com > Hence, let me suggest explicitly distinguishing those criteria that > have clinical benefit, but lack objective assessment, from those > whose assessment can be made mechanical. The clinical criteria could > be in their own section, some sort of qualification explaining why they > are included and how they should be used. The criteria document is divided into two major chapters, Chapter 4 entitled General Principles which has the harder-to-quantify stuff in it (Live Long, One Protocol to Bind Them All, Architectural Simplicity, etc) and Chapter 5, entitled Criteria, which has things that Craig and I believe are easier to quantify. I think that the evaluation of each proposal against the contents of Chapter 5 can be reduced to a simple mechanical process is not likely. Some of the process can be mechanistic. Other parts will not be. The main reason is that if we make Chapter 5 completely mechanistic then it is conceivable that the people backing proposal foo will fight against including any criteria that would elminate their proposal. (e.g. Suppose that someone offered, as a criterion, that IPv7 must be derived from ISO work. For the sake of argument, pretend that there is a "good" reason for this. I imagine that the SIP/IPAE people would not like this criterion and would devote considerable energy in making sure that it did not get into the document). The overall goal of the Criteria is to provide feedback to the protocol designers as to what the community wants in IPv7 AND to provide a framework for the "my protocol is better than your protocol" discussion that is sure to happen. -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14421; 28 Dec 92 10:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14409; 28 Dec 92 10:43 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa05941; 28 Dec 92 10:46 EST Received: by ftp.com id AA22926; Mon, 28 Dec 92 10:40:31 -0500 Date: Mon, 28 Dec 92 10:40:31 -0500 Message-Id: <9212281540.AA22926@ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: IPv7 Selection Criteria Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu, criteria@ftp.com, ericf@atc.boeing.com > However, I note that there continues to be a sentiment in favor of having > an august body make such a pronouncement. > > Hmm, be interesting to know just how universal this feeling is. Guess Off the top of my head, on a monday morning after a long weekend, I can not recall anyone advocating multiple IP-layer protocols (issues of transition and coexistance-during-evaluation aside). Read "One Protocol to Bind Them All" in the Criteria document. -- Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14568; 28 Dec 92 10:55 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14562; 28 Dec 92 10:55 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa06219; 28 Dec 92 10:58 EST Received: from inet-gw-1.pa.dec.com by ftp.com with SMTP id AA23153; Mon, 28 Dec 92 10:50:38 -0500 Received: by inet-gw-1.pa.dec.com; id AA15414; Mon, 28 Dec 92 07:50:19 -0800 Received: by ps73.ako.dec.com (5.57/Ultrix V4.2-sdh-921223); id AA20985; Mon, 28 Dec 92 10:50:16 -0500 Message-Id: <9212281550.AA20985@ps73.ako.dec.com> To: kasten@ftp.com Cc: dee@skidrow.ljo.dec.com, Evaluating the Next Generation Subject: Re: minor point In-Reply-To: Your message of "Mon, 28 Dec 92 10:40:35 EST." <9212281540.AA22929@ftp.com> Date: Mon, 28 Dec 92 10:50:15 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: huston@ps73.ako.dec.com X-Mts: smtp Frank, >I am not sure that this is necessary. I do not believe that everyone will >change to IPv7 all at once. It would be a gradual process and you would >apply for your IPv7 address when you want to change over. > > > Possibly a sub-item under ease of administration or the like: as > > mandated in the IAB draft, any IPv7 address scheme needs to have all > > of the IPv4 address space embedded in it so everyone does't have to > > apply for new numbers all at once. I can't speak for Donald, but when I first read his message, it seemed like he was saying that a system running IPv7 needs to be able to directly address an IPv4 system. Because everyone will not change to IPv7 at once, or maybe ever, the point you reinforced in your reply. I would agree with this point as well. Steve Huston huston@ps73.ako.dec.com On contract to, but not speaking for, Digital Equipment Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14738; 28 Dec 92 11:05 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14732; 28 Dec 92 11:05 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa06523; 28 Dec 92 11:08 EST Received: from inet-gw-1.pa.dec.com by ftp.com with SMTP id AA23419; Mon, 28 Dec 92 11:01:51 -0500 Received: by inet-gw-1.pa.dec.com; id AA16231; Mon, 28 Dec 92 08:01:27 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA21489; Mon, 28 Dec 92 11:02:37 -0500 Message-Id: <9212281602.AA21489@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: kasten@ftp.com Cc: dee@skidrow.ljo.dec.com, Evaluating the Next Generation Subject: Re: minor point In-Reply-To: Your message of "Mon, 28 Dec 92 10:40:35 EST." <9212281540.AA22929@ftp.com> Date: Mon, 28 Dec 92 11:02:37 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp I won't bother to press on this point as all proposals I know about in detail (all except PIP) have the characteristic anyway. Donald From: kasten@ftp.com (Frank Kastenholz) To: dee@skidrow.ljo.dec.com >Donald, >I am not sure that this is necessary. I do not believe that everyone will >change to IPv7 all at once. It would be a gradual process and you would >apply for your IPv7 address when you want to change over. > > Possibly a sub-item under ease of administration or the like: as > > mandated in the IAB draft, any IPv7 address scheme needs to have all > > of the IPv4 address space embedded in it so everyone does't have to > > apply for new numbers all at once. >-- >Frank Kastenholz   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14850; 28 Dec 92 11:12 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14844; 28 Dec 92 11:12 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa06737; 28 Dec 92 11:15 EST Received: from inet-gw-1.pa.dec.com by ftp.com with SMTP id AA23562; Mon, 28 Dec 92 11:09:04 -0500 Received: by inet-gw-1.pa.dec.com; id AA16642; Mon, 28 Dec 92 08:08:40 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA21540; Mon, 28 Dec 92 11:09:51 -0500 Message-Id: <9212281609.AA21540@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: huston@ps73.ako.dec.com Cc: kasten@ftp.com, Evaluating the Next Generation Subject: Re: minor point In-Reply-To: Your message of "Mon, 28 Dec 92 10:50:15 EST." <9212281550.AA20985@ps73.ako.dec.com> Date: Mon, 28 Dec 92 11:09:51 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: huston@ps73.ako.dec.com >Frank, > >>I am not sure that this is necessary. I do not believe that everyone will >>change to IPv7 all at once. It would be a gradual process and you would >>apply for your IPv7 address when you want to change over. >> > Possibly a sub-item under ease of administration or the like: as >> > mandated in the IAB draft, any IPv7 address scheme needs to have all >> > of the IPv4 address space embedded in it so everyone does't have to >> > apply for new numbers all at once. >I can't speak for Donald, but when I first read his message, it seemed >like he was saying that a system running IPv7 needs to be able to directly >address an IPv4 system. Because everyone will not change to IPv7 at once, >or maybe ever, the point you reinforced in your reply. No, the point by the requirement in the IAB draft was primarily to reduce the administrative burden of address assignemnt. Maybe when there are 10**12 host in the Internet, assigning brand new IPv7 addresses to the few millions of IPv4 hosts will be the trivial work of an afternoon. But early on, it would be a real hassle. Thus the idea is that everyone who has an IPv4 address should thereby automatically have an IPv7 address they can safely use without administrative address re-assignment. >I would agree with this point as well. > >Steve Huston >huston@ps73.ako.dec.com >On contract to, but not speaking for, Digital Equipment Corporation Donald   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14876; 28 Dec 92 11:13 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14870; 28 Dec 92 11:13 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa06796; 28 Dec 92 11:16 EST Received: by ftp.com id AA23630; Mon, 28 Dec 92 11:10:49 -0500 Date: Mon, 28 Dec 92 11:10:49 -0500 Message-Id: <9212281610.AA23630@ftp.com> To: huston@ps73.ako.dec.com Subject: Re: minor point Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: dee@skidrow.ljo.dec.com, criteria@ftp.com Steve, I believe that your particular concerns are adequately covered in our document under the Transistion section; where we discuss IPv7/IPv4 co-existance and the ability to have IPv4-only hosts communicate with IPv7-only hosts in some fashion. The method used to achieve this is an implementation issue. You propose that IPv4 hosts be able to be addressed algorithmically out of the IPv7 address by "encapsulating" the IPv4 address in an IPv7 address. That is one way to do it. One could also do some other operation on the IPv7 address to obtain the IPv4 address, such as using it as a key or hash into a table that provides the correct IPv4 address. Frank Kastenholz > Frank, > > >I am not sure that this is necessary. I do not believe that everyone will > >change to IPv7 all at once. It would be a gradual process and you would > >apply for your IPv7 address when you want to change over. > > > > > Possibly a sub-item under ease of administration or the like: as > > > mandated in the IAB draft, any IPv7 address scheme needs to have all > > > of the IPv4 address space embedded in it so everyone does't have to > > > apply for new numbers all at once. > > I can't speak for Donald, but when I first read his message, it seemed > like he was saying that a system running IPv7 needs to be able to directly > address an IPv4 system. Because everyone will not change to IPv7 at once, > or maybe ever, the point you reinforced in your reply. > > I would agree with this point as well.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15030; 28 Dec 92 11:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15024; 28 Dec 92 11:38 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa07408; 28 Dec 92 11:41 EST Received: from GINGER.LCS.MIT.EDU by ftp.com with SMTP id AA24023; Mon, 28 Dec 92 11:36:48 -0500 Received: by ginger.lcs.mit.edu id AA00908; Mon, 28 Dec 92 11:36:29 -0500 Date: Mon, 28 Dec 92 11:36:29 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9212281636.AA00908@ginger.lcs.mit.edu> To: criteria@ftp.com, ericf@atc.boeing.com, jnc@ginger.lcs.mit.edu, kasten@ftp.com Subject: Re: IPv7 Selection Criteria >> However, I note that there continues to be a sentiment in favor of >> having an august body make such a pronouncement. > Hmm, be interesting to know just how universal this feeling is. Off the top of my head, on a monday morning after a long weekend, I can not recall anyone advocating multiple IP-layer protocols Ah, I wasn't disagreeing that we all want one (I think everyone understand the utility of having a ubiquitous packet service), just wondering if everyone wants the "august" IAB/IESG/whatever to make a pronouncement, or whether people want some more broadly based decision (e.g. the market). Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15404; 28 Dec 92 12:07 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15398; 28 Dec 92 12:07 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa08354; 28 Dec 92 12:10 EST Received: from watson.ibm.com by ftp.com with SMTP id AA24897; Mon, 28 Dec 92 12:04:41 -0500 Message-Id: <9212281704.AA24897@ftp.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7165; Mon, 28 Dec 92 12:04:22 EST Date: Mon, 28 Dec 92 12:04:12 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu, criteria@ftp.com, ericf@atc.boeing.com, jnc@ginger.lcs.mit.edu, kasten@ftp.com Subject: IPv7 Selection Criteria Ref: Your note of Mon, 28 Dec 92 11:36:29 -0500 >.. if everyone wants the "august" IAB/IESG/whatever to make a pronouncement, >or whehter people want some more broadly based decision (e.g. the market). Noel, I would think that a pronouncement by the "august" IAB/IESG/whatever that *reflects* broadly based decision (e.g. market) is yet another alternative that should be considered. This alternative seems much more sane and sound than just "a pronouncement". Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16327; 28 Dec 92 13:26 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16321; 28 Dec 92 13:26 EST Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa10579; 28 Dec 92 13:29 EST Received: from thumper.bellcore.com by ftp.com with SMTP id AA26280; Mon, 28 Dec 92 13:18:14 -0500 Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for criteria@ftp.com; Mon, 28 Dec 92 13:17:56 EST Received: by chiya.bellcore.com (4.1/4.7) id for kasten@ftp.com; Mon, 28 Dec 92 13:17:55 EST Date: Mon, 28 Dec 92 13:17:55 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paul Tsuchiya Message-Id: <9212281817.AA14356@chiya.bellcore.com> To: dee@skidrow.ljo.dec.com, kasten@ftp.com Subject: Re: minor point Cc: criteria@ftp.com > > > I won't bother to press on this point as all proposals I know about in > detail (all except PIP) have the characteristic anyway. > Pip also has the embedded IP address (but, in the ID field, not in the Pip address........) PX