`
`i ig ii3i
`
`DECLARATION OF SANDY GINOZA FOR IETF
`RFC 1122: REQUIREMENTS FOR INTERNET HOSTS — COMMUNICATIQN LAYERS
`
`1, Sandy Ginoza, based on my personai knowledge and information, hereby declare as
`
`follows:
`
`1.
`
`I am an employee of Association Management Solutions, LLC (AMS), which
`
`acts under contract to the Internet Society (1800) as the operator of the RFC Production
`
`Center. The RFC Production Center is part of the "RFC Editor" function, which prepares
`
`documents for publication and places files in an online repository for the authoritative
`
`Request for Comments (RFC) series of documents (RFC Series), and preserves records
`
`relating to these documents. The RFC Series includes, among other things, the series of
`
`Internet standards developed by the Internet Engineering Task Force (EETF), an organized
`
`activity of ISOC. I hold the position of Director of the RFC Production Center. I began
`
`employment with AMS in this capacity on. 6 January 2010.
`
`2.
`
`Among my responsibilities as Director of the RFC Production Center, I act as
`
`the custodian of records relating to the RFC Series, and I am familiar with the record keeping
`
`practices relating to the RFC Series, including the creation and maintenance of Such records.
`
`3.
`
`From June 1999 to 5 January 2010, I was an employee of the Information
`
`Sciences Institute at University of Southern California (181). I held various position titles with
`
`the RFC Editor project at 131, ending with Senior Editor.
`
`4.
`
`The RFC Editor function was conducted by 181 under contract to the United
`
`States government prior to 1998. In 1998, ISOC, in furtherance of its IETF activity, entered into
`
`the first in a series of contracts with 181 providing for ISI‘s performance of the RFC Editor
`
`function. Beginning in 2010, certain aspects of the RFC Editor function were assumed by the
`
`Apple Inc.
`EX. 1009 - Page 1
`
`Apple Inc.
`Ex. 1009 - Page 1
`
`

`

`
`
`RFC Production Center operation of AMS under contract to ISOC (acting through its IETF
`
`function and, in particular, the IETF Administrative Oversight Committee). The business records
`
`of the RFC Editor function as it was conducted by 181 are currently housed on the computer
`
`systems of AMS, as contractor to 1800.
`
`5.
`
`I make this declaration based on my personal knowledge and information
`
`contained in the business records of the RFC Editor as they are currently housed at AMS, or
`
`confirmation with other responsible RFC Editor personnel with such knowledge.
`
`6.
`
`Prior to 1998, the RFC Editor's regular practice was to publish RFCs, making
`
`them available from a repository via FTP When a new RFC was published, an announcement
`
`of its publication, with information on how to access the RFC, would be typically sent out
`
`within 24 hours of the publication.
`
`7.
`
`Any RFC published on the RFC Editor website or via FTP was reasonably
`
`accessible to the public and was disseminated or otherwise available to the extent that persons
`
`interested and ordinarily skilled in the subject matter or art exercising reasonable diligence could
`
`have located it. In particular, the RFCs were indexed and placed in a public repository.
`
`8.
`
`The RFCs are kept in an online repository in the course of the RFC Editor's
`
`regularly conducted activity and ordinary course of business. The records are made pursuant to
`
`established procedures and are relied upon by the RFC Editor in the performance of its functions.
`
`9.
`
`It is the regular practice of the RFC Editor to make and keep the RFC records.
`
`10.
`
`Based on those records, I can state that the publication date of RFC 1122 was
`
`October 1989 (date listed on the RFC), at which time it was reasonably accessible to the public
`
`either on the RFC Editor website or via FTP from a repository. A copy of that RFC is attached
`
`to this declaration as an exhibit.
`
`Apple Inc.
`EX. 1009 - Page 2
`
`Apple Inc.
`Ex. 1009 - Page 2
`
`

`

`Pursuant to Section 1746 of Title 28 of United States Code, I deciare under penalty of
`
`perjury under the laws of the United States of America that the foregoing is true and correct
`
`and that the foregoing is based upon personal knowiedge and information and is believed to be
`
`true.
`
`Date:
`
`1‘
`
`994"" ”W
`
`By:
`
`n
`
`noza
`
`43304035312”
`
`Atttcth CALIF. ACKNOWLEDGMENTWEQH it [W
`“i
`t
`-
`
`Apple Inc.
`Ex. 1009 - Page 3
`
`Apple Inc.
`Ex. 1009 - Page 3
`
`

