rfc1127.txt

RFC 的详细文档！

   -    Telnet interrupt/SYNCH usage   [AS 3.2.4]

   -    FTP restart facility   [AS 4.1.3.4]

   -    DNS efficiency issues   [AS 6.1.3.3]

   -    DNS user interface: aliases and search lists   [AS 6.1.4.3]

   There are some other areas where the working group tried to produce a
   more extended discussion but was not totally successful; one example
   is error logging (see Appendix I below).







Braden                                                          [Page 7]

RFC 1127           Perspective on Host Requirements         October 1989


3.  OPEN ISSUES

   For some issues, the disagreement was so serious that the working
   group was unable to reach a consensus.  In each case, some spoke for
   MUST or SHOULD, while others spoke with equal fervor for MUST NOT or
   SHOULD NOT.  As a result, the HR RFCs try to summarize the differing
   viewpoints but take no stand; the corresponding requirements are
   given as MAY or OPTIONAL.  The most notorious of these contentious
   issues are as follows.

   -    Hosts forwarding source-routed datagrams, even though the hosts
        are not otherwise acting as gateways   [CL 3.3.5]

   -    The multihoming model   [CL 3.3.4]

   -    ICMP Echo Requests to a broadcast or multicast address
        [CL 3.2.2.6]

   -    Host-only route caching   [CL 3.3.1.3]

   -    Host wiretapping routing protocols   [CL 3.3.1.4]

   -    TCP sending an ACK when it receives a segment that appears to be
        out-of-order   [CL 4.2.2.21]


   There was another set of controversial issues for which the HR RFCs
   did take a compromise stand, to allow the disputed functions but
   circumscribe their use.  In many of these cases, there were one or
   more significant voices for banning the feature altogether.

   -    Host acting as gateways   [CL 3.1]

   -    Trailer encapsulation   [CL 2.3.1]

   -    Delayed TCP acknowledgments   [CL 4.2.3.2]

   -    TCP Keep-alives   [CL 4.2.3.6]

   -    Ignoring UDP checksums   [CL 4.1.3.4]

   -    Telnet Go-Aheads   [AS 3.2.2]

   -    Allowing 8-bit data in Telnet NVT mode   [AS 3.2.5]







Braden                                                          [Page 8]

RFC 1127           Perspective on Host Requirements         October 1989


4.  OTHER FUTURE WORK

   General Issues:

   (1)  Host Initialization Procedures

      When a host system boots or otherwise initializes, it needs
      certain network configuration information in order to communicate;
      e.g., its own IP address(es) and address mask(s).  In the case of
      a diskless workstation, obtaining this information is an essential
      part of the booting process.

      The ICMP Address Mask messages and the RARP (Reverse ARP) protocol
      each provide individual pieces of configuration information.  The
      working group felt that such piecemeal solutions are a mistake,
      and that a comprehensive approach to initialization would result
      in a uniform mechanism to provide all the required configuration
      information at once.  The HR working group recommends that a new
      working group be established to develop a unified approach to
      system initialization.

   (2)  Configuration Options

      Vendors, users, and network administrators all want host software
      that is "plug-and-play".  Unfortunately, the working group was
      often forced to require additional configuration parameters to
      satisfy interoperability, functionality, and/or efficiency needs
      [1.2.4 in either RFC].  The working group was fully aware of the
      drawbacks of configuration parameters, but based upon extensive
      experience with existing implementations, it felt that the
      flexibility was sometimes more important than installation
      simplicity.

      Some of the configuration parameters are forced for
      interoperability with earlier, incorrect implementations.  Very
      little can be done to ease this problem, although retirement of
      the offending systems will gradually solve it.  However, it would
      be desirable to re-examine the other required configuration
      options, in an attempt to develop ways to eliminate some of them.

   Link-Layer Issues:

   (2)  ARP Cache Maintenance

      "Proxy ARP" is a link-layer mechanism for IP routing, and its use
      results in difficult problems in managing the ARP cache.

      Even without proxy ARP, the management dynamics of the IP route



Braden                                                          [Page 9]

