DECLARATION OF SANDY GINO A FOR IETF
`
`RFC 768: U er Da
`
`RFC 793 : Transmission Control rotocol
`
`I, Sandy Ginoza, hereby declare that all statements m e herein are of my own
`
`knowledge and are true and that all statements made on info ation and belief are believed to be
`
`true; and further that these statements were made with the kn
`
`ledge that willful false
`
`statements and the like so made are punishable by fine or imp · sonment, or both, under Section
`
`1001 of Title 18 of the United States Code:
`
`1.
`
`I am an employee of Association Managem nt Solutions, LLC (AMS), which
`
`acts under contract to the IETF Administration LLC (IETF) a the operator of the RFC
`
`Production Center. The RFC Production Center is part of th "RFC Editor" function, which
`
`prepares documents for publication and places files in an on ine repository for the
`
`authoritative Request for Comments (RFC) series of docum
`
`ts (RFC Series), and preserves
`
`records relating to these documents. The RFC Series include , among other things, the series
`
`of Internet standards developed by the IETF. I hold the posi on of Director of the RFC
`
`Production Center. I began employment with AMS in this ca acity on 6 January 2010.
`
`2.
`
`Among my responsibilities as Director of the C Production Center, I act as
`
`the custodian of records relating to the RFC Series, and I am f: miliar 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 mployee of the Information
`
`Sciences Institute at University of Southern California (ISi). I eld various position titles with
`
`the RFC Editor project at ISi, ending with Senior Editor.
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 1 of 152
`
`

