1 files changed, 174 insertions, 0 deletions
diff --git a/doc/rfc/rfc768.txt b/doc/rfc/rfc768.txt
new file mode 100644
index 0000000..cbd850e
--- /dev/null
+++ b/doc/rfc/rfc768.txt
@@ -0,0 +1,174 @@
+
+
+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]
+
+\ No newline at end of file