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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket