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]
`
`VIMEO/IAC EXHIBIT 1018
`VIMEO ET AL., v. BT IPR2019-00833
`
`

`

`
`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 complexit