`

`4.
`
`The RFC Editor function was conducted by SI under contract to the United
`
`States government prior to 1998. In 1998, ISOC, in furtheran e of its IETF activity, entered into
`
`the first in a series of contracts with ISi providing for ISI's pe ormance of the RFC Editor
`
`function. Beginning in 2010, certain aspects of the RFC Edit r function were assumed by the
`
`RFC Production Center operation of AMS under contract to I OC (acting through its IETF
`
`function and, in particular, the IETF Administrative Oversigh Committee (now the IETF
`
`Administration LLC (IETF)). The business records of the RF Editor function as it was
`
`conducted by ISi are currently housed on the computer syste s of AMS, as contractor to the
`
`IETF.
`
`5.
`
`I make this declaration based on my person I knowledge and information
`
`contained in the business records of the RFC Editor as they a e currently housed at AMS, or
`
`confirmation with other responsible RFC Editor personnel wi h such knowledge.
`
`6.
`
`Prior to 1998, the RFC Editor's regular pra tice was to publish RFCs, making
`
`them available from a repository via FTP. When a new RF was published, an announcement
`
`of its publication, with information on how to access the C, would be typically sent out
`
`within 24 hours of the publication.
`
`7.
`
`Since 1998, the RFC Editor' s regular practi e was to publish RFCs, making
`
`them available on the RFC Editor website or via FTP. When a new RFC was published, an
`
`announcement of its publication, with information on how
`
`access the RFC, would be
`
`typically sent out within 24 hours of the publication. The a nouncement would go out to all
`
`subscribers and a contemporaneous electronic record of the announcement is kept in the IETF
`
`mail archive that is available online.
`
`2
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 2 of 152
`
`

`

`8.
`
`Beginning in 1998, any RFC published on t e RFC Editor website or via FTP
`
`was reasonably accessible to the public and was disseminate or otherwise available to the extent
`
`that persons interested and ordinarily skilled in the subject m tter or art exercising reasonable
`
`diligence could have located it. In particular, the RFCs were i dexed and placed in a public
`
`repository.
`
`9.
`
`The RFCs are kept in an online repository in the course of the RFC Editor's
`
`regularly conducted activity and ordinary course of business. he records are made pursuant to
`
`established procedures and are relied upon by the RFC Editor ·n the performance of its functions.
`
`10.
`
`11 .
`
`It is the regular practice of the RFC Editor t make and keep the RFC records.
`
`Based on the business records for the RFC E itor and the RFC Editor's course
`
`of conduct in publishing RFCs, I have determined that the pub ication date of RFC 768 was no
`
`later than October 1992, at which time it was reasonably acce ible to the public either on the
`
`RFC Editor website or via FTP from a repository. An announ ement of its publication also
`
`would have been sent out to subscribers within 24 hours of its ublication. A copy of that RFC
`
`is attached to this declaration as Exhibit 1.
`
`12.
`
`Based on the business records for the RFC E itor and the RFC Editor's course
`
`of conduct in publishing RFCs, I have determined that the pub ication date of RFC 791 was no
`
`later than October 1992, at which time it was reasonably acces ible to the public either on the
`
`RFC Editor website or via FTP from a repository. An announ ement of its publication also
`
`would have been sent out to subscribers within 24 hours of its ublication. A copy of that RFC
`
`is attached to this declaration as Exhibit 2.
`
`13 .
`
`Based on the business records for the RFC E
`
`tor and the RFC Editor's course
`
`of conduct in publishing RFCs, I have determined that the publ cation date of RFC 793 was no
`
`3
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 3 of 152
`
`

`

`later than October 1992, at which time it was reasonably acce sible to the public either on the
`
`RFC Editor website or via FTP from a repository. An annou cement of its publication also
`
`would have been sent out to subscribers within 24 hours of its publication. A copy of that RFC
`
`is attached to this declaration as Exhibit 3.
`
`Pursuant to Section 1746 of Title 28 of United States Code, I declare under penalty of
`
`perjury under the laws of the United States of America that e foregoing is true and correct
`
`and that the foregoing is based upon personal knowledge an information and is believed to be
`
`true.
`
`Date:
`
`4890-6189-2620
`
`4
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 4 of 152
`
`

`

`EXHIBIT 1
`EXHIBIT 1
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 5 of 152
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 5 of 152
`
`

`

`RFC 768 J. Postel
` ISI
` 28 August 1980
`
` User Datagram Protocol
` ----------------------
`
`Introduction
`------------
`
`This User Datagram Protocol (UDP) is defined to make available a
`datagram mode of packet-switched computer communication in the
`environment of an interconnected set of computer networks. This
`protocol assumes that the Internet Protocol (IP) [1] is used as the
`underlying protocol.
`
`This protocol provides a procedure for application programs to send
`messages to other programs with a minimum of protocol mechanism. The
`protocol is transaction oriented, and delivery and duplicate protection
`are not guaranteed. Applications requiring ordered reliable delivery of
`streams of data should use the Transmission Control Protocol (TCP) [2].
`
`Format
`------
`
`
` 0 7 8 15 16 23 24 31
` +--------+--------+--------+--------+
` | Source | Destination |
` | Port | Port |
` +--------+--------+--------+--------+
` | | |
` | Length | Checksum |
` +--------+--------+--------+--------+
` |
` | data octets ...
` +---------------- ...
`
` User Datagram Header Format
`
`Fields
`------
`
`Source Port is an optional field, when meaningful, it indicates the port
`of the sending process, and may be assumed to be the port to which a
`reply should be addressed in the absence of any other information. If
`not used, a value of zero is inserted.
`
`Postel [page 1]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 6 of 152
`
`

`

` 28 Aug 1980
`User Datagram Protocol RFC 768
`Fields
`
`Destination Port has a meaning within the context of a particular
`internet destination address.
`
`Length is the length in octets of this user datagram including this
`header and the data. (This means the minimum value of the length is
`eight.)
`
`Checksum is the 16-bit one’s complement of the one’s complement sum of a
`pseudo header of information from the IP header, the UDP header, and the
`data, padded with zero octets at the end (if necessary) to make a
`multiple of two octets.
`
`The pseudo header conceptually prefixed to the UDP header contains the
`source address, the destination address, the protocol, and the UDP
`length. This information gives protection against misrouted datagrams.
`This checksum procedure is the same as is used in TCP.
`
` 0 7 8 15 16 23 24 31
` +--------+--------+--------+--------+
` | source address |
` +--------+--------+--------+--------+
` | destination address |
` +--------+--------+--------+--------+
` | zero |protocol| UDP length |
` +--------+--------+--------+--------+
`
`If the computed checksum is zero, it is transmitted as all ones (the
`equivalent in one’s complement arithmetic). An all zero transmitted
`checksum value means that the transmitter generated no checksum (for
`debugging or for higher level protocols that don’t care).
`
`User Interface
`--------------
`
`A user interface should allow
`
` the creation of new receive ports,
`
` receive operations on the receive ports that return the data octets
` and an indication of source port and source address,
`
` and an operation that allows a datagram to be sent, specifying the
` data, source and destination ports and addresses to be sent.
`
`[page 2] Postel
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 7 of 152
`
`

`

`28 Aug 1980
`RFC 768 User Datagram Protocol
` IP Interface
`
`IP Interface
`-------------
`
`The UDP module must be able to determine the source and destination
`internet addresses and the protocol field from the internet header. One
`possible UDP/IP interface would return the whole internet datagram
`including all of the internet header in response to a receive operation.
`Such an interface would also allow the UDP to pass a full internet
`datagram complete with header to the IP to send. The IP would verify
`certain fields for consistency and compute the internet header checksum.
`
`Protocol Application
`--------------------
`
`The major uses of this protocol is the Internet Name Server [3], and the
`Trivial File Transfer [4].
`
`Protocol Number
`---------------
`
`This is protocol 17 (21 octal) when used in the Internet Protocol.
`Other protocol numbers are listed in [5].
`
`References
`----------
`
`[1] Postel, J., "Internet Protocol," RFC 760, USC/Information
` Sciences Institute, January 1980.
`
`[2] Postel, J., "Transmission Control Protocol," RFC 761,
` USC/Information Sciences Institute, January 1980.
`
`[3] Postel, J., "Internet Name Server," USC/Information Sciences
` Institute, IEN 116, August 1979.
`
`[4] Sollins, K., "The TFTP Protocol," Massachusetts Institute of
` Technology, IEN 133, January 1980.
`
`[5] Postel, J., "Assigned Numbers," USC/Information Sciences
` Institute, RFC 762, January 1980.
`
`Postel [page 3]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 8 of 152
`
`

`

`EXHIBIT 2
`EXHIBIT 2
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 9 of 152
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 9 of 152
`
`

`

`RFC: 791
`
`
`
`
`
`
`
` INTERNET PROTOCOL
`
`
` DARPA INTERNET PROGRAM
`
` PROTOCOL SPECIFICATION
`
`
`
` September 1981
`
` prepared for
`
` Defense Advanced Research Projects Agency
` Information Processing Techniques Office
` 1400 Wilson Boulevard
` Arlington, Virginia 22209
`
` by
`
` Information Sciences Institute
` University of Southern California
` 4676 Admiralty Way
` Marina del Rey, California 90291
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 10 of 152
`
`

`

`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 11 of 152
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 11 of 152
`
`

`

`September 1981
` Internet Protocol
`
` TABLE OF CONTENTS
`
` PREFACE ........................................................ iii
`
`1. INTRODUCTION ..................................................... 1
`
` 1.1 Motivation .................................................... 1
` 1.2 Scope ......................................................... 1
` 1.3 Interfaces .................................................... 1
` 1.4 Operation ..................................................... 2
`
`2. OVERVIEW ......................................................... 5
`
` 2.1 Relation to Other Protocols ................................... 9
` 2.2 Model of Operation ............................................ 5
` 2.3 Function Description .......................................... 7
` 2.4 Gateways ...................................................... 9
`
`3. SPECIFICATION ................................................... 11
`
` 3.1 Internet Header Format ....................................... 11
` 3.2 Discussion ................................................... 23
` 3.3 Interfaces ................................................... 31
`
`APPENDIX A: Examples & Scenarios ................................... 34
`APPENDIX B: Data Transmission Order ................................ 39
`
`GLOSSARY ............................................................ 41
`
`REFERENCES .......................................................... 45
`
` [Page i]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 12 of 152
`
`

