RFC 768
`
`Introduction
`------------
`
`J. Postel
`ISI
`28 August 1980
`
`User Datagram Protocol
`----------------------
`
`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].
`
`0 7 8 15 16 23 24 31
`+--------+--------+--------+--------+
`| Source | Destination |
`| Port | Port
`|
`+--------+--------+--------+--------+
`|
`|
`|
`| Length | Checksum
`|
`+--------+--------+--------+--------+
`
`| |
`
` data octets ...
`+---------------- ...
`
`User Datagram Header Format
`
`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]
`
`Packet Intelligence LLC Exh 2064
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 1 of 3
`
`

`

`
` 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
`
`28 Aug 1980
`RFC 768 User Datagram Protocol
`
`Packet Intelligence LLC Exh 2064
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 2 of 3
`
`

`

` 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]
`
`Packet Intelligence LLC Exh 2064
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 3 of 3
`
`