home *** CD-ROM | disk | FTP | other *** search
/ Internet Access: To the Information Highway / InternetAccessToTheInformationHighway1994.disc1of1.iso / internet / rfc4 / rfc1350.txt < prev    next >
Text File  |  1994-05-29  |  25KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         K. Sollins
  8. Request For Comments: 1350                                           MIT
  9. STD: 33                                                        July 1992
  10. Obsoletes: RFC 783
  11.  
  12.  
  13.                      THE TFTP PROTOCOL (REVISION 2)
  14.  
  15. Status of this Memo
  16.  
  17.    This RFC specifies an IAB standards track protocol for the Internet
  18.    community, and requests discussion and suggestions for improvements.
  19.    Please refer to the current edition of the "IAB Official Protocol
  20.    Standards" for the standardization state and status of this protocol.
  21.    Distribution of this memo is unlimited.
  22.  
  23. Summary
  24.  
  25.    TFTP is a very simple protocol used to transfer files.  It is from
  26.    this that its name comes, Trivial File Transfer Protocol or TFTP.
  27.    Each nonterminal packet is acknowledged separately.  This document
  28.    describes the protocol and its types of packets.  The document also
  29.    explains the reasons behind some of the design decisions.
  30.  
  31. Acknowlegements
  32.  
  33.    The protocol was originally designed by Noel Chiappa, and was
  34.    redesigned by him, Bob Baldwin and Dave Clark, with comments from
  35.    Steve Szymanski.  The current revision of the document includes
  36.    modifications stemming from discussions with and suggestions from
  37.    Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald,
  38.    Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy
  39.    Yellick, and the author.  The acknowledgement and retransmission
  40.    scheme was inspired by TCP, and the error mechanism was suggested by
  41.    PARC's EFTP abort message.
  42.  
  43.    The May, 1992 revision to fix the "Sorcerer's Apprentice" protocol
  44.    bug [4] and other minor document problems was done by Noel Chiappa.
  45.  
  46.    This research was supported by the Advanced Research Projects Agency
  47.    of the Department of Defense and was monitored by the Office of Naval
  48.    Research under contract number N00014-75-C-0661.
  49.  
  50. 1. Purpose
  51.  
  52.    TFTP is a simple protocol to transfer files, and therefore was named
  53.    the Trivial File Transfer Protocol or TFTP.  It has been implemented
  54.    on top of the Internet User Datagram protocol (UDP or Datagram) [2]
  55.  
  56.  
  57.  
  58. Sollins                                                         [Page 1]
  59.  
  60. RFC 1350                    TFTP Revision 2                    July 1992
  61.  
  62.  
  63.    so it may be used to move files between machines on different
  64.    networks implementing UDP.  (This should not exclude the possibility
  65.    of implementing TFTP on top of other datagram protocols.)  It is
  66.    designed to be small and easy to implement.  Therefore, it lacks most
  67.    of the features of a regular FTP.  The only thing it can do is read
  68.    and write files (or mail) from/to a remote server.  It cannot list
  69.    directories, and currently has no provisions for user authentication.
  70.    In common with other Internet protocols, it passes 8 bit bytes of
  71.    data.
  72.  
  73.    Three modes of transfer are currently supported: netascii (This is
  74.    ascii as defined in "USA Standard Code for Information Interchange"
  75.    [1] with the modifications specified in "Telnet Protocol
  76.    Specification" [3].)  Note that it is 8 bit ascii.  The term
  77.    "netascii" will be used throughout this document to mean this
  78.    particular version of ascii.); octet (This replaces the "binary" mode
  79.    of previous versions of this document.) raw 8 bit bytes; mail,
  80.    netascii characters sent to a user rather than a file.  (The mail
  81.    mode is obsolete and should not be implemented or used.)  Additional
  82.    modes can be defined by pairs of cooperating hosts.
  83.  
  84.    Reference [4] (section 4.2) should be consulted for further valuable
  85.    directives and suggestions on TFTP.
  86.  
  87. 2. Overview of the Protocol
  88.  
  89.    Any transfer begins with a request to read or write a file, which
  90.    also serves to request a connection.  If the server grants the
  91.    request, the connection is opened and the file is sent in fixed
  92.    length blocks of 512 bytes.  Each data packet contains one block of
  93.    data, and must be acknowledged by an acknowledgment packet before the
  94.    next packet can be sent.  A data packet of less than 512 bytes
  95.    signals termination of a transfer.  If a packet gets lost in the
  96.    network, the intended recipient will timeout and may retransmit his
  97.    last packet (which may be data or an acknowledgment), thus causing
  98.    the sender of the lost packet to retransmit that lost packet.  The
  99.    sender has to keep just one packet on hand for retransmission, since
  100.    the lock step acknowledgment guarantees that all older packets have
  101.    been received.  Notice that both machines involved in a transfer are
  102.    considered senders and receivers.  One sends data and receives
  103.    acknowledgments, the other sends acknowledgments and receives data.
  104.  
  105.    Most errors cause termination of the connection.  An error is
  106.    signalled by sending an error packet.  This packet is not
  107.    acknowledged, and not retransmitted (i.e., a TFTP server or user may
  108.    terminate after sending an error message), so the other end of the
  109.    connection may not get it.  Therefore timeouts are used to detect
  110.    such a termination when the error packet has been lost.  Errors are
  111.  
  112.  
  113.  
  114. Sollins                                                         [Page 2]
  115.  
  116. RFC 1350                    TFTP Revision 2                    July 1992
  117.  
  118.  
  119.    caused by three types of events: not being able to satisfy the
  120.    request (e.g., file not found, access violation, or no such user),
  121.    receiving a packet which cannot be explained by a delay or
  122.    duplication in the network (e.g., an incorrectly formed packet), and
  123.    losing access to a necessary resource (e.g., disk full or access
  124.    denied during a transfer).
  125.  
  126.    TFTP recognizes only one error condition that does not cause
  127.    termination, the source port of a received packet being incorrect.
  128.    In this case, an error packet is sent to the originating host.
  129.  
  130.    This protocol is very restrictive, in order to simplify
  131.    implementation.  For example, the fixed length blocks make allocation
  132.    straight forward, and the lock step acknowledgement provides flow
  133.    control and eliminates the need to reorder incoming data packets.
  134.  
  135. 3. Relation to other Protocols
  136.  
  137.    As mentioned TFTP is designed to be implemented on top of the
  138.    Datagram protocol (UDP).  Since Datagram is implemented on the
  139.    Internet protocol, packets will have an Internet header, a Datagram
  140.    header, and a TFTP header.  Additionally, the packets may have a
  141.    header (LNI, ARPA header, etc.)  to allow them through the local
  142.    transport medium.  As shown in Figure 3-1, the order of the contents
  143.    of a packet will be: local medium header, if used, Internet header,
  144.    Datagram header, TFTP header, followed by the remainder of the TFTP
  145.    packet.  (This may or may not be data depending on the type of packet
  146.    as specified in the TFTP header.)  TFTP does not specify any of the
  147.    values in the Internet header.  On the other hand, the source and
  148.    destination port fields of the Datagram header (its format is given
  149.    in the appendix) are used by TFTP and the length field reflects the
  150.    size of the TFTP packet.  The transfer identifiers (TID's) used by
  151.    TFTP are passed to the Datagram layer to be used as ports; therefore
  152.    they must be between 0 and 65,535.  The initialization of TID's is
  153.    discussed in the section on initial connection protocol.
  154.  
  155.    The  TFTP header consists of a 2 byte opcode field which indicates
  156.    the packet's type (e.g., DATA, ERROR, etc.)  These opcodes and  the
  157.    formats of  the various types of packets are discussed further in the
  158.    section on TFTP packets.
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Sollins                                                         [Page 3]
  171.  
  172. RFC 1350                    TFTP Revision 2                    July 1992
  173.  
  174.  
  175.           ---------------------------------------------------
  176.          |  Local Medium  |  Internet  |  Datagram  |  TFTP  |
  177.           ---------------------------------------------------
  178.  
  179.                       Figure 3-1: Order of Headers
  180.  
  181.  
  182. 4. Initial Connection Protocol
  183.  
  184.    A transfer is established by sending a request (WRQ to write onto a
  185.    foreign file system, or RRQ to read from it), and receiving a
  186.    positive reply, an acknowledgment packet for write, or the first data
  187.    packet for read.  In general an acknowledgment packet will contain
  188.    the block number of the data packet being acknowledged.  Each data
  189.    packet has associated with it a block number; block numbers are
  190.    consecutive and begin with one.  Since the positive response to a
  191.    write request is an acknowledgment packet, in this special case the
  192.    block number will be zero.  (Normally, since an acknowledgment packet
  193.    is acknowledging a data packet, the acknowledgment packet will
  194.    contain the block number of the data packet being acknowledged.)  If
  195.    the reply is an error packet, then the request has been denied.
  196.  
  197.    In order to create a connection, each end of the connection chooses a
  198.    TID for itself, to be used for the duration of that connection.  The
  199.    TID's chosen for a connection should be randomly chosen, so that the
  200.    probability that the same number is chosen twice in immediate
  201.    succession is very low.  Every packet has associated with it the two
  202.    TID's of the ends of the connection, the source TID and the
  203.    destination TID.  These TID's are handed to the supporting UDP (or
  204.    other datagram protocol) as the source and destination ports.  A
  205.    requesting host chooses its source TID as described above, and sends
  206.    its initial request to the known TID 69 decimal (105 octal) on the
  207.    serving host.  The response to the request, under normal operation,
  208.    uses a TID chosen by the server as its source TID and the TID chosen
  209.    for the previous message by the requestor as its destination TID.
  210.    The two chosen TID's are then used for the remainder of the transfer.
  211.  
  212.    As an example, the following shows the steps used to establish a
  213.    connection to write a file.  Note that WRQ, ACK, and DATA are the
  214.    names of the write request, acknowledgment, and data types of packets
  215.    respectively.  The appendix contains a similar example for reading a
  216.    file.
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Sollins                                                         [Page 4]
  227.  
  228. RFC 1350                    TFTP Revision 2                    July 1992
  229.  
  230.  
  231.       1. Host A sends  a  "WRQ"  to  host  B  with  source=  A's  TID,
  232.          destination= 69.
  233.  
  234.       2. Host  B  sends  a "ACK" (with block number= 0) to host A with
  235.          source= B's TID, destination= A's TID.
  236.  
  237.    At this point the connection has been established and the first data
  238.    packet can be sent by Host A with a sequence number of 1.  In the
  239.    next step, and in all succeeding steps, the hosts should make sure
  240.    that the source TID matches the value that was agreed on in steps 1
  241.    and 2.  If a source TID does not match, the packet should be
  242.    discarded as erroneously sent from somewhere else.  An error packet
  243.    should be sent to the source of the incorrect packet, while not
  244.    disturbing the transfer.  This can be done only if the TFTP in fact
  245.    receives a packet with an incorrect TID.  If the supporting protocols
  246.    do not allow it, this particular error condition will not arise.
  247.  
  248.    The following example demonstrates a correct operation of the
  249.    protocol in which the above situation can occur.  Host A sends a
  250.    request to host B. Somewhere in the network, the request packet is
  251.    duplicated, and as a result two acknowledgments are returned to host
  252.    A, with different TID's chosen on host B in response to the two
  253.    requests.  When the first response arrives, host A continues the
  254.    connection.  When the second response to the request arrives, it
  255.    should be rejected, but there is no reason to terminate the first
  256.    connection.  Therefore, if different TID's are chosen for the two
  257.    connections on host B and host A checks the source TID's of the
  258.    messages it receives, the first connection can be maintained while
  259.    the second is rejected by returning an error packet.
  260.  
  261. 5. TFTP Packets
  262.  
  263.    TFTP supports five types of packets, all of which have been mentioned
  264.    above:
  265.  
  266.           opcode  operation
  267.             1     Read request (RRQ)
  268.             2     Write request (WRQ)
  269.             3     Data (DATA)
  270.             4     Acknowledgment (ACK)
  271.             5     Error (ERROR)
  272.  
  273.    The TFTP header of a packet contains the  opcode  associated  with
  274.    that packet.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Sollins                                                         [Page 5]
  283.  
  284. RFC 1350                    TFTP Revision 2                    July 1992
  285.  
  286.  
  287.             2 bytes     string    1 byte     string   1 byte
  288.             ------------------------------------------------
  289.            | Opcode |  Filename  |   0  |    Mode    |   0  |
  290.             ------------------------------------------------
  291.  
  292.                        Figure 5-1: RRQ/WRQ packet
  293.  
  294.  
  295.    RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format
  296.    shown in Figure 5-1.  The file name is a sequence of bytes in
  297.    netascii terminated by a zero byte.  The mode field contains the
  298.    string "netascii", "octet", or "mail" (or any combination of upper
  299.    and lower case, such as "NETASCII", NetAscii", etc.) in netascii
  300.    indicating the three modes defined in the protocol.  A host which
  301.    receives netascii mode data must translate the data to its own
  302.    format.  Octet mode is used to transfer a file that is in the 8-bit
  303.    format of the machine from which the file is being transferred.  It
  304.    is assumed that each type of machine has a single 8-bit format that
  305.    is more common, and that that format is chosen.  For example, on a
  306.    DEC-20, a 36 bit machine, this is four 8-bit bytes to a word with
  307.    four bits of breakage.  If a host receives a octet file and then
  308.    returns it, the returned file must be identical to the original.
  309.    Mail mode uses the name of a mail recipient in place of a file and
  310.    must begin with a WRQ.  Otherwise it is identical to netascii mode.
  311.    The mail recipient string should be of the form "username" or
  312.    "username@hostname".  If the second form is used, it allows the
  313.    option of mail forwarding by a relay computer.
  314.  
  315.    The discussion above assumes that both the sender and recipient are
  316.    operating in the same mode, but there is no reason that this has to
  317.    be the case.  For example, one might build a storage server.  There
  318.    is no reason that such a machine needs to translate netascii into its
  319.    own form of text.  Rather, the sender might send files in netascii,
  320.    but the storage server might simply store them without translation in
  321.    8-bit format.  Another such situation is a problem that currently
  322.    exists on DEC-20 systems.  Neither netascii nor octet accesses all
  323.    the bits in a word.  One might create a special mode for such a
  324.    machine which read all the bits in a word, but in which the receiver
  325.    stored the information in 8-bit format.  When such a file is
  326.    retrieved from the storage site, it must be restored to its original
  327.    form to be useful, so the reverse mode must also be implemented.  The
  328.    user site will have to remember some information to achieve this.  In
  329.    both of these examples, the request packets would specify octet mode
  330.    to the foreign host, but the local host would be in some other mode.
  331.    No such machine or application specific modes have been specified in
  332.    TFTP, but one would be compatible with this specification.
  333.  
  334.    It is also possible to define other modes for cooperating pairs of
  335.  
  336.  
  337.  
  338. Sollins                                                         [Page 6]
  339.  
  340. RFC 1350                    TFTP Revision 2                    July 1992
  341.  
  342.  
  343.    hosts, although this must be done with care.  There is no requirement
  344.    that any other hosts implement these.  There is no central authority
  345.    that will define these modes or assign them names.
  346.  
  347.  
  348.                    2 bytes     2 bytes      n bytes
  349.                    ----------------------------------
  350.                   | Opcode |   Block #  |   Data     |
  351.                    ----------------------------------
  352.  
  353.                         Figure 5-2: DATA packet
  354.  
  355.  
  356.    Data is actually transferred in DATA packets depicted in Figure 5-2.
  357.    DATA packets (opcode = 3) have a block number and data field.  The
  358.    block numbers on data packets begin with one and increase by one for
  359.    each new block of data.  This restriction allows the program to use a
  360.    single number to discriminate between new packets and duplicates.
  361.    The data field is from zero to 512 bytes long.  If it is 512 bytes
  362.    long, the block is not the last block of data; if it is from zero to
  363.    511 bytes long, it signals the end of the transfer.  (See the section
  364.    on Normal Termination for details.)
  365.  
  366.    All  packets other than duplicate ACK's and those used for
  367.    termination are acknowledged unless a timeout occurs [4].  Sending a
  368.    DATA packet is an acknowledgment for the first ACK packet of the
  369.    previous DATA packet. The WRQ and DATA packets are acknowledged by
  370.    ACK or ERROR packets, while RRQ
  371.  
  372.  
  373.                          2 bytes     2 bytes
  374.                          ---------------------
  375.                         | Opcode |   Block #  |
  376.                          ---------------------
  377.  
  378.                          Figure 5-3: ACK packet
  379.  
  380.  
  381.    and ACK packets are acknowledged by  DATA  or ERROR packets.  Figure
  382.    5-3 depicts an ACK packet; the opcode is 4.  The  block  number  in
  383.    an  ACK echoes the block number of the DATA packet being
  384.    acknowledged.  A WRQ is acknowledged with an ACK packet having a
  385.    block number of zero.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Sollins                                                         [Page 7]
  395.  
  396. RFC 1350                    TFTP Revision 2                    July 1992
  397.  
  398.  
  399.                2 bytes     2 bytes      string    1 byte
  400.                -----------------------------------------
  401.               | Opcode |  ErrorCode |   ErrMsg   |   0  |
  402.                -----------------------------------------
  403.  
  404.                         Figure 5-4: ERROR packet
  405.  
  406.  
  407.    An ERROR packet (opcode 5) takes the form depicted in Figure 5-4.  An
  408.    ERROR packet can be the acknowledgment of any other type of packet.
  409.    The error code is an integer indicating the nature of the error.  A
  410.    table of values and meanings is given in the appendix.  (Note that
  411.    several error codes have been added to this version of this
  412.    document.) The error message is intended for human consumption, and
  413.    should be in netascii.  Like all other strings, it is terminated with
  414.    a zero byte.
  415.  
  416. 6. Normal Termination
  417.  
  418.    The end of a transfer is marked by a DATA packet that contains
  419.    between 0 and 511 bytes of data (i.e., Datagram length < 516).  This
  420.    packet is acknowledged by an ACK packet like all other DATA packets.
  421.    The host acknowledging the final DATA packet may terminate its side
  422.    of the connection on sending the final ACK.  On the other hand,
  423.    dallying is encouraged.  This means that the host sending the final
  424.    ACK will wait for a while before terminating in order to retransmit
  425.    the final ACK if it has been lost.  The acknowledger will know that
  426.    the ACK has been lost if it receives the final DATA packet again.
  427.    The host sending the last DATA must retransmit it until the packet is
  428.    acknowledged or the sending host times out.  If the response is an
  429.    ACK, the transmission was completed successfully.  If the sender of
  430.    the data times out and is not prepared to retransmit any more, the
  431.    transfer may still have been completed successfully, after which the
  432.    acknowledger or network may have experienced a problem.  It is also
  433.    possible in this case that the transfer was unsuccessful.  In any
  434.    case, the connection has been closed.
  435.  
  436. 7. Premature Termination
  437.  
  438.    If a request can not be granted, or some error occurs during the
  439.    transfer, then an ERROR packet (opcode 5) is sent.  This is only a
  440.    courtesy since it will not be retransmitted or acknowledged, so it
  441.    may never be received.  Timeouts must also be used to detect errors.
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Sollins                                                         [Page 8]
  451.  
  452. RFC 1350                    TFTP Revision 2                    July 1992
  453.  
  454.  
  455. I. Appendix
  456.  
  457. Order of Headers
  458.  
  459.                                                   2 bytes
  460.     ----------------------------------------------------------
  461.    |  Local Medium  |  Internet  |  Datagram  |  TFTP Opcode  |
  462.     ----------------------------------------------------------
  463.  
  464. TFTP Formats
  465.  
  466.    Type   Op #     Format without header
  467.  
  468.           2 bytes    string   1 byte     string   1 byte
  469.           -----------------------------------------------
  470.    RRQ/  | 01/02 |  Filename  |   0  |    Mode    |   0  |
  471.    WRQ    -----------------------------------------------
  472.           2 bytes    2 bytes       n bytes
  473.           ---------------------------------
  474.    DATA  | 03    |   Block #  |    Data    |
  475.           ---------------------------------
  476.           2 bytes    2 bytes
  477.           -------------------
  478.    ACK   | 04    |   Block #  |
  479.           --------------------
  480.           2 bytes  2 bytes        string    1 byte
  481.           ----------------------------------------
  482.    ERROR | 05    |  ErrorCode |   ErrMsg   |   0  |
  483.           ----------------------------------------
  484.  
  485. Initial Connection Protocol for reading a file
  486.  
  487.    1. Host  A  sends  a  "RRQ"  to  host  B  with  source= A's TID,
  488.       destination= 69.
  489.  
  490.    2. Host B sends a "DATA" (with block number= 1) to host  A  with
  491.       source= B's TID, destination= A's TID.
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Sollins                                                         [Page 9]
  507.  
  508. RFC 1350                    TFTP Revision 2                    July 1992
  509.  
  510.  
  511. Error Codes
  512.  
  513.    Value     Meaning
  514.  
  515.    0         Not defined, see error message (if any).
  516.    1         File not found.
  517.    2         Access violation.
  518.    3         Disk full or allocation exceeded.
  519.    4         Illegal TFTP operation.
  520.    5         Unknown transfer ID.
  521.    6         File already exists.
  522.    7         No such user.
  523.  
  524. Internet User Datagram Header [2]
  525.  
  526.    (This has been included only for convenience.  TFTP need not be
  527.    implemented on top of the Internet User Datagram Protocol.)
  528.  
  529.      Format
  530.  
  531.     0                   1                   2                   3
  532.     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
  533.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  534.    |          Source Port          |       Destination Port        |
  535.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  536.    |            Length             |           Checksum            |
  537.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  538.  
  539.  
  540.    Values of Fields
  541.  
  542.  
  543.    Source Port     Picked by originator of packet.
  544.  
  545.    Dest. Port      Picked by destination machine (69 for RRQ or WRQ).
  546.  
  547.    Length          Number of bytes in UDP packet, including UDP header.
  548.  
  549.    Checksum        Reference 2 describes rules for computing checksum.
  550.                    (The implementor of this should be sure that the
  551.                    correct algorithm is used here.)
  552.                    Field contains zero if unused.
  553.  
  554.    Note: TFTP passes transfer identifiers (TID's) to the Internet User
  555.    Datagram protocol to be used as the source and destination ports.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Sollins                                                        [Page 10]
  563.  
  564. RFC 1350                    TFTP Revision 2                    July 1992
  565.  
  566.  
  567. References
  568.  
  569.    [1]  USA Standard Code for Information Interchange, USASI X3.4-1968.
  570.  
  571.    [2]  Postel, J., "User Datagram  Protocol," RFC 768, USC/Information
  572.         Sciences Institute, 28 August 1980.
  573.  
  574.    [3]  Postel, J., "Telnet Protocol Specification," RFC 764,
  575.         USC/Information Sciences Institute, June, 1980.
  576.  
  577.    [4]  Braden, R., Editor, "Requirements for Internet Hosts --
  578.         Application and Support", RFC 1123, USC/Information Sciences
  579.         Institute, October 1989.
  580.  
  581. Security Considerations
  582.  
  583.    Since TFTP includes no login or access control mechanisms, care must
  584.    be taken in the rights granted to a TFTP server process so as not to
  585.    violate the security of the server hosts file system.  TFTP is often
  586.    installed with controls such that only files that have public read
  587.    access are available via TFTP and writing files via TFTP is
  588.    disallowed.
  589.  
  590. Author's Address
  591.  
  592.    Karen R. Sollins
  593.    Massachusetts Institute of Technology
  594.    Laboratory for Computer Science
  595.    545 Technology Square
  596.    Cambridge, MA 02139-1986
  597.  
  598.    Phone: (617) 253-6006
  599.  
  600.    EMail: SOLLINS@LCS.MIT.EDU
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Sollins                                                        [Page 11]
  619.  
  620.