`

` September 1981
`Internet Protocol
`
`[Page ii]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 13 of 152
`
`

`

`September 1981
` Internet Protocol
`
` PREFACE
`
`This document specifies the DoD Standard Internet Protocol. This
`document is based on six earlier editions of the ARPA Internet Protocol
`Specification, and the present text draws heavily from them. There have
`been many contributors to this work both in terms of concepts and in
`terms of text. This edition revises aspects of addressing, error
`handling, option codes, and the security, precedence, compartments, and
`handling restriction features of the internet protocol.
`
` Jon Postel
`
` Editor
`
` [Page iii]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 14 of 152
`
`

`

`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 15 of 152
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 15 of 152
`
`

`

` September 1981
`
`RFC: 791
`Replaces: RFC 760
`IENs 128, 123, 111,
`80, 54, 44, 41, 28, 26
`
` INTERNET PROTOCOL
`
` DARPA INTERNET PROGRAM
` PROTOCOL SPECIFICATION
`
` 1. INTRODUCTION
`
`1.1. Motivation
`
` The Internet Protocol is designed for use in interconnected systems of
` packet-switched computer communication networks. Such a system has
` been called a "catenet" [1]. The internet protocol provides for
` transmitting blocks of data called datagrams from sources to
` destinations, where sources and destinations are hosts identified by
` fixed length addresses. The internet protocol also provides for
` fragmentation and reassembly of long datagrams, if necessary, for
` transmission through "small packet" networks.
`
`1.2. Scope
`
` The internet protocol is specifically limited in scope to provide the
` functions necessary to deliver a package of bits (an internet
` datagram) from a source to a destination over an interconnected system
` of networks. There are no mechanisms to augment end-to-end data
` reliability, flow control, sequencing, or other services commonly
` found in host-to-host protocols. The internet protocol can capitalize
` on the services of its supporting networks to provide various types
` and qualities of service.
`
`1.3. Interfaces
`
` This protocol is called on by host-to-host protocols in an internet
` environment. This protocol calls on local network protocols to carry
` the internet datagram to the next gateway or destination host.
`
` For example, a TCP module would call on the internet module to take a
` TCP segment (including the TCP header and user data) as the data
` portion of an internet datagram. The TCP module would provide the
` addresses and other parameters in the internet header to the internet
` module as arguments of the call. The internet module would then
` create an internet datagram and call on the local network interface to
` transmit the internet datagram.
`
` In the ARPANET case, for example, the internet module would call on a
`
` [Page 1]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 16 of 152
`
`

`

` September 1981
`Internet Protocol
`Introduction
`
` local net module which would add the 1822 leader [2] to the internet
` datagram creating an ARPANET message to transmit to the IMP. The
` ARPANET address would be derived from the internet address by the
` local network interface and would be the address of some host in the
` ARPANET, that host might be a gateway to other networks.
`
`1.4. Operation
`
` The internet protocol implements two basic functions: addressing and
` fragmentation.
`
` The internet modules use the addresses carried in the internet header
` to transmit internet datagrams toward their destinations. The
` selection of a path for transmission is called routing.
`
` The internet modules use fields in the internet header to fragment and
` reassemble internet datagrams when necessary for transmission through
` "small packet" networks.
`
` The model of operation is that an internet module resides in each host
` engaged in internet communication and in each gateway that
` interconnects networks. These modules share common rules for
` interpreting address fields and for fragmenting and assembling
` internet datagrams. In addition, these modules (especially in
` gateways) have procedures for making routing decisions and other
` functions.
`
` The internet protocol treats each internet datagram as an independent
` entity unrelated to any other internet datagram. There are no
` connections or logical circuits (virtual or otherwise).
`
` The internet protocol uses four key mechanisms in providing its
` service: Type of Service, Time to Live, Options, and Header Checksum.
`
` The Type of Service is used to indicate the quality of the service
` desired. The type of service is an abstract or generalized set of
` parameters which characterize the service choices provided in the
` networks that make up the internet. This type of service indication
` is to be used by gateways to select the actual transmission parameters
` for a particular network, the network to be used for the next hop, or
` the next gateway when routing an internet datagram.
`
` The Time to Live is an indication of an upper bound on the lifetime of
` an internet datagram. It is set by the sender of the datagram and
` reduced at the points along the route where it is processed. If the
` time to live reaches zero before the internet datagram reaches its
` destination, the internet datagram is destroyed. The time to live can
` be thought of as a self destruct time limit.
`
`[Page 2]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 17 of 152
`
`

`

