## cLIeNUX example RFC inclusion note.

 This is an Internet "Request For Comments". RFC's are the most official
specifications of the workings of the Internet. This one, "Requirements
for Internet Hosts", number 1122, is fairly pertinent to the purpose of
cLIeNUX Core. "Host" in the context of this document means an Internet
leaf-node, an endpoint of communication. cLIeNUX Core is defaulted for one
side of that, the client side.  I saw Alan Cox mention somewhere that
RFC's 1122 and 1812 are "...the bible of the Internet, in effect." The
problem with that is that this one includes many of the others that
pre-date it, by reference. However, this one does appear at first glance
to be a very good overview of what the Internet is about, to an end-user
that doesn't mind knowing how things actually work.

I got this one from a directory containing most of the rest of them in
(from human memory) ftp://gatekeeper.dec.com/pub/net/info/rfcs . Other
interesting ones for starters are, 822, email, the very early ones on IP,
TCP, telnet, ftp and so on, The even-thousand numbered ones, which are
indexes to the others, and the particular current RFC for a particular
protocol of interest, e.g. RFC 1459 for Internet Relay Chat. There are
also informational RFCs that aren't official to the IETF or whoever, but
are quite good, such as for the X Window System protocol. To actually be
sure you have the current RFC on a particular spec you should work from
latest (highest numbers) on back. I seem to recall that there are about 20
RFCs with "TELNET" in thier titles, starting with a two-digit one. 

The degree of technicalese in RFCs varies depending on the subject matter,
but is generally pretty severe. The reason to slog through it is, this is
the sourcecode of the Internet.  As with other sourcecode, it may not be
light reading, but it is exactly how things work. In the case of network
protocols, as opposed to program code, it's actually only exactly how
things are *supposed* to work, but most organizations do in fact strive
for compliance with what's in the RFCs. What you can glean from a current
RFC can be depended upon as much as any other info on networking matters. 
It's quite wonderful that so much valuable high-quality information is
free. 

The references to other RFCs in this document have been indirected through
footnotes, which are included at the end of this document.


Rick Hohensee 19990930





Network Working Group                    Internet Engineering Task Force
Request for Comments: 1122                             R. Braden, Editor
                                                            October 1989
 
 
        Requirements for Internet Hosts -- Communication Layers
 
 
Status of This Memo
 
   This RFC is an official specification for the Internet community.  It
   incorporates by reference, amends, corrects, and supplements the
   primary protocol standards documents relating to hosts.  Distribution
   of this document is unlimited.
 
Summary
 
   This is one RFC of a pair that defines and discusses the requirements
   for Internet host software.  This RFC covers the communications
   protocol layers: link layer, IP layer, and transport layer; its
   companion RFC-1123 covers the application and support protocols.
 
 
 
                           Table of Contents
 
 
 
 
   1.  INTRODUCTION ...............................................    5
      1.1  The Internet Architecture ..............................    6
         1.1.1  Internet Hosts ....................................    6
         1.1.2  Architectural Assumptions .........................    7
         1.1.3  Internet Protocol Suite ...........................    8
         1.1.4  Embedded Gateway Code .............................   10
      1.2  General Considerations .................................   12
         1.2.1  Continuing Internet Evolution .....................   12
         1.2.2  Robustness Principle ..............................   12
         1.2.3  Error Logging .....................................   13
         1.2.4  Configuration .....................................   14
      1.3  Reading this Document ..................................   15
         1.3.1  Organization ......................................   15
         1.3.2  Requirements ......................................   16
         1.3.3  Terminology .......................................   17
      1.4  Acknowledgments ........................................   20
 
   2. LINK LAYER ..................................................   21
      2.1  INTRODUCTION ...........................................   21
 
 
 