`

`CIVIL CODE § 1189
`CALIFORNIA ALL—PURPOSE ACKNOWLEDGMENT
`
`
`A notary public or other officer completing this certificate verifies oniy the identity oi the individual who signed the
`document to which this certificate is attached, and not the truthfulness, accuracy, or validity of that document.
`
`State of California Fm
`
`‘
`..
`County of L99 ‘mat/[’6'
`95» be with» Naltrr imbue
`mwbmme
`
` Date Hereg7insert Name and We of the Officer
`personally appeared
`(fit/N101
`SEW“
`Namejsj‘ of Signeyés)
`
`)
`
`who proved to me on the basis of satisfactory evidence to be the person?) whose namejfistafe
`subscribed to the within instrument and acknowtedg d to me that he!
`e hey executed the same In
`his/@their authorized capacityfizs), and that byhis her their signatureisj
`the instrument the persontsa’
`
`entity upon behalf of which the persongs’) acte, executed the instrument.
`
`ort
`
`I certify under PENALTY OF PERJURY under the laws
`of the State of California that the foregoing paragraph
`is true and correct.
`
`1' Notary Public My Comm. Expires Dec 9, 2021
`Noiawfinubiic-Caiiiornia
`:
`Si n ture SSS , i 299 amt“;
`
`WETNESS my hand and ofiiciai seal.
`.
`.,
`
`Q a
`
`Signature
`
`senate/Au
`
`os_ gelesCounty
`“WASP” 3294720
`
`5.:
`
`'
`
`Place Notary Seal Above
`
`OPTIONAL
`
`Though this section is optional, completing this information can deter alteration of the document or
`fraudulent reattachment of this form to an unintended document.
`
`Description of Attached Document
`Titie or Type of Document
`CW“ WI
`Document Date:
`LL
`[3;
`Signeris) Other Than Named Above:
`
`“NM
`
`[if Sand
`
`Git/10l01 WI ETF CV—HCL[W MWQMU/Hfi firlflWt’lfd‘
`Number of Pages:
`2
`
`Capacityfies) Ciaimed by Signer(s)
`Signer's Name:
`El Corporate Officer — Title(s):
`[:1 Partner — D Limited
`[3 Generat
`
`El individual
`[:1 Trustee
`l:i Other:
`Signer is Representing:
`
`[I] Attorney in Fact
`El Guardian or Conservator
`
`Signer’s Name:
`E] Corporate Officer — Title(s):
`3 Partner — El Limited
`[3 Generat
`
`
`
`[J individual
`El Trustee
`3 Other:
`Signer Is Representing:
`
`El Attorney in Fact
`Cl Guardian or Conservator
`
`
`©2016 Nationai NotaryAssociation- www.NationalNotary.org- 1800-US NOTARY (1—-800—876——6827)
`item #5907
`
`Apple Inc.
`EX. 1009 - Page 4
`
`Apple Inc.
`Ex. 1009 - Page 4
`
`

`

`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]
`
`Apple Inc.
`Ex. 1009 - Page 5
`
`

`

`
`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]
`
`Apple Inc.
`Ex. 1009 - Page 6
`
`

`

`
`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]
`
`Apple Inc.
`Ex. 1009 - Page 7
`
`

`

`
`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]
`
`Apple Inc.
`Ex. 1009 - Page 8
`
`

`

`
`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]
`
`Apple Inc.
`Ex. 1009 - Page 9
`
`

`

`
`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]
`
`Apple Inc.
`Ex. 1009 - Page 10
`
`

`

`
`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]
`
`Apple Inc.
`Ex. 1009 - Page 11
`
`

`

`
`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]
`
`Apple Inc.
`Ex. 1009 - Page 12
`
`

`

`
`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]
`
`Apple Inc.
`Ex. 1009 - Page 13
`
`

`

`
`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]
`
`Apple Inc.
`Ex. 1009 - Page 14
`
`

`

`
`RFC1122