`September 1981
` Internet Protocol
` Introduction
`
` The Options provide for control functions needed or useful in some
` situations but unnecessary for the most common communications. The
` options include provisions for timestamps, security, and special
` routing.
`
` The Header Checksum provides a verification that the information used
` in processing internet datagram has been transmitted correctly. The
` data may contain errors. If the header checksum fails, the internet
` datagram is discarded at once by the entity which detects the error.
`
` The internet protocol does not provide a reliable communication
` facility. There are no acknowledgments either end-to-end or
` hop-by-hop. There is no error control for data, only a header
` checksum. There are no retransmissions. There is no flow control.
`
` Errors detected may be reported via the Internet Control Message
` Protocol (ICMP) [3] which is implemented in the internet protocol
` module.
`
`
`
` [Page 3]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 18 of 152
`
`

`

` September 1981
`Internet Protocol
`
`[Page 4]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 19 of 152
`
`

`

`September 1981
` Internet Protocol
`
` 2. OVERVIEW
`
`2.1. Relation to Other Protocols
`
` The following diagram illustrates the place of the internet protocol
` in the protocol hierarchy:
`
`
` +------+ +-----+ +-----+ +-----+
` |Telnet| | FTP | | TFTP| ... | ... |
` +------+ +-----+ +-----+ +-----+
` | | | |
` +-----+ +-----+ +-----+
` | TCP | | UDP | ... | ... |
` +-----+ +-----+ +-----+
` | | |
` +--------------------------+----+
` | Internet Protocol & ICMP |
` +--------------------------+----+
` |
` +---------------------------+
` | Local Network Protocol |
` +---------------------------+
`
` Protocol Relationships
`
` Figure 1.
`
` Internet protocol interfaces on one side to the higher level
` host-to-host protocols and on the other side to the local network
` protocol. In this context a "local network" may be a small network in
` a building or a large network such as the ARPANET.
`
`2.2. Model of Operation
`
` The model of operation for transmitting a datagram from one
` application program to another is illustrated by the following
` scenario:
`
` We suppose that this transmission will involve one intermediate
` gateway.
`
` The sending application program prepares its data and calls on its
` local internet module to send that data as a datagram and passes the
` destination address and other parameters as arguments of the call.
`
` The internet module prepares a datagram header and attaches the data
` to it. The internet module determines a local network address for
` this internet address, in this case it is the address of a gateway.
`
` [Page 5]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 20 of 152
`
`

`

` September 1981
`Internet Protocol
`Overview
`
` It sends this datagram and the local network address to the local
` network interface.
`
` The local network interface creates a local network header, and
` attaches the datagram to it, then sends the result via the local
` network.
`
` The datagram arrives at a gateway host wrapped in the local network
` header, the local network interface strips off this header, and
` turns the datagram over to the internet module. The internet module
` determines from the internet address that the datagram is to be
` forwarded to another host in a second network. The internet module
` determines a local net address for the destination host. It calls
` on the local network interface for that network to send the
` datagram.
`
` This local network interface creates a local network header and
` attaches the datagram sending the result to the destination host.
`
` At this destination host the datagram is stripped of the local net
` header by the local network interface and handed to the internet
` module.
`
` The internet module determines that the datagram is for an
` application program in this host. It passes the data to the
` application program in response to a system call, passing the source
` address and other parameters as results of the call.
`
`
` Application Application
` Program Program
` \ /
` Internet Module Internet Module Internet Module
` \ / \ /
` LNI-1 LNI-1 LNI-2 LNI-2
` \ / \ /
` Local Network 1 Local Network 2
`
` Transmission Path
`
` Figure 2
`
`[Page 6]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 21 of 152
`
`