Internet Engineering Task Force                                 [Page 1]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
      2.2  PROTOCOL WALK-THROUGH ..................................   21
      2.3  SPECIFIC ISSUES ........................................   21
         2.3.1  Trailer Protocol Negotiation ......................   21
         2.3.2  Address Resolution Protocol -- ARP ................   22
            2.3.2.1  ARP Cache Validation .........................   22
            2.3.2.2  ARP Packet Queue .............................   24
         2.3.3  Ethernet and IEEE 802 Encapsulation ...............   24
      2.4  LINK/INTERNET LAYER INTERFACE ..........................   25
      2.5  LINK LAYER REQUIREMENTS SUMMARY ........................   26
 
   3. INTERNET LAYER PROTOCOLS ....................................   27
      3.1 INTRODUCTION ............................................   27
      3.2  PROTOCOL WALK-THROUGH ..................................   29
         3.2.1 Internet Protocol -- IP ............................   29
            3.2.1.1  Version Number ...............................   29
            3.2.1.2  Checksum .....................................   29
            3.2.1.3  Addressing ...................................   29
            3.2.1.4  Fragmentation and Reassembly .................   32
            3.2.1.5  Identification ...............................   32
            3.2.1.6  Type-of-Service ..............................   33
            3.2.1.7  Time-to-Live .................................   34
            3.2.1.8  Options ......................................   35
         3.2.2 Internet Control Message Protocol -- ICMP ..........   38
            3.2.2.1  Destination Unreachable ......................   39
            3.2.2.2  Redirect .....................................   40
            3.2.2.3  Source Quench ................................   41
            3.2.2.4  Time Exceeded ................................   41
            3.2.2.5  Parameter Problem ............................   42
            3.2.2.6  Echo Request/Reply ...........................   42
            3.2.2.7  Information Request/Reply ....................   43
            3.2.2.8  Timestamp and Timestamp Reply ................   43
            3.2.2.9  Address Mask Request/Reply ...................   45
         3.2.3  Internet Group Management Protocol IGMP ...........   47
      3.3  SPECIFIC ISSUES ........................................   47
         3.3.1  Routing Outbound Datagrams ........................   47
            3.3.1.1  Local/Remote Decision ........................   47
            3.3.1.2  Gateway Selection ............................   48
            3.3.1.3  Route Cache ..................................   49
            3.3.1.4  Dead Gateway Detection .......................   51
            3.3.1.5  New Gateway Selection ........................   55
            3.3.1.6  Initialization ...............................   56
         3.3.2  Reassembly ........................................   56
         3.3.3  Fragmentation .....................................   58
         3.3.4  Local Multihoming .................................   60
            3.3.4.1  Introduction .................................   60
            3.3.4.2  Multihoming Requirements .....................   61
            3.3.4.3  Choosing a Source Address ....................   64
         3.3.5  Source Route Forwarding ...........................   65
 
 
 
Internet Engineering Task Force                                 [Page 2]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
         3.3.6  Broadcasts ........................................   66
         3.3.7  IP Multicasting ...................................   67
         3.3.8  Error Reporting ...................................   69
      3.4  INTERNET/TRANSPORT LAYER INTERFACE .....................   69
      3.5  INTERNET LAYER REQUIREMENTS SUMMARY ....................   72
 
   4. TRANSPORT PROTOCOLS .........................................   77
      4.1  USER DATAGRAM PROTOCOL -- UDP ..........................   77
         4.1.1  INTRODUCTION ......................................   77
         4.1.2  PROTOCOL WALK-THROUGH .............................   77
         4.1.3  SPECIFIC ISSUES ...................................   77
            4.1.3.1  Ports ........................................   77
            4.1.3.2  IP Options ...................................   77
            4.1.3.3  ICMP Messages ................................   78
            4.1.3.4  UDP Checksums ................................   78
            4.1.3.5  UDP Multihoming ..............................   79
            4.1.3.6  Invalid Addresses ............................   79
         4.1.4  UDP/APPLICATION LAYER INTERFACE ...................   79
         4.1.5  UDP REQUIREMENTS SUMMARY ..........................   80
      4.2  TRANSMISSION CONTROL PROTOCOL -- TCP ...................   82
         4.2.1  INTRODUCTION ......................................   82
         4.2.2  PROTOCOL WALK-THROUGH .............................   82
            4.2.2.1  Well-Known Ports .............................   82
            4.2.2.2  Use of Push ..................................   82
            4.2.2.3  Window Size ..................................   83
            4.2.2.4  Urgent Pointer ...............................   84
            4.2.2.5  TCP Options ..................................   85
            4.2.2.6  Maximum Segment Size Option ..................   85
            4.2.2.7  TCP Checksum .................................   86
            4.2.2.8  TCP Connection State Diagram .................   86
            4.2.2.9  Initial Sequence Number Selection ............   87
            4.2.2.10  Simultaneous Open Attempts ..................   87
            4.2.2.11  Recovery from Old Duplicate SYN .............   87
            4.2.2.12  RST Segment .................................   87
            4.2.2.13  Closing a Connection ........................   87
            4.2.2.14  Data Communication ..........................   89
            4.2.2.15  Retransmission Timeout ......................   90
            4.2.2.16  Managing the Window .........................   91
            4.2.2.17  Probing Zero Windows ........................   92
            4.2.2.18  Passive OPEN Calls ..........................   92
            4.2.2.19  Time to Live ................................   93
            4.2.2.20  Event Processing ............................   93
            4.2.2.21  Acknowledging Queued Segments ...............   94
         4.2.3  SPECIFIC ISSUES ...................................   95
            4.2.3.1  Retransmission Timeout Calculation ...........   95
            4.2.3.2  When to Send an ACK Segment ..................   96
            4.2.3.3  When to Send a Window Update .................   97
            4.2.3.4  When to Send Data ............................   98
 
 
 
