rfc1127.txt

RFC 的详细文档！

   need future effort.

6.  REFERENCES

   [RFC-1122]  Braden, R., Editor, "Requirements for Internet Hosts --
   Communications Layers", RFC 1122, IETF Host Requirements Working
   Group, October 1989.

   [RFC-1123]  Braden, R., Editor, "Requirements for Internet Hosts --
   Application and Support", RFC 1123, IETF Host Requirements Working
   Group, October 1989.

   [RFC-1009]  Braden, R., and J. Postel, "Requirements for Internet
   Gateways", RFC 1009, USC/Information Sciences Institute, June 1987.

   [RFC-1101]  Mockapetris, P., "DNS Encoding of Network Names and Other
   Types", RFC 1101, USC/Information Sciences Institute, April 1989.

   [RFC-1063]  Mogul, J., C. Kent, C. Partridge, and K. McCloghrie, "IP
   MTU Discovery Options", RFC-1063, DEC, BBN, & TWG, July 1988.

   [RFC-816]  Clark, D., "Fault Isolation and Recovery", RFC-816, MIT,
   July 1982.

   [CLynn]  Lynn, C., "Use of TCP Reset to Convey Error Diagnostics",
   Internal Memo, BBN, December 1988.

   [Lekashman]  Message to ietf-hosts mailing list from John Lekashman,
   14 September 1988.

   [Matthews]  Message to Postel from Jim Matthews, 3 August 1989.




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


