Charles M. Kozierok The TCP-IP Guide

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

ICMPv4 Redirect Message Format

The format for ICMPv4 Redirect messages can be found in Table 93 and Figure 144.

Redirect Message Interpretation Codes

When a Redirect is received back by a device, it inspects the included portion of the original

datagram. Since this contains the original destination address of the redirected target

device, this tells the original sender which addresses should be redirected in the future. The

Internet Address field tells it what router it should use for subsequent datagrams. The Code

field tells the sender how broadly to interpret the redirection. There are four different Code

values; see Table 94.

Obviously, routers usually generate Redirect messages and send them to hosts; hosts do

not normally create them. The specific rules for when Redirects are created can be fairly

complex, as a number of conditions may exist that preclude these messages from being

sent. In particular, special rules exist for when a router may Redirect an entire network (or

Table 93: ICMPv4 Redirect Message Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMP message type; for Redirect messages this value

is 5.

Code 1

Code: Identifies the meaning or “scope” of the Redirect message. See

Table 94 for an explanation of how this field is used in Redirect messages.

Checksum 2

Checksum: 16-bit checksum field for the ICMP header, as described in the

topic on the ICMP common message format.

Internet Address 4

Internet Address: The address of the router to which future datagrams

sent to the original destination should be sent.

Original

Datagram

Portion

Variable

Original Datagram Portion: The full IP header and the first 8 bytes of the

payload of the datagram that led to the creation of the Redirect.

Figure 144: ICMPv4 Redirect Message Format

Type = 5

Code

(Redirection Type)

Checksum

Internet Address

(Address of Preferred Router for Future Transmissions)

Original IP Datagram Portion

(Original IP Header + First Eight Bytes Of Data Field)

4 8 12 16 20 24 28 320

subnet) instead of just a single host. Also, remember that the Type Of Service field is

optional and often not used, so Redirects with Code values of 2 or 3 are less common than

those with values of 0 and 1.

Note: One problem with Redirects for whole networks is that the network specifi-

cation may be ambiguous in an environment where subnetting or classless

addressing are used. For this reason, the use of Code values 0 and 2 was

prohibited by RFC 1812; they are considered obsolete on the modern Internet.

Limitations of Redirect Messages

I must emphasize that ICMP Redirect messages are not a mechanism by which the

general routing process in IP is implemented; they are a support function only. They are a

convenient way for hosts to be given information about routes by local routers, but are not

used to communicate route information between routers.

This means that a Redirect can tell a host to use a more efficient first-hop router, but cannot

tell a router to use a more efficient second-hop router. In our example above, suppose that

in addition to the connections mentioned, R2 is connected to R3 and R4 as shown in Figure

143. R2 sends the datagram in question to R3, which realizes it needs to send to R4, a

router already directly connected to R2. R3 cannot send a Redirect to R2 telling it to use

R4 next time. The messages are simply not designed for this purpose—remember that

ICMP messages always go back to the source of the original datagram, which would not be

R2 in this case. Such inefficiencies must be resolved using routing protocols.

Table 94: ICMP Redirect Message Interpretation Codes

Code

Value

Message Subtype Meaning

Redirect Datagrams For The

Network (Or Subnet)

Redirect all future datagrams sent not only to the device

whose address caused this Redirect, but also datagrams

sent to all other devices on the network (or subnet) where

that device is located. (This code is now obsolete; see the

note that follows this table.)

1 Redirect Datagrams For The Host

Redirect all future datagrams only for the address of the

specific device to which the original datagram was sent.

Redirect Datagrams For The Type

Of Service (TOS) and Network (Or

Subnet)

As for Code value 0, but only for future datagrams that

have the same Type Of Service (TOS) value as the

original datagram. (This code is now obsolete; see the

note that follows this table.)

Redirect Datagrams For The Type

Of Service (TOS) and Host

As for Code value 1, but only for future datagrams that

have the same Type Of Service (TOS) value as the

original datagram.

Key Concept: ICMPv4 Redirect messages are used by a router to inform a host of a

preferred router to use for future datagrams sent to a particular host or network. They

are not used to alter routes between routers.

ICMPv4 Parameter Problem Messages

The previous topics in this section describe four specific ICMPv4 message types that allow

a device to report various error conditions to the original sender of a datagram. However,

other error situations may arise also that don't correspond to any of these four specific

message types. Typically, the problem results when a device attempts to process the

