RFC relevance of connection

As per Relevance of the word connection, we have this rfc below:

Network Working Group K. R.
Request for Comments: 783
June, 1981
Updates: IEN 133

THE TFTP PROTOCOL (REVISION 2)

TFTP is a very simple protocol used to transfer files. It is

this that its name comes, Trivial File Transfer Protocol or TFTP.

nonterminal packet is acknowledged separately. This document

the protocol and its types of packets. The document also explains

reasons behind some of the design decisions

The protocol was originally designed by Noel Chiappa, and

redesigned by him, Bob Baldwin and Dave Clark, with comments from

Szymanski. The current revision of the document includes

stemming from discussions with and suggestions from Larry Allen,

Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, Liza Martin,

Reed, Craig Milo Rogers (of UCS-ISI), Kathy Yellick, and the author

The acknowledgement and retransmission scheme was inspired by TCP,

the error mechanism was suggested by PARC's EFTP abort message

This research was supported by the Advanced Research Projects Agency

the Department of Defense and was monitored by the Office of

Research under contract number N00014-75-C-0661.

2

1.

TFTP is a simple protocol to transfer files, and therefore was

the Trivial File Transfer Protocol or TFTP. It has been implemented

top of the Internet User Datagram protocol (UDP or Datagram) [2] so

may be used to move files between machines on different

implementing UDP. (This should not exlude the possibility

implementing TFTP on top of other datagram protocols.) It is

to be small and easy to implement. Therefore, it lacks most of

features of a regular FTP. The only thing it can do is read and

files (or mail) from/to a remote server. It cannot list directories

and currently has no provisions for user authentication. In common

other Internet protocols, it passes 8 bit bytes of data

1 2
Three modes of transfer are currently supported: netascii ; octet ,

raw 8 bit bytes; mail, netascii characters sent to a user rather than

file. Additional modes can be defined by pairs of cooperating hosts

_______________
1
This is ascii as defined in "USA Standard Code for
Interchange" [1] with the modifications specified in "Telnet
Specification" [3]. Note that it is 8 bit ascii. The term "netascii
will be used throughout this document to mean this particular version
ascii
2
This replaces the "binary" mode of previous versions of

3

2. Overview of the

Any transsfer begins with a request to read or write a file, which

serves to request a connection. If the server grants the request,

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

acknowledged by an acknowledgment packet before the next packet can

sent. A data packet of less than 512 bytes signals termination of

transfer. If a packet gets lost in the network, the intended

will timeout and may retransmit his last packet (which may be data or

acknowledgment), thus causing the sender of the lost packet

retransmit that lost packet. The sender has to keep just one packet

hand for retransmission, since the lock step acknowledgment

that all older packets have been received. Notice that both

involved in a transfer are considered senders and receivers. One

data and receives acknowledgments, the other sends acknowledgments

receives data

Most errors cause termination of the connection. An error

signalled by sending an error packet. This packet is not acknowledged

and not retransmitted (i.e., a TFTP server or user may terminate

sending an error message), so the other end of the connection may

get it. Therefore timeouts are used to detect such a termination

the error packet has been lost. Errors are caused by three types

events: not being able to satisfy the request (e.g., file not found

access violation, or no such user), receiving a packet which cannot

explained by a delay or duplication in the network (e.g. an

4

formed packet), and losing access to a necessary resource (e.g.,

full or access denied during a transfer).

TFTP recognizes only one error condition that does not

termination, the source port of a received packet being incorrect.

this case, an error packet is sent to the originating host

This protocol is very restrictive, in order to

implementation. For example, the fixed length blocks make

straight forward, and the lock step acknowledgement provides

control and eliminates the need to reorder incoming data packets

3. Relation to other

As mentioned TFTP is designed to be implemented on top of the

protocol. Since Datagram is implemented on the Internet protocol

packets will have an Internet header, a Datagram header, and a

header. Additionally, the packets may have a header (LNI, ARPA header

etc.) to allow them through the local transport medium. As shown

Figure 3-1, the order of the contents of a packet will be: local

header, if used, Internet header, Datagram header, TFTP header,

by the remainder of the TFTP packet. (This may or may not be

depending on the type of packet as specified in the TFTP header.)

does not specify any of the values in the Internet header. On the

hand, the source and destination port fields of the Datagram header (

format is given in the appendix) are used by TFTP and the length

