rfc1726.txt

中、英文RFC文档大全打包下载完全版 .

      hostile environment. If a protocol can not be used in such a
      hostile environment then it is not suitable for use in the
      Internet.

      Some predictions have been made that, as the Internet grows and as
      more and more technically less-sophisticated sites get connected,
      there will be more failures in the network.  These failures may be
      a combination of simple size; if the size of the network goes up
      by a factor of n, then the total number of failures in the network
      can be expected to increase by some function of n.  Also, as the
      network's users become less sophisticated, it can be assumed that
      they will make more, innocent and well meaning, mistakes, either
      in configuration or use of their systems.

      The IPng protocols should be able to continue operating in an
      environment that suffers more, total, outages than we are
      currently used to.  Similarly, the protocols must protect the
      general population from errors (either of omission or commission)
      made by individual users and sites.

   Time Frame
      We believe that the elements of Robust Service should be available
      immediately in the protocol with two exceptions.

      The security aspects of Robust Service are, in fact, described
      elsewhere in this document.







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


      Protection against Byzantine failure modes is not needed
      immediately.  A proposed architecture for it should be done
      immediately.  Prototype development should be completed in 12-18
      months, with final deployment as needed.

5.5 Transition

   CRITERION
      The protocol must have a straightforward transition plan from the
      current IPv4.

   DISCUSSION
      A smooth, orderly, transition from IPv4 to IPng is needed.  If we
      can't transition to the new protocol, then no matter how wonderful
      it is, we'll never get to it.

      We believe that it is not possible to have a "flag-day" form of
      transition in which all hosts and routers must change over at
      once. The size, complexity, and distributed administration of the
      Internet make such a cutover impossible.

      Rather, IPng will need to co-exist with IPv4 for some period of
      time.  There are a number of ways to achieve this co-existence
      such as requiring hosts to support two stacks, converting between
      protocols, or using backward compatible extensions to IPv4.  Each
      scheme has its strengths and weaknesses, which have to be weighed.

      Furthermore, we note that, in all probability, there will be IPv4
      hosts on the Internet effectively forever.  IPng must provide
      mechanisms to allow these hosts to communicate, even after IPng
      has become the dominant network layer protocol in the Internet.

      The absence of a rational and well-defined transition plan is not
      acceptable.  Indeed, the difficulty of running a network that is
      transitioning from IPv4 to IPng must be minimized.  (A good target
      is that running a mixed IPv4-IPng network should be no more and
      preferably less difficult than running IPv4 in parallel with
      existing non-IP protocols).

      Furthermore, a network in transition must still be robust.  IPng
      schemes which maximize stability and connectivity in mixed IPv4-
      IPng networks are preferred.

      Finally, IPng is expected to evolve over time and therefore, it
      must be possible to have multiple versions of IPng, some in
      production use, some in experimental, developmental, or evaluation
      use, to coexist on the network.  Transition plans must address
      this issue.



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


      The transition plan must address the following general areas of
      the Internet's infrastructure:

         Host Protocols and Software
         Router Protocols and Software
         Security and Authentication
         Domain Name System
         Network Management
         Operations Tools (e.g., Ping and Traceroute)
         Operations and Administration procedures

      The impact on protocols which use IP addresses as data (e.g., DNS,
      distributed file systems, SNMP and FTP) must be specifically
      addressed.

      The transition plan should address the issue of cost distribution.
      That is, it should identify what tasks are required of the service
      providers, of the end users, of the backbones and so on.

   Time Frame
      A transition plan is required immediately.

