rfc1726.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,427 行 · 第 1/5 页

Network Working Group                                       C. Partridge
Request for Comments: 1726                  BBN Systems and Technologies
Category: Informational                                    F. Kastenholz
                                                            FTP Software
                                                           December 1994

                    Technical Criteria for Choosing
                     IP The Next Generation (IPng)

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document was submitted to the IPng Area in response to RFC 1550.
   Publication of this document does not imply acceptance by the IPng
   Area of any ideas expressed within.  Comments should be submitted to
   the [e-mail] mailing list.  This RFC specifies
   criteria related to mobility for consideration in design and
   selection of the Next Generation of IP.

Table of Contents

  1.        Introduction. . . . . . . . . . . . . . . . . . . . . . .  2
  2.        Goals . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  3.        Note on Terminology . . . . . . . . . . . . . . . . . . .  4
  4.        General Principles. . . . . . . . . . . . . . . . . . . .  4
    4.1     Architectural Simplicity. . . . . . . . . . . . . . . . .  4
    4.2     One Protocol to Bind Them All . . . . . . . . . . . . . .  4
    4.3     Live Long . . . . . . . . . . . . . . . . . . . . . . . .  5
    4.4     Live Long AND Prosper . . . . . . . . . . . . . . . . . .  5
    4.5     Co-operative Anarchy. . . . . . . . . . . . . . . . . . .  5
  5.        Criteria. . . . . . . . . . . . . . . . . . . . . . . . .  6
    5.1     Scale . . . . . . . . . . . . . . . . . . . . . . . . . .  7
    5.2     Topological Flexibility . . . . . . . . . . . . . . . . .  8
    5.3     Performance . . . . . . . . . . . . . . . . . . . . . . .  9
    5.4     Robust Service. . . . . . . . . . . . . . . . . . . . . . 10
    5.5     Transition. . . . . . . . . . . . . . . . . . . . . . . . 12
    5.6     Media Independence. . . . . . . . . . . . . . . . . . . . 13
    5.7     Unreliable Datagram Service . . . . . . . . . . . . . . . 15
    5.8     Configuration, Administration, and Operation. . . . . . . 16
    5.9     Secure Operation. . . . . . . . . . . . . . . . . . . . . 17
    5.10    Unique Naming . . . . . . . . . . . . . . . . . . . . . . 18
    5.11    Access. . . . . . . . . . . . . . . . . . . . . . . . . . 19
    5.12    Multicast . . . . . . . . . . . . . . . . . . . . . . . . 20



Partridge and Kastenholz                                        [Page 1]

RFC 1726                IPng Technical Criteria            December 1994


    5.13    Extensibility . . . . . . . . . . . . . . . . . . . . . . 21
    5.13.1  Algorithms. . . . . . . . . . . . . . . . . . . . . . . . 22
    5.13.2  Headers . . . . . . . . . . . . . . . . . . . . . . . . . 22
    5.13.3  Data Structures . . . . . . . . . . . . . . . . . . . . . 22
    5.13.4  Packets . . . . . . . . . . . . . . . . . . . . . . . . . 22
    5.14    Network Service . . . . . . . . . . . . . . . . . . . . . 22
    5.15    Support for Mobility. . . . . . . . . . . . . . . . . . . 24
    5.16    Control Protocol. . . . . . . . . . . . . . . . . . . . . 25
    5.17    Private Networks. . . . . . . . . . . . . . . . . . . . . 25
  6.        Things We Chose Not to Require. . . . . . . . . . . . . . 26
    6.1     Fragmentation . . . . . . . . . . . . . . . . . . . . . . 26
    6.2     IP Header Checksum. . . . . . . . . . . . . . . . . . . . 26
    6.3     Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 27
    6.4     Network Management. . . . . . . . . . . . . . . . . . . . 27
    6.5     Accounting. . . . . . . . . . . . . . . . . . . . . . . . 27
    6.6     Routing . . . . . . . . . . . . . . . . . . . . . . . . . 27
    6.6.1   Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 28
    6.6.2   Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 28
    6.6.3   QOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
    6.6.4   Feedback. . . . . . . . . . . . . . . . . . . . . . . . . 28
    6.6.5   Stability . . . . . . . . . . . . . . . . . . . . . . . . 28
    6.6.6   Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29
  7.       References . . . . . . . . . . . . . . . . . . . . . . . . 29
  8.        Security Considerations . . . . . . . . . . . . . . . . . 30
  9.        Acknowledgements. . . . . . . . . . . . . . . . . . . . . 30
 10.        Authors' Addresses. . . . . . . . . . . . . . . . . . . . 31

