idnits 2.17.1 draft-partridge-ipv7-criteria-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 106: '... (4) A MUST criterion for "d...' RFC 2119 keyword, line 652: '...cast should be a MUST, however the aut...' RFC 2119 keyword, line 683: '...lity should be a MUST, however the aut...' RFC 2119 keyword, line 742: '... that a protocol MUST NOT do something...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 194 has weird spacing: '... when there...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (14 December 1992) is 11449 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 783 looks like a reference -- Missing reference section? '2' on line 786 looks like a reference -- Missing reference section? '3' on line 789 looks like a reference -- Missing reference section? '4' on line 793 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT 4 Criteria for Choosing 5 IP Version 7 (IPv7) 7 14 December 1992 9 Craig Partridge 10 BBN Systems and Technologies 11 craig@aland.bbn.com 13 Frank Kastenholz 14 FTP Software, Inc 15 2 High Street 16 North Andover, Mass 01845-2620 USA 18 kasten@ftp.com 20 Status of this Memo 22 This document is an Internet Draft. Internet Drafts are 23 working documents of the Internet Engineering Task Force 24 (IETF), its Areas, and its Working Groups. Note that other 25 groups may also distribute working documents as Internet 26 Drafts. 28 Internet Drafts are draft documents valid for a maximum of six 29 months. Internet Drafts may be updated, replaced, or 30 obsoleted by other documents at any time. It is not 31 appropriate to use Internet Drafts as reference material or to 32 cite them other than as a ``working draft'' or ``work in 33 progress.'' Please check the 1id-abstracts.txt listing 34 contained in the internet-drafts Shadow Directories on 35 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or 36 munnari.oz.au to learn the current status of any Internet 37 Draft. 39 This is a working document only, it should neither be cited 40 nor quoted in any formal document. 42 This document will expire before 19 June 1993. 44 Distribution of this document is unlimited. 46 Please send comments to criteria@ftp.com or the authors. 48 1. Introduction 50 This note attempts to codify and organize the criteria to be 51 used in evaluating the protocols being proposed for adoption 52 as IP Version 7. 54 The criteria presented are culled from several sources, 55 including "IP Version 7" [1], "IESG Deliberations on Routing 56 and Addressing" [2], "Towards the Future Internet 57 Architecture" [3], and the ongoing discussions held on the 58 Big-Internet mailing list and the mailing lists devoted to the 59 individual IPv7 efforts. 61 This document presumes that a new IP-layer protocol is 62 actually desired. There is some discussion in the community as 63 to whether we can extend the life of IPv4 for a significant 64 amount of time by better engineering of, e.g., routing 65 protocols, or we should develop IPv7 now. This question is 66 not addressed in this document. 68 1.1. Change Log 70 At the Washington D.C. IETF meeting, a BOF was held during 71 which this document was discussed. The following changes have 72 been made to reflect that discussion. 74 (1) The list has been changed from an ordered list of 75 criteria, where each criterion was considered "more 76 important" than those that followed to a split into two 77 groups: (A) those criteria which the new IP "must" have, 78 where "must" is defined by agreeing that a new IPv7 will 79 not be accepted or deployed unless it fullfills all the 80 "must" requirements; and (B) those criteria which it 81 would be desirable to have in the new IP but are not a 82 pre-requisite for deployment. 84 This change has engendered most of the editorial work on 85 the document. Most notably, references to "ordered 86 lists" had to be reworded, and the document needed to be 87 re-organized to have must and should subsections. 89 (2) A section called "General Principles" has been added to 90 the beginning of the document. This section contains 91 those items discussed that are hard to quantify as 92 criteria for the protocol, yet which we believe are 93 essential to the future success of IPv7 and the Internet 94 as a whole. 96 (3) Discussion at the BOF made it clear that it would be 97 desirable to refine the criteria into questions that 98 could be used to help distinguish proposals. The goal of 99 these questions is not to grade proposals, and determine 100 which one becomes IPv7, but rather to help elucidate the 101 various ways that the different proposals try to meet the 102 criteria. A beginning of this process, in the form of a 103 section of detailed questions has been added to the end 104 of the document. 106 (4) A MUST criterion for "documents being on-line and owned 107 by the IETF" has been added per the BOF. 109 (5) Per the BOF, the section on accounting has been deleted. 111 (6) Several criteria were mentioned at the BOF but we could 112 find no reasonable definition of them. Place-holders for 113 these criteria are given, but no discussion of them is 114 given. We hope that these place-holders will stimulate 115 discussion on the mailing list. If not, they will be 116 deleted. 118 (7) The IP Checksum was made a non-goal. There has been 119 sufficient discussion on the big-i mailing list to 120 suggest that it does not provide significant data 121 protection. 123 (8) Some typos were fixed. Some additional explanatory text 124 has been added. 126 (9) Additional parts added to the "Configuration, 127 Administration, and Operation" section per the discussion 128 at the BOF. 130 (10) The "Scale" criterion has been expanded per the BOF to 131 address 10**12 nodes and requesting a description of the 132 performance as the limit is reached. 134 (11) Robust Service includes a mention of Hostile attacks and 135 Byzantine failures. 137 2. Goals 139 We believe that by developing a list of criteria for 140 evaluating proposals for IP version 7 (IPv7), the IETF will 141 make it easier for developers of proposals to prioritize their 142 work and efforts and make reasoned choices as to where they 143 should spend relatively more and less time. 145 This set of criteria originally began as an ordered list, with 146 the goal of ranking the importance of various criteria. 147 However, after discussion it became clear that the criteria 148 list actually could be more simply characterized as falling 149 into two groups: those criteria which had to be met by any 150 proposed IPv7 before anyone felt that IPv7 should be deployed; 151 and those criteria which it would be useful, but not 152 essential, for an IPv7 to meet. The current criteria are 153 presented in this form. 155 We have attempted to state the criteria in the form of goals 156 or requirements and not demand specific engineering solutions. 157 For example, there has been talk in the community of making 158 route aggregation a requirement. We believe that Route 159 Aggregation is not, in and of itself, a requirement but rather 160 one part of a solution to the real problem of scaling to some 161 very large, complex topology. Therefore, Route Aggregation is 162 NOT listed as a requirement. 164 In determining the relative order of the various criteria, we 165 have had two guiding principles. First, IPv7 must offer an 166 internetwork service akin to that of IPv4, but improved to 167 handle the well-known and widely-understood problems of 168 scaling the Internet architecture to more end-points and an 169 ever increasing range of bandwidths. Second, it must be 170 desirable for users and network managers to upgrade their 171 equipment to support IPv7. At minimum, this second point 172 implies that there must be a straightforward way to transition 173 systems from IPv4 to IPv7. But it also strongly suggests that 174 IPv7 should offer features that IPv4 does not; new features 175 provide a motivation to deploy IPv7 more quickly. 177 3. Note on Terminology 179 The existing proposals tend distinguish between end-point 180 identification of, e.g., individual hosts, and topological 181 addresses of network attachment points. In this memo we do 182 not make that distinction. We use the term "Address" as it is 183 currently used in IPv4; i.e., for both the identification of a 184 particular endpoint or host AND as the topological address of 185 a point on the network. We presume that if the endpoint/ 186 address split remains, the proposals will make the proper 187 distinctions with respect to the criteria enumerated below. 189 4. General Principles 191 4.1. Architectural Simplicity 193 In anything at all, perfection is finally attained not 194 when there is no longer anything to add, but when 195 there is no longer anything to take away. 197 Antoine de Saint-Exupery 199 4.2. One Protocol to Bind Them All 201 One of the most important aspects of The Internet is that it 202 provides global IP-layer connectivity. The IP-layer provides 203 the point of commonality among all of the nodes on the 204 Internet. In effect, the main goal of the Internet is to 205 provide an IP Connectivity Service to all who wish it. 207 This does NOT say that the Internet is a One-Protocol 208 Internet. The Internet is today, and shall remain in the 209 future, a Multi-Protocol Internet. Multi-Protocol operations 210 are required to allow for continued testing, experimentation, 211 and development and because service providers' customers 212 clearly want to be able to run protocols such as CLNP, DECNET, 213 and Novell over their Internet connections. 215 4.3. Live Long 217 It is very difficult to change a protocol as central to the 218 workings of the Internet as IP. Even more problematic is 219 changing such a protocol frequently. This simply can not be 220 done. We believe that it is impossible to expect the community 221 to make significant, non-backward compatible changes to the IP 222 layer more often than once every 10-15 years. In order to be 223 conservative, we strongly urge protocol developers to consider 224 what the Internet will look like in 20 years and design their 225 protocols to fit that vision. 227 As a data point, the SNMP community recently rebelled at 228 changing from SNMPv1 to SNMPv1+Security with SNMPv2+Security 229 on the horizon. The community chose to delay deployment of 230 SNMPv1+Security until SNMPv2 is done. 232 Author's Note 233 We believe that this section covers the "Long Life" 234 criterion discussed in the Washington D.C. IETF BOF. 236 4.4. Live Long AND Prosper 238 We believe that simply allowing for bigger addresses and more 239 efficient routing is not enough of a benefit to encourage 240 vendors, service providers, and users to switch to IPv7, with 241 its attendant distruptions of service, etc. These problems 242 can be solved much more simply with more router-thrust, 243 balkanization of the Internet, and so on. 245 We believe that there must be positive, functional or 246 operational, benefits to switching to IPv7. 248 In other words, IPv7 must be able to live for a long time AND 249 it must allow the Internet to prosper and to grow. 251 5. Criteria 253 This section enumerates the criteria against which the IP 254 Version 7 proposals will be evaluated. 256 Each criterion is presented in its own section. The first 257 paragraph of each section is a short, one or two sentence 258 statement of the criterion. Additional paragraphs then 259 explain the criterion in more detail, clarify what it does and 260 does not say and provide some indication of its relative 261 importance. 263 5.1. MUSTs 265 The following criteria were deemed by an IETF BOF session to 266 be absolutely essential. Any new IP protocol must meet all of 267 these criteria before it is deployed. The standard for making 268 a criteria a must requirement was that we would refuse to 269 deploy a candidate IPv7 that failed to meet just one must 270 requirement, EVEN IF THE CURRENT IPV4 INTERNET IS COLLAPSING 271 DUE TO ROUTING CONGESTION. 273 5.1.1. Scale 275 CRITERION 276 The IPv7 Protocol must scale to allow the identification 277 and addressing of 10**12 end systems. The IPv7 Protocol, 278 and its associated routing protocols and architecture 279 must allow for up to 10**9 individual networks. The 280 routing schemes must scale with the number of constituent 281 networks at a rate that is much less than linear. 283 DISCUSSION 284 The whole purpose of the IPv7 effort is to allow the 285 Internet to grow beyond the size constraints imposed by 286 the current IPv4 addressing and routing technologies. 288 Both aspects of scaling are important. If we can't route 289 then connecting all these hosts is worthless, but without 290 connected hosts, there's no point in routing, so we must 291 scale in both directions. 293 In any proposal, Particular attention should be paid to 294 describing the routing hierarchy, how the routing and 295 addressing will be organized, how different layers of the 296 routing interact, and relationship between addressing and 297 routing. 299 Particular attention must be paid to describing what 300 happens when the size of the network approaches these 301 limits. How are network, forwarding, and routing 302 performance affected? Does performance fall off or does 303 the network simply stop as the limit is neared. 305 Placement 306 This criterion is the essential problem motivating the 307 transition to IPv7. If the proposed protocol does not 308 satisfy this criteria, there is no point in considering 309 it. 311 5.1.2. Topological Flexibility 313 CRITERION 314 The routing architecture and protocols of IPv7 must allow 315 for many different network topologies. 317 DISCUSSION 318 As the Internet becomes ever more global and ubiquitous, 319 it will develop new and different topologies. We already 320 see cases where the network hierarchy is very "broad" 321 with many subnetworks, each with only a few hosts and 322 where it is very "narrow", with few subnetworks each with 323 many hosts. We can expect these and other topological 324 forms. Furthermore, since we expect that IPv7 will allow 325 for many more levels of hierarchy than are allowed under 326 IPv4, we can expect very "tall" and very "short" 327 topologies as well. 329 5.1.3. Robust Service 331 CRITERION 332 The network service and its associated routing and 333 control protocols must be robust. 335 DISCUSSION 336 Murphy's Law applies to networking. Any proposed IPv7 337 protocol must be well-behaved in the face of malformed 338 packets, mis-information, and occasional failures of 339 links, routers and hosts. IPv7 should perform gracefully 340 in response to willful management and configuration 341 mistakes (i.e. service outages should be minimized). 343 Putting this requirement another way, IPv7 must make it 344 possible to continue the Internet tradition of being 345 conservative in what is sent, but liberal in what one is 346 willing to receive. 348 We note that IPv4 is reasonably robust and any proposed 349 IPv7 must be at least as robust as IPv4. 351 Hostile attacks on the network layer and Byzantine 352 failure modes must be dealt with in a safe and graceful 353 manner. 355 We note that Robust Service is, in some form, a part of 356 security and vice-versa. 358 Placement 359 Due to its size, complexity, decentralized 360 administration, brain-dead users and administrators, and 361 so on, The Internet is a very hostile environment. If a 362 protocol can not be used in such a hostile environment 363 then it is not suitable for use in the Internet. 365 5.1.4. Transition 367 CRITERION 368 The protocol must have a straightforward transition plan 369 from the current IPv4. 371 DISCUSSION 372 A smooth, orderly, transition from IPv4 to IPv7 is 373 needed. If we can't transition to the new protocol, then 374 no matter how wonderful it is, we'll never get to it. 376 We believe that it is not possible to have a "flag-day" 377 form of transition in which all hosts and routers must 378 change over at once. The size, complexity, and 379 distributed administration of the Internet make such a 380 cutover impossible. 382 Rather IPv7 will need to co-exist with IPv4 for some 383 period of time. There are a number of ways to achieve 384 this co-existence such as requiring hosts to support two 385 stacks, converting between protocols, or using backward 386 compatible extensions to IPv4. Each scheme has its 387 strengths and weaknesses, which have to be weighed. 389 However, the absence of a rational and well-defined 390 transition plan is not acceptable. Indeed, the 391 difficulty of running a network that is transitioning 392 from IPv4 to IPv7 must be minimized. (A good target is 393 that running a mixed IPv4-IPv7 network should be no more 394 and preferably less difficult than running IPv4 in 395 parallel with existing non-IP protocols). 397 Furthermore, a network in transition must still be 398 robust. IPv7 schemes which maximize stability and 399 connectivity in mixed IPv4-IPv7 networks are preferred. 401 Finally, it may be necessary that multiple IPv7 protocols 402 coexist on the network during the testing and evaluation 403 periods. Transition plans must address this issue. 405 The transition plan must address the following general 406 areas of the Internet's infrastructure: 407 o Host Protocols and Software 408 o Router Protocols and Software 409 o Security and Authentication 410 o Domain Name System 411 o Network Management 412 o Operations Tools (e.g., Ping and Traceroute) 413 o Operations and Administration procedures 415 The impact on protocols which use IP addresses as data 416 (e.g. DNS, SNMP and FTP) must be specifically addressed. 418 The transition plan should address the issue of cost 419 distribution. That is, it should identify what tasks are 420 required of the service providers, of the end users, of 421 the backbones and so on. 423 Placement 424 If the transition scheme is painful, no one will 425 transition. But we should only transition if the 426 protocol we transition to solves the scaling problems and 427 is useful to use. 429 5.1.5. Media 431 CRITERION 432 The protocol must work across an internetwork of many 433 differnet LAN, MAN, and WAN media, with individual link 434 speeds ranging from a ones-of-bits per second to hundreds 435 of gigabits per second. Multiple-access and point-to- 436 point media must be supported, as must both media 437 supporting switched and permanent circuits. 439 DISCUSSION 440 The joy of IP is that it works over just about anything. 441 That ease of adding new technologies, and continuing to 442 operate with old technologies must be maintained. We 443 believe this range of speed is right for the next twenty 444 years, though it may be we should require terabit 445 performance at the high-end. 447 By switched circuits we mean both "permanent" connections 448 such as X.25 and Frame Relay services AND "temporary" 449 types of dialup connections similar to today's SLIP and 450 dialup PPP services. The latter form of connection 451 implies that dynamic network access (i.e., the ability to 452 unplug a machine, move it to a different point on the 453 network topology, and plug it back in, possibly with a 454 changed IPv7 address) is required. We note that this is 455 an aspect of mobility. 457 By work, we mean we have hopes that a stream of IPv7 458 datagrams (whether from one source, or many) can come 459 close to filling the link at high speeds, but also scales 460 gracefully to low speeds. 462 Placement 463 The protocol must be general. It must operate over all of 464 the media that IPv4 operates over today. A general goal 465 of the Internet is ubiquity. Besides all of the common 466 media available today, there are all sorts of "legacy" 467 systems which we would like to connect to IPv7 and these 468 systems might have odd media. Furthermore, there are all 469 sorts of difficult corners of the world which ought to be 470 connected to the Ubiquitous Internet but the medium to 471 get into such corners is "odd" (one example mentioned at 472 the Washington D.C. IETF was to use ELF to connect to 473 submerged submarines -- ELF has a "speed" on the order of 474 <10 characters per second) 476 5.1.6. Unreliable Datagram Service 478 CRITERION 479 The protocol must support an unreliable datagram delivery 480 service. 482 DISCUSSION 483 We like IP's datagram service and it seems to work very 484 well. So we must keep it. 486 5.1.7. Configuration, Administration, and Operation 488 CRITERION 489 The protocol must permit easy and largely distributed 490 configuration and operation. Automatic configuration of 491 hosts and routers is required. 493 DISCUSSION 494 People complain that IP is hard to manage. We cannot 495 plug and play. We must fix that problem. 497 We do note that fully automated configuration, especially 498 for large, complex networks, is still a topic of 499 research. Our concern is mostly for small and medium 500 sized, less complex, networks; places where the essential 501 knowledge and skills would not be as readily available. 503 In dealing with this criterion, address assignment and 504 delegation procedures and restrictions should be 505 addressed by the proposal. Furthermore, "ownership" of 506 addresses (e.g. user or service provider) has recently 507 become a concern and the issue should be addressed. 509 Additional elements of this criterion are: 511 - Ease of address allocation. 513 - Ease of changing the topology of the network within a 514 particular routing domain. 516 - Ease of changing network provider. 518 - Ease of (re)configuring host/endpoint parameters such 519 as addressing and identification. 521 - Ease of (re)configuring router parameters such as 522 addressing and identification. 524 Placement 525 The placement of this criterion as a "must" is in 526 response to the pressures of the user community, who are 527 crying out for easier to use IP. 529 5.1.8. Allow Secure Operation 531 CRITERION 532 The protocol should not preclude secure operation. 534 DISCUSSION 535 We need to be sure that we have not created a network 536 that is a cracker's playground. 538 In order to meet the Robustness criterion, some elements 539 of what is commonly shrugged off as "security" are 540 needed; e.g. to prevent a villan from injecting bogus 541 routing packets, and destroying the routing system within 542 the network. This criterion covers those aspects of 543 security that are not needed to provide the Robustness 544 criterion. 547 5.1.9. Unique Naming 549 CRITERION 550 IPv7 must assign all IP-Layer objects in the global, 551 ubiquitous, Internet unique names. 553 DISCUSSION 554 We use the term "Name" in this criterion synonymously 555 with the term "End Point Identifier" as used in the 556 NIMROD proposal, or as IP Addresses uniquely identify 557 interfaces/hosts in IPv4. 559 The authors are not convinced that this ought to be a 560 criterion of the protocol. We feel that it may in fact be 561 a part of a solution to other criteria and as such, is 562 not a criterion of its own. The BOF expressed a very 563 strong desire to include this criterion and we are 564 placing it here in the hope that it will stimulate 565 discussion on the subject. 567 5.1.10. Access 569 CRITERION 570 The protocols that define IPv7, its associated protocols 571 (similar to ARP and ICMP in IPv4) and the routing 572 protocols (e.g. OSPF, BGP, and RIP in IPv4) must be 573 freely available in the same fashion that RFCs are: 574 namely in ASCII format, obtainable by anonymous FTP, and 575 freely reproducible without copyright restrictions. 577 DISCUSSION 578 An essential aspect of the development of the Internet 579 and its protocols has been the fact that the protocol 580 specifications are freely available to anyone who wishes 581 a copy. Beyond simply minimizing the cost of learning 582 about the technology, the free access to specifications 583 has made it easy for researchers and developers to easily 584 incorporate portions of old protocol specifications in 585 the revised specifications. This type of easy access to 586 the standards documents is required for IPv7. 588 5.2. SHOULDs 590 The following criteria were deemed by an IETF BOF session to 591 be of lesser importance than the preceeding ones. Every 592 attempt should be made by protocol designers to satisfy these 593 criteria, however, deployment would not be held up, waiting 594 for one of these criteria to be met. 596 Some of the criteria represent technologies which are only now 597 starting to move from the research world to the engineering 598 and development world. 600 Other criteria were demoted to this level for reasons that are 601 unclear to the authors. In particular, the authors firmly 602 believe that multicasting and extensibility are actually 603 requirements that no IPv7 should be without. To reflect the 604 decisions at the DC meeting, these criteria have been demoted 605 to this section, but the authors may, after further 606 reflection, move them back into the must category in the 607 future. 609 5.2.1. Addressing 611 CRITERION 612 The protocol must allow for both unicast and multicast 613 addressing. Part of the multicast capability is a 614 requirement to be able to send to "all IP hosts on THIS 615 network". 617 DISCUSSION 618 IPv4 has made heavy use of the ability to multicast 619 requests to all IPv4 hosts on a subnet, especially for 620 autoconfiguration. This ability must be retained in 621 IPv7. 623 Unfortunately, IPv4 currently uses the local media 624 broadcast address to multicast to all IP hosts. This 625 behavior is anti-social in mixed-protocol networks and 626 should be fixed in IPv7. There's no good reason for IPv7 627 to send to all hosts on a subnet when it only wishes to 628 send to all IPv7 hosts. The protocol must make 629 allowances for media that do not support true 630 multicasting. 632 In the past few years, we have begun to deploy support 633 for wide-area multicast addressing in the Internet, and 634 it has proved valuable. This capability should not be 635 lost in the transition to IPv7. 637 The ability to restrict the range of a broadcast or 638 multicast to specific networks is also important. 640 It should be noted that addressing -- specifically the 641 syntax and semantics of addresses -- has a great impact 642 on the scalability of the architecture. 644 Placement 645 We believe that Multicast Addressing is vital to support 646 future applications such as remote conferencing. It is 647 also used quite heavily in the current Internet for 648 things like service location and routing. 650 Author's Note 651 The Washington D.C. BOF did not come down firmly that 652 multicast should be a MUST, however the authors believe 653 it to be essential. 655 5.2.2. Extensibility 657 CRITERION 658 The protocol must be extensible; it must be able to 659 evolve to meet the future service needs of the Internet. 660 This evolution must be achievable without requiring 661 network-wide software upgrades. 663 DISCUSSION 664 We do not today know all of the things that we will want 665 the Internet to be able to do 10 years from now. At the 666 same time, it is not reasonable to ask users to 667 transition to a new protocol with each passing decade. 668 Thus, we believe that it must be possible to extend IPv7 669 to support new services and facilities. Furthermore, it 670 is essential that any extensions can be incrementally 671 deployed to only those systems which desire to use them. 672 Systems upgraded in this fashion must still be able to 673 communicate with systems which have not been so upgraded. 675 Placement 676 We believe that this criterion should be a "MUST" simply 677 because we can not predict very well what the future will 678 bring so the protocol must be able to deal with the 679 future -- whatever it is. 681 Author's Note 682 The Washington D.C. BOF did not come down firmly that 683 extensibility should be a MUST, however the authors 684 believe it to be essential. 686 5.2.3. Support for Guaranteed Flows 688 CRITERION 689 The protocol should support guaranteed flows. 691 DISCUSSION 692 Multimedia is now on our desktop and will be an essential 693 part of future networking. So we have to find ways to 694 support it; and a failure to support it may mean users 695 choose to use protocols other than IPv7. 697 The IETF multicasts have shown that we can currently 698 support multimedia over internetworks with some hitches. 699 If we can achieve the needed support for guaranteed flows 700 in IPv7, we will dramatically increase its success. 702 5.2.4. Support for Mobility 704 CRITERION 705 The protocol should support mobile hosts. 707 DISCUSSION 708 Again, mobility is becoming increasingly important. Look 709 at the portables that everyone is carrying. Note the 710 strength of the Apple commercial showing someone 711 automatically connecting up her Powerbook to her computer 712 back in the office. There have been a number of pilot 713 projects showing ways to support mobility in IPv4. All 714 have some drawbacks. But like guaranteed flows, if we 715 can support mobility, IPv7 will have features that will 716 encourage transition. 718 We use a vague definition of "mobility" here. To some 719 people, this means hosts that physically move and remain 720 connected (via some wireless datalink), to others it 721 means disconnecting a host from one spot in the network, 722 connecting it back in another arbitrary spot and 723 continuing to work. At this point we expect that the 724 proposals will discuss their own abilities in this 725 general area. 727 5.2.5. Cost Distribution 729 This is a place-holder from the BOF. 731 5.2.6. Risk and Maturity 733 This is a place-holder from the BOF. 735 5.2.7. Performance 737 This is a place-holder from the BOF. 739 5.3. Explicit Non-Goals 741 This section contains some explicit non-goals of IPv7. A 742 non-goal does not mean that a protocol MUST NOT do something. 743 It means that the authors do not believe that it matters 744 whether the non-goal is in the protocol or not. If a protocol 745 includes one of the non-goals; well, that's cool. If it 746 doesn't; that's cool too. A non-goal might be necessary in 747 order to meet some other criterion, however this is irrelevant 748 to including the non-goal merely for its own sake. 750 Fragmentation 751 The technology exists for path MTU discovery. Presumably, 752 IPv7 will continue to provide this technology. 753 Therefore, we believe that IPv7 Fragmentation and 754 Reassembly, as provided in IPv4, is not necessary. 756 IPv4/IPv7 Communication 757 It is not necessary that IPv4-only and IPv7-only hosts be 758 able to communicate directly with each other. 760 IP Checksum 761 There has been discussion indicating that the IP Checksum 762 does not provide enough error protection to warrant its 763 performance impact. The argument states that there is 764 almost always a stronger datalink level CRC, and that 765 end-to-end protection is provided by the TCP checksum. 766 Therefore we believe that an IPv7 checksum is not 767 required per-se. 769 6. Detailed Questions 771 This section is an initial draft of a list of detailed 772 questions designed to start to help refine our 773 understanding of how each proposal meets the criteria. 774 The questions are written such that there are no right or 775 wrong answers, but rather, that by reading answers to the 776 questions one can develop a better understanding of the 777 tradeoffs chosen by the protocol designers. The 778 questions are grouped according to the criteria they are 779 intended to help readers better understand. 781 7. References 783 [1] Internet Architecture Board, IP Version 7, Draft 8, 784 Internet Draft, July, 1992. 786 [2] Gross, P. and P. Almquist, IESG Deliberations on Routing 787 and Addressing, Internet Draft, September 1992. 789 [3] Clark, D., et al, Towards the Future Internet 790 Architecture Network Working Group Request For Comments 791 1287, December 1991. 793 [4] Dave Clark's paper at SIGCOMM '88 where he pointed out 794 that the design of TCP/IP was guided, in large part, by 795 an ordered list of requirements. 797 Table of Contents 799 Status of this Memo .................................... 1 800 1 Introduction .......................................... 2 801 1.1 Change Log .......................................... 2 802 2 Goals ................................................. 5 803 3 Note on Terminology ................................... 6 804 4 General Principles .................................... 7 805 4.1 Architectural Simplicity ............................ 7 806 4.2 One Protocol to Bind Them All ....................... 7 807 4.3 Live Long ........................................... 7 808 4.4 Live Long AND Prosper ............................... 8 809 5 Criteria .............................................. 9 810 5.1 MUSTs ............................................... 9 811 5.1.1 Scale ............................................. 9 812 5.1.2 Topological Flexibility ........................... 10 813 5.1.3 Robust Service .................................... 10 814 5.1.4 Transition ........................................ 11 815 5.1.5 Media ............................................. 13 816 5.1.6 Unreliable Datagram Service ....................... 14 817 5.1.7 Configuration, Administration, and Operation ...... 14 818 5.1.8 Allow Secure Operation ............................ 15 819 5.1.9 Unique Naming ..................................... 15 820 5.1.10 Access ........................................... 16 821 5.2 SHOULDs ............................................. 16 822 5.2.1 Addressing ........................................ 17 823 5.2.2 Extensibility ..................................... 18 824 5.2.3 Support for Guaranteed Flows ...................... 19 825 5.2.4 Support for Mobility .............................. 19 826 5.2.5 Cost Distribution ................................. 20 827 5.2.6 Risk and Maturity ................................. 20 828 5.2.7 Performance ....................................... 20 829 5.3 Explicit Non-Goals .................................. 20 830 6 Detailed Questions .................................... 22 831 7 References ............................................ 23