5.6 Media Independence

   CRITERION
      The protocol must work across an internetwork of many different
      LAN, MAN, and WAN media, with individual link speeds ranging from
      a ones-of-bits per second to hundreds of gigabits per second.
      Multiple-access and point-to-point media must be supported, as
      must media supporting both switched and permanent circuits.

   DISCUSSION
      The joy of IP is that it works over just about anything.  This
      generality must be preserved.  The ease of adding new
      technologies, and ability to continue operating with old
      technologies must be maintained.

      We believe this range of speed is right for the next twenty years,
      though we may wish to require terabit performance at the high-end.
      We believe that, at a minimum, media running at 500 gigabits per
      second will be commonly available within 10 years.  The low end of
      the link-speed range is based on the speed of systems like pagers
      and ELF (ELF connects to submerged submarines and has a "speed" on
      the order of <10 characters per second).

      By switched circuits we mean both "permanent" connections such as
      X.25 and Frame Relay services AND "temporary" types of dialup
      connections similar to today's SLIP and dialup PPP services, and



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


      perhaps, ATM SVCs.  The latter form of connection implies that
      dynamic network access (i.e., the ability to unplug a machine,
      move it to a different point on the network topology, and plug it
      back in, possibly with a changed IPng address) is required. We
      note that this is an aspect of mobility.

      By work, we mean we have hopes that a stream of IPng datagrams
      (whether from one source, or many) can come close to filling the
      link at high speeds, but also scales gracefully to low speeds.

      Many network media are multi-protocol.  It is essential that IPng
      be able to peacefully co-exist on such media with other protocols.
      Routers and hosts must be able to discriminate among the protocols
      that might be present on such a medium.  For example, on an
      Ethernet, a specific, IPng Ethernet Type value might be called
      for; or the old IPv4 Ethernet type is used and the first four
      (version number in the old IPv4 header) bits would distinguish
      between IPv4 and IPng.

      Different media have different MAC address formats and schemes.
      It must be possible for a node to dynamically determine the MAC
      address of a node given that node's IP address.  We explicitly
      prohibit using static, manually configured mappings as the
      standard approach.

      Another aspect of this criterion is that many different MTUs will
      be found in an IPng internetwork.  An IPng must be able to operate
      in such a multi-MTU environment.  It must be able to adapt to the
      MTUs of the physical media over which it operates.  Two possible
      techniques for dealing with this are path MTU discovery and
      fragmentation and reassembly; other techniques might certainly be
      developed.

      We note that, as of this writing (mid 1994), ATM seems to be set
      to become a major network media technology.  Any IPng should be
      designed to operate over ATM.  However, IPng still must be able to
      operate over other, more "traditional" network media.
      Furthermore, a host on an ATM network must be able to interoperate
      with a host on another, non-ATM, medium, with no more difficulty
      or complexity than hosts on different media can interoperate today
      using IPv4.

      IPng must be able to deal both with "dumb" media, such as we have
      today, and newer, more intelligent, media.  In particular, IPng
      functions must be able to exist harmoniously with lower-layer
      realizations of the same, or similar, functions. Routing and
      resource management are two areas where designers should pay
      particular attention.  Some subnetwork technologies may include



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


      integral accounting and billing capabilities, and IPng must
      provide the correct control information to such subnetworks.

   Time Frame
      Specifications for current media encapsulations (i.e., all
      encapsulations that are currently Proposed standards, or higher,
      in the IETF) are required immediately.  These specifications must
      include any auxiliary protocols needed (such as an address
      resolution mechanism for Ethernet or the link control protocol for
      PPP).  A general 'guide' should also be available immediately to
      help others develop additional media encapsulations.  Other,
      newer, encapsulations can be developed as the need becomes
      apparent.

      Van Jacobson-like header compression should be shown immediately,
      as should any other aspects of very-low-speed media.  Similarly,
      any specific aspects of high-speed media should be shown
      immediately.

5.7 Unreliable Datagram Service

   CRITERION
      The protocol must support an unreliable datagram delivery service.

   DISCUSSION
      We like IP's datagram service and it seems to work very well.  So
      we must keep it.  In particular, the ability, within IPv4, to send
      an independent datagram, without prearrangement, is extremely
      valuable (in fact, may be required for some applications such as
      SNMP) and must be retained.

      Furthermore, the design principle that says that we can take any
      datagram and throw it away with no warning or other action, or
      take any router and turn it off with no warning, and have datagram
      traffic still work, is very powerful.  This vastly enhances the
      robustness of the network and vastly eases administration and
      maintenance of the network.  It also vastly simplifies the design
      and implementation of software [14].

      Furthermore, the Unreliable Datagram Service should support some
      minimal level of service; something that is approximately
      equivalent to IPv4 service.  This has two functions; it eases the
      task of IPv4/IPng translating systems in mapping IPv4 traffic to
      IPng and vice versa, and it simplifies the task of fitting IPng
      into small, limited environments such as boot ROMs.

   Time Frame
      Unreliable Datagram Service must be available immediately.



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


5.8 Configuration, Administration, and Operation

   CRITERION
      The protocol must permit easy and largely distributed
      configuration and operation. Automatic configuration of hosts and
      routers is required.

   DISCUSSION
      People complain that IP is hard to manage.  We cannot plug and
      play.  We must fix that problem.

      We do note that fully automated configuration, especially for
      large, complex networks, is still a topic of research.  Our
      concern is mostly for small and medium sized, less complex,
      networks; places where the essential knowledge and skills would
      not be as readily available.

      In dealing with this criterion, address assignment and delegation
      procedures and restrictions should be addressed by the proposal.
      Furthermore, "ownership" of addresses (e.g., user or service
      provider) has recently become a concern and the issue should be
      addressed.

      We require that a node be able to dynamically obtain all of its
      operational, IP-level parameters at boot time via a dynamic
      configuration mechanism.

      A host must be able to dynamically discover routers on the host's
      local network.  Ideally, the information which a host learns via
      this mechanism would also allow the host to make a rational