175 lines
5.8 KiB
Plaintext
175 lines
5.8 KiB
Plaintext
|
||
|
||
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]
|
||
|
||
|
||
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
|
||
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]
|
||
|