Internet Engineering Task Force                                 [Page 3]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
            4.2.3.5  TCP Connection Failures ......................  100
            4.2.3.6  TCP Keep-Alives ..............................  101
            4.2.3.7  TCP Multihoming ..............................  103
            4.2.3.8  IP Options ...................................  103
            4.2.3.9  ICMP Messages ................................  103
            4.2.3.10  Remote Address Validation ...................  104
            4.2.3.11  TCP Traffic Patterns ........................  104
            4.2.3.12  Efficiency ..................................  105
         4.2.4  TCP/APPLICATION LAYER INTERFACE ...................  106
            4.2.4.1  Asynchronous Reports .........................  106
            4.2.4.2  Type-of-Service ..............................  107
            4.2.4.3  Flush Call ...................................  107
            4.2.4.4  Multihoming ..................................  108
         4.2.5  TCP REQUIREMENT SUMMARY ...........................  108
 
   5.  REFERENCES .................................................  112
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Internet Engineering Task Force                                 [Page 4]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
1.  INTRODUCTION
 
   This document is one of a pair that defines and discusses the
   requirements for host system implementations of the Internet protocol
   suite.  This RFC covers the communication protocol layers:  link
   layer, IP layer, and transport layer.  Its companion RFC,
   "Requirements for Internet Hosts -- Application and Support"
   [INTRO:1], covers the application layer protocols.  This document
   should also be read in conjunction with "Requirements for Internet
   Gateways" [INTRO:2].
 
   These documents are intended to provide guidance for vendors,
   implementors, and users of Internet communication software.  They
   represent the consensus of a large body of technical experience and
   wisdom, contributed by the members of the Internet research and
   vendor communities.
 
   This RFC enumerates standard protocols that a host connected to the
   Internet must use, and it incorporates by reference the RFCs and
   other documents describing the current specifications for these
   protocols.  It corrects errors in the referenced documents and adds
   additional discussion and guidance for an implementor.
 
   For each protocol, this document also contains an explicit set of
   requirements, recommendations, and options. The reader must
   understand that the list of requirements in this document is
   incomplete by itself; the complete set of requirements for an
   Internet host is primarily defined in the standard protocol
   specification documents, with the corrections, amendments, and
   supplements contained in this RFC.
 
   A good-faith implementation of the protocols that was produced after
   careful reading of the RFC's and with some interaction with the
   Internet technical community, and that followed good communications
   software engineering practices, should differ from the requirements
   of this document in only minor ways.  Thus, in many cases, the
   "requirements" in this RFC are already stated or implied in the
   standard protocol documents, so that their inclusion here is, in a
   sense, redundant.  However, they were included because some past
   implementation has made the wrong choice, causing problems of
   interoperability, performance, and/or robustness.
 
   This document includes discussion and explanation of many of the
   requirements and recommendations.  A simple list of requirements
   would be dangerous, because:
 
   o    Some required features are more important than others, and some
        features are optional.
 
 
 
Internet Engineering Task Force                                 [Page 5]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
   o    There may be valid reasons why particular vendor products that
        are designed for restricted contexts might choose to use
        different specifications.
 
   However, the specifications of this document must be followed to meet
   the general goal of arbitrary host interoperation across the
   diversity and complexity of the Internet system.  Although most
   current implementations fail to meet these requirements in various
   ways, some minor and some major, this specification is the ideal
   towards which we need to move.
 
   These requirements are based on the current level of Internet
   architecture.  This document will be updated as required to provide
   additional clarifications or to include additional information in
   those areas in which specifications are still evolving.
 
   This introductory section begins with a brief overview of the
   Internet architecture as it relates to hosts, and then gives some
   general advice to host software vendors.  Finally, there is some
   guidance on reading the rest of the document and some terminology.
 
   1.1  The Internet Architecture
 
      General background and discussion on the Internet architecture and
      supporting protocol suite can be found in the DDN Protocol
      Handbook [INTRO:3]; for background see for example [INTRO:9],
      [INTRO:10], and [INTRO:11].  Reference [INTRO:5] describes the
      procedure for obtaining Internet protocol documents, while
      [INTRO:6] contains a list of the numbers assigned within Internet
      protocols.
 
      1.1.1  Internet Hosts
 
         A host computer, or simply "host," is the ultimate consumer of
         communication services.  A host generally executes application
         programs on behalf of user(s), employing network and/or
         Internet communication services in support of this function.
         An Internet host corresponds to the concept of an "End-System"
         used in the OSI protocol suite [INTRO:13].
 
         An Internet communication system consists of interconnected
         packet networks supporting communication among host computers
         using the Internet protocols.  The networks are interconnected
         using packet-switching computers called "gateways" or "IP
         routers" by the Internet community, and "Intermediate Systems"
         by the OSI world [INTRO:13].  The RFC "Requirements for
         Internet Gateways" [INTRO:2] contains the official
         specifications for Internet gateways.  That RFC together with
 
 
 
Internet Engineering Task Force                                 [Page 6]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
         the present document and its companion [INTRO:1] define the
         rules for the current realization of the Internet architecture.
 
         Internet hosts span a wide range of size, speed, and function.
         They range in size from small microprocessors through
         workstations to mainframes and supercomputers.  In function,
         they range from single-purpose hosts (such as terminal servers)
         to full-service hosts that support a variety of online network
         services, typically including remote login, file transfer, and
         electronic mail.
 
         A host is generally said to be multihomed if it has more than
         one interface to the same or to different networks.  See
         Section 1.1.3 on "Terminology".
 
      1.1.2  Architectural Assumptions
 
         The current Internet architecture is based on a set of
         assumptions about the communication system.  The assumptions
         most relevant to hosts are as follows:
 
         (a)  The Internet is a network of networks.
 
              Each host is directly connected to some particular
              network(s); its connection to the Internet is only
              conceptual.  Two hosts on the same network communicate
              with each other using the same set of protocols that they
              would use to communicate with hosts on distant networks.
 
         (b)  Gateways don't keep connection state information.
 
              To improve robustness of the communication system,
              gateways are designed to be stateless, forwarding each IP
              datagram independently of other datagrams.  As a result,
              redundant paths can be exploited to provide robust service
              in spite of failures of intervening gateways and networks.
 
              All state information required for end-to-end flow control
              and reliability is implemented in the hosts, in the
              transport layer or in application programs.  All
              connection control information is thus co-located with the
              end points of the communication, so it will be lost only
              if an end point fails.
 
         (c)  Routing complexity should be in the gateways.
 
              Routing is a complex and difficult problem, and ought to
              be performed by the gateways, not the hosts.  An important
 
 
 