header fields of an IP datagram and finds something in it that doesn't make sense.

If a device finds a problem with any of the parameters in an IP datagram header that is

serious enough that it cannot complete processing the header, it must discard the

datagram. Like other cases where a datagram must be tossed out, this is serious enough to

warrant communication of the problem back to the device that sent the original datagram.

This is accomplished in ICMPv4 using the Parameter Problem message type.

This is a “catch all” type of message that can be used to indicate an error in any header field

of an IP datagram. The message type does not contain any specific fields or coding to

indicate what the problem is. This was done intentionally to keep the Parameter Problem

message “generic” and ensure that it could indicate any sort of error. Instead of special

error codes, most Parameter Problem messages tell the original source which parameter

caused the problem by including a special pointer that indicates which field in the original

datagram header caused the problem.

ICMPv4 Parameter Problem Message Format

Table 95 and Figure 145 show the format for ICMPv4 Parameter Problem messages.

Table 95: ICMPv4 Parameter Problem Message Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMP message type; for Parameter Problem

messages this value is 12.

Code 1

Code: Identifies the “subtype” of problem being communicated. See Table

96 for more information on this field for Parameter Problem messages.

Checksum 2

Checksum: 16-bit checksum field for the ICMP header, as described in the

topic on the ICMP common message format.

Pointer 1

Pointer: An offset that points to the byte location in the datagram that

caused the Parameter Problem message to be generated. The device

receiving the ICMP message can use this value to get an idea of which

field in the original message had the problem.

This field is used only when the Code value is 0.

Parameter Problem Message Interpretation Codes and The Pointer Field

When a Parameter Problem message is generated due to a specific bad field in the original

message, the Pointer field is used as described above to show the location of the problem.

This meaning of the Parameter Problem message is the one that was defined in the original

ICMP standard, RFC 792, and is associated with Code value 0. There are some cases of a

parameter problem where a pointer to a specific field in the original message really wouldn't

make sense, so other standards have defined two new Code field values for Parameter

Problem messages. Table 96 shows the three Code values and provides a brief explanation

of each.

Unused 3 Unused: 3 bytes that are left blank and not used.

Original

Datagram

Portion

Variable

Original Datagram Portion: The full IP header and the first 8 bytes of the

payload of the datagram that prompted this error message to be sent.

Figure 145: ICMPv4 Parameter Problem Message Format

Table 96: ICMPv4 Parameter Problem Message Interpretation Codes

Code

Value

Message

Subtype

Description

Pointer Indicates

The Error

This is the normal use of the Parameter Problem message; when this Code

value is used, the Pointer field indicates the location of the problem.

Missing A

Required Option

The IP datagram needed to have an option in it that was missing. Since the

option was missing there is no way to point to it, of course. ☺

2 Bad Length

The length of the datagram overall was incorrect, indicating a general

problem with the message as a whole. Again, the Pointer field makes no

sense here.

Table 95: ICMPv4 Parameter Problem Message Format

Field Name

Size

(bytes)

Description

Type = 11

Code

(Problem Type)

Checksum

Pointer Unused

Original IP Datagram Portion

(Original IP Header + First Eight Bytes Of Data Field)

4 8 12 16 20 24 28 320

Key Concept: The ICMPv4 Parameter Problem message is a generic “catch all” that

can be used to convey an error of any type in an IP datagram. A special Pointer field

is normally used to indicate to the recipient of the message where the problem was in

the original datagram.

Note that the Pointer field is only 8 bits wide, but since this allows for values up to 256 this

is sufficient to allow it to point to any location within the IP header. It is possible for the

Pointer field to point to a field within an IP option. Both hosts and routers can generate

Parameter Problem messages.

ICMP Version 4 (ICMPv4) Informational Message Types and Formats

The five ICMP error message types communicate important information about error or

problem conditions encountered during the operation of an IP internetwork. In contrast, the

other class of ICMP messages contains those messages that are informational. They are

not sent in response to some issue with a regular IP datagram, but are used on they own to

implement various support functions for IP. Informational messages are used for testing and

diagnostic purposes, as well as to let devices share critical information they need to

function correctly.

In this section I describe nine different ICMP version 4 informational messages. Since many

of these messages are used in functional sets, pairs of related messages are described in

the same topic. I begin with a discussion of the Echo (Request) and Echo Reply messages

used for network testing, and Timestamp and Timestamp Reply messages used for clock