`

`September 1981
` Internet Protocol
` Overview
`
`2.3. Function Description
`
` The function or purpose of Internet Protocol is to move datagrams
` through an interconnected set of networks. This is done by passing
` the datagrams from one internet module to another until the
` destination is reached. The internet modules reside in hosts and
` gateways in the internet system. The datagrams are routed from one
` internet module to another through individual networks based on the
` interpretation of an internet address. Thus, one important mechanism
` of the internet protocol is the internet address.
`
` In the routing of messages from one internet module to another,
` datagrams may need to traverse a network whose maximum packet size is
` smaller than the size of the datagram. To overcome this difficulty, a
` fragmentation mechanism is provided in the internet protocol.
`
` Addressing
`
` A distinction is made between names, addresses, and routes [4]. A
` name indicates what we seek. An address indicates where it is. A
` route indicates how to get there. The internet protocol deals
` primarily with addresses. It is the task of higher level (i.e.,
` host-to-host or application) protocols to make the mapping from
` names to addresses. The internet module maps internet addresses to
` local net addresses. It is the task of lower level (i.e., local net
` or gateways) procedures to make the mapping from local net addresses
` to routes.
`
` Addresses are fixed length of four octets (32 bits). An address
` begins with a network number, followed by local address (called the
` "rest" field). There are three formats or classes of internet
` addresses: in class a, the high order bit is zero, the next 7 bits
` are the network, and the last 24 bits are the local address; in
` class b, the high order two bits are one-zero, the next 14 bits are
` the network and the last 16 bits are the local address; in class c,
` the high order three bits are one-one-zero, the next 21 bits are the
` network and the last 8 bits are the local address.
`
` Care must be taken in mapping internet addresses to local net
` addresses; a single physical host must be able to act as if it were
` several distinct hosts to the extent of using several distinct
` internet addresses. Some hosts will also have several physical
` interfaces (multi-homing).
`
` That is, provision must be made for a host to have several physical
` interfaces to the network with each having several logical internet
` addresses.
`
` [Page 7]
`
`IPR2022-00833
`CommScope, Inc. Exhibit 1034
`Page 22 of 152
`
`

`

` September 1981
`Internet Protocol
`Overview
`
` Examples of address mappings may be found in "Address Mappings" [5].
`
` Fragmentation
`
` Fragmentation of an internet datagram is necessary when it
` originates in a local net that allows a large packet size and must
` traverse a local net that limits packets to a smaller size to reach
` its destination.
`
` An internet datagram can be marked "don’t fragment." Any internet
` datagram so marked is not to be internet fragmented under any
` circumstances. If internet datagram marked don’t fragment cannot be
` delivered to its destination without fragmenting it, it is to be
` discarded instead.
`
` Fragmentation, transmission and reassembly across a local network
` which is invisible to the internet protocol module is called
` intranet fragmentation and may be used [6].
`
` The internet fragmentation and reassembly procedure needs to be able
` to break a datagram into an almost arbitrary number of pieces that
` can be later reassembled. The receiver of the fragments uses the
` identification field to ensure that fragments of different datagrams
` are not mixed. The fragment offset field tells the receiver the
` position of a fragment in the original datagram. The fragment
` offset and length determine the portion of the original datagram
` covered by this fragment. The more-fragments flag indicates (by
` being reset) the last fragment. These fields provide sufficient
` information to reassemble datagrams.
`
` The identification field is used to distinguish the fragments of one
` datagram from those of another. Th