Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

The server receives the request containing the options, and if it supports the option

extension, processes them. It then returns a special Option Acknowledgment (OACK)

message to the client, where it lists all the options that the client specified that the server

recognizes and accepts. Any options that the client requested but the server rejects, it does

not include in this option acknowledgment. The client may only use the options that the

server accepts. If the client rejects the server's response, it may send back an error

message (with error code 8) upon receipt of the unacceptable OACK message.

The server may specify an alternative value in its response for certain options, if it recog-

nizes the option but doesn't like the client’s suggested value. Obviously, if the server doesn't

support options at all, it will ignore the client's option requests, and respond back with a

data message (for a read) or a regular acknowledgment (for a write) as in normal TFTP.

If the server did send an OACK, the client then proceeds to send messages using the

regular messaging exchange described in the previous section. In the case of a write, the

option acknowledgment replaces the regular acknowledgment in the message dialog. In the

case of a read, the option acknowledgment is the server's first message instead of the first

data block that it would normally send. TFTP doesn't allow the same device to send two

datagrams in a row, so there needs to be a reply from the client before that first block can

be sent. The client does this by sending a regular acknowledgment with a block number of

0 in it — the same form of acknowledgment a server normally sends for a write.

Key Concept: TFTP is supposed to be a small and simple protocol, so it includes

few “extra” features. One that it does support is option negotiation, where a TFTP

client and server attempt to come to agreement on additional parameters that they

will use in transferring a file. The TFTP client includes one or more options in its Read

Request or Write Request message; the TFTP server then sends an Option Acknowl-

edgment (OACK) message listing each option the server agrees to use. The use of options

when reading a file means that an extra acknowledgment must be sent by the client--to

acknowledge the OACK--before the server sends the first block of the file.

Phew, that's confusing. For review, let's take a look at each of the four possible cases (read

and write, with and without options).

TFTP Read Process With and Without Option Negotiation

The initial message exchange for a normal read (without option negotiation), as shown in

Figure 293:

1. Client sends Read Request.

2. Server sends Data block #1.

3. Client acknowledges data block #1.

And so on…

And now, a read with option negotiation (Figure 295):

1. Client sends Read Request with options.

2. Server sends Option Acknowledgment.

3. Client sends regular acknowledgment for “block #0”, that is, it acknowledges the

OACK.

4. Server sends data block #1.

5. Client acknowledges data block #1.

Etc…

Figure 295: TFTP Read Process With Option Negotiation

This diagram shows the same example illustrated in Figure 293, but with one added message exchange used

for option negotiation (purple background). The client’s initial Read Request here includes options that it

wants to use for this transfer. The server responds not immediately with the first data block, but with an Option

Acknowledgment. The client indicates receipt of the OACK by sending an acknowledgment using block #0.

The server sends data block #1 and the rest of the exchange proceeds as normal.

TFTP ServerTFTP Client

1. Send Read Request

For File With Options

4. Receive Acknowledgment,

Send Data Bytes 1 to 512

6. Receive Acknowledgment,

Send Data Bytes 513 to 1,024

5. Receive Block #1,

Send Acknowledgment

DATA