APPENDIX I -- ISSUES FOR FUTURE REVISION

   In order to complete the HR RFCs, it was necessary to defer some
   technical issues.  These issues should be considered by the parties
   responsible for the first update of the HR RFCs.

   The issues pending at the time of publication are listed here, in
   order by protocol layer.

   General Issue:

      Error Logging

      The working group felt that more complete and explicit guidance on
      error logging procedures is needed than is presently contained in
      Section 1.2.3 (both HR RFCs).

   Link Layer Issues:

   -    Stolen IP Address

      How should a host react when it detects through ARP traffic that
      some other host has "stolen" its IP address?

   IP Layer Issues:

   -    "Raw Mode" Interface

      HR-CL could define an optional "raw mode" interface from the
      application layer to IP.

   -    Rational Fragmentation

      When a host performs intentional fragmentation, it should make the
      first fragment as large as possible (this same requirement should
      be placed on gateways).

   -    Interaction of Multiple Options

      HR-CL does not give specific rules for the interactions of
      multiple options in the same IP header; this issue was generally
      deferred to a revision of the Gateway Requirements RFC.  However,
      this issue might be revisited for hosts.

   -    ICMP Error for Source-Routed Packet

      It was suggested that when a source-routed packet arrives with an
      error, any ICMP error message should be sent with the



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


      corresponding return route.  This assumes that the ICMP error
      message is more likely to be delivered successfully with the
      source route than without it.

   -    "Strong" IP Options and ICMP Types

      The HR RFCs takes the general approach that a host should ignore
      whatever it does not understand, so that possible future
      extensions -- e.g., new IP options or new ICMP message types --
      will cause minimum problems for existing hosts.  The result of
      this approach is that when new facilities are used with old hosts,
      a "black hole" can result.  Several people have suggested that
      this is not always what is wanted; it may sometimes be more useful
      to obtain an ICMP error message from the old host.  To quote
      Jeremey Siegel:

         "The basic premise is that if an option is to have any real
         meaning at all within an '[upward] compatible' environment, it
         must be known whether or not the option actually *carries* its
         meaning.  An absurd analogy might be programming languages: I
         could make a compiler which simply ignored unknown sorts of
         statements, thereby allowing for future expansion of the
         language.

         Right now, there are four "classes" of options; only two are
         defined.  Take one of the other classes, and define it such
         that any options in that class, if unrecognized, cause an ICMP
         error message.  Thus anyone who wants to propose a "strong"
         option (one which requires full participation by all systems
         involved to operate correctly) can assign it to that class.
         Options in the current classes may still be passed through if
         they are unknown; only "weak" options will be assigned to these
         classes in the future."

   -    Network Mask

      As explained in HR-CL [CL 3.1.2.3], we believe that a possible
      future transition for the interpretation of IP addresses may be
      eased if hosts always treat an IP address as an indivisible 32-
      bit number.  However, there are various circumstances where a host
      has to distinguish its own network number.  Charlie Lynn has
      suggested that indivisibility can be retained if a host is
      configured with both an address mask (indicating subnetting) and a
      network mask (with network but not subnet bits).

   -    WhoAmI Query

      The following requirement is needed: for a multihomed host, a



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


      UDP-based application should (must?) be able to query the
      communication layers to obtain a list of all local IP addresses
      for the host.

   -    New Destination Unreachable codes

      For each of the new ICMP Destination Unreachable codes defined in
      HR-CL [CL 3.2.2.1], it should be documented whether the error is
      "soft" or "hard".

   -    ICMP Error Schizophrenia

      Section 3.3.8 of HR-CL requires a host to send ICMP error
      messages, yet in nearly all individual cases the specific
      requirements say that errors are to be silently ignored.  The
      working group recognized this contradiction but was unwilling to
      resolve it.

      At every choice point, the working group opted towards a
      requirement that would avoid broadcast storms.  For example, (1)
      ICMP errors cannot be sent for broadcasts, and also (2) individual
      errors are to be silently ignored.  This is redundant; either
      provision (1) or (2) alone, if followed, should eliminate
      broadcast storms.  The general area of responses to errors and
      broadcast storms could be reassessed and the individual decisions
      reviewed.

   Transport-Layer Requirements:

   -    Delayed ACK Definition

      A more precise and complete definition of the conditions for
      delaying a TCP ACK segment may be desirable; see Section 4.2.3.2
      of HR-CL.

   Telnet Requirements:

   -    Flushing Output

      The DISCUSSION in Section 3.2.4 of HR-AS concerns three possible
      ways for a User Telnet to flush output.  It would be helpful for
      users and implementers if one of these could be recommended over
      the others; however, when the working group discussed the matter,
      there seemed to be compelling arguments for each choice.  This
      issue needs more study.






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


   -    Telnet LineMode Option

      This important new option is still experimental, but when it
      becomes a standard, implementation should become recommended or
      required.

   FTP Requirements:

   -    Reply Codes

   A number of problems have been raised with FTP reply codes.

   (a)  Access Control Failures

      Note that a 550 message is used to indicate access control
      problems for a read-type operation (e.g., RETR, RNFR), while a 553
      message is used for the same purpose for a write-type operation
      (e.g., STOR, STOU, RNTO).

      LIST, NLST, and STAT may fail with a 550 reply due to an access
      control violation.

      MKD should fail with a 553 reply if a directory already exists
      with the same name.

   (b)  Directory Operations (RFC-959 Appendix II)

      An RMD may result in a 450 reply if the directory is busy.

      Many of the reply codes shown in the text of Appendix II are
      wrong.  A positive completion for CWD should be 250.  The 521 code
      shown for MKD should be 553 (see above), while the 431 shown for
      CWD should be a 550.

   (c)  HELP and SITE Commands

      The positive completion reply to a HELP command should be code
      214.

      HELP or SITE with an invalid argument should return a 504 reply.

   -    Bidirectional FTP

      The FTP specification allows an implementation in which data
      transfer takes place in both directions simultaneously, although
      few if any implementations support this.  Perhaps HR-AS should
      take a stand for or against this.




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


   SMTP Requirements:

   -    Offline SEND

      Some on the working group felt that the SMTP SEND command,
      intended to display a message immediately on the recipient's
      terminal, should produce an error message if delivery must be
      deferred.

   -    Header-like Fields

   John Klensin proposed:

      "Header-like fields whose keywords do not conform to RFC822 are
      strongly discouraged; gateways SHOULD filter them out or place
      them into the message body.  If, however, they are not removed,
      Internet hosts not acting as gateways SHOULD NOT utilize or
      inspect them.  Hence address-like subfields of those fields SHOULD
      NOT be altered by the gateway."

   -    Syntax of Received: Line

      The precise syntax of a revised Received: line (see Section 5.2.8
      of HR-AS) could be given.  An unresolved question concerned the
      use of "localhost" rather than a fully-qualified domain name in
      the FROM field of a Received: line.  Finally, new syntax was
      proposed for the Message Id field.

Appendix II -- Gateway Issues

   The working group identified a set of issues that should be
   considered when the Gateway Requirements RFC [RFC-1009] ("GR RFC") is
   revised.

   -    All-Subnets Broadcast

      This facility is not currently widely implemented, and HR-CL warns
      users of this fact.  The GR RFC should take a stand on whether or
      not gateways ought to implement the necessary routing.

   -    Rational Fragmentation

      When a gateway performs intentional fragmentation, it should make
      the first fragment as large as possible.

   -    Illegal Source Address

      It has been suggested that a gateway should not forward a packet



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


      containing an illegal IP source address, e.g., zero.

   -    Option Processing

      Specific rules should be given for the order of processing
      multiple options in the same IP header.  Two approaches have been
      used: to process options in the order presented, or to parse them
      all and then process them in some "canonical" order.

      The legality should also be defined for using broadcast or
      multicast addresses in IP options that include IP addresses.

Security Considerations

   A future revision of the Host Requirements RFCs should incorporate a
   more complete discussion of security issues at all layers.

Author's Address

   Robert Braden
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695

   Phone: [phone]

   EMail: [e-mail]
























Braden                                                         [Page 20]