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]
|
|||
|
|