rfc1726.txt

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

   * It is easier to experiment with new protocols and services and then
     roll out intermediate and final results in a controlled fashion.
   * By eliminating a single point of control, a single point of failure
     is also eliminated, making it much less likely that the entire
     network will fail.
   * It allows the administrative tasks for the network to be more
     widely distributed.

   An example of the benefits of this "Cooperative Anarchy" can be seen
   in the benefits derived from using the Domain Naming System over the
   original HOSTS.TXT system.

5. Criteria

   This section enumerates the criteria against which we suggest the IP
   The Next Generation proposals be evaluated.

   Each criterion is presented in its own section. The first paragraph
   of each section is a short, one or two sentence statement of the
   criterion.  Additional paragraphs then explain the criterion in more
   detail, clarify what it does and does not say and provide some
   indication of its relative importance.

   Also, each criterion includes a subsection called "Time Frame".  This
   is intended to give a rough indication of when the authors believe
   that the particular criterion will become "important".  We believe
   that if an element of technology is significant enough to include in
   this document then we probably understand the technology enough to
   predict how important that technology will be.  In general, these
   time frames indicate that, within the desired time frame, we should
   be able to get an understanding of how the feature will be added to a
   protocol, perhaps after discussions with the engineers doing the
   development.  Time Frame is not a deployment schedule since
   deployment schedules depend on non-technical issues, such as vendors
   determining whether a market exists, users fitting new releases into
   their systems, and so on.








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


5.1 Scale

   CRITERION
      The IPng Protocol must scale to allow the identification and
      addressing of at least 10**12 end systems (and preferably much
      more).  The IPng Protocol, and its associated routing protocols
      and architecture must allow for at least 10**9 individual networks
      (and preferably more).  The routing schemes must scale at a rate
      that is less than the square root of the number of constituent
      networks [10].

   DISCUSSION
      The initial, motivating, purpose of the IPng effort is to allow
      the Internet to grow beyond the size constraints imposed by the
      current IPv4 addressing and routing technologies.

      Both aspects of scaling are important.  If we can't route then
      connecting all these hosts is worthless, but without connected
      hosts, there's no point in routing, so we must scale in both
      directions.

      In any proposal, particular attention must be paid to describing
      the routing hierarchy, how the routing and addressing will be
      organized, how different layers of the routing interact, and the
      relationship between addressing and routing.

      Particular attention must be paid to describing what happens when
      the size of the network approaches these limits. How are network,
      forwarding, and routing performance affected? Does performance
      fall off or does the network simply stop as the limit is neared.

      This criterion is the essential problem motivating the transition
      to IPng.  If the proposed protocol does not satisfy this criteria,
      there is no point in considering it.

      We note that one of the white papers solicited for the IPng
      process [5] indicates that 10**12 end nodes is a reasonable
      estimate based on the expected number of homes in the world and
      adding two orders of magnitude for "safety".  However, this white
      paper treats each home in the world as an end-node of a world-wide
      Internet.  We believe that each home in the world will in fact be
      a network of the world-wide Internet.  Therefore, if we take [5]'s
      derivation of 10**12 as accurate, and change their assumption that
      a home will be an end-node to a home being a network, we may
      expect that there will be the need to support at least 10**12
      networks, with the possibility of supporting up to 10**15 end-
      nodes.




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


   Time Frame
      Any IPng proposal should be able to show immediately that it has
      an architecture for the needed routing protocols, addressing
      schemes, abstraction techniques, algorithms, data structures, and
      so on that can support growth to the required scales.

      Actual development, specification, and deployment of the needed
      protocols can be deferred until IPng deployment has extended far
      enough to require such protocols.  A proposed IPng should be able
      to demonstrate ahead of time that it can scale as needed.

5.2 Topological Flexibility

   CRITERION
      The routing architecture and protocols of IPng must allow for many
      different network topologies.  The routing architecture and
      protocols must not assume that the network's physical structure is
      a tree.

   DISCUSSION
      As the Internet becomes ever more global and ubiquitous, it will
      develop new and different topologies. We already see cases where
      the network hierarchy is very "broad" with many subnetworks, each
      with only a few hosts and where it is very "narrow", with few
      subnetworks each with many hosts.  We can expect these and other
      topological forms in the future.  Furthermore, since we expect
      that IPng will allow for many more levels of hierarchy than are
      allowed under IPv4, we can expect very "tall" and very "short"
      topologies as well.

      Constituent organizations of the Internet should be allowed to
      structure their internal topologies in any manner they see fit.
      Within reasonable implementation limits, organizations should be
      allowed to structure their addressing in any manner.  We
      specifically wish to point out that if the network's topology or
      addressing is hierarchical, constituent organizations should be
      able to allocate to themselves as many levels of hierarchy as they
      wish.

      It is very possible that the diameter of the Internet will grow to
      be extremely large; perhaps larger than 256 hops.

      Neither the current, nor the future, Internet will be physically
      structured as a tree, nor can we assume that connectivity can
      occur only between certain points in the graph.  The routing and
      addressing architectures must allow for multiply connected
      networks and be able to utilize multiple paths for any reason,
      including redundancy, load sharing, type- and quality-of-service



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


      differentiation.

   Time Frame
      We believe that Topological Flexibility is an inherent element of
      a protocol and therefore should be immediately demonstrable in an
      IPng proposal.

5.3 Performance

   CRITERION
      A state of the art, commercial grade router must be able to
      process and forward IPng traffic at speeds capable of fully
      utilizing common, commercially available, high-speed media at the
      time.  Furthermore, at a minimum, a host must be able to achieve
      data transfer rates with IPng comparable to the rates achieved
      with IPv4, using similar levels of host resources.

   DISCUSSION
      Network media speeds are constantly increasing.  It is essential
      that the Internet's switching elements (routers) be able to keep
      up with the media speeds.

      We limit this requirement to commercially available routers and
      media.  If some network site can obtain a particular media
      technology "off the shelf", then it should also be able to obtain
      the needed routing technology "off the shelf." One can always go
      into some laboratory or research center and find newer, faster,
      technologies for network media and for routing.  We do believe,
      however, that IPng should be routable at a speed sufficient to
      fully utilize the fastest available media, though that might
      require specially built, custom, devices.

      We expect that more and more services will be available over the
      Internet. It is not unreasonable, therefore, to expect that the
      ratio of "local" traffic (i.e., the traffic that stays on one's
      local network) to "export" traffic (i.e., traffic destined to or
      sourced from a network other than one's own local network) will
      change, and the percent of export traffic will increase.

      We note that the host performance requirement should not be taken
      to imply that IPng need only be as good as IPv4.  If an IPng
      candidate can achieve better performance with equivalent resources
      (or equivalent transfer rates with fewer resources) vis-a-vis IPv4
      then so much the better.  We also observe that many researchers
      believe that a proper IPng router should be capable of routing
      IPng traffic over links at speeds that are capable of fully
      utilizing an ATM switch on the link.




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


      Some developments indicate that the use of very high speed point-
      to-point connections may become commonplace.  In particular, [5]
      indicates that OC-3 speeds may be widely used in the Cable TV
      Industry and there may be many OC-3 speed lines connecting to
      central switching elements.

      Processing of the IPng header, and subsequent headers (such as the
      transport header), can be made more efficient by aligning fields
      on their natural boundaries and making header lengths integral
      multiples of typical word lengths (32, 64, and 128 bits have been
      suggested) in order to preserve alignment in following headers.

      We point out that optimizing the header's fields and lengths only
      to today's processors may not be sufficient for the long term.
      Processor word and cache-line lengths, and memory widths are
      constantly increasing.  In doing header optimizations, the
      designer should predict word-widths one or two CPU generations
      into the future and optimize accordingly. If IPv4 and TCP had been
      optimized for processors common when they were designed, they
      would be very efficient for 6502s and Z-80s.

   Time Frame
      An IPng proposal must provide a plausible argument of how it will
      scale up in performance.  (Obviously no one can completely predict
      the future, but the idea is to illustrate that if technology
      trends in processor performance and memory performance continue,
      and perhaps using techniques like parallelism, there is reason to
      believe the proposed IPng will scale as technology scales).

5.4 Robust Service

   CRITERION
      The network service and its associated routing and control
      protocols must be robust.

   DISCUSSION
      Murphy's Law applies to networking.  Any proposed IPng protocol
      must be well-behaved in the face of malformed packets, mis-
      information, and occasional failures of links, routers and hosts.
      IPng should perform gracefully in response to willful management
      and configuration mistakes (i.e., service outages should be
      minimized).

      Putting this requirement another way, IPng must make it possible
      to continue the Internet tradition of being conservative in what
      is sent, but liberal in what one is willing to receive.





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


      We note that IPv4 is reasonably robust and any proposed IPng must
      be at least as robust as IPv4.

      Hostile attacks on the network layer and Byzantine failure modes
      must be dealt with in a safe and graceful manner.

      We note that Robust Service is, in some form, a part of security
      and vice-versa.

      The detrimental effects of failures, errors, buggy
      implementations, and misconfigurations must be localized as much
      as possible.  For example, misconfiguring a workstation's IP
      Address should not break the routing protocols.  in the event of
      misconfigurations, IPng must to be able to detect and at least
      warn, if not work around, any misconfigurations.

      Due to its size, complexity, decentralized administration, error-
      prone users and administrators, and so on, The Internet is a very