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]
`
`AT&T Exhibit 1028
`AT&T v. VoIP, IPR 2017-01384
`Page 1
`
`

`

`
`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]
`
`AT&T Exhibit 1028
`AT&T v. VoIP, IPR 2017-01384
`Page 2
`
`

`

`
`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]
`
`AT&T Exhibit 1028
`AT&T v. VoIP, IPR 2017-01384
`Page 3
`
`

`

`
`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]
`
`AT&T Exhibit 1028
`AT&T v. VoIP, IPR 2017-01384
`Page 4
`
`

`

`
`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]
`
`AT&T Exhibit 1028
`AT&T v. VoIP, IPR 2017-01384
`Page 5
`
`

`

`
`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
` along with an IP ARP reply responding to an IP ARP
` request.
`
` 2.3.2 Address Resolution Protocol -- ARP
`
` 2.3.2.1 ARP Cache Validation
`
` An implementation of the Address Resolution Protocol (ARP)
` [LINK:2] MUST provide a mechanism to flush out-of-date cache
` entries. If this mechanism involves a timeout, it SHOULD be
` possible to configure the timeout value.
`
` A mechanism to prevent ARP flooding (repeatedly sending an
` ARP Request for the same IP address, at a high rate) MUST be
` included. The recommended maximum rate is 1 per second per
`
`Internet Engineering Task Force [Page 22]
`
`AT&T Exhibit 1028
`AT&T v. VoIP, IPR 2017-01384
`Page 6
`
`

`

`
`RFC1122 LINK LAYER October 1989
`
` destination.
`
` DISCUSSION:
` The ARP specification [LINK:2] suggests but does not
` require a timeout mechanism to invalidate cache entries
` when hosts change their Ethernet addresses. The
` prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
` has significantly increased the likelihood that cache
` entries in hosts will become invalid, and therefore
` some ARP-cache invalidation mechanism is now required
` for hosts. Even in the absence of proxy ARP, a long-
` period cache timeout is useful in order to
` automatically correct any bad ARP data that might have
` been cached.
`
` IMPLEMENTATION:
` Four mechanisms have been used, sometimes in
` combination, to flush out-of-date cache entries.
`
` (1) Timeout -- Periodically time out cache entries,
` even if they are in use. Note that this timeout
` should be restarted when the cache entry is
` "refreshed" (by observing the source fields,
` regardless of target address, of an ARP broadcast
` from the system in question). For proxy ARP
` situations, the timeout needs to be on the order
` of a minute.
`
` (2) Unicast Poll -- Actively poll the remote host by
` periodically sending a point-to-point ARP Request
` to it, and delete the entry if no ARP Reply is
` received from N successive polls. Again, the
` timeout should be on the order of a minute, and
` typically N is 2.
`
` (3) Link-Layer Advice -- If the link-layer driver
` detects a delivery problem, flush the
` corresponding ARP cache entry.
`
` (4) Higher-layer Advice -- Provide a call from the
` Internet layer to the link layer to indicate a
` delivery problem. The effect of this call would
` be to invalidate the corresponding cache entry.
` This call would be analogous to the
` "ADVISE_DELIVPROB()" call from the transport layer
` to the Internet layer (see Section 3.4), and in
` fact the ADVISE_DELIVPROB routine might in turn
` call the link-layer advice routine to invalidate
`
`Internet Engineering Task Force [Page 23]
`
`AT&T Exhibit 1028
`AT&T v. VoIP, IPR 2017-01384
`Page 7
`
`

`

`
`RFC1122 LINK LAYER October 1989
`
` the ARP cache entry.
`
` Approaches (1) and (2) involve ARP cache timeouts on
` the order of a minute or less. In the absence of proxy
` ARP, a timeout this short could create noticeable
` overhead traffic on a very large Ethernet. Therefore,
` it may be necessary to configure a host to lengthen the
` ARP cache timeout.
`
` 2.3.2.2 ARP Packet Queue
`
` The link layer SHOULD save (rather than discard) at least
` one (the latest) packet of each set of packets destined to
` the same unresolved IP address, and transmit the saved
` packet when the address has been resolved.
`
` DISCUSSION:
` Failure to follow this recommendation causes the first
` packet of every exchange to be lost. Although higher-
` layer protocols can generally cope with packet loss by
` retransmission, packet loss does impact performance.
` For example, loss of a TCP open request causes the
` initial round-trip time estimate to be inflated. UDP-
` based applications such as the Domain Name System are
` more seriously affected.
`
` 2.3.3 Ethernet and IEEE 802 Encapsulation
`
` The IP encapsulation for Ethernets is described in RFC-894
` [LINK:3], while RFC-1042 [LINK:4] describes the IP
` encapsulation for IEEE 802 networks. RFC-1042 elaborates and
` replaces the discussion in Section 3.4 of [INTRO:2].
`
` Every Internet host connected to a 10Mbps Ethernet cable:
`
` o MUST be able to send and receive packets using RFC-894
` encapsulation;
`
` o SHOULD be able to receive RFC-1042 packets, intermixed
` with RFC-894 packets; and
`
` o MAY be able to send packets using RFC-1042 encapsulation.
`
` An Internet host that implements sending both the RFC-894 and
` the RFC-1042 encapsulations MUST provide a configuration switch
` to select which is sent, and this switch MUST default to RFC-
` 894.
`
`Internet Engineering Task Force [Page 24]
`
`AT&T Exhibit 1028
`AT&T v. VoIP, IPR 2017-01384
`Page 8
`
`

`

`
`RFC1122 LINK LAYER October 1989
`
` Note that the standard IP encapsulation in RFC-1042 does not
` use the protocol id value (K1=6) that IEEE reserved for IP;
` instead, it uses a value (K1=170) that implies an extension
` (the "SNAP") which can be used to hold the Ether-Type field.
` An Internet system MUST NOT send 802 packets using K1=6.
`
` Address translation from Internet addresses to link-layer
` addresses on Ethernet and IEEE 802 networks MUST be managed by
` the Address Resolution Protocol (ARP).
`
` The MTU for an Ethernet is 1500 and for 802.3 is 1492.
`
` DISCUSSION:
` The IEEE 802.3 specification provides for operation over a
` 10Mbps Ethernet cable, in which case Ethernet and IEEE
` 802.3 frames can be physically intermixed. A receiver can
` distinguish Ethernet and 802.3 frames by the value of the
` 802.3 Length field; this two-octet field coincides in the
` header with the Ether-Type field of an Ethernet frame. In
` particular, the 802.3 Length field must be less than or
` equal to 1500, while all valid Ether-Type values are
` greater than 1500.
`
` Another compatibility problem arises with link-layer
` broadcasts. A broadcast sent with one framing will not be
` seen by hosts that can receive only the other framing.
`
` The provisions of this section were designed to provide
` direct interoperation between 894-capable and 1042-capable
` systems on the same cable, to the maximum extent possible.
` It is intended to support the present situation where
` 894-only systems predominate, while providing an easy
` transition to a possible future in which 1042-capable
` systems become common.
`
` Note that 894-only systems cannot interoperate directly
` with 1042-only systems. If the two system types are set
` up as two different logical networks on the same cable,
` they can communicate only through an IP gateway.
` Furthermore, it is not useful or even possible for a
` dual-format host to discover automatically which format to
` send, because of the problem of link-layer broadcasts.
`
` 2.4 LINK/INTERNET LAYER INTERFACE
`
` The packet receive interface between the IP layer and the link
` layer MUST include a flag to indicate whether the incoming packet
` was addressed to a link-layer broadcast address.
`
`Internet Engineering Task Force [Page 25]
`
`AT&T Exhibit 1028
`AT&T v. VoIP, IPR 2017-01384
`Page 9
`
`