rfc1716.txt

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

         the specification.

      o  SHOULD
         This word means that there may exist valid reasons in
         particular circumstances to ignore this item, but the full
         implications should be understood and the case carefully
         weighed before choosing a different course.

      o  SHOULD IMPLEMENT
         This phrase is similar in meaning to SHOULD, but is used when
         we recommend that a particular feature be provided but does not
         necessarily recommend that it be enabled by default.

      o  SHOULD NOT
         This phrase means that there may exist valid reasons in
         particular circumstances when the described behavior is
         acceptable or even useful, but the full implications should be
         understood and the case carefully weighed before implementing
         any behavior described with this label.

      o  MAY
         This word means that this item is truly optional.  One vendor
         may choose to include the item because a particular marketplace
         requires it or because it enhances the product, for example;
         another vendor may omit the same item.


Almquist & Kastenholz                                           [Page 5]

RFC 1716          Towards Requirements for IP Routers      November 1994


1.1.3  Compliance

      Some requirements are applicable to all routers.  Other
      requirements are applicable only to those which implement
      particular features or protocols.  In the following paragraphs,
      Relevant refers to the union of the requirements applicable to all
      routers and the set of requirements applicable to a particular
      router because of the set of features and protocols it has
      implemented.

      Note that not all Relevant requirements are stated directly in
      this memo.  Various parts of this memo incorporate by reference
      sections of the Host Requirements specification, [INTRO:2] and
      [INTRO:3].  For purposes of determining compliance with this memo,
      it does not matter whether a Relevant requirement is stated
      directly in this memo or merely incorporated by reference from one
      of those documents.

      An implementation is said to be conditionally compliant if it
      satisfies all of the Relevant MUST, MUST IMPLEMENT, and MUST NOT
      requirements.  An implementation is said to be unconditionally
      compliant if it is conditionally compliant and also satisfies all
      of the Relevant SHOULD, SHOULD IMPLEMENT, and SHOULD NOT
      requirements.  An implementation is not compliant if it is not
      conditionally compliant (i.e., it fails to satisfy one or more of
      the Relevant MUST, MUST IMPLEMENT, or MUST NOT requirements).

      For any of the SHOULD and SHOULD NOT requirements, a router may
      provide a configuration option that will cause the router to act
      other than as specified by the requirement.  Having such a
      configuration option does not void a router's claim to
      unconditional compliance as long as the option has a default
      setting, and that leaving the option at its default setting causes
      the router to operate in a manner which conforms to the
      requirement.

      Likewise, routers may provide, except where explicitly prohibited
      by this memo, options which cause them to violate MUST or MUST NOT
      requirements.  A router which provides such options is compliant
      (either fully or conditionally) if and only if each such option
      has a default setting which causes the router to conform to the
      requirements of this memo.  Please note that the authors of this
      memo, although aware of market realities, strongly recommend
      against provision of such options.  Requirements are labeled MUST
      or MUST NOT because experts in the field have judged them to be
      particularly important to interoperability or proper functioning
      in the Internet.  Vendors should weigh carefully the customer


Almquist & Kastenholz                                           [Page 6]

RFC 1716          Towards Requirements for IP Routers      November 1994


      support costs of providing options which violate those rules.

      Of course, this memo is not a complete specification of an IP
      router, but rather is closer to what in the OSI world is called a
      profile.  For example, this memo requires that a number of
      protocols be implemented.  Although most of the contents of their
      protocol specifications are not repeated in this memo,
      implementors are nonetheless required to implement the protocols
      according to those specifications.

1.2  Relationships to Other Standards

   There are several reference documents of interest in checking the
   current status of protocol specifications and standardization:

     o  INTERNET OFFICIAL PROTOCOL STANDARDS
        This document describes the Internet standards process and lists
        the standards status of the protocols.  As of this writing, the
        current version of this document is STD 1, RFC 1610, [ARCH:7].
        This document is periodically re-issued.  You should always
        consult an RFC repository and use the latest version of this
        document.

     o  Assigned Numbers
        This document lists the assigned values of the parameters used
        in the various protocols.  For example, IP protocol codes, TCP
        port numbers, Telnet Option Codes, ARP hardware types, and
        Terminal Type names.  As of this writing, the current version of
        this document is STD 2, RFC 1700, [INTRO:7].  This document is
        periodically re-issued.  You should always consult an RFC
        repository and use the latest version of this document.

     o  Host Requirements
        This pair of documents reviews the specifications that apply to
        hosts and supplies guidance and clarification for any
        ambiguities.  Note that these requirements also apply to
        routers, except where otherwise specified in this memo.  As of
        this writing (December, 1993) the current versions of these
        documents are RFC 1122 and RFC 1123, (STD 3) [INTRO:2], and
        [INTRO:3] respectively.

     o  Router Requirements (formerly Gateway Requirements)
        This memo.

     Note that these documents are revised and updated at different
     times; in case of differences between these documents, the most
     recent must prevail.


Almquist & Kastenholz                                           [Page 7]