1. Introduction

   This version of this memo was commissioned by the IPng area of the
   IETF in order to define a set of criteria to be used in evaluating
   the protocols being proposed for adoption as the next generation of
   IP.

   The criteria presented here were culled from several sources,
   including "IP Version 7" [1], "IESG Deliberations on Routing and
   Addressing" [2], "Towards the Future Internet Architecture" [3], the
   IPng Requirements BOF held at the Washington D.C. IETF Meeting in
   December of 1992, the IPng Working Group meeting at the Seattle IETF
   meeting in March 1994, the discussions held on the Big-Internet
   mailing list ([e-mail], send requests to join to
   [e-mail]), discussions with the IPng Area
   Directors and Directorate, and the mailing lists devoted to the
   individual IPng efforts.

   This document presumes that a new IP-layer protocol is actually
   desired. There is some discussion in the community as to whether we
   can extend the life of IPv4 for a significant amount of time by



Partridge and Kastenholz                                        [Page 2]

RFC 1726                IPng Technical Criteria            December 1994


   better engineering of, e.g., routing protocols, or we should develop
   IPng now.  This question is not addressed in this document.

   We would like to gratefully acknowledge the assistance of literally
   hundreds of people who shared their views and insights with us.
   However, this memo is solely the personal opinion of the authors and
   in no way represents, nor should it be construed as representing, the
   opinion of the ISOC, the IAB, the IRTF, the IESG, the IETF, the
   Internet community as a whole, nor the authors' respective employers.

2. Goals

   We believe that by developing a list of criteria for evaluating
   proposals for IP The Next Generation (IPng), the IETF will make it
   easier for developers of proposals to prioritize their work and
   efforts and make reasoned choices as to where they should spend
   relatively more and less time.  Furthermore, a list of criteria may
   help the IETF community determine which proposals are serious
   contenders for a next generation IP, and which proposals are
   insufficient to the task.  Note that these criteria are probably not
   sufficient to make final decisions about which proposal is best.
   Questions such as whether to trade a little performance (e.g.,
   packets per second routed) for slightly more functionality (e.g.,
   more flexible routing) cannot be easily addressed by a simple list of
   criteria.  However, at minimum, we believe that protocols that meet
   these criteria are capable of serving as the future IPng.

   This set of criteria originally began as an ordered list, with the
   goal of ranking the importance of various criteria.  Eventually, the
   layout evolved into the current form, where each criterion was
   presented without weighting, but a time frame, indicating
   approximately when a specific criterion, or feature of a criterion,
   should be available was added to the specification.

   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; instead,
   the more general functional goal of having the routing scale is
   listed instead of the particular mechanism of route aggregation.

   In determining the relative timing of the various criteria, we have
   had two guiding principles.  First, IPng must offer an internetwork
   service akin to that of IPv4, but improved to handle the well-known
   and widely-understood problems of scaling the Internet architecture



Partridge and Kastenholz                                        [Page 3]

RFC 1726                IPng Technical Criteria            December 1994


   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 IPng.  At a minimum, this second
   point implies that there must be a straightforward way to transition
   systems from IPv4 to IPng.  But it also strongly suggests that IPng
   should offer features that IPv4 does not; new features provide a
   motivation to deploy IPng more quickly.

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.

4. General Principles

4.1 Architectural Simplicity

         In anything at all, perfection is finally attained not
         when there is no longer anything to add, but when there
         is no longer anything to take away.

                                          Antoine de Saint-Exupery

   We believe that many communications functions are more appropriately
   performed at protocol layers other than the IP layer.  We see
   protocol stacks as hourglass-shaped, with IPng in the middle, or
   waist, of the hourglass.  As such, essentially all higher-layer
   protocols make use of and rely upon IPng.  Similarly IPng, by virtue
   of its position in the "protocol hourglass" encompasses a wide
   variety of lower-layer protocols.  When IPng does not perform a
   particular function or provide a certain service, it should not get
   in the way of the other elements of the protocol stack which may well
   wish to perform the function.

4.2 One Protocol to Bind Them All

   One of the most important aspects of The Internet is that it provides
   global IP-layer connectivity. The IP layer provides the point of
   commonality among all of the nodes on the Internet. In effect, the
   main goal of the Internet is to provide an IP Connectivity Service to
   all who wish it.



Partridge and Kastenholz                                        [Page 4]

RFC 1726                IPng Technical Criteria            December 1994


   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 has had great difficulty moving
   from SNMPv1 to SNMPv2.  Frequent changes in software are hard.

4.4 Live Long AND Prosper

   We believe that simply allowing for bigger addresses and more
   efficient routing is not enough of a benefit to encourage vendors,
   service providers, and users to switch to IPng, with its attendant
   disruptions of service, etc.  These problems can be solved much more
   simply with faster routers, balkanization of the Internet address
   space, and other hacks.

   We believe that there must be positive functional or operational
   benefits to switching to IPng.

   In other words, IPng must be able to live for a long time AND it must
   allow the Internet to prosper and to grow to serve new applications
   and user needs.

4.5 Co-operative Anarchy

   A major contributor to the Internet's success is the fact that there
   is no single, centralized, point of control or promulgator of policy
   for the entire network.  This allows individual constituents of the
   network to tailor their own networks, environments, and policies to
   suit their own needs.  The individual constituents must cooperate
   only to the degree necessary to ensure that they interoperate.






Partridge and Kastenholz                                        [Page 5]

RFC 1726                IPng Technical Criteria            December 1994