RFC 1127           Perspective on Host Requirements         October 1989


      cache interact in subtle ways with transport-layer dynamics;
      introducing routing via proxy ARP brings a third protocol layer
      into the problem, complicating the inter-layer dynamics still
      further.

      The algorithms for maintaining the ARP cache need to be studied
      and experimented with, to create more complete and explicit
      algorithms and requirements.

   (3)  FDDI Bit-order in MAC addresses

      On IEEE 802.3 or 802.4 LAN, the MAC address in the header uses the
      same bit-ordering as transmission of the address as data.  On
      802.5 and FDDI networks, however, the MAC address in the header is
      in a different bit-ordering from the equivalent 6 bytes sent as
      data.  This will make it hard to do MAC-level bridging between
      FDDI and 802.3 LAN's, for example, although gateways (IP routers)
      can still be used.

      The working group concluded that this is a serious but subtle
      problem with no obvious fix, and that resolving it was beyond the
      scope of the HR working group.

   IP-Layer Issues

   (4)  Dead Gateway Detection

      A fundamental requirement for a host is to be able to detect when
      the first-hop gateway has failed.  The early TCP/IP
      experimentation was based on the ARPANET, which provided explicit
      notification of gateway failure; as a result, dead gateway
      detection algorithms were not much considered at that time.  The
      very general guidelines presented by Dave Clark [RFC-816] are
      inadequate for implementors.  The first attempt at applying these
      guidelines was the introduction of universal gateway pinging by
      TOPS-20 systems; this quickly proved to be a major generator of
      ARPANET traffic, and was squelched.  The most widely used
      implementation of the Internet protocols, 4.2BSD, solved the
      problem in an extra-architectural manner, by letting the host
      wiretap the gateway routing protocol (RIP).  As a result of this
      history, the HR working group was faced with an absence of
      documentated techniques that a host conforming to the Internet
      architecture could use to detect dead gateways.

      After extensive discussion, the working group agreed on the
      outline of an appropriate algorithm.  A detailed algorithm was in
      fact written down, to validate the discussion in the HR RFCs.
      This algorithm, or a better one, should be tried experimentally



Braden                                                         [Page 10]

RFC 1127           Perspective on Host Requirements         October 1989


      and documented in a new RFC.

   (5)  Gateway Discovery

      A host needs to discover the IP addresses of gateways on its
      connected networks.  One approach, begun but not finished by
      members of the HR working group, would be to define a new pair of
      ICMP query messages for gateway discovery.  In the future, gateway
      discovery should be considered as part of the complete host
      initialization problem.

   (6)  MTU Discovery

      Members of the HR working group designed IP options that a host
      could use to discover the minimum MTU of a particular Internet
      path [RFC-1063].  To be useful, the Probe MTU options would have
      to be implemented in all gateways, which is an obstacle to its
      adoption.  Code written to use these options has never been
      tested.  This work should be carried forward; an effective MTU
      choice will become increasingly important for efficient Internet
      service.

   (7)  Routing Advice from Gateways

      A working group member produced a draft specification for ICMP
      messages a host could use to ask gateways for routing advice
      [Lekashman].  While this is not of such pressing importance as the
      issues listed previously, it deserves further consideration and
      perhaps experimentation.

   (8)  Dynamic TTL Discovery

      Serious connectivity problems have resulted from host software
      that has too small a TTL value built into the code.  HR-CL
      specifies that TTL values must be configurable, to allow TTL to be
      increased if required for communication in a future Internet;
      conformance with this requirement would solve the current
      problems.  However, configurable parameters are an operational
      headache, so it has been suggested that a host could have an
      algorithm to determine the TTL ("Internet diameter") dynamically.
      Several algorithms have been suggested, but considerably more work
      would be required to validate them.  This is a lower-priority
      problem than issues (4)-(6).

   (9)  Dynamic Discovery of Reassembly Timeout Time

      The maximum time for retaining a partially-reassembled datagram is
      another parameter that creates a potential operational headache.



Braden                                                         [Page 11]

