home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1100s / rfc1127.txt < prev    next >
Text File  |  1989-11-16  |  40KB  |  1,123 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       R. Braden
  8. Request for Comments: 1127                                        ISI
  9.                                                          October 1989
  10.  
  11.  
  12.               A Perspective on the Host Requirements RFCs
  13.  
  14. Status of This Memo
  15.  
  16.    This RFC is for information only; it does not constitute a standard,
  17.    draft standard, or proposed standard, and it does not define a
  18.    protocol.  Distribution of this memo is unlimited.
  19.  
  20. Summary
  21.  
  22.    This RFC contains an informal summary of the discussions and
  23.    conclusions of the IETF Working Group on Host Requirements while it
  24.    was preparing the Host Requirements RFCs.  This summary has several
  25.    purposes: (1) to inform the community of host protocol issues that
  26.    need further work; (2) to preserve some history and context as a
  27.    starting point for future revision efforts; and (3) to provide some
  28.    insight into the results of the Host Requirements effort.
  29.  
  30. 1.  INTRODUCTION
  31.  
  32.    A working group of the Internet Engineering Task Force (IETF) has
  33.    recently completed and published a monumental standards document on
  34.    software requirements for Internet hosts [RFC-1122, RFC-1123].  This
  35.    document has been published as two RFC's: "Requirements for Internet
  36.    Hosts -- Communication Layers", referred to here as "HR-CL", and
  37.    "Requirements for Internet Hosts -- Application and Support",
  38.    referred to here as "HR-AS".  Together, we refer to them as the Host
  39.    Requirements RFCs, or "HR RFCs".
  40.  
  41.    Creation of the Host Requirements document required the dedicated
  42.    efforts of about 20 Internet experts, with significant contributions
  43.    from another 20.  The Host Requirements working group held 7 formal
  44.    meetings over the past 20 months, and exchanged about 3 megabytes of
  45.    electronic mail.  The HR RFCs went through approximate 20 distinct
  46.    drafts.
  47.  
  48.    This group of people struggled with a broad range of issues in host
  49.    implementations of the Internet protocols, attempting to reconcile
  50.    theoretical and architectural concerns with the sometimes conflicting
  51.    imperatives of the real world.  The present RFC recaps the results of
  52.    this struggle, with the issues that were settled and those that
  53.    remain for future work.  This exegesis has several goals:
  54.  
  55.  
  56.  
  57.  
  58. Braden                                                          [Page 1]
  59.  
  60. RFC 1127           Perspective on Host Requirements         October 1989
  61.  
  62.  
  63.    (1)  to give the Internet technical community some insight into the
  64.         results of the host requirements effort;
  65.  
  66.    (2)  to inform the community of areas that need further work; and
  67.  
  68.    (3)  to preserve some history and context of the effort as a starting
  69.         point for a future revision.
  70.  
  71. 1.1  GOALS OF THE HOST REQUIREMENTS RFCs
  72.  
  73.    The basic purpose of the Host Requirements RFCs is to define the
  74.    requirements for Internet host software.  However, the document goes
  75.    far beyond a simple prescription of requirements, to include:
  76.  
  77.    (a)  a bibliography of the documents essential to an implementor;
  78.  
  79.    (b)  corrections and updates to the original standards RFC's;
  80.  
  81.    (c)  material to fill gaps in the previous specifications;
  82.  
  83.    (d)  limitations on implementation choices, where appropriate;
  84.  
  85.    (e)  clarification of important issues and the intent of the
  86.         protocols; and
  87.  
  88.    (f)  documentation of known solutions to recurring problems as well
  89.         as implementation hints.
  90.  
  91.    Broadly speaking, the Host Requirements working group started from
  92.    the following goals for Internet host software:
  93.  
  94.    (1)  Interoperability
  95.  
  96.    (2)  Extensibility
  97.  
  98.    (3)  Functionality
  99.  
  100.    (4)  Efficiency
  101.  
  102.    (5)  Architectural Purity
  103.  
  104.    Of these, interoperability was clearly preeminent, while
  105.    architectural purity had the lowest priority.  It is more difficult
  106.    to assign relative importance to extensibility, functionality, and
  107.    efficiency, as it varied from one topic to another.
  108.  
  109.    At a more technical level, the working group pursued a set of general
  110.    goals that included the following:
  111.  
  112.  
  113.  
  114. Braden                                                          [Page 2]
  115.  
  116. RFC 1127           Perspective on Host Requirements         October 1989
  117.  
  118.  
  119.    *    Discourage hosts from unexpectedly acting as gateways.
  120.  
  121.    *    Discourage the use of bad IP addresses.
  122.  
  123.    *    Eliminate broadcast storms.
  124.  
  125.    *    Discourage gratuitous Address Mask Reply messages.
  126.  
  127.    *    Facilitate the use IP Type-of-Service for routing and queueing.
  128.  
  129.    *    Encourage implementations of IP multicasting.
  130.  
  131.    *    Encourage TCP connection robustness.
  132.  
  133.    *    Encourage (mandate!) implementation of known TCP performance
  134.         enhancements.
  135.  
  136.    *    Encourage user interfaces that support the full capabilities of
  137.         the protocols.
  138.  
  139.    *    Encourage more complete implementations of FTP.
  140.  
  141.    *    Encourage robust mail delivery
  142.  
  143.    *    Discourage the source-routing of mail in the Internet.
  144.  
  145.    *    Encourage error logging.
  146.  
  147.    In addition to these general technical goals, the working group
  148.    decided to discourage the use of certain protocol features: e.g., the
  149.    IP Stream Id option, ICMP Information Request and Reply messages, the
  150.    RFC-795 TOS mappings, WKS records in the Domain Name System, and FTP
  151.    Page structure.
  152.  
  153.    The HR RFC tries to deal only with the software implementation, not
  154.    with the way in which that software is configured and applied.  There
  155.    are a number of requirements on Internet hosts that were omitted from
  156.    the HR RFC as administrative or configuration issues.
  157.  
  158.    The HR RFCs contain many, many detailed requirements and
  159.    clarifications that are straightforward and (almost) non-
  160.    controversial.
  161.  
  162.    Indeed, many of these are simply restatements or reinforcement of
  163.    requirements that are already explicit or implicit in the original
  164.    standards RFC's.  Some more cynical members of the working group
  165.    refer to these as "Read The Manual" provisions.  However, they were
  166.    included in the HR RFCs because at least one implementation has
  167.  
  168.  
  169.  
  170. Braden                                                          [Page 3]
  171.  
  172. RFC 1127           Perspective on Host Requirements         October 1989
  173.  
  174.  
  175.    failed to abide by these requirements.  In addition, many provisions
  176.    of the HR RFCs are simply applications of Jon Postel's Robustness
  177.    Principle [1.2.2 in either RFC].
  178.  
  179.    However, not all issues were so easy; the working group struggled
  180.    with a number of deep and controversial technical issues.  Where the
  181.    result was a reasonable consensus, then definite, firm
  182.    recommendations and requirements resulted.  We list these settled
  183.    issues in Section 2.  Section 2 also lists a number of areas where
  184.    the HR RFCs fill gaping holes in the current specifications by giving
  185.    extended discussions of particular issues.
  186.  
  187.    However, in some other cases the working group was unable to reach a
  188.    crisp decision or even a reasonable consensus; we list these open
  189.    issues in Section 3.  Future discussion is needed to ascertain which
  190.    of these issues really do have "right answers", and which can
  191.    reasonably be left as implementation choices.  Section 4 contains
  192.    some other areas that the working group did not tackle but which need
  193.    further work outside the context of the HR RFCs (although the outcome
  194.    may be reflected in a future revision).  Finally, Appendix I lists
  195.    specific issues for consideration by a future HR RFC revision effort,
  196.    while Appendix II lists the issues that are relevant to a revision of
  197.    the Gateway Requirements RFC.
  198.  
  199.    It should be noted that this categorization of issues is imperfect; a
  200.    few issues appear (legitimately) in more than one category.
  201.  
  202.    For brevity, we do not attempt to define all the terminology or
  203.    explain all the concepts mentioned here.  For those cases where
  204.    further clarification is needed, we include (in square brackets)
  205.    references to the corresponding sections of the HR RFCs.
  206.  
  207. 2.  SETTLED ISSUES
  208.  
  209.    Here are the areas in which the Host Requirements working group was
  210.    able to reach a consensus and take a definite stand.
  211.  
  212.    -    ARP Cache Management   [CL 2.3.2.1]
  213.  
  214.         Require a mechanism to flush out-of-date ARP cache entries.
  215.  
  216.    -    Queueing packets in ARP   [CL 2.3.2.2]
  217.  
  218.         Recommend that ARP queue unresolved packet(s) in the link layer.
  219.  
  220.    -    Ethernet/802.3 Interoperability   [CL 2.3.3]
  221.  
  222.         Impose interoperability requirements for Ethernet and IEEE 802.3
  223.  
  224.  
  225.  
  226. Braden                                                          [Page 4]
  227.  
  228. RFC 1127           Perspective on Host Requirements         October 1989
  229.  
  230.  
  231.         encapsulation.
  232.  
  233.    -    Broadcast Storms   [CL 2.4, 3.2.2]
  234.  
  235.         Require many provisions to prevent broadcast storms.
  236.  
  237.         In particular, require that the link-layer driver pass a flag to
  238.         the IP layer to indicate if a packet was received via a link-
  239.         layer broadcast, and require that this flag be used by the IP
  240.         layer.
  241.  
  242.    -    Bad IP addresses
  243.  
  244.         Include numerous provisions to discourage the use of bad IP
  245.         addresses.
  246.  
  247.    -    Address Mask Replies   [CL 3.2.2.9]
  248.  
  249.         Discourage gratuitous ICMP Address Mask Reply messages.
  250.  
  251.    -    Type-of-Service
  252.  
  253.         Include various requirements on IP, transport, and application
  254.         layers to make Type-of-Service (TOS) useful.
  255.  
  256.    -    Time-to-Live   [CL 3.2.1.7]
  257.  
  258.         Require that Time-to-Live (TTL) be configurable.
  259.  
  260.    -    Source Routing   [CL 3.2.1.8(e)]
  261.  
  262.         Require that host be able to act as originator or final
  263.         destination of a source route.
  264.  
  265.    -    IP Multicasting   [CL 3.3.7]
  266.  
  267.         Encourage implementation of local IP multicasting.
  268.  
  269.    -    Reassembly Timeout   [CL 3.3.2]
  270.  
  271.         Require a fixed reassembly timeout.
  272.  
  273.    -    Choosing a Source Address   [CL 3.3.4.3, 3.4, 4.1.3.5, 4.2.3.7]
  274.  
  275.         Require that an application on a multihomed host be able to
  276.         either specify which local IP address to use for a new TCP
  277.         connection or UDP request, or else leave the local address
  278.         "wild" and let the IP layer pick one.
  279.  
  280.  
  281.  
  282. Braden                                                          [Page 5]
  283.  
  284. RFC 1127           Perspective on Host Requirements         October 1989
  285.  
  286.  
  287.    -    TCP Performance   [CL 4.2.12.15, 4.2.3.1-4]
  288.  
  289.         Require TCP performance improvements.
  290.  
  291.    -    TCP Connection Robustness   [CL 4.2.3.5, 4.2.3.9]
  292.  
  293.         Encourage robustness of TCP connections.
  294.  
  295.    -    TCP Window Shrinking   [CL 4.2.2.16]
  296.  
  297.         Discourage the shrinking of TCP windows from the right.
  298.  
  299.    -    Dotted-Decimal Host Numbers   [AS 2.1]
  300.  
  301.         Recommend that applications be able to accept dotted-decimal
  302.         host numbers in place of host names.
  303.  
  304.    -    Telnet End-of-Line   [AS 3.3.1]
  305.  
  306.         Include compatibility requirements for Telnet end-of-line.
  307.  
  308.    -    Minimal FTP   [AS 4.1.2.13]
  309.  
  310.         Enlarge the minimum FTP implementation.
  311.  
  312.    -    Robust Mail Delivery   [AS 5.3.2, 5.3.4, 6.1.3.4]
  313.  
  314.         Recommend the use of long timeouts and of alternative addresses
  315.         for multihomed hosts, to obtain robust mail delivery.
  316.  
  317.    -    Source-Routing of Mail  [AS 5.2.6, 5.2.16, 5.2.19]
  318.  
  319.         Discourage the use of source routes for delivering mail.  (This
  320.         was one of the few cases where the working group opted for the
  321.         architecturally pure resolution of an issue.)
  322.  
  323.    -    Fully-Qualified Domain Names   [AS 5.2.18]
  324.  
  325.         Require the use of fully-qualified domain names in RFC-822
  326.         addresses.
  327.  
  328.    -    Domain Name System Required   [AS 6.1.1]
  329.  
  330.         Require that hosts implement the Domain Name System (DNS).
  331.  
  332.    -    WKS Records Detracted   [AS 2.2, 5.2.12, 6.1.3.6]
  333.  
  334.         Recommend against using WKS records from DNS.
  335.  
  336.  
  337.  
  338. Braden                                                          [Page 6]
  339.  
  340. RFC 1127           Perspective on Host Requirements         October 1989
  341.  
  342.  
  343.    -    UDP Preferred for DNS Queries  [AS 6.1.2.4, 6.1.3.2]
  344.  
  345.         Require that UDP be preferred over TCP for DNS queries.
  346.  
  347.    -    DNS Negative Caching  [AS 6.1.3.3]
  348.  
  349.         Recommend that DNS name servers and resolvers cache negative
  350.         responses and temporary failures.
  351.  
  352.    Finally, here is a list of areas in which the HR RFCs provide
  353.    extended discussion of issues that have been inadequately documented
  354.    in the past.
  355.  
  356.    -    ARP cache handling   [CL 2.3.2.1]
  357.  
  358.    -    Trailer encapsulation   [CL 2.3.1]
  359.  
  360.    -    Dead gateway detection algorithms   [CL 3.3.1.4]
  361.  
  362.    -    IP multihoming models   [CL 3.3.4]
  363.  
  364.         (Note that this topic is also one of the significant contentious
  365.         issues; see the next section.)
  366.  
  367.    -    Maximum transmission unit (MTU and transport-layer maximum-
  368.         segment size (MSS) issues   [CL 3.3.2, 3.3.3, 3.4, 4.1.4,
  369.         4.2.2.6]
  370.  
  371.    -    TCP silly-window syndrome (SWS) avoidance algorithms
  372.         [CL 4.2.3.3, 4.2.3.4]
  373.  
  374.    -    Telnet end-of-line issues   [AS 3.3.1]
  375.  
  376.    -    Telnet interrupt/SYNCH usage   [AS 3.2.4]
  377.  
  378.    -    FTP restart facility   [AS 4.1.3.4]
  379.  
  380.    -    DNS efficiency issues   [AS 6.1.3.3]
  381.  
  382.    -    DNS user interface: aliases and search lists   [AS 6.1.4.3]
  383.  
  384.    There are some other areas where the working group tried to produce a
  385.    more extended discussion but was not totally successful; one example
  386.    is error logging (see Appendix I below).
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Braden                                                          [Page 7]
  395.  
  396. RFC 1127           Perspective on Host Requirements         October 1989
  397.  
  398.  
  399. 3.  OPEN ISSUES
  400.  
  401.    For some issues, the disagreement was so serious that the working
  402.    group was unable to reach a consensus.  In each case, some spoke for
  403.    MUST or SHOULD, while others spoke with equal fervor for MUST NOT or
  404.    SHOULD NOT.  As a result, the HR RFCs try to summarize the differing
  405.    viewpoints but take no stand; the corresponding requirements are
  406.    given as MAY or OPTIONAL.  The most notorious of these contentious
  407.    issues are as follows.
  408.  
  409.    -    Hosts forwarding source-routed datagrams, even though the hosts
  410.         are not otherwise acting as gateways   [CL 3.3.5]
  411.  
  412.    -    The multihoming model   [CL 3.3.4]
  413.  
  414.    -    ICMP Echo Requests to a broadcast or multicast address
  415.         [CL 3.2.2.6]
  416.  
  417.    -    Host-only route caching   [CL 3.3.1.3]
  418.  
  419.    -    Host wiretapping routing protocols   [CL 3.3.1.4]
  420.  
  421.    -    TCP sending an ACK when it receives a segment that appears to be
  422.         out-of-order   [CL 4.2.2.21]
  423.  
  424.  
  425.    There was another set of controversial issues for which the HR RFCs
  426.    did take a compromise stand, to allow the disputed functions but
  427.    circumscribe their use.  In many of these cases, there were one or
  428.    more significant voices for banning the feature altogether.
  429.  
  430.    -    Host acting as gateways   [CL 3.1]
  431.  
  432.    -    Trailer encapsulation   [CL 2.3.1]
  433.  
  434.    -    Delayed TCP acknowledgments   [CL 4.2.3.2]
  435.  
  436.    -    TCP Keep-alives   [CL 4.2.3.6]
  437.  
  438.    -    Ignoring UDP checksums   [CL 4.1.3.4]
  439.  
  440.    -    Telnet Go-Aheads   [AS 3.2.2]
  441.  
  442.    -    Allowing 8-bit data in Telnet NVT mode   [AS 3.2.5]
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Braden                                                          [Page 8]
  451.  
  452. RFC 1127           Perspective on Host Requirements         October 1989
  453.  
  454.  
  455. 4.  OTHER FUTURE WORK
  456.  
  457.    General Issues:
  458.  
  459.    (1)  Host Initialization Procedures
  460.  
  461.       When a host system boots or otherwise initializes, it needs
  462.       certain network configuration information in order to communicate;
  463.       e.g., its own IP address(es) and address mask(s).  In the case of
  464.       a diskless workstation, obtaining this information is an essential
  465.       part of the booting process.
  466.  
  467.       The ICMP Address Mask messages and the RARP (Reverse ARP) protocol
  468.       each provide individual pieces of configuration information.  The
  469.       working group felt that such piecemeal solutions are a mistake,
  470.       and that a comprehensive approach to initialization would result
  471.       in a uniform mechanism to provide all the required configuration
  472.       information at once.  The HR working group recommends that a new
  473.       working group be established to develop a unified approach to
  474.       system initialization.
  475.  
  476.    (2)  Configuration Options
  477.  
  478.       Vendors, users, and network administrators all want host software
  479.       that is "plug-and-play".  Unfortunately, the working group was
  480.       often forced to require additional configuration parameters to
  481.       satisfy interoperability, functionality, and/or efficiency needs
  482.       [1.2.4 in either RFC].  The working group was fully aware of the
  483.       drawbacks of configuration parameters, but based upon extensive
  484.       experience with existing implementations, it felt that the
  485.       flexibility was sometimes more important than installation
  486.       simplicity.
  487.  
  488.       Some of the configuration parameters are forced for
  489.       interoperability with earlier, incorrect implementations.  Very
  490.       little can be done to ease this problem, although retirement of
  491.       the offending systems will gradually solve it.  However, it would
  492.       be desirable to re-examine the other required configuration
  493.       options, in an attempt to develop ways to eliminate some of them.
  494.  
  495.    Link-Layer Issues:
  496.  
  497.    (2)  ARP Cache Maintenance
  498.  
  499.       "Proxy ARP" is a link-layer mechanism for IP routing, and its use
  500.       results in difficult problems in managing the ARP cache.
  501.  
  502.       Even without proxy ARP, the management dynamics of the IP route
  503.  
  504.  
  505.  
  506. Braden                                                          [Page 9]
  507.  
  508. RFC 1127           Perspective on Host Requirements         October 1989
  509.  
  510.  
  511.       cache interact in subtle ways with transport-layer dynamics;
  512.       introducing routing via proxy ARP brings a third protocol layer
  513.       into the problem, complicating the inter-layer dynamics still
  514.       further.
  515.  
  516.       The algorithms for maintaining the ARP cache need to be studied
  517.       and experimented with, to create more complete and explicit
  518.       algorithms and requirements.
  519.  
  520.    (3)  FDDI Bit-order in MAC addresses
  521.  
  522.       On IEEE 802.3 or 802.4 LAN, the MAC address in the header uses the
  523.       same bit-ordering as transmission of the address as data.  On
  524.       802.5 and FDDI networks, however, the MAC address in the header is
  525.       in a different bit-ordering from the equivalent 6 bytes sent as
  526.       data.  This will make it hard to do MAC-level bridging between
  527.       FDDI and 802.3 LAN's, for example, although gateways (IP routers)
  528.       can still be used.
  529.  
  530.       The working group concluded that this is a serious but subtle
  531.       problem with no obvious fix, and that resolving it was beyond the
  532.       scope of the HR working group.
  533.  
  534.    IP-Layer Issues
  535.  
  536.    (4)  Dead Gateway Detection
  537.  
  538.       A fundamental requirement for a host is to be able to detect when
  539.       the first-hop gateway has failed.  The early TCP/IP
  540.       experimentation was based on the ARPANET, which provided explicit
  541.       notification of gateway failure; as a result, dead gateway
  542.       detection algorithms were not much considered at that time.  The
  543.       very general guidelines presented by Dave Clark [RFC-816] are
  544.       inadequate for implementors.  The first attempt at applying these
  545.       guidelines was the introduction of universal gateway pinging by
  546.       TOPS-20 systems; this quickly proved to be a major generator of
  547.       ARPANET traffic, and was squelched.  The most widely used
  548.       implementation of the Internet protocols, 4.2BSD, solved the
  549.       problem in an extra-architectural manner, by letting the host
  550.       wiretap the gateway routing protocol (RIP).  As a result of this
  551.       history, the HR working group was faced with an absence of
  552.       documentated techniques that a host conforming to the Internet
  553.       architecture could use to detect dead gateways.
  554.  
  555.       After extensive discussion, the working group agreed on the
  556.       outline of an appropriate algorithm.  A detailed algorithm was in
  557.       fact written down, to validate the discussion in the HR RFCs.
  558.       This algorithm, or a better one, should be tried experimentally
  559.  
  560.  
  561.  
  562. Braden                                                         [Page 10]
  563.  
  564. RFC 1127           Perspective on Host Requirements         October 1989
  565.  
  566.  
  567.       and documented in a new RFC.
  568.  
  569.    (5)  Gateway Discovery
  570.  
  571.       A host needs to discover the IP addresses of gateways on its
  572.       connected networks.  One approach, begun but not finished by
  573.       members of the HR working group, would be to define a new pair of
  574.       ICMP query messages for gateway discovery.  In the future, gateway
  575.       discovery should be considered as part of the complete host
  576.       initialization problem.
  577.  
  578.    (6)  MTU Discovery
  579.  
  580.       Members of the HR working group designed IP options that a host
  581.       could use to discover the minimum MTU of a particular Internet
  582.       path [RFC-1063].  To be useful, the Probe MTU options would have
  583.       to be implemented in all gateways, which is an obstacle to its
  584.       adoption.  Code written to use these options has never been
  585.       tested.  This work should be carried forward; an effective MTU
  586.       choice will become increasingly important for efficient Internet
  587.       service.
  588.  
  589.    (7)  Routing Advice from Gateways
  590.  
  591.       A working group member produced a draft specification for ICMP
  592.       messages a host could use to ask gateways for routing advice
  593.       [Lekashman].  While this is not of such pressing importance as the
  594.       issues listed previously, it deserves further consideration and
  595.       perhaps experimentation.
  596.  
  597.    (8)  Dynamic TTL Discovery
  598.  
  599.       Serious connectivity problems have resulted from host software
  600.       that has too small a TTL value built into the code.  HR-CL
  601.       specifies that TTL values must be configurable, to allow TTL to be
  602.       increased if required for communication in a future Internet;
  603.       conformance with this requirement would solve the current
  604.       problems.  However, configurable parameters are an operational
  605.       headache, so it has been suggested that a host could have an
  606.       algorithm to determine the TTL ("Internet diameter") dynamically.
  607.       Several algorithms have been suggested, but considerably more work
  608.       would be required to validate them.  This is a lower-priority
  609.       problem than issues (4)-(6).
  610.  
  611.    (9)  Dynamic Discovery of Reassembly Timeout Time
  612.  
  613.       The maximum time for retaining a partially-reassembled datagram is
  614.       another parameter that creates a potential operational headache.
  615.  
  616.  
  617.  
  618. Braden                                                         [Page 11]
  619.  
  620. RFC 1127           Perspective on Host Requirements         October 1989
  621.  
  622.  
  623.       An appropriate reassembly timeout value must balance available
  624.       reassembly buffer space against reliable reassembly.  The best
  625.       value thus may depend upon the system and upon subtle delay
  626.       properties (delay dispersion) of the Internet.  Again, dynamic
  627.       discovery could be desirable.
  628.  
  629.    (10) Type-of-Service Routing in Hosts
  630.  
  631.       As pointed out previously, the HR RFCs contain a number of
  632.       provisions designed to make Type-of-Service (TOS) useful.  This
  633.       includes the suggestion that the route cache should have a place
  634.       or specifying the TOS of a particular route.  However, host
  635.       algorithms for using TOS specifications need to be developed and
  636.       documented.
  637.  
  638.    (11) Using Subnets
  639.  
  640.       An RFC is needed to provide a thorough explanation of the
  641.       implications of subnetting for Internet protocols and for network
  642.       administration.
  643.  
  644.    Transport-Layer Issues:
  645.  
  646.    (12) RST Message
  647.  
  648.       It has been proposed that TCP RST (Reset) segments can contain
  649.       text to provide an explicit explanation of the reason for the
  650.       particular RST.  A proposal has been drafted [CLynn].
  651.  
  652.    (13) Performance Algorithms
  653.  
  654.       HR-CL contains a number of requirements on TCP performance
  655.       algorithms; Van Jacobson's slow start and congestion avoidance,
  656.       Karn's algorithm, Nagle's algorithm, and SWS prevention at the
  657.       sender and receiver.  Implementors of new TCPs really need more
  658.       guidance than could possibly be included in the HR RFCs.  The
  659.       working group suggested that an RFC on TCP performance is needed,
  660.       to describe each of these issues more deeply and especially to
  661.       explain how they fit together.
  662.  
  663.       Another issue raised by the HR RFCs is the need for validation (or
  664.       rejection) of Van Jacobson's fast retransmit algorithm.
  665.  
  666.    Application-Layer Issues:
  667.  
  668.    (14) Proposed FTP extensions
  669.  
  670.       A number of minor extensions proposed for FTP should be processed
  671.  
  672.  
  673.  
  674. Braden                                                         [Page 12]
  675.  
  676. RFC 1127           Perspective on Host Requirements         October 1989
  677.  
  678.  
  679.       and accepted or rejected.  We are aware of the following
  680.       proposals:
  681.  
  682.       (a)  Atomic Store Command
  683.  
  684.          The FTP specification leaves undefined the disposition of a
  685.          partial file created when an FTP session fails during a store
  686.          operation.  It was suggested that this ambiguity could be
  687.          resolved by defining a new store command, Store Atomic (STOA).
  688.          The receiver would delete the partial file if the transfer
  689.          failed before the final data-complete reply had been sent.
  690.          This assumes the use of a transfer mode (e.g., block) in which
  691.          end-of-file can be distinguished from TCP connection failure,
  692.          of course.
  693.  
  694.       (b)  NDIR Command
  695.  
  696.          "NDIR would be a directories-only analogue to the NLST command.
  697.          Upon receiving an NDIR command an FTP server would return a
  698.          list of the subdirectories to the specified directory or file
  699.          group; or of the current directory if no argument was sent.
  700.          ... The existing NLST command allows user FTPs to implement
  701.          user-interface niceties such as a "multiple get" command.  It
  702.          also allows a selective (as opposed to generative) file-naming
  703.          user interface: the user can pick the desired file out of a
  704.          list instead of typing its name." [Matthews]
  705.  
  706.          However, the interface needs to distinguish files from
  707.          directories.  Up to now, such interfaces have relied on a bug
  708.          in many FTP servers, which have included directory names in the
  709.          list returned by NLST.  As hosts come into conformance with
  710.          HR-AS, we need an NDIR command to return directory names.
  711.  
  712.       (c)  Adaptive Compression
  713.  
  714.          It has been suggested that a sophisticated adaptive data
  715.          compression algorithm, like that provided by the Unix
  716.          "compress" command, should be added as an alternative FTP
  717.          transfer mode.
  718.  
  719.    (15) SMTP: Global Mail Addressing
  720.  
  721.       While writing requirements for electronic mail, the working group
  722.       was urged to set rules for SMTP and RFC-822 that would be
  723.       universal, applicable not only to the Internet environment but
  724.       also to the other mail environments that use one or both of these
  725.       protocols.  The working group chose to ignore this Siren call, and
  726.       instead limit the HR RFC to requirements specific to the Internet.
  727.  
  728.  
  729.  
  730. Braden                                                         [Page 13]
  731.  
  732. RFC 1127           Perspective on Host Requirements         October 1989
  733.  
  734.  
  735.       However, the networking world would certainly benefit from some
  736.       global agreements on mail routing.  Strong passions are lurking
  737.       here.
  738.  
  739.    (16) DNS: Fully Replacing hosts.txt
  740.  
  741.       As noted in HR-AS [AS 6.1.3.8], the DNS does not yet incorporate
  742.       all the potentially-useful information included in the DDN NIC's
  743.       hosts.txt file.  The DNS should be expanded to cover the hosts.txt
  744.       information.  RFC-1101 [RFC-1101] is a step in the right
  745.       direction, but more work is needed.
  746.  
  747. 5.  SUMMARY
  748.  
  749.    We have summarized the results of the Host Requirements Working
  750.    Group, and listed a set of issues in Internet host protocols that
  751.    need future effort.
  752.  
  753. 6.  REFERENCES
  754.  
  755.    [RFC-1122]  Braden, R., Editor, "Requirements for Internet Hosts --
  756.    Communications Layers", RFC 1122, IETF Host Requirements Working
  757.    Group, October 1989.
  758.  
  759.    [RFC-1123]  Braden, R., Editor, "Requirements for Internet Hosts --
  760.    Application and Support", RFC 1123, IETF Host Requirements Working
  761.    Group, October 1989.
  762.  
  763.    [RFC-1009]  Braden, R., and J. Postel, "Requirements for Internet
  764.    Gateways", RFC 1009, USC/Information Sciences Institute, June 1987.
  765.  
  766.    [RFC-1101]  Mockapetris, P., "DNS Encoding of Network Names and Other
  767.    Types", RFC 1101, USC/Information Sciences Institute, April 1989.
  768.  
  769.    [RFC-1063]  Mogul, J., C. Kent, C. Partridge, and K. McCloghrie, "IP
  770.    MTU Discovery Options", RFC-1063, DEC, BBN, & TWG, July 1988.
  771.  
  772.    [RFC-816]  Clark, D., "Fault Isolation and Recovery", RFC-816, MIT,
  773.    July 1982.
  774.  
  775.    [CLynn]  Lynn, C., "Use of TCP Reset to Convey Error Diagnostics",
  776.    Internal Memo, BBN, December 1988.
  777.  
  778.    [Lekashman]  Message to ietf-hosts mailing list from John Lekashman,
  779.    14 September 1988.
  780.  
  781.    [Matthews]  Message to Postel from Jim Matthews, 3 August 1989.
  782.  
  783.  
  784.  
  785.  
  786. Braden                                                         [Page 14]
  787.  
  788. RFC 1127           Perspective on Host Requirements         October 1989
  789.  
  790.  
  791. APPENDIX I -- ISSUES FOR FUTURE REVISION
  792.  
  793.    In order to complete the HR RFCs, it was necessary to defer some
  794.    technical issues.  These issues should be considered by the parties
  795.    responsible for the first update of the HR RFCs.
  796.  
  797.    The issues pending at the time of publication are listed here, in
  798.    order by protocol layer.
  799.  
  800.    General Issue:
  801.  
  802.       Error Logging
  803.  
  804.       The working group felt that more complete and explicit guidance on
  805.       error logging procedures is needed than is presently contained in
  806.       Section 1.2.3 (both HR RFCs).
  807.  
  808.    Link Layer Issues:
  809.  
  810.    -    Stolen IP Address
  811.  
  812.       How should a host react when it detects through ARP traffic that
  813.       some other host has "stolen" its IP address?
  814.  
  815.    IP Layer Issues:
  816.  
  817.    -    "Raw Mode" Interface
  818.  
  819.       HR-CL could define an optional "raw mode" interface from the
  820.       application layer to IP.
  821.  
  822.    -    Rational Fragmentation
  823.  
  824.       When a host performs intentional fragmentation, it should make the
  825.       first fragment as large as possible (this same requirement should
  826.       be placed on gateways).
  827.  
  828.    -    Interaction of Multiple Options
  829.  
  830.       HR-CL does not give specific rules for the interactions of
  831.       multiple options in the same IP header; this issue was generally
  832.       deferred to a revision of the Gateway Requirements RFC.  However,
  833.       this issue might be revisited for hosts.
  834.  
  835.    -    ICMP Error for Source-Routed Packet
  836.  
  837.       It was suggested that when a source-routed packet arrives with an
  838.       error, any ICMP error message should be sent with the
  839.  
  840.  
  841.  
  842. Braden                                                         [Page 15]
  843.  
  844. RFC 1127           Perspective on Host Requirements         October 1989
  845.  
  846.  
  847.       corresponding return route.  This assumes that the ICMP error
  848.       message is more likely to be delivered successfully with the
  849.       source route than without it.
  850.  
  851.    -    "Strong" IP Options and ICMP Types
  852.  
  853.       The HR RFCs takes the general approach that a host should ignore
  854.       whatever it does not understand, so that possible future
  855.       extensions -- e.g., new IP options or new ICMP message types --
  856.       will cause minimum problems for existing hosts.  The result of
  857.       this approach is that when new facilities are used with old hosts,
  858.       a "black hole" can result.  Several people have suggested that
  859.       this is not always what is wanted; it may sometimes be more useful
  860.       to obtain an ICMP error message from the old host.  To quote
  861.       Jeremey Siegel:
  862.  
  863.          "The basic premise is that if an option is to have any real
  864.          meaning at all within an '[upward] compatible' environment, it
  865.          must be known whether or not the option actually *carries* its
  866.          meaning.  An absurd analogy might be programming languages: I
  867.          could make a compiler which simply ignored unknown sorts of
  868.          statements, thereby allowing for future expansion of the
  869.          language.
  870.  
  871.          Right now, there are four "classes" of options; only two are
  872.          defined.  Take one of the other classes, and define it such
  873.          that any options in that class, if unrecognized, cause an ICMP
  874.          error message.  Thus anyone who wants to propose a "strong"
  875.          option (one which requires full participation by all systems
  876.          involved to operate correctly) can assign it to that class.
  877.          Options in the current classes may still be passed through if
  878.          they are unknown; only "weak" options will be assigned to these
  879.          classes in the future."
  880.  
  881.    -    Network Mask
  882.  
  883.       As explained in HR-CL [CL 3.1.2.3], we believe that a possible
  884.       future transition for the interpretation of IP addresses may be
  885.       eased if hosts always treat an IP address as an indivisible 32-
  886.       bit number.  However, there are various circumstances where a host
  887.       has to distinguish its own network number.  Charlie Lynn has
  888.       suggested that indivisibility can be retained if a host is
  889.       configured with both an address mask (indicating subnetting) and a
  890.       network mask (with network but not subnet bits).
  891.  
  892.    -    WhoAmI Query
  893.  
  894.       The following requirement is needed: for a multihomed host, a
  895.  
  896.  
  897.  
  898. Braden                                                         [Page 16]
  899.  
  900. RFC 1127           Perspective on Host Requirements         October 1989
  901.  
  902.  
  903.       UDP-based application should (must?) be able to query the
  904.       communication layers to obtain a list of all local IP addresses
  905.       for the host.
  906.  
  907.    -    New Destination Unreachable codes
  908.  
  909.       For each of the new ICMP Destination Unreachable codes defined in
  910.       HR-CL [CL 3.2.2.1], it should be documented whether the error is
  911.       "soft" or "hard".
  912.  
  913.    -    ICMP Error Schizophrenia
  914.  
  915.       Section 3.3.8 of HR-CL requires a host to send ICMP error
  916.       messages, yet in nearly all individual cases the specific
  917.       requirements say that errors are to be silently ignored.  The
  918.       working group recognized this contradiction but was unwilling to
  919.       resolve it.
  920.  
  921.       At every choice point, the working group opted towards a
  922.       requirement that would avoid broadcast storms.  For example, (1)
  923.       ICMP errors cannot be sent for broadcasts, and also (2) individual
  924.       errors are to be silently ignored.  This is redundant; either
  925.       provision (1) or (2) alone, if followed, should eliminate
  926.       broadcast storms.  The general area of responses to errors and
  927.       broadcast storms could be reassessed and the individual decisions
  928.       reviewed.
  929.  
  930.    Transport-Layer Requirements:
  931.  
  932.    -    Delayed ACK Definition
  933.  
  934.       A more precise and complete definition of the conditions for
  935.       delaying a TCP ACK segment may be desirable; see Section 4.2.3.2
  936.       of HR-CL.
  937.  
  938.    Telnet Requirements:
  939.  
  940.    -    Flushing Output
  941.  
  942.       The DISCUSSION in Section 3.2.4 of HR-AS concerns three possible
  943.       ways for a User Telnet to flush output.  It would be helpful for
  944.       users and implementers if one of these could be recommended over
  945.       the others; however, when the working group discussed the matter,
  946.       there seemed to be compelling arguments for each choice.  This
  947.       issue needs more study.
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Braden                                                         [Page 17]
  955.  
  956. RFC 1127           Perspective on Host Requirements         October 1989
  957.  
  958.  
  959.    -    Telnet LineMode Option
  960.  
  961.       This important new option is still experimental, but when it
  962.       becomes a standard, implementation should become recommended or
  963.       required.
  964.  
  965.    FTP Requirements:
  966.  
  967.    -    Reply Codes
  968.  
  969.    A number of problems have been raised with FTP reply codes.
  970.  
  971.    (a)  Access Control Failures
  972.  
  973.       Note that a 550 message is used to indicate access control
  974.       problems for a read-type operation (e.g., RETR, RNFR), while a 553
  975.       message is used for the same purpose for a write-type operation
  976.       (e.g., STOR, STOU, RNTO).
  977.  
  978.       LIST, NLST, and STAT may fail with a 550 reply due to an access
  979.       control violation.
  980.  
  981.       MKD should fail with a 553 reply if a directory already exists
  982.       with the same name.
  983.  
  984.    (b)  Directory Operations (RFC-959 Appendix II)
  985.  
  986.       An RMD may result in a 450 reply if the directory is busy.
  987.  
  988.       Many of the reply codes shown in the text of Appendix II are
  989.       wrong.  A positive completion for CWD should be 250.  The 521 code
  990.       shown for MKD should be 553 (see above), while the 431 shown for
  991.       CWD should be a 550.
  992.  
  993.    (c)  HELP and SITE Commands
  994.  
  995.       The positive completion reply to a HELP command should be code
  996.       214.
  997.  
  998.       HELP or SITE with an invalid argument should return a 504 reply.
  999.  
  1000.    -    Bidirectional FTP
  1001.  
  1002.       The FTP specification allows an implementation in which data
  1003.       transfer takes place in both directions simultaneously, although
  1004.       few if any implementations support this.  Perhaps HR-AS should
  1005.       take a stand for or against this.
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Braden                                                         [Page 18]
  1011.  
  1012. RFC 1127           Perspective on Host Requirements         October 1989
  1013.  
  1014.  
  1015.    SMTP Requirements:
  1016.  
  1017.    -    Offline SEND
  1018.  
  1019.       Some on the working group felt that the SMTP SEND command,
  1020.       intended to display a message immediately on the recipient's
  1021.       terminal, should produce an error message if delivery must be
  1022.       deferred.
  1023.  
  1024.    -    Header-like Fields
  1025.  
  1026.    John Klensin proposed:
  1027.  
  1028.       "Header-like fields whose keywords do not conform to RFC822 are
  1029.       strongly discouraged; gateways SHOULD filter them out or place
  1030.       them into the message body.  If, however, they are not removed,
  1031.       Internet hosts not acting as gateways SHOULD NOT utilize or
  1032.       inspect them.  Hence address-like subfields of those fields SHOULD
  1033.       NOT be altered by the gateway."
  1034.  
  1035.    -    Syntax of Received: Line
  1036.  
  1037.       The precise syntax of a revised Received: line (see Section 5.2.8
  1038.       of HR-AS) could be given.  An unresolved question concerned the
  1039.       use of "localhost" rather than a fully-qualified domain name in
  1040.       the FROM field of a Received: line.  Finally, new syntax was
  1041.       proposed for the Message Id field.
  1042.  
  1043. Appendix II -- Gateway Issues
  1044.  
  1045.    The working group identified a set of issues that should be
  1046.    considered when the Gateway Requirements RFC [RFC-1009] ("GR RFC") is
  1047.    revised.
  1048.  
  1049.    -    All-Subnets Broadcast
  1050.  
  1051.       This facility is not currently widely implemented, and HR-CL warns
  1052.       users of this fact.  The GR RFC should take a stand on whether or
  1053.       not gateways ought to implement the necessary routing.
  1054.  
  1055.    -    Rational Fragmentation
  1056.  
  1057.       When a gateway performs intentional fragmentation, it should make
  1058.       the first fragment as large as possible.
  1059.  
  1060.    -    Illegal Source Address
  1061.  
  1062.       It has been suggested that a gateway should not forward a packet
  1063.  
  1064.  
  1065.  
  1066. Braden                                                         [Page 19]
  1067.  
  1068. RFC 1127           Perspective on Host Requirements         October 1989
  1069.  
  1070.  
  1071.       containing an illegal IP source address, e.g., zero.
  1072.  
  1073.    -    Option Processing
  1074.  
  1075.       Specific rules should be given for the order of processing
  1076.       multiple options in the same IP header.  Two approaches have been
  1077.       used: to process options in the order presented, or to parse them
  1078.       all and then process them in some "canonical" order.
  1079.  
  1080.       The legality should also be defined for using broadcast or
  1081.       multicast addresses in IP options that include IP addresses.
  1082.  
  1083. Security Considerations
  1084.  
  1085.    A future revision of the Host Requirements RFCs should incorporate a
  1086.    more complete discussion of security issues at all layers.
  1087.  
  1088. Author's Address
  1089.  
  1090.    Robert Braden
  1091.    USC/Information Sciences Institute
  1092.    4676 Admiralty Way
  1093.    Marina del Rey, CA 90292-6695
  1094.  
  1095.    Phone: (213) 822 1511
  1096.  
  1097.    EMail: Braden@ISI.EDU
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Braden                                                         [Page 20]
  1123.