rfc985.txt

RFC 相关的技术文档

        NIC-50003, SRI International, December 1985.

   [27] Mills, D.L., "Autonomous Confederations", DARPA Network Working
        Group Report RFC-975, M/A-COM Linkabit, February 1986.

   [28] Jacobsen, O., and J. Postel, "Protocol Document Order
        Information",  DARPA Network Working Group Report RFC-980, SRI
        International, March 1986.

   [29] Malis, A.G., "PSN End-to-End Functional Specification", DARPA
        Network Working Group Report RFC-979, BBN Communications,
        March 1986.




























NTAG                                                           [Page 18]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


Appendix A.  Ethernet Management

   Following is a summary of procedures specified for use by hosts and
   gateways on an Ethernet.

   A.1.  Hardware

      A packet is accepted from the cable only if its destination
      Ethernet address matches either the assigned interface address or
      a broadcast/multicast address.  Presumably, this filtering is done
      by the interface hardware;  however, the software driver is
      expected to do this if the hardware does not.  Some hosts
      incorporate an optional feature that associates an assigned
      multicast address with a specific subnet in order to restrict
      access for testing, etc.  When this feature is activated, the
      assigned multicast address replaces the broadcast address.

   A.2.  IP datagram

      In case of broadcast/multicast (as determined from the destination
      Ethernet address) an IP datagram is discarded if the source IP
      address is not in the same subnet, as determined by the assigned
      host IP address and subnet mask.  It is desirable that this test
      be overridden by a configuration parameter, in order to support
      the infrequent cases where more than one subnet may coexist on the
      same cable.

   A.3.  ARP datagram

      An ARP reply is discarded if the destination IP address does not
      match the local host address.  An ARP request is discarded if the
      source IP address is not in the same subnet.  It is desirable that
      this test be overridden by a configuration parameter, in order to
      support the infrequent cases where more than one subnet may
      coexist on the same cable (see RFC-925 for examples).  An ARP
      reply is generated only if the destination protocol IP address is
      reachable from the local host (as determined by the routing
      algorithm) and the next hop is not via the same interface.  If the
      local host functions as a gateway, this may result in ARP replies
      for destinations not in the same subnet.

   A.4.  ICMP redirect

      An ICMP redirect is discarded if the destination IP address does
      not match the local host address or the new target address is not
      on the same subnet.  An accepted redirect updates the routing data
      base for the old target address.  If there is no route or


NTAG                                                           [Page 19]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


      associated with the old target address, the redirect is ignored.
      If the old route is associated with a default gateway, a new route
      associated with the new target address is inserted in the data
      base.  Note that it is not possible to send a gratuitous redirect
      unless the sender is possessed of considerable imagination.

      When subnets are in use there is some ambiguity as to the scope of
      a redirect, unless all hosts and gateways involved have prior
      knowledge of the subnet masks.  It is recommended that the use of
      ICMP network-redirect messages be avoided in favor of ICMP
      host-redirect messages instead.  This requires the original sender
      (i.e.  redirect recipient) to support a general IP
      address-translation cache, rather than the usual network table.
      However, this is normally done anyway in the case of ARP.

      An ICMP redirect is generated only if the destination IP address
      is reachable from the local host (as determined by the routing
      algorithm) and the next hop is via the same interface and the
      target address is defined in the routing data base.  Redirects
      should never be sent in response to an IP net or subnet broadcast
      address or in response to a Class-D or Class-E IP address.

      ICMP redirects are never forwarded, regardless of destination
      address.  The source IP address of the ICMP redirect itself is not
      checked, since the sending gateway may use one of its addresses
      not on the common net.  The source IP address of the encapsulated
      IP datagram is not checked on the assumption the host or gateway
      sending the original IP datagram knows what it is doing.





















NTAG                                                           [Page 20]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