RFC 1127           Perspective on Host Requirements         October 1989


      An appropriate reassembly timeout value must balance available
      reassembly buffer space against reliable reassembly.  The best
      value thus may depend upon the system and upon subtle delay
      properties (delay dispersion) of the Internet.  Again, dynamic
      discovery could be desirable.

   (10) Type-of-Service Routing in Hosts

      As pointed out previously, the HR RFCs contain a number of
      provisions designed to make Type-of-Service (TOS) useful.  This
      includes the suggestion that the route cache should have a place
      or specifying the TOS of a particular route.  However, host
      algorithms for using TOS specifications need to be developed and
      documented.

   (11) Using Subnets

      An RFC is needed to provide a thorough explanation of the
      implications of subnetting for Internet protocols and for network
      administration.

   Transport-Layer Issues:

   (12) RST Message

      It has been proposed that TCP RST (Reset) segments can contain
      text to provide an explicit explanation of the reason for the
      particular RST.  A proposal has been drafted [CLynn].

   (13) Performance Algorithms

      HR-CL contains a number of requirements on TCP performance
      algorithms; Van Jacobson's slow start and congestion avoidance,
      Karn's algorithm, Nagle's algorithm, and SWS prevention at the
      sender and receiver.  Implementors of new TCPs really need more
      guidance than could possibly be included in the HR RFCs.  The
      working group suggested that an RFC on TCP performance is needed,
      to describe each of these issues more deeply and especially to
      explain how they fit together.

      Another issue raised by the HR RFCs is the need for validation (or
      rejection) of Van Jacobson's fast retransmit algorithm.

   Application-Layer Issues:

   (14) Proposed FTP extensions

      A number of minor extensions proposed for FTP should be processed



Braden                                                         [Page 12]

RFC 1127           Perspective on Host Requirements         October 1989


      and accepted or rejected.  We are aware of the following
      proposals:

      (a)  Atomic Store Command

         The FTP specification leaves undefined the disposition of a
         partial file created when an FTP session fails during a store
         operation.  It was suggested that this ambiguity could be
         resolved by defining a new store command, Store Atomic (STOA).
         The receiver would delete the partial file if the transfer
         failed before the final data-complete reply had been sent.
         This assumes the use of a transfer mode (e.g., block) in which
         end-of-file can be distinguished from TCP connection failure,
         of course.

      (b)  NDIR Command

         "NDIR would be a directories-only analogue to the NLST command.
         Upon receiving an NDIR command an FTP server would return a
         list of the subdirectories to the specified directory or file
         group; or of the current directory if no argument was sent.
         ... The existing NLST command allows user FTPs to implement
         user-interface niceties such as a "multiple get" command.  It
         also allows a selective (as opposed to generative) file-naming
         user interface: the user can pick the desired file out of a
         list instead of typing its name." [Matthews]

         However, the interface needs to distinguish files from
         directories.  Up to now, such interfaces have relied on a bug
         in many FTP servers, which have included directory names in the
         list returned by NLST.  As hosts come into conformance with
         HR-AS, we need an NDIR command to return directory names.

      (c)  Adaptive Compression

         It has been suggested that a sophisticated adaptive data
         compression algorithm, like that provided by the Unix
         "compress" command, should be added as an alternative FTP
         transfer mode.

   (15) SMTP: Global Mail Addressing

      While writing requirements for electronic mail, the working group
      was urged to set rules for SMTP and RFC-822 that would be
      universal, applicable not only to the Internet environment but
      also to the other mail environments that use one or both of these
      protocols.  The working group chose to ignore this Siren call, and
      instead limit the HR RFC to requirements specific to the Internet.



Braden                                                         [Page 13]

RFC 1127           Perspective on Host Requirements         October 1989


      However, the networking world would certainly benefit from some
      global agreements on mail routing.  Strong passions are lurking
      here.

   (16) DNS: Fully Replacing hosts.txt

      As noted in HR-AS [AS 6.1.3.8], the DNS does not yet incorporate
      all the potentially-useful information included in the DDN NIC's
      hosts.txt file.  The DNS should be expanded to cover the hosts.txt
      information.  RFC-1101 [RFC-1101] is a step in the right
      direction, but more work is needed.

5.  SUMMARY

   We have summarized the results of the Host Requirements Working
   Group, and listed a set of issues in Internet host protocols that