Internet Engineering Task Force                                 [Page 7]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
              objective is to insulate host software from changes caused
              by the inevitable evolution of the Internet routing
              architecture.
 
         (d)  The System must tolerate wide network variation.
 
              A basic objective of the Internet design is to tolerate a
              wide range of network characteristics -- e.g., bandwidth,
              delay, packet loss, packet reordering, and maximum packet
              size.  Another objective is robustness against failure of
              individual networks, gateways, and hosts, using whatever
              bandwidth is still available.  Finally, the goal is full
              "open system interconnection": an Internet host must be
              able to interoperate robustly and effectively with any
              other Internet host, across diverse Internet paths.
 
              Sometimes host implementors have designed for less
              ambitious goals.  For example, the LAN environment is
              typically much more benign than the Internet as a whole;
              LANs have low packet loss and delay and do not reorder
              packets.  Some vendors have fielded host implementations
              that are adequate for a simple LAN environment, but work
              badly for general interoperation.  The vendor justifies
              such a product as being economical within the restricted
              LAN market.  However, isolated LANs seldom stay isolated
              for long; they are soon gatewayed to each other, to
              organization-wide internets, and eventually to the global
              Internet system.  In the end, neither the customer nor the
              vendor is served by incomplete or substandard Internet
              host software.
 
              The requirements spelled out in this document are designed
              for a full-function Internet host, capable of full
              interoperation over an arbitrary Internet path.
 
 
      1.1.3  Internet Protocol Suite
 
         To communicate using the Internet system, a host must implement
         the layered set of protocols comprising the Internet protocol
         suite.  A host typically must implement at least one protocol
         from each layer.
 
         The protocol layers used in the Internet architecture are as
         follows [INTRO:4]:
 
 
         o  Application Layer
 
 
 
Internet Engineering Task Force                                 [Page 8]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
              The application layer is the top layer of the Internet
              protocol suite.  The Internet suite does not further
              subdivide the application layer, although some of the
              Internet application layer protocols do contain some
              internal sub-layering.  The application layer of the
              Internet suite essentially combines the functions of the
              top two layers -- Presentation and Application -- of the
              OSI reference model.
 
              We distinguish two categories of application layer
              protocols:  user protocols that provide service directly
              to users, and support protocols that provide common system
              functions.  Requirements for user and support protocols
              will be found in the companion RFC [INTRO:1].
 
              The most common Internet user protocols are:
 
                o  Telnet (remote login)
                o  FTP    (file transfer)
                o  SMTP   (electronic mail delivery)
 
              There are a number of other standardized user protocols
              [INTRO:4] and many private user protocols.
 
              Support protocols, used for host name mapping, booting,
              and management, include SNMP, BOOTP, RARP, and the Domain
              Name System (DNS) protocols.
 
 
         o  Transport Layer
 
              The transport layer provides end-to-end communication
              services for applications.  There are two primary
              transport layer protocols at present:
 
                o Transmission Control Protocol (TCP)
                o User Datagram Protocol (UDP)
 
              TCP is a reliable connection-oriented transport service
              that provides end-to-end reliability, resequencing, and
              flow control.  UDP is a connectionless ("datagram")
              transport service.
 
              Other transport protocols have been developed by the
              research community, and the set of official Internet
              transport protocols may be expanded in the future.
 
              Transport layer protocols are discussed in Chapter 4.
 
 
 
Internet Engineering Task Force                                 [Page 9]

 

 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
         o  Internet Layer
 
              All Internet transport protocols use the Internet Protocol
              (IP) to carry data from source host to destination host.
              IP is a connectionless or datagram internetwork service,
              providing no end-to-end delivery guarantees. Thus, IP
              datagrams may arrive at the destination host damaged,
              duplicated, out of order, or not at all.  The layers above
              IP are responsible for reliable delivery service when it
              is required.  The IP protocol includes provision for
              addressing, type-of-service specification, fragmentation
              and reassembly, and security information.
 
              The datagram or connectionless nature of the IP protocol
              is a fundamental and characteristic feature of the
              Internet architecture.  Internet IP was the model for the
              OSI Connectionless Network Protocol [INTRO:12].
 
              ICMP is a control protocol that is considered to be an
              integral part of IP, although it is architecturally
              layered upon IP, i.e., it uses IP to carry its data end-
              to-end just as a transport protocol like TCP or UDP does.
              ICMP provides error reporting, congestion reporting, and
              first-hop gateway redirection.
 
              IGMP is an Internet layer protocol used for establishing
              dynamic host groups for IP multicasting.
 
              The Internet layer protocols IP, ICMP, and IGMP are
              discussed in Chapter 3.
 
 
         o  Link Layer
 
              To communicate on its directly-connected network, a host
              must implement the communication protocol used to
              interface to that network.  We call this a link layer or
              media-access layer protocol.
 
              There is a wide variety of link layer protocols,
              corresponding to the many different types of networks.
              See Chapter 2.
 
 
      1.1.4  Embedded Gateway Code
 
         Some Internet host software includes embedded gateway
         functionality, so that these hosts can forward packets as a
 
 
 
