home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 700s / rfc783.txt < prev    next >
Text File  |  1992-10-14  |  23KB  |  970 lines
  1.  
  2.  
  3.  
  4. Network Working Group                                      K. R. Sollins
  5. Request for Comments: 783                                            MIT
  6.                                                               June, 1981
  7. Updates: IEN 133
  8.  
  9.  
  10.                      THE TFTP PROTOCOL (REVISION 2)
  11.  
  12.  
  13.  
  14.                                 Summary
  15.  
  16.   TFTP  is  a  very  simple protocol used to transfer files.  It is from
  17.  
  18. this that its name comes, Trivial File Transfer Protocol or TFTP.   Each
  19.  
  20. nonterminal  packet is acknowledged separately.  This document describes
  21.  
  22. the protocol and its types of packets.  The document also  explains  the
  23.  
  24. reasons behind some of the design decisions.
  25.  
  26.  
  27.  
  28.                             ACKNOWLEDGEMENTS
  29.  
  30.  
  31.   The  protocol  was  originally  designed  by  Noel  Chiappa,  and  was
  32.  
  33. redesigned by him, Bob Baldwin and Dave Clark, with comments from  Steve
  34.  
  35. Szymanski.   The current revision of the document includes modifications
  36.  
  37. stemming from discussions with and suggestions from  Larry  Allen,  Noel
  38.  
  39. Chiappa,  Dave  Clark,  Geoff Cooper, Mike Greenwald, Liza Martin, David
  40.  
  41. Reed, Craig Milo Rogers (of UCS-ISI), Kathy  Yellick,  and  the  author.
  42.  
  43. The  acknowledgement  and retransmission scheme was inspired by TCP, and
  44.  
  45. the error mechanism was suggested by PARC's EFTP abort message.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64. This research was supported by the Advanced Research Projects Agency  of
  65.  
  66. the  Department  of  Defense  and  was  monitored by the Office of Naval
  67.  
  68. Research under contract number N00014-75-C-0661.
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.                                 2
  85.  
  86.  
  87. 1. Purpose
  88.  
  89.   TFTP  is  a simple protocol to transfer files, and therefore was named
  90.  
  91. the Trivial File Transfer Protocol or TFTP.  It has been implemented  on
  92.  
  93. top  of  the Internet User Datagram protocol (UDP or Datagram) [2] so it
  94.  
  95. may be used  to  move  files  between  machines  on  different  networks
  96.  
  97. implementing   UDP.     (This  should  not  exlude  the  possibility  of
  98.  
  99. implementing TFTP on top of other datagram protocols.)  It  is  designed
  100.  
  101. to  be  small  and  easy  to implement.  Therefore, it lacks most of the
  102.  
  103. features of a regular FTP.  The only thing it can do is read  and  write
  104.  
  105. files  (or  mail)  from/to a remote server.  It cannot list directories,
  106.  
  107. and currently has no provisions for user authentication.  In common with
  108.  
  109. other Internet protocols, it passes 8 bit bytes of data.
  110.  
  111.  
  112.                                                              1        2
  113.   Three modes of transfer are currently  supported:  netascii ;  octet ,
  114.  
  115. raw  8 bit bytes; mail, netascii characters sent to a user rather than a
  116.  
  117. file.  Additional modes can be defined by pairs of cooperating hosts.
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129. _______________
  130.   1
  131.    This is ascii as  defined  in  "USA  Standard  Code  for  Information
  132. Interchange"  [1]  with  the modifications specified in "Telnet Protocol
  133. Specification" [3].  Note that it is 8 bit ascii.  The  term  "netascii"
  134. will be used throughout this document to mean this particular version of
  135. ascii.
  136.   2
  137.    This  replaces  the  "binary"  mode  of  previous  versions  of  this
  138.  
  139.  
  140.  
  141.                                  3
  142.  
  143.  
  144. 2. Overview of the Protocol
  145.  
  146.   Any transsfer begins with a request to read or write a file, which also
  147.  
  148. serves  to  request a connection.  If the server grants the request, the
  149.  
  150. connection is opened and the file is sent in fixed length blocks of  512
  151.  
  152. bytes.    Each  data  packet  contains  one  block  of data, and must be
  153.  
  154. acknowledged by an acknowledgment packet before the next packet  can  be
  155.  
  156. sent.    A  data  packet of less than 512 bytes signals termination of a
  157.  
  158. transfer.  If a packet gets lost in the network, the intended  recipient
  159.  
  160. will timeout and may retransmit his last packet (which may be data or an
  161.  
  162. acknowledgment),   thus  causing  the  sender  of  the  lost  packet  to
  163.  
  164. retransmit that lost packet.  The sender has to keep just one packet  on
  165.  
  166. hand  for  retransmission, since the lock step acknowledgment guarantees
  167.  
  168. that all older packets have been received.  Notice  that  both  machines
  169.  
  170. involved  in a transfer are considered senders and receivers.  One sends
  171.  
  172. data and receives acknowledgments, the other sends  acknowledgments  and
  173.  
  174. receives data.
  175.  
  176.  
  177.  
  178.   Most  errors  cause  termination  of  the  connection.    An  error is
  179.  
  180. signalled by sending an error packet.  This packet is not  acknowledged,
  181.  
  182. and  not  retransmitted (i.e., a TFTP server or user may terminate after
  183.  
  184. sending an error message), so the other end of the  connection  may  not
  185.  
  186. get  it.   Therefore timeouts are used to detect such a termination when
  187.  
  188. the error packet has been lost.  Errors are caused  by  three  types  of
  189.  
  190. events:  not  being  able  to satisfy the request (e.g., file not found,
  191.  
  192. access violation, or no such user), receiving a packet which  cannot  be
  193.  
  194. explained  by a delay or duplication in the network (e.g. an incorrectly
  195.  
  196.  
  197.                                  4
  198.  
  199.  
  200. formed  packet),  and  losing access to a necessary resource (e.g., disk
  201.  
  202. full or access denied during a transfer).
  203.  
  204.  
  205.  
  206.   TFTP  recognizes  only  one  error  condition  that  does  not   cause
  207.  
  208. termination,  the  source port of a received packet being incorrect.  In
  209.  
  210. this case, an error packet is sent to the originating host.
  211.  
  212.  
  213.  
  214.   This  protocol   is   very   restrictive,   in   order   to   simplify
  215.  
  216. implementation.    For  example, the fixed length blocks make allocation
  217.  
  218. straight forward,  and  the  lock  step  acknowledgement  provides  flow
  219.  
  220. control and eliminates the need to reorder incoming data packets.
  221.  
  222.  
  223.  
  224. 3. Relation to other Protocols
  225.  
  226.   As mentioned TFTP is designed to be implemented on top of the Datagram
  227.  
  228. protocol.    Since  Datagram  is  implemented  on the Internet protocol,
  229.  
  230. packets will have an Internet header, a  Datagram  header,  and  a  TFTP
  231.  
  232. header.   Additionally, the packets may have a header (LNI, ARPA header,
  233.  
  234. etc.)  to allow them through the local transport medium.   As  shown  in
  235.  
  236. Figure 3-1, the order of the contents of a packet will be:  local medium
  237.  
  238. header, if used, Internet header, Datagram header, TFTP header, followed
  239.  
  240. by  the  remainder  of  the  TFTP  packet.  (This may or may not be data
  241.  
  242. depending on the type of packet as specified in the TFTP header.)   TFTP
  243.  
  244. does not specify any of the values in the Internet header.  On the other
  245.  
  246. hand, the source and destination port fields of the Datagram header (its
  247.  
  248. format  is  given in the appendix) are used by TFTP and the length field
  249.  
  250. reflects the size of the TFTP packet.  The transfer identifiers  (TID's)
  251.  
  252.  
  253.                                  5
  254.  
  255.  
  256. used  by  TFTP  are  passed  to  the Datagram layer to be used as ports;
  257.  
  258. therefore they must be between 0 and  65,535.    The  initialization  of
  259.  
  260. TID's is discussed in the section on initial connection protocol.
  261.  
  262.  
  263.  
  264.   The  TFTP header consists of a 2 byte opcode field which indicates the
  265.  
  266. packet's type (e.g., DATA, ERROR, etc.)  These opcodes and  the  formats
  267.  
  268. of  the various types of packets are discussed further in the section on
  269.  
  270. TFTP packets.
  271.  
  272.                       Figure 3-1: Order of Headers
  273.  
  274.  
  275.  
  276.  
  277.           ---------------------------------------------------
  278.          |  Local Medium  |  Internet  |  Datagram  |  TFTP  |
  279.           ---------------------------------------------------
  280.  
  281.  
  282.  
  283. 4. Initial Connection Protocol
  284.  
  285.   A transfer is established by sending a request (WRQ to  write  onto  a
  286.  
  287. foreign  file  system, or RRQ to read from it), and receiving a positive
  288.  
  289. reply, an acknowledgment packet for write, or the first data packet  for
  290.  
  291. read.  In general an acknowledgment packet will contain the block number
  292.  
  293. of  the data packet being acknowledged.  Each data packet has associated
  294.  
  295. with it a block number; block numbers are  consecutive  and  begin  with
  296.  
  297. one.      Since   the  positive  response  to  a  write  request  is  an
  298.  
  299. acknowledgment packet, in this special case the  block  number  will  be
  300.  
  301. zero.  (Normally, since an acknowledgment packet is acknowledging a data
  302.  
  303. packet,  the  acknowledgment packet will contain the block number of the
  304.  
  305. data packet being acknowledged.)  If the reply is an error packet,  then
  306.  
  307.  
  308.                                  6
  309.  
  310.  
  311. the request has been denied.
  312.  
  313.  
  314.  
  315.   In  order to create a connection, each end of the connection chooses a
  316.  
  317. TID for itself, to be used for the duration of  that  connection.    The
  318.  
  319. TID's  chosen  for  a  connection should be randomly chosen, so that the
  320.  
  321. probability that the same number is chosen twice in immediate succession
  322.  
  323. is very low.  Every packet has associated with it the two TID's  of  the
  324.  
  325. ends  of  the connection, the source TID and the destination TID.  These
  326.  
  327. TID's are handed to the supporting UDP (or other datagram  protocol)  as
  328.  
  329. the  source and destination ports.  A requesting host chooses its source
  330.  
  331. TID as described above, and sends its initial request to the  known  TID
  332.  
  333. 69  decimal  (105  octal)  on  the  serving  host.   The response to the
  334.  
  335. request, under normal operation, uses a TID chosen by the server as  its
  336.  
  337. source  TID and the TID chosen for the previous message by the requestor
  338.  
  339. as its destination TID.  The two chosen TID's  are  then  used  for  the
  340.  
  341. remainder  of  the  transfer. 
  342.  
  343.  
  344.   As an example, the following shows  the  steps  used  to  establish  a
  345.  
  346. connection  to write a file.  Note that WRQ, ACK, and DATA are the names
  347.  
  348. of  the  write  request,  acknowledgment,  and  data  types  of  packets
  349.  
  350. respectively.    The  appendix  contains a similar example for reading a
  351.  
  352. file.
  353.  
  354.  
  355.    1. Host A sends  a  "WRQ"  to  host  B  with  source=  A's  TID,
  356.       destination= 69.
  357.  
  358.  
  359.    2. Host  B  sends  a "ACK" (with block number= 0) to host A with
  360.       source= B's TID, destination= A's TID.
  361.  
  362.  
  363.                                  7
  364.  
  365.  
  366. At this point the connection has been established  and  the  first  data
  367.  
  368. packet  can  be sent by Host A with a sequence number of 1.  In the next
  369.  
  370. step, and in all succeeding steps, the hosts should make sure  that  the
  371.  
  372. source  TID matches the value that was agreed on in steps 1 and 2.  If a
  373.  
  374. source TID does not match, the packet should be discarded as erroneously
  375.  
  376. sent from somewhere else.  An error packet should be sent to the  source
  377.  
  378. of the incorrect packet, while not disturbing the transfer.
  379.  
  380. This  can be  done  only if the  TFTP in fact  receives a packet with an
  381.  
  382. incorrect  TID.  If the  supporting  protocols  do  not  allow  it, this
  383.  
  384. particular error condition will not arise.
  385.  
  386.  
  387.  
  388.  
  389.   The following example demonstrates a correct operation of the protocol
  390.  
  391. in  which the above situation can occur.  Host A sends a request to host
  392.  
  393. B. Somewhere in the network, the request packet is duplicated, and as  a
  394.  
  395. result  two acknowledgments are returned to host A, with different TID's
  396.  
  397. chosen on host B in response to  the  two  requests.    When  the  first
  398.  
  399. response  arrives,  host  A  continues  the connection.  When the second
  400.  
  401. response to the request arrives, it should be rejected, but there is  no
  402.  
  403. reason to terminate the first connection.  Therefore, if different TID's
  404.  
  405. are  chosen  for  the  two  connections  on host B and host A checks the
  406.  
  407. source TID's of the messages it receives, the first  connection  can  be
  408.  
  409. maintained while the second is rejected by returning an error packet.
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.                                  8
  417.  
  418.  
  419. 5. TFTP Packets
  420.  
  421.   TFTP  supports five types of packets, all of which have been mentioned
  422.  
  423. above:
  424.  
  425.  
  426.           opcode  operation
  427.             1     Read request (RRQ)
  428.             2     Write request (WRQ)
  429.             3     Data (DATA)
  430.             4     Acknowledgment (ACK)
  431.             5     Error (ERROR)
  432.  
  433.  
  434. The TFTP header of a packet contains the  opcode  associated  with  that
  435.  
  436. packet.
  437.  
  438.                        Figure 5-1: RRQ/WRQ packet
  439.  
  440.  
  441.  
  442.  
  443.             2 bytes     string    1 byte     string   1 byte
  444.             ------------------------------------------------
  445.            | Opcode |  Filename  |   0  |    Mode    |   0  |
  446.             ------------------------------------------------
  447.  
  448.  
  449.  
  450.   RRQ  and  WRQ  packets  (opcodes 1 and 2 respectively) have the format
  451.  
  452. shown in Figure 5-1.  The file name is a sequence of bytes  in  netascii
  453.  
  454. terminated  by  a  zero  byte.    The  mode  field  contains  the string
  455.  
  456. "netascii", "octet", or "mail" (or any comibnation of  upper  and  lower
  457.  
  458. case,  such  as  "NETASCII", NetAscii", etc.) in netascii indicating the
  459.  
  460. three modes defined in the protocol.  A  host  which  receives  netascii
  461.  
  462. mode data must translate the data to its own format.  Octet mode is used
  463.  
  464. to transfer a file that is in the 8-bit format of the machine from which
  465.  
  466. the  file is being transferred.  It is assumed that each type of machine
  467.  
  468. has a single 8-bit format that is more common, and that that  format  is
  469.  
  470.  
  471.                                  9
  472.  
  473.  
  474. chosen.   For example, on a DEC-20, a 36 bit machine, this is four 8-bit
  475.  
  476. bytes to a word with four bits of breakage.  If a host receives a  octet
  477.  
  478. file  and  then  returns  it, the returned file must be identical to the
  479.  
  480. original.  Mail mode uses the name of a mail recipient  in  place  of  a
  481.  
  482. file  and  must begin with a WRQ.  Otherwise it is identical to netascii
  483.  
  484. mode.  The mail recipient string should be of  the  form  "username"  or
  485.  
  486. "username@hostname".    If the second form is used, it allows the option
  487.  
  488. of mail forwarding by a relay computer.
  489.  
  490.  
  491.  
  492.   The discussion above assumes that both the sender  and  recipient  are
  493.  
  494. operating  in  the same mode, but there is no reason that this has to be
  495.  
  496. the case.  For example, one might build a storage server.  There  is  no
  497.  
  498. reason that such a machine needs to translate netascii into its own form
  499.  
  500. of  text.    Rather,  the  sender  might send files in netascii, but the
  501.  
  502. storage server might simply store  them  without  translation  in  8-bit
  503.  
  504. format.    Another  such situation is a problem that currently exists on
  505.  
  506. DEC-20 systems.  Neither netascii nor octet accesses all the bits  in  a
  507.  
  508. word.  One might create a special mode for such a machine which read all
  509.  
  510. the  bits in a word, but in which the receiver stored the information in
  511.  
  512. 8-bit format.  When such a file is retrieved from the storage  site,  it
  513.  
  514. must  be restored to its original form to be useful, so the reverse mode
  515.  
  516. must also be implemented.  The user site  will  have  to  remember  some
  517.  
  518. information  to  achieve  this.   In both of these examples, the request
  519.  
  520. packets would specify octet mode to the foreign host, but the local host
  521.  
  522. would be in some other mode.  No such machine  or  application  specific
  523.  
  524. modes have been specified in TFTP, but one would be compatible with this
  525.  
  526.  
  527.                                  10
  528.  
  529.  
  530. specification.
  531.  
  532.  
  533.  
  534.   It  is  also  possible  to define other modes for cooperating pairs of
  535.  
  536. hosts, although this must be done with care.  There  is  no  requirement
  537.  
  538. that  any  other  hosts  implement these.  There is no central authority
  539.  
  540. that will define these modes or assign them names.
  541.  
  542.                         Figure 5-2: DATA packet
  543.  
  544.  
  545.  
  546.  
  547.                    2 bytes     2 bytes      n bytes
  548.                    ----------------------------------
  549.                   | Opcode |   Block #  |   Data     |
  550.                    ----------------------------------
  551.  
  552.  
  553.  
  554.   Data is actually transferred in DATA packets depicted in  Figure  5-2.
  555.  
  556. DATA packets (opcode = 3) have a block number and data field.  The block
  557.  
  558. numbers  on data packets begin with one and increase by one for each new
  559.  
  560. block of data.  This restriction allows the  program  to  use  a  single
  561.  
  562. number  to  discriminate  between  new packets and duplicates.  The data
  563.  
  564. field is from zero to 512 bytes long.  If it  is  512  bytes  long,  the
  565.  
  566. block  is  not  the  last block of data; if it is from zero to 511 bytes
  567.  
  568. long, it signals the end of the transfer.  (See the  section  on  Normal
  569.  
  570. Termination for details.)
  571.  
  572.  
  573.  
  574.   All  packets  other  than  those used for termination are acknowledged
  575.  
  576. individually unless a timeout occurs.   Sending  a  DATA  packet  is  an
  577.  
  578. acknowledgment  for the ACK packet of the previous DATA packet.  The WRQ
  579.  
  580. and DATA packets are acknowledged by ACK or ERROR packets, while RRQ and
  581.  
  582.  
  583.                                  11
  584.  
  585.  
  586.                          Figure 5-3: ACK packet
  587.  
  588.  
  589.  
  590.  
  591.                          2 bytes     2 bytes
  592.                          ---------------------
  593.                         | Opcode |   Block #  |
  594.                          ---------------------
  595.  
  596.  
  597. ACK  packets  are  acknowledged  by  DATA  or ERROR packets.  Figure 5-3
  598.  
  599. depicts an ACK packet; the opcode is 4.  The  block  number  in  an  ACK
  600.  
  601. echoes the block number of the DATA packet being acknowledged.  A WRQ is
  602.  
  603. acknowledged with an ACK packet having a block number of zero.
  604.  
  605.                         Figure 5-4: ERROR packet
  606.  
  607.  
  608.  
  609.  
  610.                2 bytes     2 bytes      string    1 byte
  611.                -----------------------------------------
  612.               | Opcode |  ErrorCode |   ErrMsg   |   0  |
  613.                -----------------------------------------
  614.  
  615.  
  616.  
  617.   An  ERROR packet (opcode 5) takes the form depicted in Figure 5-4.  An
  618.  
  619. ERROR packet can be the acknowledgment of any other type of packet.  The
  620.  
  621. error code is an integer indicating the nature of the error.  A table of
  622.  
  623. values and meanings is given in the appendix.  (Note that several  error
  624.  
  625. codes  have  been  added  to  this version of this document.)  The error
  626.  
  627. message is intended for human consumption, and should  be  in  netascii.
  628.  
  629. Like all other strings, it is terminated with a zero byte.
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.                                  12
  639.  
  640.  
  641. 6. Normal Termination
  642.  
  643.   The end of a transfer is marked by a DATA packet that contains between
  644.  
  645. 0  and  511  bytes of data (i.e. Datagram length < 516).  This packet is
  646.  
  647. acknowledged by an ACK packet like all other DATA  packets.    The  host
  648.  
  649. acknowledging  the  final  DATA  packet  may  terminate  its side of the
  650.  
  651. connection on sending the final ACK.  On the  other  hand,  dallying  is
  652.  
  653. encouraged.    This  means that the host sending the final ACK will wait
  654.  
  655. for a while before terminating in order to retransmit the final  ACK  if
  656.  
  657. it has been lost.  The acknowledger will know that the ACK has been lost
  658.  
  659. if  it  receives the final DATA packet again.  The host sending the last
  660.  
  661. DATA must retransmit it until the packet is acknowledged or the  sending
  662.  
  663. host  times  out.    If  the  response  is  an ACK, the transmission was
  664.  
  665. completed successfully.  If the sender of the data times out and is  not
  666.  
  667. prepared  to  retransmit  any  more,  the  transfer  may still have been
  668.  
  669. completed successfully, after which the acknowledger or network may have
  670.  
  671. experienced a problem.  It is  also  possible  in  this  case  that  the
  672.  
  673. transfer was unsuccessful.  In any case, the connection has been closed.
  674.  
  675.  
  676.  
  677. 7. Premature Termination
  678.  
  679.   If  a  request  can  not  be  granted, or some error occurs during the
  680.  
  681. transfer, then an ERROR packet (opcode 5) is  sent.    This  is  only  a
  682.  
  683. courtesy  since  it will not be retransmitted or acknowledged, so it may
  684.  
  685. never be received.  Timeouts must also be used to detect errors.
  686.  
  687.  
  688.  
  689.  
  690.  
  691.                                  13
  692.  
  693.  
  694. I. Appendix
  695.  
  696.  
  697. Order of Headers
  698.  
  699.  
  700.                                                2 bytes
  701.  ----------------------------------------------------------
  702. |  Local Medium  |  Internet  |  Datagram  |  TFTP Opcode  |
  703.  ----------------------------------------------------------
  704.  
  705.  
  706. TFTP Formats
  707.  
  708.  
  709. Type   Op #     Format without header
  710.        2 bytes    string   1 byte     string   1 byte
  711.        -----------------------------------------------
  712. RRQ/  | 01/02 |  Filename  |   0  |    Mode    |   0  |
  713. WRQ    -----------------------------------------------
  714.        2 bytes    2 bytes       n bytes
  715.        ---------------------------------
  716. DATA  | 03    |   Block #  |    Data    |
  717.        ---------------------------------
  718.        2 bytes    2 bytes
  719.        -------------------
  720. ACK   | 04    |   Block #  |
  721.        --------------------
  722.        2 bytes  2 bytes        string    1 byte
  723.        ----------------------------------------
  724. ERROR | 05    |  ErrorCode |   ErrMsg   |   0  |
  725.        ----------------------------------------
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742. 
  743.  
  744.                                  14
  745.  
  746.  
  747. Initial Connection Protocol for reading a file
  748.  
  749.  
  750.    1. Host  A  sends  a  "RRQ"  to  host  B  with  source= A's TID,
  751.       destination= 69.
  752.  
  753.    2. Host B sends a "DATA" (with block number= 1) to host  A  with
  754.       source= B's TID, destination= A's TID.
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.                                  15
  801.  
  802.  
  803. Error Codes
  804.  
  805.  
  806. Value     Meaning
  807. 0         Not defined, see error message (if any).
  808. 1         File not found.
  809. 2         Access violation.
  810. 3         Disk full or allocation exceeded.
  811. 4         Illegal TFTP operation.
  812. 5         Unknown transfer ID.
  813. 6         File already exists.
  814. 7         No such user.
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.                                16
  858.  
  859.                                  3
  860. Internet User Datagram Header [2] 
  861.  
  862.  
  863.   Format
  864.  
  865.  0                   1                   2                   3
  866.  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
  867. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  868. |          Source Port          |       Destination Port        |
  869. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  870. |            Length             |           Checksum            |
  871. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  872.  
  873.  
  874. Values of Fields
  875.  
  876.  
  877. Source Port     Picked by originator of packet.
  878.  
  879.  
  880. Dest. Port      Picked by destination machine (69 for RRQ or WRQ).
  881.  
  882.  
  883. Length          Number of bytes in packet after Datagram header.
  884.  
  885.                                                                    4
  886. Checksum        Reference 2 describes rules for computing checksum. 
  887.                 Field contains zero if unused.
  888.  
  889.  
  890. Note:  TFTP  passes  transfer  identifiers  (TID's) to the Internet User
  891.  
  892. Datagram protocol to be used as the source and destination ports.
  893.  
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905. _______________
  906.   3
  907.    This has been included only  for  convenience.    TFTP  need  not  be
  908. implemented on top of the Internet User Datagram Protocol.
  909.   4
  910.    The  implementor of this should be sure that the correct algorithm is
  911. used here.
  912.  
  913.  
  914.                                  17
  915.  
  916.  
  917. References
  918.  
  919.   [1]     USA  Standard  Code  for  Information Interchange, USASI X3.4-
  920.  
  921.           1968.
  922.  
  923.  
  924.  
  925.   [2]     Postel, Jon., "User Datagram  Protocol,"  RFC768,  August  28,
  926.  
  927.           1980.
  928.  
  929.  
  930.                 
  931.   [3]     "Telnet Protocol Specification," RFC764, June, 1980.
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960.  
  961.  
  962.  
  963.  
  964.  
  965.  
  966.  
  967.  
  968.  
  969.                                  18
  970.