RFC 1716          Towards Requirements for IP Routers      November 1994


     These and other Internet protocol documents may be obtained from
     the:

     The InterNIC
     DS.INTERNIC.NET
     InterNIC Directory and Database Service

     [phone] or [phone]

     [e-mail]


1.3  General Considerations

   There are several important lessons that vendors of Internet software
   have learned and which a new vendor should consider seriously.

1.3.1  Continuing Internet Evolution

      The enormous growth of the Internet has revealed problems of
      management and scaling in a large datagram-based packet
      communication system.  These problems are being addressed, and as
      a result there will be continuing evolution of the specifications
      described in this memo.  New routing protocols, algorithms, and
      architectures are constantly being developed.  New and additional
      internet-layer protocols are also constantly being devised.
      Because routers play such a crucial role in the Internet, and
      because the number of routers deployed in the Internet is much
      smaller than the number of hosts, vendors should expect that
      router standards will continue to evolve much more quickly than
      host standards.  These changes will be carefully planned and
      controlled since there is extensive participation in this planning
      by the vendors and by the organizations responsible for operation
      of the networks.

      Development, evolution, and revision are characteristic of
      computer network protocols today, and this situation will persist
      for some years.  A vendor who develops computer communications
      software for the Internet protocol suite (or any other protocol
      suite!) and then fails to maintain and update that software for
      changing specifications is going to leave a trail of unhappy
      customers.  The Internet is a large communication network, and the
      users are in constant contact through it.  Experience has shown
      that knowledge of deficiencies in vendor software propagates
      quickly through the Internet technical community.



Almquist & Kastenholz                                           [Page 8]

RFC 1716          Towards Requirements for IP Routers      November 1994


1.3.2  Robustness Principle

      At every layer of the protocols, there is a general rule (from
      [TRANS:2] by Jon Postel) whose application can lead to enormous
      benefits in robustness and interoperability:

                       Be conservative in what you do,
                  be liberal in what you accept from others.

      Software should be written to deal with every conceivable error,
      no matter how unlikely; sooner or later a packet will come in with
      that particular combination of errors and attributes, and unless
      the software is prepared, chaos can ensue.  In general, it is best
      to assume that the network is filled with malevolent entities that
      will send packets designed to have the worst possible effect.
      This assumption will lead to suitably protective design.  The most
      serious problems in the Internet have been caused by unforeseen
      mechanisms triggered by low probability events; mere human malice
      would never have taken so devious a course!

      Adaptability to change must be designed into all levels of router
      software.  As a simple example, consider a protocol specification
      that contains an enumeration of values for a particular header
      field - e.g., a type field, a port number, or an error code; this
      enumeration must be assumed to be incomplete.  If the protocol
      specification defines four possible error codes, the software must
      not break when a fifth code shows up.  An undefined code might be
      logged, but it must not cause a failure.

      The second part of the principle is almost as important: software
      on hosts or other routers may contain deficiencies that make it
      unwise to exploit legal but obscure protocol features.  It is
      unwise to stray far from the obvious and simple, lest untoward
      effects result elsewhere.  A corollary of this is watch out for
      misbehaving hosts; router software should be prepared to survive
      in the presence of misbehaving hosts.  An important function of
      routers in the Internet is to limit the amount of disruption such
      hosts can inflict on the shared communication facility.

1.3.3  Error Logging

      The Internet includes a great variety of systems, each
      implementing many protocols and protocol layers, and some of these
      contain bugs and misfeatures in their Internet protocol software.
      As a result of complexity, diversity, and distribution of
      function, the diagnosis of problems is often very difficult.


Almquist & Kastenholz                                           [Page 9]

RFC 1716          Towards Requirements for IP Routers      November 1994


      Problem diagnosis will be aided if routers include a carefully
      designed facility for logging erroneous or strange events.  It is
      important to include as much diagnostic information as possible
      when an error is logged.  In particular, it is often useful to
      record the header(s) of a packet that caused an error.  However,
      care must be taken to ensure that error logging does not consume
      prohibitive amounts of resources or otherwise interfere with the
      operation of the router.

      There is a tendency for abnormal but harmless protocol events to
      overflow error logging files; this can be avoided by using a
      circular log, or by enabling logging only while diagnosing a known
      failure.  It may be useful to filter and count duplicate
      successive messages.  One strategy that seems to work well is to
      both:
      o  Always count abnormalities and make such counts accessible
         through the management protocol (see Chapter 8); and
      o  Allow the logging of a great variety of events to be
         selectively enabled.  For example, it might useful to be able
         to log everything or to log everything for host X.

      This topic is further discussed in [MGT:5].

1.3.4  Configuration

      In an ideal world, routers would be easy to configure, and perhaps
      even entirely self-configuring.  However, practical experience in
      the real world suggests that this is an impossible goal, and that
      in fact many attempts by vendors to make configuration easy
      actually cause customers more grief than they prevent.  As an
      extreme example, a router designed to come up and start routing
      packets without requiring any configuration information at all
      would almost certainly choose some incorrect parameter, possibly
      causing serious problems on any networks unfortunate enough to be
      connected to it.