Appendix B.  Policy Issues

   The following sections discuss certain issues of special concern to
   the NSF scientific networking community.  These issues have primary
   relevance in the policy area, but also have ramifications in the
   technical area.

   B.1.  Interconnection Technology

      Currently the most important common interconnection technology
      between Internet systems of different vendors is Ethernet.  Among
      the reasons for this are the following:

         1.  Ethernet specifications are well-understood and mature.

         2.  Ethernet technology is in almost all aspects vendor
             independent.

         3.  Ethernet-compatible systems are common and becoming more
             so.

      These advantages combined favor the use of Ethernet technology as
      the common point of demarcation between NSF network systems
      supplied by different vendors, regardless of technology.  It is a
      requirement of NSF gateways that, regardless of the possibly
      proprietary switching technology used to implement a given
      vendor-supplied network, its gateways must support an Ethernet
      attachment to gateways of other vendors.

      It is expected that future NSF gateway requirements will specify
      other interconnection technologies.  The most likely candidates
      are those based on X.25 or IEEE 802, but other technologies
      including broadband cable, fiber-optic or other protocols such as
      DDCMP may also be considered.

   B.2.  Proprietary and Extensible Issues

      Internet technology is a growing, adaptable technology.  Although
      hosts, gateways and networks supporting this technology have been
      in continuous operation for several years, vendors users and
      operators should understand that not all networking issues are
      fully understood. As a result, when new needs or better solutions
      are developed for use in the NSF networking community, it may be
      necessary to field new protocols.  Normally, these new protocols
      will be designed to interoperate in all practical respects with
      existing protocols; however, occasionally it may happen that
      existing systems must be upgraded to support these protocols.


NTAG                                                           [Page 21]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


      NSF systems vendors should understand that they also undertake a
      commitment to remain aware of current Internet technology and be
      prepared to upgrade their products from time to time as
      appropriate.  As a result, these vendors are strongly urged to
      consider extensibility and periodic upgrades as fundamental
      characteristics of their products.  One of the most productive and
      rewarding ways to do this on a long-term basis is to participate
      in ongoing Internet research and development programs in
      partnership with the academic community.

   B.3.  Multi-Protocol Gateways

      Although the present requirements for an NSF gateway specify only
      the Internet protocol suite, it is highly desirable that gateway
      designs allow future extensions to support additional suites and
      allow simultaneous operation with more than a single one.
      Clearly, the ISO protocol suite is a prime candidate for one of
      these suites.  Other candidates include XNS and DECnet.

      Future requirements for NSF gateways may include provisions for
      other protocol suites in addition to Internet, as well as models
      and specifications to interwork between them, should that be
      appropriate.  For instance, it is expected that the ISO suite will
      eventually become the dominant one;  however, it is also expected
      that requirements to support other suites will continue, perhaps
      indefinitely.

      Present NSF gateway requirements do not include protocols above
      the network layer, such as TCP, unless necessary for network
      monitoring or control.  Vendors should recognize that future
      requirements to interwork between Internet and ISO applications,
      for example, may result in an opportunity to market gateways
      supporting multiple protocols at all levels through the
      application level.  It is expected that the network-level NSF
      gateway requirements summarized in this document will be
      incorporated in the requirements document for these
      application-level gateways.

   B.4.  Access Control and Accounting

      There are no requirements for NSF gateways at this time to
      incorporate specific access-control and accounting mechanisms in
      the design;  however, these important issues are currently under
      study and will be incorporated into a redraft of this document at
      an early date.  Vendors are encouraged to plan for the early
      introduction of these mechanisms in their products.  While at this



NTAG                                                           [Page 22]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


      time no definitive common model for access control and accounting
      has emerged, it is possible to outline some general features such
      a model is likely to have, among them the following:

         1.  The primary access control and accounting executive
             mechanisms will be in the service hosts themselves, not the
             gateways, packet switches or workstations.

         2.  Agents acting on behalf of access control and accounting
             executive mechanisms may be necessary in the gateways,
             packet switches or workstations.  These may be used to
             collect data, enforce password protection or mitigate
             resource priority and fairness.  However, the architecture
             and protocols used by these agents may be a local matter
             and not possible to specify in advance.

         3.  NSF gateways may be required to incorporate access control
             and accounting mechanisms based on packet
             source/destination address, as well as other fields in the
             IP header, internal priority and fairness.  However, it is
             extremely unlikely that these mechanisms would involve a
             user-level login to the gateway itself.



























NTAG                                                           [Page 23]