(Block #1)

ACK

(Block #1)

DATA

(Block #2)

7. Receive Block #2,

Send Acknowledgment

ACK

(Block #2)

8. Receive Acknowledgment,

Send Data Bytes 1,025 to 1,200

DATA

(Block #3)

ACK

(Block #3)

9. Receive Block #3,

Send Acknowledgment

10. Receive Acknowledgment;

File Transfer Complete

RRQ

(With Options)

OACK

2. Receive Read Request,

Send Option Acknowledgment

3. Receive OACK,

Send Acknowledgment

ACK

(Block #0)

TFTP Write Process With and Without Option Negotiation

The initial message exchange for a normal write (without option negotiation):

1. Client sends write request.

2. Server sends acknowledgment.

3. Client sends data block #1.

4. Server acknowledges data block #1.

…

And a write with option negotiation:

1. Client sends write request with options.

2. Server sends option acknowledgment (instead of regular acknowledgment).

3. Client sends data block #1.

4. Server acknowledges data block #1.

…

TFTP Options

Table 235 contains a summary of the three TFTP options currently defined.

TFTP Message Formats

Unlike FTP, all communication in TFTP is accomplished in the form of discrete messages

that follow a particular message format. The reason why TFTP and FTP are so different in

this regard is the different transport protocols they use. FTP uses TCP, which allows data to

be streamed a byte at a time; FTP also makes use of a dedicated channel for commands.

TFTP runs on UDP, which uses a conventional “header/data” formatting scheme.

Table 235: TFTP Options

TFTP

Option

Name

TFTP Option

Code (Used in

Request

Messages)

Defining

RFC

Description

Block Size blksize 2348

Allows the client and server to send data blocks of a size

different than 512 bytes, to improve efficiency or address

limitations of a particular type of network.

Timeout

Interval

interval 2349

Permits the client and server to agree on a specified

number of seconds to use for their retransmission timers.

Again, may be of value on certain networks with high

latency or other special requirements.

Transfer Size tsize 2349

Lets the device sending the file (client on a write, server on

a read) tell the other device the size of the file before the

transfer commences. This allows the receiving device to

allocate space for it in advance.

The original TFTP standard defines five different types of messages: Read Request (RRQ),

Write Request (WRQ), Data (DATA), Acknowledgment (ACK) and Error (ERROR). The

TFTP option extension feature defines a sixth message: Option Acknowledgment (OACK).

Of these six messages, the first two share the same message format. The others all have

their own unique format. The only common field in every TFTP message is the Operation

Code (Opcode), which tells the recipient of the message what type it is.

TFTP's message formats are different than those used for certain other protocols because

many of the fields are variable in length. Usually, variable-length fields in messages are

expressed using a preceding length field that specifies the length of the variable-sized field.

Instead, TFTP sends such fields as strings of ASCII characters using netascii, the Tel net

version of ASCII. The end of the string is marked by a zero byte. The exception to this is the

data field in Data messages, the content of which depends on the transfer mode.

You will find below the details of each TFTP message type.

Read Request and Write Request Messages

These messages use a common message format, described in Table 236 and shown

graphically in Figure 296.

Table 236: TFTP Read Request / Write Request Message Format

Field Name

Size

(bytes)

Description

Opcode 2

Operation Code: Specifies the TFTP message type. A value of 1 indicates

a Read Request message, while a value of 2 is a Write Request message.

Filename Variable Filename: The name of the file to be read or written.

Mode Variable

Transfer Mode: The string “netascii” or “octet”, zero-terminated. (Why not

just use one byte set to 0 for netascii and 1 for octet? Don't ask me! ☺)

Options Variable

ons:

e c

suppor

TFTP

ons,

ill

enco

sequence following the Mode field. Each option consists of these subfields:

Subfield

Name

Size

(bytes)

Description

optN Variable

Option Code for Option #N: A string specifying

the name of the option; currently, “blksize”,

“interval” and “tsize” are supported.

valueN Variable

Option Value for Option #N: The value the client

is requesting for this option. Note that this is a

zero-terminated string just like other TFTP

variable-length fields, even for a numeric value.

Data Messages

Data blocks are sent using the simplified format shown in Table 237 and Figure 297.

Figure 296: TFTP Read Request / Write Request Message Format

Table 237: TFTP Data Message Format

Field Name

Size

(bytes)

Description

Opcode 2

Operation Code: Specifies the TFTP message type. A value of 3 indicates

a Data message.

Block # 2 Block Number: The number of the data block being sent.

Data Variable Data: 0 to 512 bytes of data.

Operation Code = 1 (RRQ) or 2 (WRQ)

Transfer Mode

Option #1 Code

4 8 12 16 20 24 28 320

...

Option #1 Value

Filename

Option #N Value

Option #N Code

Acknowledgment Messages

Acknowledgments have the simplest format of any TFTP message, as you can see in Table

238 and Figure 298.

Figure 297: TFTP Data Message Format

Table 238: TFTP Acknowledgment Message Format

Field Name

Size

(bytes)

Description

Opcode 2

Operation Code: Specifies the TFTP message type. A value of 4 indicates

an Acknowledgment message.

Block # 2

Block Number: The number of the data block being acknowledged; a

value of 0 is used to acknowledge receipt of a write request without

options, or to acknowledge receipt of an option acknowledgment.

Figure 298: TFTP Acknowledgment Message Format

Operation Code = 3 Block Number

Data

4 8 12 16 20 24 28 320

Operation Code = 4 Block Number

4 8 12 16 20 24 28 320

Error Messages

Error messages can be sent by either client or server in cases where a problem is detected

in the communication. They have the format indicated in Table 239 and Figure 299.

Table 239: TFTP Error Message Format

Field Name

Size

(bytes)

Description

Opcode 2

Operation Code: Specifies the TFTP message type. A value of 5 indicates

an Error message.

Error Code 2

Error Msg Variable

Error Message: A descriptive text error message string, intended for

“human consumption”, as the standard puts it. ☺

Figure 299: TFTP Error Message Format

rror

numer

c co

ype o

message

ng commu-

nicated. Values 0 to 7 are defined by the TFTP standard, while value 8 was

added by the TFTP option extension:

Error Code

Value

Error Type

0 Not defined; see error message field for details.

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.

Client transfer termination due to unacceptable option

negotiation.

Operation Code = 5 Error Code

Error Message

4 8 12 16 20 24 28 320

Option Acknowledgment Messages

OACK messages are used to acknowledge receipt of TFTP options. They are structured as

shown in Table 240 and Figure 300.

Table 240: TFTP Option Acknowledgment Message Format

Field Name

Size

(bytes)

Description

Opcode 2

Operation Code: Specifies the TFTP message type. A value of 6 indicates

an Option Acknowledgment message.

Options Variable

Figure 300: TFTP Option Acknowledgment Message Format

ons:

ons

ng ac

now

e server.

consists of these two subfields:

Subfield

Name

Size

(bytes)

Description

optN Variable

Option Code for Option #N: A string specifying

the name of the option, copied from the Read

Request or Write Request message.

valueN Variable

Option Value for Option #N: The acknowledged

value for the option, which may be the value that

the client specified, or an alternative value,

depending on the type of option.

Operation Code = 6

4 8 12 16 20 24 28 320

...

Option #1 Value

Option #N Value

Option #N Code

Option #1 Code

TCP/IP Electronic Mail System: Concepts and Protocols (RFC 822,

MIME, SMTP, POP3, IMAP)

It is common for human beings to create systems that are reminiscent of ones to which they

are already accustomed. We are all accustomed to using the regular mail system to send

letters and other documents from our location to recipients anywhere that the postal system

serves. Naturally, one of the first applications of internetworks was to create an electronic

version of this conventional mail system that would allow messages to be sent in a similar

manner, but more quickly and easily. Over the course of many years, an electronic mail

system for TCP/IP was created and refined. It is now the most widely used means of

electronic messaging in the world.

In this section I describe TCP/IP electronic mail in detail, in five sections that discuss

electronic mail concepts and the various components and protocols that comprise the

overall TCP/IP e-mail system. The first subsection provides an overview of TCP/IP

electronic mail and discusses the way that it is used and the different protocols and

methods that comprise the system. The second discusses how e-mail messages are

addressed, and the third covers standard and special formats for e-mail messages. The

fourth and fifth subsections describe the TCP/IP protocols that implement electronic mail

functionality. This includes an examination of the Simple Mail Transfer Protocol (SMTP),

which is responsible for the delivery of e-mail, and several protocols and methods used for

mailbox access and mail retrieval, including POP3 and IMAP.

Note: This discussion focuses primarily on the mechanisms used for electronic

mail composition, delivery and access in modern internetworks. In the e-mail

overview topic I make mention of some techniques used in the past for TCP/IP

electronic mail, but only briefly for historical completeness, and to contrast these methods

to the ones presently used.

TCP/IP Electronic Mail System Overview and Concepts

Electronic mail in the TCP/IP protocol suite is not implemented as just a single protocol or

technology. Rather, it is a complete system that contains a number of related components

that work together. These include standards defining methods for addressing and message

formatting, and a number of protocols that play different functions in implementing

electronic mail messaging. Before proceeding to examine each of these pieces, it makes

sense to start with an overview of the system as a whole.

In this section I provide an introductory look at TCP/IP electronic mail, to help you under-

stand the system, how it works, and how different components fit into it. I begin with an

overview and history of e-mail and its implementation in TCP/IP. I provide a general

overview of the steps involved in the e-mail communication process. I conclude with a more

specific discussion of the communication model used in TCP/IP and the roles played by

various TCP/IP devices and protocols in the sending and receiving of electronic mail.

TCP/IP Electronic Mail System Overview and History

The need to communicate is as old as humanity itself. Thousands of years ago, communi-

cation was, of necessity, almost exclusively local. Messages were primarily oral, and even

when in writing, rarely delivered a great distance. Most people never travelled far from their

homes, and rarely communicated with those distant from themselves. But even in ancient

times, messengers were used by leaders to send short pieces of critical information from

place to place. It was slow and unreliable, but some messages were important enough that

an effort to communicate often had to be made in spite of the difficulties.

Advances in transportation led to advances in communication capability, eventually

resulting in the creation of physical mail systems. Today, these systems have evolved to the

point where anyone in the developed world can send a letter to just about anyone else.

Reliability has vastly improved, despite all the jokes people make about the postal service.

☺ Speed is also much better than it was in the olden times, with messages now taking days

to reach their destination instead of weeks or months.

Waiting even days for a message to get from one place to another is pretty slow by the

standards of our modern world. For this reason, one of the most natural applications of

networks was to use them as a replacement for the physical transportation of messages

from one place to another. Transforming mail from a physical process to an electronic one

yields enormous benefits, chief among them greatly increased communication speed, the

ability to instantly send one message to multiple recipients, and the ability to get nearly

instantaneous feedback upon receipt of a message.

The Early Days of Electronic Mail

The idea behind electronic mail (e-mail or email) is not only as old as computer networks, it

actually predates internetworking. The first electronic mail systems were implemented on

traditional mainframe computers. These are single large computers accessed by many

users simultaneously through connected terminals. An e-mail system on a mainframe

consisted of a set of software running on the mainframe that implemented the entire