Internet Engineering Task Force                                [Page 10]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
         gateway would, while still performing the application layer
         functions of a host.
 
         Such dual-purpose systems must follow the Gateway Requirements
         RFC [INTRO:2]  with respect to their gateway functions, and
         must follow the present document with respect to their host
         functions.  In all overlapping cases, the two specifications
         should be in agreement.
 
         There are varying opinions in the Internet community about
         embedded gateway functionality.  The main arguments are as
         follows:
 
         o    Pro: in a local network environment where networking is
              informal, or in isolated internets, it may be convenient
              and economical to use existing host systems as gateways.
 
              There is also an architectural argument for embedded
              gateway functionality: multihoming is much more common
              than originally foreseen, and multihoming forces a host to
              make routing decisions as if it were a gateway.  If the
              multihomed  host contains an embedded gateway, it will
              have full routing knowledge and as a result will be able
              to make more optimal routing decisions.
 
         o    Con: Gateway algorithms and protocols are still changing,
              and they will continue to change as the Internet system
              grows larger.  Attempting to include a general gateway
              function within the host IP layer will force host system
              maintainers to track these (more frequent) changes.  Also,
              a larger pool of gateway implementations will make
              coordinating the changes more difficult.  Finally, the
              complexity of a gateway IP layer is somewhat greater than
              that of a host, making the implementation and operation
              tasks more complex.
 
              In addition, the style of operation of some hosts is not
              appropriate for providing stable and robust gateway
              service.
 
         There is considerable merit in both of these viewpoints.  One
         conclusion can be drawn: an host administrator must have
         conscious control over whether or not a given host acts as a
         gateway.  See Section 3.1 for the detailed requirements.
 
 
 
 
 
 
 
Internet Engineering Task Force                                [Page 11]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
   1.2  General Considerations
 
      There are two important lessons that vendors of Internet host
      software have learned and which a new vendor should consider
      seriously.
 
      1.2.1  Continuing Internet Evolution
 
         The enormous growth of the Internet has revealed problems of
         management and scaling in a large datagram-based packet
         communication system.  These problems are being addressed, and
         as a result there will be continuing evolution of the
         specifications described in this document.  These changes will
         be carefully planned and controlled, since there is extensive
         participation in this planning by the vendors and by the
         organizations responsible for operations of the networks.
 
         Development, evolution, and revision are characteristic of
         computer network protocols today, and this situation will
         persist for some years.  A vendor who develops computer
         communication software for the Internet protocol suite (or any
         other protocol suite!) and then fails to maintain and update
         that software for changing specifications is going to leave a
         trail of unhappy customers.  The Internet is a large
         communication network, and the users are in constant contact
         through it.  Experience has shown that knowledge of
         deficiencies in vendor software propagates quickly through the
         Internet technical community.
 
      1.2.2  Robustness Principle
 
         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability [IP:1]:
 
                "Be liberal in what you accept, and
                 conservative in what you send"
 
         Software should be written to deal with every conceivable
         error, no matter how unlikely; sooner or later a packet will
         come in with that particular combination of errors and
         attributes, and unless the software is prepared, chaos can
         ensue.  In general, it is best to assume that the network is
         filled with malevolent entities that will send in packets
         designed to have the worst possible effect.  This assumption
         will lead to suitable protective design, although the most
         serious problems in the Internet have been caused by
         unenvisaged mechanisms triggered by low-probability events;
 
 
 
Internet Engineering Task Force                                [Page 12]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
         mere human malice would never have taken so devious a course!
 
         Adaptability to change must be designed into all levels of
         Internet host software.  As a simple example, consider a
         protocol specification that contains an enumeration of values
         for a particular header field -- e.g., a type field, a port
         number, or an error code; this enumeration must be assumed to
         be incomplete.  Thus, if a protocol specification defines four
         possible error codes, the software must not break when a fifth
         code shows up.  An undefined code might be logged (see below),
         but it must not cause a failure.
 
         The second part of the principle is almost as important:
         software on other hosts may contain deficiencies that make it
         unwise to exploit legal but obscure protocol features.  It is
         unwise to stray far from the obvious and simple, lest untoward
         effects result elsewhere.  A corollary of this is "watch out
         for misbehaving hosts"; host software should be prepared, not
         just to survive other misbehaving hosts, but also to cooperate
         to limit the amount of disruption such hosts can cause to the
         shared communication facility.
 
      1.2.3  Error Logging
 
         The Internet includes a great variety of host and gateway
         systems, each implementing many protocols and protocol layers,
         and some of these contain bugs and mis-features in their
         Internet protocol software.  As a result of complexity,
         diversity, and distribution of function, the diagnosis of
         Internet problems is often very difficult.
 
         Problem diagnosis will be aided if host implementations include
         a carefully designed facility for logging erroneous or
         "strange" protocol events.  It is important to include as much
         diagnostic information as possible when an error is logged.  In
         particular, it is often useful to record the header(s) of a
         packet that caused an error.  However, care must be taken to
         ensure that error logging does not consume prohibitive amounts
         of resources or otherwise interfere with the operation of the
         host.
 
         There is a tendency for abnormal but harmless protocol events
         to overflow error logging files; this can be avoided by using a
         "circular" log, or by enabling logging only while diagnosing a
         known failure.  It may be useful to filter and count duplicate
         successive messages.  One strategy that seems to work well is:
         (1) always count abnormalities and make such counts accessible
         through the management protocol (see [INTRO:1]); and (2) allow
 
 
 
Internet Engineering Task Force                                [Page 13]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
         the logging of a great variety of events to be selectively
         enabled.  For example, it might useful to be able to "log
         everything" or to "log everything for host X".
 
         Note that different managements may have differing policies
         about the amount of error logging that they want normally
         enabled in a host.  Some will say, "if it doesn't hurt me, I
         don't want to know about it", while others will want to take a
         more watchful and aggressive attitude about detecting and
         removing protocol abnormalities.
 
      1.2.4  Configuration
 
         It would be ideal if a host implementation of the Internet
         protocol suite could be entirely self-configuring.  This would
         allow the whole suite to be implemented in ROM or cast into
         silicon, it would simplify diskless workstations, and it would
         be an immense boon to harried LAN administrators as well as
         system vendors.  We have not reached this ideal; in fact, we
         are not even close.
 
         At many points in this document, you will find a requirement
         that a parameter be a configurable option.  There are several
         different reasons behind such requirements.  In a few cases,
         there is current uncertainty or disagreement about the best
         value, and it may be necessary to update the recommended value
         in the future.  In other cases, the value really depends on
         external factors -- e.g., the size of the host and the
         distribution of its communication load, or the speeds and
         topology of nearby networks -- and self-tuning algorithms are
         unavailable and may be insufficient.  In some cases,
         configurability is needed because of administrative
         requirements.
 
         Finally, some configuration options are required to communicate
         with obsolete or incorrect implementations of the protocols,
         distributed without sources, that unfortunately persist in many
         parts of the Internet.  To make correct systems coexist with
         these faulty systems, administrators often have to "mis-
         configure" the correct systems.  This problem will correct
         itself gradually as the faulty systems are retired, but it
         cannot be ignored by vendors.
 
         When we say that a parameter must be configurable, we do not
         intend to require that its value be explicitly read from a
         configuration file at every boot time.  We recommend that
         implementors set up a default for each parameter, so a
         configuration file is only necessary to override those defaults
 
 
 
Internet Engineering Task Force                                [Page 14]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
         that are inappropriate in a particular installation.  Thus, the
         configurability requirement is an assurance that it will be
         POSSIBLE to override the default when necessary, even in a
         binary-only or ROM-based product.
 
         This document requires a particular value for such defaults in
         some cases.  The choice of default is a sensitive issue when
         the configuration item controls the accommodation to existing
         faulty systems.  If the Internet is to converge successfully to
         complete interoperability, the default values built into
         implementations must implement the official protocol, not
         "mis-configurations" to accommodate faulty implementations.
         Although marketing considerations have led some vendors to
         choose mis-configuration defaults, we urge vendors to choose
         defaults that will conform to the standard.
 
         Finally, we note that a vendor needs to provide adequate
         documentation on all configuration parameters, their limits and
         effects.
 
 
   1.3  Reading this Document
 
      1.3.1  Organization
 
         Protocol layering, which is generally used as an organizing
         principle in implementing network software, has also been used
         to organize this document.  In describing the rules, we assume
         that an implementation does strictly mirror the layering of the
         protocols.  Thus, the following three major sections specify
         the requirements for the link layer, the internet layer, and
         the transport layer, respectively.  A companion RFC [INTRO:1]
         covers application level software.  This layerist organization
         was chosen for simplicity and clarity.
 
         However, strict layering is an imperfect model, both for the
         protocol suite and for recommended implementation approaches.
         Protocols in different layers interact in complex and sometimes
         subtle ways, and particular functions often involve multiple
         layers.  There are many design choices in an implementation,
         many of which involve creative "breaking" of strict layering.
         Every implementor is urged to read references [INTRO:7] and
         [INTRO:8].
 
         This document describes the conceptual service interface
         between layers using a functional ("procedure call") notation,
         like that used in the TCP specification [TCP:1].  A host
         implementation must support the logical information flow
 
 
 
Internet Engineering Task Force                                [Page 15]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
         implied by these calls, but need not literally implement the
         calls themselves.  For example, many implementations reflect
         the coupling between the transport layer and the IP layer by
         giving them shared access to common data structures.  These
         data structures, rather than explicit procedure calls, are then
         the agency for passing much of the information that is
         required.
 
         In general, each major section of this document is organized
         into the following subsections:
 
         (1)  Introduction
 
         (2)  Protocol Walk-Through -- considers the protocol
              specification documents section-by-section, correcting
              errors, stating requirements that may be ambiguous or
              ill-defined, and providing further clarification or
              explanation.
 
         (3)  Specific Issues -- discusses protocol design and
              implementation issues that were not included in the walk-
              through.
 
         (4)  Interfaces -- discusses the service interface to the next
              higher layer.
 
         (5)  Summary -- contains a summary of the requirements of the
              section.
 
 
         Under many of the individual topics in this document, there is
         parenthetical material labeled "DISCUSSION" or
         "IMPLEMENTATION". This material is intended to give
         clarification and explanation of the preceding requirements
         text.  It also includes some suggestions on possible future
         directions or developments.  The implementation material
         contains suggested approaches that an implementor may want to
         consider.
 
         The summary sections are intended to be guides and indexes to
         the text, but are necessarily cryptic and incomplete.  The
         summaries should never be used or referenced separately from
         the complete RFC.
 
      1.3.2  Requirements
 
         In this document, the words that are used to define the
         significance of each particular requirement are capitalized.
 
 
 
Internet Engineering Task Force                                [Page 16]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
         These words are:
 
         *    "MUST"
 
              This word or the adjective "REQUIRED" means that the item
              is an absolute requirement of the specification.
 
         *    "SHOULD"
 
              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.
 
         *    "MAY"
 
              This word or the adjective "OPTIONAL" means that this item
              is truly optional.  One vendor may choose to include the
              item because a particular marketplace requires it or
              because it enhances the product, for example; another
              vendor may omit the same item.
 
 
         An implementation is not compliant if it fails to satisfy one
         or more of the MUST requirements for the protocols it
         implements.  An implementation that satisfies all the MUST and
         all the SHOULD requirements for its protocols is said to be
         "unconditionally compliant"; one that satisfies all the MUST
         requirements but not all the SHOULD requirements for its
         protocols is said to be "conditionally compliant".
 
      1.3.3  Terminology
 
         This document uses the following technical terms:
 
         Segment
              A segment is the unit of end-to-end transmission in the
              TCP protocol.  A segment consists of a TCP header followed
              by application data.  A segment is transmitted by
              encapsulation inside an IP datagram.
 
         Message
              In this description of the lower-layer protocols, a
              message is the unit of transmission in a transport layer
              protocol.  In particular, a TCP segment is a message.  A
              message consists of a transport protocol header followed
              by application protocol data.  To be transmitted end-to-
 
 
 
Internet Engineering Task Force                                [Page 17]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
              end through the Internet, a message must be encapsulated
              inside a datagram.
 
         IP Datagram
              An IP datagram is the unit of end-to-end transmission in
              the IP protocol.  An IP datagram consists of an IP header
              followed by transport layer data, i.e., of an IP header
              followed by a message.
 
              In the description of the internet layer (Section 3), the
              unqualified term "datagram" should be understood to refer
              to an IP datagram.
 
         Packet
              A packet is the unit of data passed across the interface
              between the internet layer and the link layer.  It
              includes an IP header and data.  A packet may be a
              complete IP datagram or a fragment of an IP datagram.
 
         Frame
              A frame is the unit of transmission in a link layer
              protocol, and consists of a link-layer header followed by
              a packet.
 
         Connected Network
              A network to which a host is interfaced is often known as
              the "local network" or the "subnetwork" relative to that
              host.  However, these terms can cause confusion, and
              therefore we use the term "connected network" in this
              document.
 
         Multihomed
              A host is said to be multihomed if it has multiple IP
              addresses.  For a discussion of multihoming, see Section
              3.3.4 below.
 
         Physical network interface
              This is a physical interface to a connected network and
              has a (possibly unique) link-layer address.  Multiple
              physical network interfaces on a single host may share the
              same link-layer address, but the address must be unique
              for different hosts on the same physical network.
 
         Logical [network] interface
              We define a logical [network] interface to be a logical
              path, distinguished by a unique IP address, to a connected
              network.  See Section 3.3.4.
 
 
 
 
Internet Engineering Task Force                                [Page 18]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
         Specific-destination address
              This is the effective destination address of a datagram,
              even if it is broadcast or multicast; see Section 3.2.1.3.
 
         Path
              At a given moment, all the IP datagrams from a particular
              source host to a particular destination host will
              typically traverse the same sequence of gateways.  We use
              the term "path" for this sequence.  Note that a path is
              uni-directional; it is not unusual to have different paths
              in the two directions between a given host pair.
 
         MTU
              The maximum transmission unit, i.e., the size of the
              largest packet that can be transmitted.
 
 
         The terms frame, packet, datagram, message, and segment are
         illustrated by the following schematic diagrams:
 
         A. Transmission on connected network:
           _______________________________________________
          | LL hdr | IP hdr |         (data)              |
          |________|________|_____________________________|
 
           <---------- Frame ----------------------------->
                    <----------Packet -------------------->
 
 
         B. Before IP fragmentation or after IP reassembly:
                    ______________________________________
                   | IP hdr | transport| Application Data |
                   |________|____hdr___|__________________|
 
                    <--------  Datagram ------------------>
                             <-------- Message ----------->
           or, for TCP:
                    ______________________________________
                   | IP hdr |  TCP hdr | Application Data |
                   |________|__________|__________________|
 
                    <--------  Datagram ------------------>
                             <-------- Segment ----------->
 
 
 
 
 
 
 
 
Internet Engineering Task Force                                [Page 19]

 
 
 
RFC1122                       INTRODUCTION                  October 1989
 
 
   1.4  Acknowledgments
 
      This document incorporates contributions and comments from a large
      group of Internet protocol experts, including representatives of
      university and research labs, vendors, and government agencies.
      It was assembled primarily by the Host Requirements Working Group
      of the Internet Engineering Task Force (IETF).
 
      The Editor would especially like to acknowledge the tireless
      dedication of the following people, who attended many long
      meetings and generated 3 million bytes of electronic mail over the
      past 18 months in pursuit of this document: Philip Almquist, Dave
      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
 
      In addition, the following people made major contributions to the
      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
      Technology), and Mike StJohns (DCA).  The following also made
      significant contributions to particular areas: Eric Allman
      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
      (Toronto).
 
      We are grateful to all, including any contributors who may have
      been inadvertently omitted from this list.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Internet Engineering Task Force                                [Page 20]

 
 
 
RFC1122                        LINK LAYER                   October 1989
 
 
2. LINK LAYER
 
   2.1  INTRODUCTION
 
      All Internet systems, both hosts and gateways, have the same
      requirements for link layer protocols.  These requirements are
      given in Chapter 3 of "Requirements for Internet Gateways"
      [INTRO:2], augmented with the material in this section.
 
   2.2  PROTOCOL WALK-THROUGH
 
      None.
 
   2.3  SPECIFIC ISSUES
 
      2.3.1  Trailer Protocol Negotiation
 
         The trailer protocol [LINK:1] for link-layer encapsulation MAY
         be used, but only when it has been verified that both systems
         (host or gateway) involved in the link-layer communication
         implement trailers.  If the system does not dynamically
         negotiate use of the trailer protocol on a per-destination
         basis, the default configuration MUST disable the protocol.
 
         DISCUSSION:
              The trailer protocol is a link-layer encapsulation
              technique that rearranges the data contents of packets
              sent on the physical network.  In some cases, trailers
              improve the throughput of higher layer protocols by
              reducing the amount of data copying within the operating
              system.  Higher layer protocols are unaware of trailer
              use, but both the sending and receiving host MUST
              understand the protocol if it is used.
 
              Improper use of trailers can result in very confusing
              symptoms.  Only packets with specific size attributes are
              encapsulated using trailers, and typically only a small
              fraction of the packets being exchanged have these
              attributes.  Thus, if a system using trailers exchanges
              packets with a system that does not, some packets
              disappear into a black hole while others are delivered
              successfully.
 
         IMPLEMENTATION:
              On an Ethernet, packets encapsulated with trailers use a
              distinct Ethernet type [LINK:1], and trailer negotiation
              is performed at the time that ARP is used to discover the
              link-layer address of a destination system.
 
 
 
Internet Engineering Task Force                                [Page 21]

 
 
 
RFC1122                        LINK LAYER                   October 1989
 
 
              Specifically, the ARP exchange is completed in the usual
              manner using the normal IP protocol type, but a host that
              wants to speak trailers will send an additional "trailer
              ARP reply" packet, i.e., an ARP reply that specifies the
              trailer encapsulation protocol type but otherwise has the
              format of a normal ARP reply.  If a host configured to use
              trailers receives a trailer ARP reply message from a
              remote machine, it can add that machine to the list of
              machines that understand trailers, e.g., by marking the
              corresponding entry in the ARP cache.
 
              Hosts wishing to receive trailer encapsulations send
              trailer ARP replies whenever they complete exchanges of
              normal ARP messages for IP.  Thus, a host that received an
              ARP request for its IP protocol address would send a
              trailer ARP reply in addition to the normal IP ARP reply;
              a host that sent the IP ARP request would send a trailer
              ARP reply when it received the corresponding IP ARP reply.
              In this way, either the requesting or responding host in
              an IP ARP exchange may request that it receive trailer
              encapsulations.
 
              This scheme, using extra trailer ARP reply packets rather
              than sending an ARP request for the trailer protocol type,
              was designed to avoid a continuous exchange of ARP packets
              with a misbehaving host that, contrary to any
              specification or common sense, responded to an ARP reply
              for trailers with another ARP reply for IP.  This problem
              is avoided by sending a trailer ARP reply in response to
              an IP ARP reply only when the IP ARP reply answers an
              outstanding request; this is true when the hardware
              address for the host is still unknown when the IP ARP
              reply is received.  A trailer ARP reply may always be sent


<snip>
