home *** CD-ROM | disk | FTP | other *** search
/ Hackers Toolkit 2.0 / Hackers_Toolkit_v2.0.iso / HTML / archive / Texts / Rfc / RFC768.TXT < prev    next >
Encoding:
Text File  |  1999-11-04  |  6.1 KB  |  174 lines

  1. RFC 768
  2.                             J. Postel
  3.                             ISI
  4.                             28 August 1980
  5.  
  6.  
  7.  
  8.                          User Datagram Protocol
  9.                          ----------------------
  10.  
  11. Introduction
  12. ------------
  13.  
  14. This User Datagram  Protocol  (UDP)  is  defined  to  make  available  a
  15. datagram   mode  of  packet-switched   computer   communication  in  the
  16. environment  of  an  interconnected  set  of  computer  networks.   This
  17. protocol  assumes  that the Internet  Protocol  (IP)  [1] is used as the
  18. underlying protocol.
  19.  
  20. This protocol  provides  a procedure  for application  programs  to send
  21. messages  to other programs  with a minimum  of protocol mechanism.  The
  22. protocol  is transaction oriented, and delivery and duplicate protection
  23. are not guaranteed.  Applications requiring ordered reliable delivery of
  24. streams of data should use the Transmission Control Protocol (TCP) [2].
  25.  
  26. Format
  27. ------
  28.  
  29.                                     
  30.                   0      7 8     15 16    23 24    31  
  31.                  +--------+--------+--------+--------+ 
  32.                  |     Source      |   Destination   | 
  33.                  |      Port       |      Port       | 
  34.                  +--------+--------+--------+--------+ 
  35.                  |                 |                 | 
  36.                  |     Length      |    Checksum     | 
  37.                  +--------+--------+--------+--------+ 
  38.                  |                                     
  39.                  |          data octets ...            
  40.                  +---------------- ...                 
  41.  
  42.                       User Datagram Header Format
  43.  
  44. Fields
  45. ------
  46.  
  47. Source Port is an optional field, when meaningful, it indicates the port
  48. of the sending  process,  and may be assumed  to be the port  to which a
  49. reply should  be addressed  in the absence of any other information.  If
  50. not used, a value of zero is inserted.
  51.  
  52.  
  53.  
  54.  
  55.  
  56. Postel                                                          [page 1]
  57.  
  58.  
  59.                                                              28 Aug 1980
  60. User Datagram Protocol                                           RFC <A NAME=id124 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc768.html">768</A>
  61. Fields
  62.  
  63.  
  64.  
  65. Destination  Port has a meaning  within  the  context  of  a  particular
  66. internet destination address.
  67.  
  68. Length  is the length  in octets  of this user datagram  including  this
  69. header  and the data.   (This  means  the minimum value of the length is
  70. eight.)
  71.  
  72. Checksum is the 16-bit one's complement of the one's complement sum of a
  73. pseudo header of information from the IP header, the UDP header, and the
  74. data,  padded  with zero octets  at the end (if  necessary)  to  make  a
  75. multiple of two octets.
  76.  
  77. The pseudo  header  conceptually prefixed to the UDP header contains the
  78. source  address,  the destination  address,  the protocol,  and the  UDP
  79. length.   This information gives protection against misrouted datagrams.
  80. This checksum procedure is the same as is used in TCP.
  81.  
  82.                   0      7 8     15 16    23 24    31 
  83.                  +--------+--------+--------+--------+
  84.                  |          source address           |
  85.                  +--------+--------+--------+--------+
  86.                  |        destination address        |
  87.                  +--------+--------+--------+--------+
  88.                  |  zero  |protocol|   UDP length    |
  89.                  +--------+--------+--------+--------+
  90.  
  91. If the computed  checksum  is zero,  it is transmitted  as all ones (the
  92. equivalent  in one's complement  arithmetic).   An all zero  transmitted
  93. checksum  value means that the transmitter  generated  no checksum  (for
  94. debugging or for higher level protocols that don't care).
  95.  
  96. User Interface
  97. --------------
  98.  
  99. A user interface should allow
  100.  
  101.   the creation of new receive ports,
  102.  
  103.   receive  operations  on the receive  ports that return the data octets
  104.   and an indication of source port and source address,
  105.  
  106.   and an operation  that allows  a datagram  to be sent,  specifying the
  107.   data, source and destination ports and addresses to be sent.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. [page 2]                                                          Postel
  115.  
  116.  
  117. 28 Aug 1980
  118. RFC <A NAME=id240 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc768.html">768</A>                                           User Datagram Protocol
  119.                                                             IP Interface
  120.  
  121.  
  122.  
  123. IP Interface
  124. -------------
  125.  
  126. The UDP module  must be able to determine  the  source  and  destination
  127. internet addresses and the protocol field from the internet header.  One
  128. possible  UDP/IP  interface  would return  the whole  internet  datagram
  129. including all of the internet header in response to a receive operation.
  130. Such an interface  would  also allow  the UDP to pass  a  full  internet
  131. datagram  complete  with header  to the IP to send.  The IP would verify
  132. certain fields for consistency and compute the internet header checksum.
  133.  
  134. Protocol Application
  135. --------------------
  136.  
  137. The major uses of this protocol is the Internet Name Server [3], and the
  138. Trivial File Transfer [4].
  139.  
  140. Protocol Number
  141. ---------------
  142.  
  143. This is protocol  17 (21 octal)  when used  in  the  Internet  Protocol.
  144. Other protocol numbers are listed in [5].
  145.  
  146. References
  147. ----------
  148.  
  149. [1]     Postel,   J.,   "Internet  Protocol,"  RFC <A NAME=id303 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc760.html">760</A>,  USC/Information
  150.         Sciences Institute, January 1980.
  151.  
  152. [2]     Postel,    J.,   "Transmission   Control   Protocol,"   RFC <A NAME=id310 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc761.html">761</A>,
  153.         USC/Information Sciences Institute, January 1980.
  154.  
  155. [3]     Postel,  J.,  "Internet  Name Server,"  USC/Information Sciences
  156.         Institute, IEN <A NAME=id320 HREF="http://www.cis.ohio-state.edu/htbin/ien/ien-116.html">116</A>, August 1979.
  157.  
  158. [4]     Sollins,  K.,  "The TFTP Protocol,"  Massachusetts  Institute of
  159.         Technology, IEN <A NAME=id327 HREF="http://www.cis.ohio-state.edu/htbin/ien/ien-133.html">133</A>, January 1980.
  160.  
  161. [5]     Postel,   J.,   "Assigned   Numbers,"  USC/Information  Sciences
  162.         Institute, RFC <A NAME=id333 HREF="http://www.cis.ohio-state.edu/htbin/rfc/rfc762.html">762</A>, January 1980.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172. Postel                                                          [page 3]
  173.  
  174.