reflects the size of the TFTP packet. The transfer identifiers (TID's

5

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

TID's is discussed in the section on initial connection protocol

The TFTP header consists of a 2 byte opcode field which indicates

packet's type (e.g., DATA, ERROR, etc.) These opcodes and the

of the various types of packets are discussed further in the section

TFTP packets

Figure 3-1: Order of

---------------------------------------------------
| Local Medium | Internet | Datagram | TFTP |
---------------------------------------------------

4. Initial Connection

A transfer is established by sending a request (WRQ to write onto

foreign file system, or RRQ to read from it), and receiving a

reply, an acknowledgment packet for write, or the first data packet

read. In general an acknowledgment packet will contain the block

of the data packet being acknowledged. Each data packet has

with it a block number; block numbers are consecutive and begin

one. Since the positive response to a write request is

acknowledgment packet, in this special case the block number will

zero. (Normally, since an acknowledgment packet is acknowledging a

packet, the acknowledgment packet will contain the block number of

data packet being acknowledged.) If the reply is an error packet,

6

the request has been denied

In order to create a connection, each end of the connection chooses

TID for itself, to be used for the duration of that connection.

TID's chosen for a connection should be randomly chosen, so that

probability that the same number is chosen twice in immediate

is very low. Every packet has associated with it the two TID's of

ends of the connection, the source TID and the destination TID.

TID's are handed to the supporting UDP (or other datagram protocol)

the source and destination ports. A requesting host chooses its

TID as described above, and sends its initial request to the known

69 decimal (105 octal) on the serving host. The response to

request, under normal operation, uses a TID chosen by the server as

source TID and the TID chosen for the previous message by the

as its destination TID. The two chosen TID's are then used for

remainder of the transfer.

As an example, the following shows the steps used to establish

connection to write a file. Note that WRQ, ACK, and DATA are the

of the write request, acknowledgment, and data types of

respectively. The appendix contains a similar example for reading

file

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
source= B's TID, destination= A's TID

7

At this point the connection has been established and the first

packet can be sent by Host A with a sequence number of 1. In the

step, and in all succeeding steps, the hosts should make sure that

source TID matches the value that was agreed on in steps 1 and 2. If

source TID does not match, the packet should be discarded as

sent from somewhere else. An error packet should be sent to the

of the incorrect packet, while not disturbing the transfer

This can be done only if the TFTP in fact receives a packet with

incorrect TID. If the supporting protocols do not allow it,

particular error condition will not arise

The following example demonstrates a correct operation of the

in which the above situation can occur. Host A sends a request to

B. Somewhere in the network, the request packet is duplicated, and as

result two acknowledgments are returned to host A, with different TID'

chosen on host B in response to the two requests. When the

response arrives, host A continues the connection. When the

response to the request arrives, it should be rejected, but there is

reason to terminate the first connection. Therefore, if different TID'

are chosen for the two connections on host B and host A checks

source TID's of the messages it receives, the first connection can

maintained while the second is rejected by returning an error packet

8

5. TFTP

TFTP supports five types of packets, all of which have been

above

opcode
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

packet

Figure 5-1: RRQ/WRQ

2 bytes string 1 byte string 1
------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 |
------------------------------------------------

RRQ and WRQ packets (opcodes 1 and 2 respectively) have the

shown in Figure 5-1. The file name is a sequence of bytes in

terminated by a zero byte. The mode field contains the

"netascii", "octet", or "mail" (or any comibnation of upper and

case, such as "NETASCII", NetAscii", etc.) in netascii indicating

three modes defined in the protocol. A host which receives

mode data must translate the data to its own format. Octet mode is

to transfer a file that is in the 8-bit format of the machine from

the file is being transferred. It is assumed that each type of

has a single 8-bit format that is more common, and that that format

9

chosen. For example, on a DEC-20, a 36 bit machine, this is four 8-

bytes to a word with four bits of breakage. If a host receives a

file and then returns it, the returned file must be identical to

original. Mail mode uses the name of a mail recipient in place of

file and must begin with a WRQ. Otherwise it is identical to

mode. The mail recipient string should be of the form "username"

"username@hostname". If the second form is used, it allows the

of mail forwarding by a relay computer

The discussion above assumes that both the sender and recipient

operating in the same mode, but there is no reason that this has to

the case. For example, one might build a storage server. There is

reason that such a machine needs to translate netascii into its own

of text. Rather, the sender might send files in netascii, but

storage server might simply store them without translation in 8-

format. Another such situation is a problem that currently exists

DEC-20 systems. Neither netascii nor octet accesses all the bits in

word. One might create a special mode for such a machine which read

the bits in a word, but in which the receiver stored the information

8-bit format. When such a file is retrieved from the storage site,

must be restored to its original form to be useful, so the reverse

must also be implemented. The user site will have to remember

information to achieve this. In both of these examples, the

packets would specify octet mode to the foreign host, but the local

would be in some other mode. No such machine or application

modes have been specified in TFTP, but one would be compatible with

10

specification

It is also possible to define other modes for cooperating pairs

hosts, although this must be done with care. There is no

that any other hosts implement these. There is no central

that will define these modes or assign them names

Figure 5-2: DATA

2 bytes 2 bytes n
----------------------------------
| Opcode | Block # | Data |
----------------------------------

Data is actually transferred in DATA packets depicted in Figure 5-2.

DATA packets (opcode = 3) have a block number and data field. The

numbers on data packets begin with one and increase by one for each

block of data. This restriction allows the program to use a

number to discriminate between new packets and duplicates. The

field is from zero to 512 bytes long. If it is 512 bytes long,

block is not the last block of data; if it is from zero to 511

long, it signals the end of the transfer. (See the section on

Termination for details.)

All packets other than those used for termination are

individually unless a timeout occurs. Sending a DATA packet is

acknowledgment for the ACK packet of the previous DATA packet. The

and DATA packets are acknowledged by ACK or ERROR packets, while RRQ

11

Figure 5-3: ACK

2 bytes 2
---------------------
| Opcode | Block # |
---------------------

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

echoes the block number of the DATA packet being acknowledged. A WRQ

acknowledged with an ACK packet having a block number of zero

Figure 5-4: ERROR

2 bytes 2 bytes string 1
-----------------------------------------
| Opcode | ErrorCode | ErrMsg | 0 |
-----------------------------------------

An ERROR packet (opcode 5) takes the form depicted in Figure 5-4.

ERROR packet can be the acknowledgment of any other type of packet.

error code is an integer indicating the nature of the error. A table

values and meanings is given in the appendix. (Note that several

codes have been added to this version of this document.) The

message is intended for human consumption, and should be in netascii

Like all other strings, it is terminated with a zero byte

12

6. Normal

The end of a transfer is marked by a DATA packet that contains

0 and 511 bytes of data (i.e. Datagram length < 516). This packet

acknowledged by an ACK packet like all other DATA packets. The

acknowledging the final DATA packet may terminate its side of

connection on sending the final ACK. On the other hand, dallying

encouraged. This means that the host sending the final ACK will

for a while before terminating in order to retransmit the final ACK

it has been lost. The acknowledger will know that the ACK has been

if it receives the final DATA packet again. The host sending the

DATA must retransmit it until the packet is acknowledged or the

host times out. If the response is an ACK, the transmission

completed successfully. If the sender of the data times out and is

prepared to retransmit any more, the transfer may still have

completed successfully, after which the acknowledger or network may

experienced a problem. It is also possible in this case that

transfer was unsuccessful. In any case, the connection has been closed

7. Premature

If a request can not be granted, or some error occurs during

transfer, then an ERROR packet (opcode 5) is sent. This is only

courtesy since it will not be retransmitted or acknowledged, so it

never be received. Timeouts must also be used to detect errors

13

I.

Order of

2
----------------------------------------------------------
| Local Medium | Internet | Datagram | TFTP Opcode |
----------------------------------------------------------

TFTP

Type Op # Format without
2 bytes string 1 byte string 1
-----------------------------------------------
RRQ/ | 01/02 | Filename | 0 | Mode | 0 |
WRQ -----------------------------------------------
2 bytes 2 bytes n
---------------------------------
DATA | 03 | Block # | Data |
---------------------------------
2 bytes 2
-------------------
ACK | 04 | Block # |
--------------------
2 bytes 2 bytes string 1
----------------------------------------
ERROR | 05 | ErrorCode | ErrMsg | 0 |
----------------------------------------

14

Initial Connection Protocol for reading a

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
source= B's TID, destination= A's TID

15

Error

Value
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

16

3
Internet User Datagram Header [2]

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

Source Port Picked by originator of packet

Dest. Port Picked by destination machine (69 for RRQ or WRQ).

Length Number of bytes in packet after Datagram header

4
Checksum Reference 2 describes rules for computing checksum.
Field contains zero if unused

Note: TFTP passes transfer identifiers (TID's) to the Internet

Datagram protocol to be used as the source and destination ports

_______________
3
This has been included only for convenience. TFTP need not
implemented on top of the Internet User Datagram Protocol
4
The implementor of this should be sure that the correct algorithm
used here

17

[1] USA Standard Code for Information Interchange, USASI X3.4-

1968.

[2] Postel, Jon., "User Datagram Protocol," RFC768, August 28,

1980.

[3] "Telnet Protocol Specification," RFC764, June, 1980.

18

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX