rfc1127.txt

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

Network Working Group                                       R. Braden
Request for Comments: 1127                                        ISI
                                                         October 1989


              A Perspective on the Host Requirements RFCs

Status of This Memo

   This RFC is for information only; it does not constitute a standard,
   draft standard, or proposed standard, and it does not define a
   protocol.  Distribution of this memo is unlimited.

Summary

   This RFC contains an informal summary of the discussions and
   conclusions of the IETF Working Group on Host Requirements while it
   was preparing the Host Requirements RFCs.  This summary has several
   purposes: (1) to inform the community of host protocol issues that
   need further work; (2) to preserve some history and context as a
   starting point for future revision efforts; and (3) to provide some
   insight into the results of the Host Requirements effort.

1.  INTRODUCTION

   A working group of the Internet Engineering Task Force (IETF) has
   recently completed and published a monumental standards document on
   software requirements for Internet hosts [RFC-1122, RFC-1123].  This
   document has been published as two RFC's: "Requirements for Internet
   Hosts -- Communication Layers", referred to here as "HR-CL", and
   "Requirements for Internet Hosts -- Application and Support",
   referred to here as "HR-AS".  Together, we refer to them as the Host
   Requirements RFCs, or "HR RFCs".

   Creation of the Host Requirements document required the dedicated
   efforts of about 20 Internet experts, with significant contributions
   from another 20.  The Host Requirements working group held 7 formal
   meetings over the past 20 months, and exchanged about 3 megabytes of
   electronic mail.  The HR RFCs went through approximate 20 distinct
   drafts.

   This group of people struggled with a broad range of issues in host
   implementations of the Internet protocols, attempting to reconcile
   theoretical and architectural concerns with the sometimes conflicting
   imperatives of the real world.  The present RFC recaps the results of
   this struggle, with the issues that were settled and those that
   remain for future work.  This exegesis has several goals:




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


   (1)  to give the Internet technical community some insight into the
        results of the host requirements effort;

   (2)  to inform the community of areas that need further work; and

   (3)  to preserve some history and context of the effort as a starting
        point for a future revision.

1.1  GOALS OF THE HOST REQUIREMENTS RFCs

   The basic purpose of the Host Requirements RFCs is to define the
   requirements for Internet host software.  However, the document goes
   far beyond a simple prescription of requirements, to include:

   (a)  a bibliography of the documents essential to an implementor;

   (b)  corrections and updates to the original standards RFC's;

   (c)  material to fill gaps in the previous specifications;

   (d)  limitations on implementation choices, where appropriate;

   (e)  clarification of important issues and the intent of the
        protocols; and

   (f)  documentation of known solutions to recurring problems as well
        as implementation hints.

   Broadly speaking, the Host Requirements working group started from
   the following goals for Internet host software:

   (1)  Interoperability

   (2)  Extensibility

   (3)  Functionality

   (4)  Efficiency

   (5)  Architectural Purity

   Of these, interoperability was clearly preeminent, while
   architectural purity had the lowest priority.  It is more difficult
   to assign relative importance to extensibility, functionality, and
   efficiency, as it varied from one topic to another.

   At a more technical level, the working group pursued a set of general
   goals that included the following:



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


   *    Discourage hosts from unexpectedly acting as gateways.

   *    Discourage the use of bad IP addresses.

   *    Eliminate broadcast storms.

   *    Discourage gratuitous Address Mask Reply messages.

   *    Facilitate the use IP Type-of-Service for routing and queueing.

   *    Encourage implementations of IP multicasting.

   *    Encourage TCP connection robustness.

   *    Encourage (mandate!) implementation of known TCP performance
        enhancements.

   *    Encourage user interfaces that support the full capabilities of
        the protocols.

   *    Encourage more complete implementations of FTP.

   *    Encourage robust mail delivery

   *    Discourage the source-routing of mail in the Internet.

   *    Encourage error logging.

   In addition to these general technical goals, the working group
   decided to discourage the use of certain protocol features: e.g., the
   IP Stream Id option, ICMP Information Request and Reply messages, the
   RFC-795 TOS mappings, WKS records in the Domain Name System, and FTP
   Page structure.

   The HR RFC tries to deal only with the software implementation, not
   with the way in which that software is configured and applied.  There
   are a number of requirements on Internet hosts that were omitted from
   the HR RFC as administrative or configuration issues.

   The HR RFCs contain many, many detailed requirements and
   clarifications that are straightforward and (almost) non-
   controversial.

   Indeed, many of these are simply restatements or reinforcement of
   requirements that are already explicit or implicit in the original
   standards RFC's.  Some more cynical members of the working group
   refer to these as "Read The Manual" provisions.  However, they were
   included in the HR RFCs because at least one implementation has



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


   failed to abide by these requirements.  In addition, many provisions
   of the HR RFCs are simply applications of Jon Postel's Robustness
   Principle [1.2.2 in either RFC].

   However, not all issues were so easy; the working group struggled
   with a number of deep and controversial technical issues.  Where the
   result was a reasonable consensus, then definite, firm
   recommendations and requirements resulted.  We list these settled
   issues in Section 2.  Section 2 also lists a number of areas where
   the HR RFCs fill gaping holes in the current specifications by giving
   extended discussions of particular issues.

   However, in some other cases the working group was unable to reach a
   crisp decision or even a reasonable consensus; we list these open
   issues in Section 3.  Future discussion is needed to ascertain which
   of these issues really do have "right answers", and which can
   reasonably be left as implementation choices.  Section 4 contains
   some other areas that the working group did not tackle but which need
   further work outside the context of the HR RFCs (although the outcome
   may be reflected in a future revision).  Finally, Appendix I lists
   specific issues for consideration by a future HR RFC revision effort,
   while Appendix II lists the issues that are relevant to a revision of
   the Gateway Requirements RFC.

   It should be noted that this categorization of issues is imperfect; a
   few issues appear (legitimately) in more than one category.

   For brevity, we do not attempt to define all the terminology or
   explain all the concepts mentioned here.  For those cases where
   further clarification is needed, we include (in square brackets)
   references to the corresponding sections of the HR RFCs.