synchronization. I explain the use and format of Router Advertisement and Router Solici-

tation messages, which allow hosts to discover the identity of local routers and learn

important information about them. I also describe the Address Mask Request and Address

Mask Reply messages that communicate subnet mask information. I conclude with a look

at the Traceroute message, which implements a more sophisticated version of the

traceroute utility.

Note: The original ICMP standard also defined two more informational message

types: Information Request and Information Reply. These were intended to allow

devices to determine an IP address and possibly other configuration information.

This function was later implemented using protocols such as RARP, BOOTP and DHCP,

and these message types obsoleted. Therefore, they are not discussed in this section.

(Well, I guess I did just discuss them there... you know what I mean!)

ICMPv4 Echo (Request) and Echo Reply Messages

One of the main purposes of ICMP informational messages is to enable testing and

diagnostics, to help identify and correct problems on an internetwork. The most basic test

that can be conducted between two devices is simply checking if they are capable of

sending datagrams to each other. The usual way that this is done is to have one device

send a test message to a second device, which receives the message and replies back to

tell the first device it received the message.

ICMPv4 includes a pair of messages specifically for connection testing. Suppose Device A

wants to see if it can reach Device B. Device A begins the test process by sending an

ICMPv4 Echo message to B. Device B, when it receives the Echo, responds back to Device

A with an Echo Reply message. When Device A receives this message, it knows that it is

able to communicate (both send and receive) successfully with Device B.

Note: The name of the first message in this pair is often given as Echo Request.

While this does convey the paired nature of the Echo and Echo Reply messages,

the formal name used in the standards is simply an Echo message.

ICMPv4 Echo and Echo Reply Message Format

Table 97 and Figure 146 show the format for both ICMPv4 Echo and Echo Reply

messages.

It is possible that a source device may want to send more than one Echo message to either

a single destination or multiple destinations. Conversely, a single destination might receive

Echo messages from more than one source. It is essential that a device receiving an Echo

Reply knows which Echo prompted it to be sent.

Table 97: ICMPv4 Echo and Echo Reply Message Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMP message type. For Echo messages the value is

8; for Echo Reply messages the value is 0.

Code 1 Code: Not used for Echo and Echo Reply messages; set to 0.

Checksum 2

Checksum: 16-bit checksum field for the ICMP header, as described in the

topic on the ICMP common message format.

Identifier 2

Identifier: An identification field that can be used to help in matching Echo

and Echo Reply messages.

Sequence

Number

Sequence Number: A sequence number to help in matching Echo and

Echo Reply messages.

Optional Data Variable

Optional Data: Additional data to be sent along with the message (not

specified.)

Figure 146: ICMPv4 Echo and Echo Reply Message Format

Type = 0 or 8 Code = 0 Checksum

Identifier Sequence Number

Optional Data

4 8 12 16 20 24 28 320

Two special fields are used within the format of these messages to allow Echo and Echo

Reply messages to be matched together, and to allow a sequence of messages to be

exchanged. The Identifier field was envisioned as being used as a higher-level label, like a

session identifier, while the Sequence Number was seen as something to identify individual

test messages within a series. However, the use of these fields is up to the particular imple-

mentation. In some cases, the Identifier field is filled in with the process number of the

application that is using the Echo or Echo Reply message, to allow several users to use

utilities like ping without interference.

Application of Echo and Echo Reply Messages

The most common way that you may use the Echo and Echo Reply messages is through

the popular utility ping, which is used to test host reachability. While the basic test simply

consists of sending an Echo and waiting for an Echo Reply, modern versions of ping are

quite sophisticated. They allow the user to specify many parameters, including the number

of Echo messages sent, how often they are sent, the size of message transmitted and

more. They also provide a great deal of information about the connection, including the

number of Echo Reply messages received, the time elapsed for the pair of messages to be

exchanged and a lot more. See the topic describing ping for a full explanation of the utility.

Key Concept: IICMPv4 Echo (Request) and Echo Reply messages are used to

facilitate network reachability testing. A device can test its ability to perform basic

communication with another one by sending an Echo message and waiting for an

Echo Reply to be returned by the other device. The ping utility, a widely-used diagnostic tool

in TCP/IP internetworks, makes use of these messages.

ICMPv4 Timestamp (Request) and Timestamp Reply Messages

All of the hosts and routers on an internetwork operate independently of each other. One

aspect of this autonomy is that each device maintains a separate system clock. Since even

