rfc1350.txt

this gives details of the network programming

   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: [phone]

   EMail: [e-mail]

















Sollins                                                        [Page 11]