2.  SETTLED ISSUES

   Here are the areas in which the Host Requirements working group was
   able to reach a consensus and take a definite stand.

   -    ARP Cache Management   [CL 2.3.2.1]

        Require a mechanism to flush out-of-date ARP cache entries.

   -    Queueing packets in ARP   [CL 2.3.2.2]

        Recommend that ARP queue unresolved packet(s) in the link layer.

   -    Ethernet/802.3 Interoperability   [CL 2.3.3]

        Impose interoperability requirements for Ethernet and IEEE 802.3



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


        encapsulation.

   -    Broadcast Storms   [CL 2.4, 3.2.2]

        Require many provisions to prevent broadcast storms.

        In particular, require that the link-layer driver pass a flag to
        the IP layer to indicate if a packet was received via a link-
        layer broadcast, and require that this flag be used by the IP
        layer.

   -    Bad IP addresses

        Include numerous provisions to discourage the use of bad IP
        addresses.

   -    Address Mask Replies   [CL 3.2.2.9]

        Discourage gratuitous ICMP Address Mask Reply messages.

   -    Type-of-Service

        Include various requirements on IP, transport, and application
        layers to make Type-of-Service (TOS) useful.

   -    Time-to-Live   [CL 3.2.1.7]

        Require that Time-to-Live (TTL) be configurable.

   -    Source Routing   [CL 3.2.1.8(e)]

        Require that host be able to act as originator or final
        destination of a source route.

   -    IP Multicasting   [CL 3.3.7]

        Encourage implementation of local IP multicasting.

   -    Reassembly Timeout   [CL 3.3.2]

        Require a fixed reassembly timeout.

   -    Choosing a Source Address   [CL 3.3.4.3, 3.4, 4.1.3.5, 4.2.3.7]

        Require that an application on a multihomed host be able to
        either specify which local IP address to use for a new TCP
        connection or UDP request, or else leave the local address
        "wild" and let the IP layer pick one.



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


   -    TCP Performance   [CL 4.2.12.15, 4.2.3.1-4]

        Require TCP performance improvements.

   -    TCP Connection Robustness   [CL 4.2.3.5, 4.2.3.9]

        Encourage robustness of TCP connections.

   -    TCP Window Shrinking   [CL 4.2.2.16]

        Discourage the shrinking of TCP windows from the right.

   -    Dotted-Decimal Host Numbers   [AS 2.1]

        Recommend that applications be able to accept dotted-decimal
        host numbers in place of host names.

   -    Telnet End-of-Line   [AS 3.3.1]

        Include compatibility requirements for Telnet end-of-line.

   -    Minimal FTP   [AS 4.1.2.13]

        Enlarge the minimum FTP implementation.

   -    Robust Mail Delivery   [AS 5.3.2, 5.3.4, 6.1.3.4]

        Recommend the use of long timeouts and of alternative addresses
        for multihomed hosts, to obtain robust mail delivery.

   -    Source-Routing of Mail  [AS 5.2.6, 5.2.16, 5.2.19]

        Discourage the use of source routes for delivering mail.  (This
        was one of the few cases where the working group opted for the
        architecturally pure resolution of an issue.)

   -    Fully-Qualified Domain Names   [AS 5.2.18]

        Require the use of fully-qualified domain names in RFC-822
        addresses.

   -    Domain Name System Required   [AS 6.1.1]

        Require that hosts implement the Domain Name System (DNS).

   -    WKS Records Detracted   [AS 2.2, 5.2.12, 6.1.3.6]

        Recommend against using WKS records from DNS.



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


   -    UDP Preferred for DNS Queries  [AS 6.1.2.4, 6.1.3.2]

        Require that UDP be preferred over TCP for DNS queries.

   -    DNS Negative Caching  [AS 6.1.3.3]

        Recommend that DNS name servers and resolvers cache negative
        responses and temporary failures.

   Finally, here is a list of areas in which the HR RFCs provide
   extended discussion of issues that have been inadequately documented
   in the past.

   -    ARP cache handling   [CL 2.3.2.1]

   -    Trailer encapsulation   [CL 2.3.1]

   -    Dead gateway detection algorithms   [CL 3.3.1.4]

   -    IP multihoming models   [CL 3.3.4]

        (Note that this topic is also one of the significant contentious
        issues; see the next section.)

   -    Maximum transmission unit (MTU and transport-layer maximum-
        segment size (MSS) issues   [CL 3.3.2, 3.3.3, 3.4, 4.1.4,
        4.2.2.6]

   -    TCP silly-window syndrome (SWS) avoidance algorithms
        [CL 4.2.3.3, 4.2.3.4]

   -    Telnet end-of-line issues   [AS 3.3.1]