highly-accurate clocks have slight differences in how accurately they keep time, as well as

the time they are initialized with, this means that under normal circumstances, no two

devices on an internetwork are guaranteed to have exactly the same time.

The creators of TCP/IP recognized that certain applications might not work properly if there

was too much differential between the system clocks of a pair of devices. To support this

requirement, they created a pair of ICMP messages that allow devices to exchange system

time information. The initiating device creates a Timestamp message and sends it to the

device with which it wishes to synchronize. That device responds with a Timestamp Reply

message. Timestamp fields in these messages are used to mark the times that these

messages are sent and received to allow the devices' clocks to be synchronized.

Note: As with the Echo message, the Timestamp message is sometimes seen as

Timestamp Request, though the word “Request” doesn't appear in its formal

name.

ICMPv4 Timestamp and Timestamp Reply Message Format

The ICMPv4 Timestamp and Timestamp Reply messages have the same format. The origi-

nating device fills in some of the fields, and the replying device others. The format is as

shown in Table 98 and Figure 147.

The Identifier and Sequence Number fields are used to match Timestamp and Timestamp

Reply messages, exactly as they were used for Echo and Echo Reply messages. The

Identifier field is intended as a higher-level label, like a session identifier, while the

Sequence Number is often used to identify individual messages within a series. However,

the use of these fields is up to the particular implementation.

All three timestamps are represented as the number of milliseconds since midnight,

Universal Time (UT, also called Greenwich Mean Time or GMT). The reason there are three

timestamps instead of the two you might ordinarily expect, is that a separate timestamp is

recorded by the responding device both when it receives the Timestamp message and

when it generates the Timestamp Reply. When the Reply is received back by the originating

device, it then has the times that both the Timestamp and the Timestamp Reply were sent.

Table 98: ICMPv4 Timestamp and Timestamp Reply Message Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMP message type. For Timestamp messages the

value is 13; for Timestamp Reply messages the value is 14.

Code 1 Code: Not used for Timestamp and Timestamp Reply messages; set to 0.

Checksum 2

Checksum: 16-bit checksum field for the ICMP header, as described in the

topic on the ICMP common message format.

Identifier 2

Identifier: An identification field that can be used to help in matching

Timestamp and Timestamp Reply messages.

Sequence

Number

Sequence Number: A sequence number to help in matching Timestamp

and Timestamp Reply messages.

Originate

Timestamp

Originate Timestamp: A time value filled in by the originating device just

before sending the Timestamp message.

Receive

Timestamp

Receive Timestamp: A time value filled in by the responding device just

as it receives the Timestamp message.

Transmit

Timestamp

Transmit Timestamp: A time value filled in by the responding device just

before sending back the Timestamp Reply message.

This allows the originating device to differentiate between the time required for transmitting

datagrams over the network, and the time for the other device to process the Timestamp

and turn it into a Timestamp Reply.

Issues Using Timestamp and Timestamp Reply Messages

In practice, even with three timestamp fields, it is difficult to coordinate system clocks over

an internetwork—especially a large one like the Internet. The main problem is that the

amount of time it takes to send a datagram between any pair of devices varies from one

datagram to the next. And again, since IP is unreliable, it's possible the time for a datagram

to be received could be infinite—it might be lost or dropped by a router.

This means that a simple exchange of Timestamp and Timestamp Reply messages is

simply not a reliable enough method for ensuring that two devices are synchronized on a

typical IP internetwork. For this reason, modern devices often use a more sophisticated

method for time synchronization, such as the Network Time Protocol (NTP).

Note that unlike many of the other ICMP message types, support for Timestamp and

Timestamp Reply messages is optional, for both hosts and routers.

ICMPv4 Router Advertisement and Router Solicitation Messages

In the overview topic describing IP routing fundamentals, I discussed a critical aspect of IP

internetwork design: the difference between the roles of a router and that of a host with

regard to routing. Routers are charged with the job of routing datagrams, and therefore, of

knowing routes and exchanging route information. Hosts generally do not know a great deal

about routes; they rely on routers to convey datagrams intended for destinations outside the

local network.

Figure 147: ICMPv4 Timestamp and Timestamp Reply Message Format

Type = 13 or 14 Code = 0 Checksum

Identifier Sequence Number

Originate Timestamp

Receive Timestamp

Transmit Timestamp

4 8 12 16 20 24 28 320