doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc1350.txt b/doc/rfc/rfc1350.txt
new file mode 100644
index 0000000..e00113b
--- /dev/null
+++ b/doc/rfc/rfc1350.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                         K. Sollins
+Request For Comments: 1350                                           MIT
+STD: 33                                                        July 1992
+Obsoletes: RFC 783
+
+
+                     THE TFTP PROTOCOL (REVISION 2)
+
+Status of this Memo
+
+   This RFC specifies an IAB standards track protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+Summary
+
+   TFTP is a very simple protocol used to transfer files.  It is from
+   this that its name comes, Trivial File Transfer Protocol or TFTP.
+   Each nonterminal packet is acknowledged separately.  This document
+   describes the protocol and its types of packets.  The document also
+   explains the reasons behind some of the design decisions.
+
+Acknowlegements
+
+   The protocol was originally designed by Noel Chiappa, and was
+   redesigned by him, Bob Baldwin and Dave Clark, with comments from
+   Steve Szymanski.  The current revision of the document includes
+   modifications stemming from discussions with and suggestions from
+   Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald,
+   Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy
+   Yellick, and the author.  The acknowledgement and retransmission
+   scheme was inspired by TCP, and the error mechanism was suggested by
+   PARC's EFTP abort message.
+
+   The May, 1992 revision to fix the "Sorcerer's Apprentice" protocol
+   bug [4] and other minor document problems was done by Noel Chiappa.
+
+   This research was supported by the Advanced Research Projects Agency
+   of the Department of Defense and was monitored by the Office of Naval
+   Research under contract number N00014-75-C-0661.
+
+1. Purpose
+
+   TFTP is a simple protocol to transfer files, and therefore was named
+   the Trivial File Transfer Protocol or TFTP.  It has been implemented
+   on top of the Internet User Datagram protocol (UDP or Datagram) [2]
+
+
+
+Sollins                                                         [Page 1]
+
+RFC 1350                    TFTP Revision 2                    July 1992
+
+
+   so it may be used to move files between machines on different
+   networks implementing UDP.  (This should not exclude the possibility
+   of implementing TFTP on top of other datagram protocols.)  It is
+   designed to be small and easy to implement.  Therefore, it lacks most
+   of the features of a regular FTP.  The only thing it can do is read
+   and write files (or mail) from/to a remote server.  It cannot list
+   directories, and currently has no provisions for user authentication.
+   In common with other Internet protocols, it passes 8 bit bytes of
+   data.
+
+   Three modes of transfer are currently supported: netascii (This is
+   ascii as defined in "USA Standard Code for Information Interchange"
+   [1] with the modifications specified in "Telnet Protocol
+   Specification" [3].)  Note that it is 8 bit ascii.  The term
+   "netascii" will be used throughout this document to mean this
+   particular version of ascii.); octet (This replaces the "binary" mode
+   of previous versions of this document.) raw 8 bit bytes; mail,
+   netascii characters sent to a user rather than a file.  (The mail
+   mode is obsolete and should not be implemented or used.)  Additional
+   modes can be defined by pairs of cooperating hosts.
+
+   Reference [4] (section 4.2) should be consulted for further valuable
+   directives and suggestions on TFTP.
+
+2. Overview of the Protocol
+
+   Any transfer begins with a request to read or write a file, which
+   also serves to request a connection.  If the server grants the
+   request, the connection is opened and the file is sent in fixed
+   length blocks of 512 bytes.  Each data packet contains one block of
+   data, and must be acknowledged by an acknowledgment packet before the
+   next packet can be sent.  A data packet of less than 512 bytes
+   signals termination of a transfer.  If a packet gets lost in the
+   network, the intended recipient will timeout and may retransmit his
+   last packet (which may be data or an acknowledgment), thus causing
+   the sender of the lost packet to retransmit that lost packet.  The
+   sender has to keep just one packet on hand for retransmission, since
+   the lock step acknowledgment guarantees that all older packets have
+   been received.  Notice that both machines involved in a transfer are
+   considered senders and receivers.  One sends data and receives
+   acknowledgments, the other sends acknowledgments and receives data.
+
+   Most errors cause termination of the connection.  An error is
+   signalled by sending an error packet.  This packet is not
+   acknowledged, and not retransmitted (i.e., a TFTP server or user may
+   terminate after sending an error message), so the other end of the
+   connection may not get it.  Therefore timeouts are used to detect
+   such a termination when the error packet has been lost.  Errors are
+
+
+
+Sollins                                                         [Page 2]
+
+RFC 1350                    TFTP Revision 2                    July 1992
+
+
+   caused by three types of events: not being able to satisfy the
+   request (e.g., file not found, access violation, or no such user),
+   receiving a packet which cannot be explained by a delay or
+   duplication in the network (e.g., an incorrectly formed packet), and
+   losing access to a necessary resource (e.g., disk full or access
+   denied during a transfer).
+
+   TFTP recognizes only one error condition that does not cause
+   termination, the source port of a received packet being incorrect.
+   In this case, an error packet is sent to the originating host.
+
+   This protocol is very restrictive, in order to simplify
+   implementation.  For example, the fixed length blocks make allocation
+   straight forward, and the lock step acknowledgement provides flow
+   control and eliminates the need to reorder incoming data packets.
+
+3. Relation to other Protocols
+
+   As mentioned TFTP is designed to be implemented on top of the
+   Datagram protocol (UDP).  Since Datagram is implemented on the
+   Internet protocol, packets will have an Internet header, a Datagram
+   header, and a TFTP header.  Additionally, the packets may have a
+   header (LNI, ARPA header, etc.)  to allow them through the local
+   transport medium.  As shown in Figure 3-1, the order of the contents
+   of a packet will be: local medium header, if used, Internet header,
+   Datagram header, TFTP header, followed by the remainder of the TFTP
+   packet.  (This may or may not be data depending on the type of packet
+   as specified in the TFTP header.)  TFTP does not specify any of the
+   values in the Internet header.  On the other hand, the source and
+   destination port fields of the Datagram header (its format is given
+   in the appendix) are used by TFTP and the length field reflects the
+   size of the TFTP packet.  The transfer identifiers (TID's) used by
+   TFTP are passed to the Datagram layer to be used as ports; therefore
+   they must be between 0 and 65,535.  The initialization of TID's is
+   discussed in the section on initial connection protocol.
+
+   The  TFTP header consists of a 2 byte opcode field which indicates
+   the packet's type (e.g., DATA, ERROR, etc.)  These opcodes and  the
+   formats of  the various types of packets are discussed further in the
+   section on TFTP packets.
+
+
+
+
+
+
+
+
+
+
+
+Sollins                                                         [Page 3]
+
+RFC 1350                    TFTP Revision 2                    July 1992
+
+
+          ---------------------------------------------------
+         |  Local Medium  |  Internet  |  Datagram  |  TFTP  |
+          ---------------------------------------------------
+
+                      Figure 3-1: Order of Headers
+
+
+4. Initial Connection Protocol
+
+   A transfer is established by sending a request (WRQ to write onto a
+   foreign file system, or RRQ to read from it), and receiving a
+   positive reply, an acknowledgment packet for write, or the first data
+   packet for read.  In general an acknowledgment packet will contain
+   the block number of the data packet being acknowledged.  Each data
+   packet has associated with it a block number; block numbers are
+   consecutive and begin with one.  Since the positive response to a
+   write request is an acknowledgment packet, in this special case the
+   block number will be zero.  (Normally, since an acknowledgment packet
+   is acknowledging a data packet, the acknowledgment packet will
+   contain the block number of the data packet being acknowledged.)  If
+   the reply is an error packet, then the request has been denied.
+
+   In order to create a connection, each end of the connection chooses a
+   TID for itself, to be used for the duration of that connection.  The
+   TID's chosen for a connection should be randomly chosen, so that the
+   probability that the same number is chosen twice in immediate
+   succession is very low.  Every packet has associated with it the two
+   TID's of the ends of the connection, the source TID and the
+   destination TID.  These TID's are handed to the supporting UDP (or
+   other datagram protocol) as the source and destination ports.  A
+   requesting host chooses its source TID as described above, and sends
+   its initial request to the known TID 69 decimal (105 octal) on the
+   serving host.  The response to the request, under normal operation,
+   uses a TID chosen by the server as its source TID and the TID chosen
+   for the previous message by the requestor as its destination TID.
+   The two chosen TID's are then used for the remainder of the transfer.
+
+   As an example, the following shows the steps used to establish a
+   connection to write a file.  Note that WRQ, ACK, and DATA are the
+   names of the write request, acknowledgment, and data types of packets
+   respectively.  The appendix contains a similar example for reading a
+   file.
+
+
+
+
+
+
+
+
+
+Sollins                                                         [Page 4]
+
+RFC 1350                    TFTP Revision 2                    July 1992
+
+
+      1. Host A sends  a  "WRQ"  to  host  B  with  source=  A's  TID,
+         destination= 69.
+
+      2. Host  B  sends  a "ACK" (with block number= 0) to host A with
+         source= B's TID, destination= A's TID.
+
+   At this point the connection has been established and the first data
+   packet can be sent by Host A with a sequence number of 1.  In the
+   next step, and in all succeeding steps, the hosts should make sure
+   that the source TID matches the value that was agreed on in steps 1
+   and 2.  If a source TID does not match, the packet should be
+   discarded as erroneously sent from somewhere else.  An error packet
+   should be sent to the source of the incorrect packet, while not
+   disturbing the transfer.  This can be done only if the TFTP in fact
+   receives a packet with an incorrect TID.  If the supporting protocols
+   do not allow it, this particular error condition will not arise.
+
+   The following example demonstrates a correct operation of the
+   protocol in which the above situation can occur.  Host A sends a
+   request to host B. Somewhere in the network, the request packet is
+   duplicated, and as a result two acknowledgments are returned to host
+   A, with different TID's chosen on host B in response to the two
+   requests.  When the first response arrives, host A continues the
+   connection.  When the second response to the request arrives, it
+   should be rejected, but there is no reason to terminate the first
+   connection.  Therefore, if different TID's are chosen for the two
+   connections on host B and host A checks the source TID's of the
+   messages it receives, the first connection can be maintained while
+   the second is rejected by returning an error packet.
+
+5. TFTP Packets
+
+   TFTP supports five types of packets, all of which have been mentioned
+   above:
+
+          opcode  operation
+            1     Read request (RRQ)
+            2     Write request (WRQ)
+            3     Data (DATA)
+            4     Acknowledgment (ACK)
+            5     Error (ERROR)
+
+   The TFTP header of a packet contains the  opcode  associated  with
+   that packet.
+
+
+
+
+
+
+
+Sollins                                                         [Page 5]
+
+RFC 1350                    TFTP Revision 2                    July 1992
+
+
+            2 bytes     string    1 byte     string   1 byte
+            ------------------------------------------------
+           | Opcode |  Filename  |   0  |    Mode    |   0  |
+            ------------------------------------------------
+
+                       Figure 5-1: RRQ/WRQ packet
+
+
+   RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format
+   shown in Figure 5-1.  The file name is a sequence of bytes in
+   netascii terminated by a zero byte.  The mode field contains the
+   string "netascii", "octet", or "mail" (or any combination of upper
+   and lower case, such as "NETASCII", NetAscii", etc.) in netascii
+   indicating the three modes defined in the protocol.  A host which
+   receives netascii mode data must translate the data to its own
+   format.  Octet mode is used to transfer a file that is in the 8-bit
+   format of the machine from which the file is being transferred.  It
+   is assumed that each type of machine has a single 8-bit format that
+   is more common, and that that format is chosen.  For example, on a
+   DEC-20, a 36 bit machine, this is four 8-bit bytes to a word with
+   four bits of breakage.  If a host receives a octet file and then
+   returns it, the returned file must be identical to the original.
+   Mail mode uses the name of a mail recipient in place of a file and
+   must begin with a WRQ.  Otherwise it is identical to netascii mode.
+   The mail recipient string should be of the form "username" or
+   "username@hostname".  If the second form is used, it allows the
+   option of mail forwarding by a relay computer.
+
+   The discussion above assumes that both the sender and recipient are
+   operating in the same mode, but there is no reason that this has to
+   be the case.  For example, one might build a storage server.  There
+   is no reason that such a machine needs to translate netascii into its
+   own form of text.  Rather, the sender might send files in netascii,
+   but the storage server might simply store them without translation in
+   8-bit format.  Another such situation is a problem that currently
+   exists on DEC-20 systems.  Neither netascii nor octet accesses all
+   the bits in a word.  One might create a special mode for such a
+   machine which read all the bits in a word, but in which the receiver
+   stored the information in 8-bit format.  When such a file is
+   retrieved from the storage site, it must be restored to its original
+   form to be useful, so the reverse mode must also be implemented.  The
+   user site will have to remember some information to achieve this.  In
+   both of these examples, the request packets would specify octet mode
+   to the foreign host, but the local host would be in some other mode.
+   No such machine or application specific modes have been specified in
+   TFTP, but one would be compatible with this specification.
+
+   It is also possible to define other modes for cooperating pairs of
+
+
+
+Sollins                                                         [Page 6]
+
+RFC 1350                    TFTP Revision 2                    July 1992
+
+
+   hosts, although this must be done with care.  There is no requirement
+   that any other hosts implement these.  There is no central authority
+   that will define these modes or assign them names.
+
+
+                   2 bytes     2 bytes      n bytes
+                   ----------------------------------
+                  | Opcode |   Block #  |   Data     |
+                   ----------------------------------
+
+                        Figure 5-2: DATA packet
+
+
+   Data is actually transferred in DATA packets depicted in Figure 5-2.
+   DATA packets (opcode = 3) have a block number and data field.  The
+   block numbers on data packets begin with one and increase by one for
+   each new block of data.  This restriction allows the program to use a
+   single number to discriminate between new packets and duplicates.
+   The data field is from zero to 512 bytes long.  If it is 512 bytes
+   long, the block is not the last block of data; if it is from zero to
+   511 bytes long, it signals the end of the transfer.  (See the section
+   on Normal Termination for details.)
+
+   All  packets other than duplicate ACK's and those used for
+   termination are acknowledged unless a timeout occurs [4].  Sending a
+   DATA packet is an acknowledgment for the first ACK packet of the
+   previous DATA packet. The WRQ and DATA packets are acknowledged by
+   ACK or ERROR packets, while RRQ
+
+
+                         2 bytes     2 bytes
+                         ---------------------
+                        | Opcode |   Block #  |
+                         ---------------------
+
+                         Figure 5-3: ACK packet
+
+
+   and ACK packets are acknowledged by  DATA  or ERROR packets.  Figure
+   5-3 depicts an ACK packet; the opcode is 4.  The  block  number  in
+   an  ACK echoes the block number of the DATA packet being
+   acknowledged.  A WRQ is acknowledged with an ACK packet having a
+   block number of zero.
+
+
+
+
+
+
+
+
+Sollins                                                         [Page 7]
+
+RFC 1350                    TFTP Revision 2                    July 1992
+
+
+               2 bytes     2 bytes      string    1 byte
+               -----------------------------------------
+              | Opcode |  ErrorCode |   ErrMsg   |   0  |
+               -----------------------------------------
+
+                        Figure 5-4: ERROR packet
+
+
+   An ERROR packet (opcode 5) takes the form depicted in Figure 5-4.  An
+   ERROR packet can be the acknowledgment of any other type of packet.
+   The error code is an integer indicating the nature of the error.  A
+   table of values and meanings is given in the appendix.  (Note that
+   several error codes have been added to this version of this
+   document.) The error message is intended for human consumption, and
+   should be in netascii.  Like all other strings, it is terminated with
+   a zero byte.
+
+6. Normal Termination
+
+   The end of a transfer is marked by a DATA packet that contains
+   between 0 and 511 bytes of data (i.e., Datagram length < 516).  This
+   packet is acknowledged by an ACK packet like all other DATA packets.
+   The host acknowledging the final DATA packet may terminate its side
+   of the connection on sending the final ACK.  On the other hand,
+   dallying is encouraged.  This means that the host sending the final
+   ACK will wait for a while before terminating in order to retransmit
+   the final ACK if it has been lost.  The acknowledger will know that
+   the ACK has been lost if it receives the final DATA packet again.
+   The host sending the last DATA must retransmit it until the packet is
+   acknowledged or the sending host times out.  If the response is an
+   ACK, the transmission was completed successfully.  If the sender of
+   the data times out and is not prepared to retransmit any more, the
+   transfer may still have been completed successfully, after which the
+   acknowledger or network may have experienced a problem.  It is also
+   possible in this case that the transfer was unsuccessful.  In any
+   case, the connection has been closed.
+
+7. Premature Termination
+
+   If a request can not be granted, or some error occurs during the
+   transfer, then an ERROR packet (opcode 5) is sent.  This is only a
+   courtesy since it will not be retransmitted or acknowledged, so it
+   may never be received.  Timeouts must also be used to detect errors.
+
+
+
+
+
+
+
+
+Sollins                                                         [Page 8]
+
+RFC 1350                    TFTP Revision 2                    July 1992
+
+
+I. Appendix
+
+Order of Headers
+
+                                                  2 bytes
+    ----------------------------------------------------------
+   |  Local Medium  |  Internet  |  Datagram  |  TFTP Opcode  |
+    ----------------------------------------------------------
+
+TFTP Formats
+
+   Type   Op #     Format without header
+
+          2 bytes    string   1 byte     string   1 byte
+          -----------------------------------------------
+   RRQ/  | 01/02 |  Filename  |   0  |    Mode    |   0  |
+   WRQ    -----------------------------------------------
+          2 bytes    2 bytes       n bytes
+          ---------------------------------
+   DATA  | 03    |   Block #  |    Data    |
+          ---------------------------------
+          2 bytes    2 bytes
+          -------------------
+   ACK   | 04    |   Block #  |
+          --------------------
+          2 bytes  2 bytes        string    1 byte
+          ----------------------------------------
+   ERROR | 05    |  ErrorCode |   ErrMsg   |   0  |
+          ----------------------------------------
+
+Initial Connection Protocol for reading a file
+
+   1. Host  A  sends  a  "RRQ"  to  host  B  with  source= A's TID,
+      destination= 69.
+
+   2. Host B sends a "DATA" (with block number= 1) to host  A  with
+      source= B's TID, destination= A's TID.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sollins                                                         [Page 9]
+
+RFC 1350                    TFTP Revision 2                    July 1992
+
+
+Error Codes
+
+   Value     Meaning
+
+   0         Not defined, see error message (if any).
+   1         File not found.
+   2         Access violation.
+   3         Disk full or allocation exceeded.
+   4         Illegal TFTP operation.
+   5         Unknown transfer ID.
+   6         File already exists.
+   7         No such user.
+
+Internet User Datagram Header [2]
+
+   (This has been included only for convenience.  TFTP need not be
+   implemented on top of the Internet User Datagram Protocol.)
+
+     Format
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          Source Port          |       Destination Port        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Length             |           Checksum            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   Values of Fields
+
+
+   Source Port     Picked by originator of packet.
+
+   Dest. Port      Picked by destination machine (69 for RRQ or WRQ).
+
+   Length          Number of bytes in UDP packet, including UDP header.
+
+   Checksum        Reference 2 describes rules for computing checksum.
+                   (The implementor of this should be sure that the
+                   correct algorithm is used here.)
+                   Field contains zero if unused.
+
+   Note: TFTP passes transfer identifiers (TID's) to the Internet User
+   Datagram protocol to be used as the source and destination ports.
+
+
+
+
+
+
+Sollins                                                        [Page 10]
+
+RFC 1350                    TFTP Revision 2                    July 1992
+
+
+References
+
+   [1]  USA Standard Code for Information Interchange, USASI X3.4-1968.
+
+   [2]  Postel, J., "User Datagram  Protocol," RFC 768, USC/Information
+        Sciences Institute, 28 August 1980.
+
+   [3]  Postel, J., "Telnet Protocol Specification," RFC 764,
+        USC/Information Sciences Institute, June, 1980.
+
+   [4]  Braden, R., Editor, "Requirements for Internet Hosts --
+        Application and Support", RFC 1123, USC/Information Sciences
+        Institute, October 1989.
+
+Security Considerations
+
+   Since TFTP includes no login or access control mechanisms, care must
+   be taken in the rights granted to a TFTP server process so as not to
+   violate the security of the server hosts file system.  TFTP is often
+   installed with controls such that only files that have public read
+   access are available via TFTP and writing files via TFTP is
+   disallowed.
+
+Author's Address
+
+   Karen R. Sollins
+   Massachusetts Institute of Technology
+   Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139-1986
+
+   Phone: (617) 253-6006
+
+   EMail: SOLLINS@LCS.MIT.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sollins                                                        [Page 11]
+
\ No newline at end of file