Charles M. Kozierok The TCP-IP Guide

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

are many fewer Code values for ICMPv6. The ICMPv6 Code values were “streamlined”,

mainly because several of the ICMPv4 codes were related to relatively obscure features

that aren't applicable to ICMPv6.

Table 104 shows the different Code values, corresponding message subtypes and a brief

explanation of each:

Note that Code value 2 is not used. Also, Destination Unreachable messages are only sent

when there is a fundamental problem with delivering a particular datagram; they are not

sent when a datagram is dropped simply due to congestion of a router.

Processing of Destination Unreachable Messages

It is up to the recipient of an ICMPv6 Destination Unreachable message to decide what to

do with it. However, just as the original datagram may not reach its destination, the same is

true of the Destination Unreachable message itself. Therefore, a device cannot rely on the

receipt of one of these error messages to inform it of every delivery problem. This is

especially true given that it is possible some unreachable destination problems may not be

detectable.

Key Concept: ICMPv6 Destination Unreachable messages are used in the same

manner as the ICMPv4 message of that name: to inform a sending device of a failure

to deliver an IP datagram. The message’s Code field provides information about the

nature of the delivery problem (though the Code values are different than they are in

ICMPv4.)

Table 104: ICMPv6 Destination Unreachable Message Subtypes

Code

Value

Message

Subtype

Description

No Route To

Destination

The datagram was not delivered because it could not be routed to the

destination. Since this means the datagram could not be sent to the desti-

nation device's local network, this is basically equivalent to the “Network

Unreachable” message subtype in ICMPv4.

Communication

With Destination

Administratively

Prohibited

The datagram could not be forwarded due to filtering that blocks the

message based on its contents. Equivalent to the message subtype with

the same name (and Code value 13) in ICMPv4.

Address

Unreachable

There was a problem attempting to deliver the datagram to the host

specified in the destination address. This code is equivalent to the ICMPv4

“Host Unreachable” code and usually means the destination address was

bad or there was a problem with resolving it into a layer two address.

4 Port Unreachable

The destination port specified in the UDP or TCP header was invalid or

does not exist on the destination host.

ICMPv6 Packet Too Big Messages

One of the most interesting changes made to the operation of the Internet Protocol in

version 6 is related to the process of datagram fragmentation and reassembly. In IPv4, a

host can send a datagram of any size allowed by the IP specification out onto the inter-

network. If a router needs to send the datagram over a physical link that has a maximum

transmission unit (MTU) size that is too small for the size of the datagram, it will automati-

cally fragment the datagram and send the fragments individually so they will fit. The

destination device will receive the fragments and reassemble them. I explain the basics

behind this in the section on IPv4 datagram size, MTU, fragmentation and reassembly.

Note: Recall that “packet” is a synonym for “datagram”. I generally use the latter

term, but this message has “packet” in the name and it’s not like I was just going to

change it!

Even though it is convenient for hosts to be able to rely on routers to automatically fragment

messages as needed, it is inefficient for routers to spend time doing this. For this reason, in

IPv6 the decision was made to not allow routers to fragment datagrams. This puts the

responsibility on each host to ensure that datagrams they send out are small enough to fit

over every physical network between itself and any destination. This is done either by using

the IPv6 default minimum MTU of 1280, which every physical link must support, or a special

Path MTU Discovery process for determining the minimum MTU between a pair of devices.

Again, the full details are in the discussion of IPv6 datagram size, MTU, fragmentation and

reassembly.

If an IPv6 router is not allowed to fragment an IPv6 datagram that is too large to fit on the

next physical link over which it must be forwarded, what should the router do with it? The

datagram can't be forwarded, so the router has no choice but to discard it. When this

happens, the router is required to report this occurrence back to the device that initially sent

the datagram, using an ICMPv6 Packet Too Big message. The source device will know that

it needs to fragment the datagram in order to have it successfully reach its destination.

ICMPv6 Packet Too Big Message Format

Table 105 and Figure 153 show the format for ICMPv6 Packet Too Big messages:

Table 105: ICMPv6 Packet Too Big Message Format (Page 1 of 2)

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMPv6 message type; for Packet Too Big messages

this is set to 2.

Code 1 Code: Not used for this message type; 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.

Key Concept: In IPv6, routers are not allowed to fragment datagrams that are too

large to send over a physical link to which they are connected. An oversized

datagram is dropped, and an ICMPv6 Packet Too Big message sent back to the

datagram’s originator to inform it of this occurrence.

Applications of Packet Too Big Messages

While Packet Too Big is obviously an error message, it also has another use: the implemen-

tation of Path MTU Discovery. This process, described in RFC 1981, defines a method for a

device to determine the minimum MTU for a path to a destination. To perform path MTU

discovery, the source device sends a series of test messages, decreasing the size of the

datagram until it no longer receives Packet Too Big messages back in response to its tests.

See the topic on IPv6 MTU and fragmentation issues for a bit more detail on this.

MTU 4

MTU: The maximum transmission unit (MTU) size, in bytes, of the physical

link over which the router wanted to send the datagram, but was not able to

do so due to the datagram's size. Including this value in the Packet Too Big

message tells the source device the size it needs to use for its next trans-

mission to this destination to avoid this problem in the future (at least for

this particular link.)

Original

Datagram

Portion

Variable

Original Datagram Portion: As much of the IPv6 datagram as will fit

without causing the size of the ICMPv6 message (including its own IP

header) to exceed the minimum IPv6 MTU of 1280 bytes.

Figure 153: ICMPv6 Packet Too Big Message Format

Table 105: ICMPv6 Packet Too Big Message Format (Page 2 of 2)

Field Name

Size

(bytes)

Description

Type = 2 Code = 0 Checksum

MTU (of physical link where error occurred)

Original IPv6 Datagram Portion

(As Much As Will Fit Without Exceeding The 1280-Byte IPv6 Minimum MTU)

4 8 12 16 20 24 28 320

Note: The Packet Too Big message is new to ICMPv6. However, its use is

somewhat similar to the use of the Fragmentation Needed and DF Set version of

the ICMP4 Destination Unreachable message type, which is used as part of IPv4’s

path MTU discovery feature.

Incidentally, Packet Too Big is an exception to the rule that ICMP messages are sent only in

response to unicast datagrams; it may be sent in reply to an oversized multicast datagram.

If this occurs, it is important to realize that some of the intended targets of the multicast may

still have received it, if the path the multicast took to them did not go through the link with

the small MTU that caused the error.

ICMPv6 Time Exceeded Messages

The engineers who first designed the Internet Protocol recognized that due to the nature of

how routing works on an internetwork, there was always a danger that a datagram might

get “lost in the system” and spend too much time being passed from one router to another.

They included in IPv4 datagrams a field called Time To Live, which was intended to be set

to a time value by the device sending the datagram, and used as a timer to cause the

discard of the datagram if it took too long to get it to its destination.

Eventually, the meaning of this field changed so it was used not as a time in seconds but a

number of hops through which the datagram was allowed to be sent. In IPv6, the new

meaning of this field was formalized when it was renamed Hop Limit. Regardless of name,

the field still has the same basic purpose: it restricts how long a datagram can exist on an

internetwork by limiting the number of times routers can forward it. This is particularly

designed to provide protection against router loops that may occur in large or improperly-

configured internetworks. An example of this situation is where Router A thinks datagrams

intended for network X should next go to Router B; B thinks they should go to Router C; and

C thinks they need to go to A. Without a Hop Limit, such datagrams would circle forever,

clogging networks and never accomplishing anything useful, as shown in Figure 154.

Each time a router passes an IPv6 datagram, it decreases the Hop Limit field. If the value

ever reaches zero, the datagram expires and is discarded. When this happens, the router

that dropped the datagram sends an ICMPv6 Time Exceeded message back to the

datagram's originator to inform it that the datagram was dropped. This is basically the same

as the ICMPv4 Time Exceeded message. As in the ICMPv4 case, the device receiving the

message must decide whether and how to respond to receipt of the message. For example,

since the error can be caused by a device using a Hop Limit that was too low, the device

may try to re-send the datagram with a higher value before concluding that there is a

routing problem and giving up. (See the topic covering the ICMPv4 Time Exceeded

message for an illustration of how TTL expiration works.)

Just as with the ICMPv4 equivalent, there is also another “time expiration” situation that

ICMPv6 Time Exceeded messages are used for. When an IP message is broken into

fragments that are sent independently, the destination device is charged with reassembling

the fragments into the original message. One or more fragments may not make it to the

destination, however. To prevent the device from waiting forever, it sets a timer when the

first fragment arrives. If this timer expires before all of the other fragments are also

received, the device gives up on this message. The fragments are tossed out, and a Time

Exceeded message is also generated.

Figure 154: An Example of A Router Loop

This diagram shows a simple internetwork consisting of four networks, each of which is served by a router. It

is an adaptation of Figure 93, but in this case the routing tables have been set up incorrectly. R1 thinks that it

needs to route any traffic intended for network N4 to R3; R3 thinks it goes to R2; and R2 thinks it goes back to

R1. This means that when any device tries to send to N4, the datagram will circle this “triangle” until its Hop

Limit is reached, at which point an ICMPv6 Time Exceeded message will be generated.

R1 R4

R1 Routing Table

Ne tw o r k Route

N1 Direc t

N2 R2

N3 R3

N4 R3

R2 Routing Table

Ne tw o r k Route

N2 Direc t

N1 R1

N3 R3

R3 Routing Table

Ne tw o r k Route

N3 Direc t

N1 R1

N2 R2

R4 Routing Table

Ne tw o r k Route

N4 Direc t

N1 R1

R2 R3

N2 N3

Dest=N4

ICMPv6 Time Exceeded Message Format

The format for ICMPv6 Time Exceeded messages can be found in Table 106 and Figure

155.

Key Concept: Like their ICMPv4 namesakes, ICMPv6 Time Exceeded messages

are sent in two different “time-related” circumstances. The first is if a datagram’s Hop

Limit field is reduced to zero, causing it to expire and the datagram to be dropped.

The second is when all the pieces of a fragmented message are not received before the

recipient’s reassembly timer expires.

Table 106: ICMPv6 Time Exceeded Message Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMPv6 message type; for Time Exceeded messages

this is set to 3.

Code 1

Code: Identifies the “subtype” of time error being communicated. A value

of 0 indicates expiration of the Hop Limit field; a value of 1 indicates that

the fragment reassembly time has been exceeded.

Checksum 2

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

topic on the ICMP common message format.

Unused 4 Unused: 4 bytes left blank and not used.

Original

Datagram

Portion

Variable

Original Datagram Portion: As much of the IPv6 datagram as will fit

without causing the size of the ICMPv6 error message (including its own IP

header) to exceed the minimum IPv6 maximum transmission unit (MTU) of

1280 bytes.

Figure 155: ICMPv6 Time Exceeded Message Format

Type = 3

Code

(Timer Type)

Checksum

Unused

Original IPv6 Datagram Portion

(As Much As Will Fit Without Exceeding The 1280-Byte IPv6 Minimum MTU)

4 8 12 16 20 24 28 320

Applications of Time Exceeded Messages

In IPv4, ICMP Time Exceeded messages are used both as an error message and in a

clever application to implement the TCP/IP traceroute command. This is done by first

sending a “dummy” datagram is sent with a Time To Live value of 1, causing the first hop in

the route to discard the datagram and send back an ICMP Time Exceeded. Then, a second

datagram is sent to the same destination with a TTL value of 2, causing the second device

in the route to report back a Time Exceeded, and so on.

There is of course an IPv6 version of traceroute, sometimes called traceroute6. Due to IPv6

and its protocols and applications still being in development, I have not been able to confirm

definitively that traceroute6 is implemented using ICMPv6 Time Exceeded messages in the

manner described above, but I believe this is the case (and it certainly would make sense.)

See the topic discussing traceroute for further information.

ICMPv6 Parameter Problem Messages

The ICMPv6 Destination Unreachable, Packet Too Big and Time Exceeded messages

described in the previous topics in this section are used to indicate specific error conditions

to the original sender of a datagram. Recognizing that a router or host may encounter some

other problem in processing a datagram that is not covered by any of these message types,

ICMPv6 includes a generic error message type, just as ICMPv4 did. This is called the

ICMPv6 Parameter Problem message.

As the name suggests, a Parameter Problem message indicates that a device found a

problem with a parameter (another name for a datagram field) while attempting to work its

way through the header (or headers) in an IPv6 datagram. This message is only generated

when the error encountered is serious enough that the device could not make sense of the

datagram and had to discard it. That is, if an error is found that a device is able to recover

from and not drop the datagram, no Parameter Problem message is created.

As was the case for the ICMPv4 version of this message, the ICMPv6 message was

designed to be generic, so it can indicate an error in basically any field in the original

datagram. A special Pointer field is used that points to the place in that datagram where the

error was encountered. By looking at the structure of the original message (which as you

may recall is included, up to a certain size, in the ICMP message format) the original device

can tell which field contained the problem. The Code value is also used to communicate

additional general information about the nature of the problem.

ICMPv6 Parameter Problem Message Format

Table 107 and Figure 156 show the format for ICMPv4 Parameter Problem messages:

Parameter Problem Message Interpretation Codes and The Pointer Field

The Pointer field, which was only 8 bits wide in ICMPv4, has been widened to 32 bits in

ICMPv6, to provide more flexibility in isolating the error. The Code value is also used

somewhat differently in ICMPv6 than it was in the ICMPv4 version of this message type. In

ICMPv4, the Pointer was used only when the Code field was 0, and other code values

indicated other problem categories for which the Pointer field did not make sense. In

ICMPv6, the Pointer field is used with all Code types, to indicate the general nature of what

the problem is. This means the Pointer field tells the recipient of the Parameter Problem

Figure 156: ICMPv6 Parameter Problem Message Format

Table 107: ICMPv6 Parameter Problem Message Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMPv6 message type; for Parameter Problem

messages this is set to 4.

Code 1

Code: Identifies the general class of the parameter problem. See Table

108 for more information.

Checksum 2

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

topic on the ICMP common message format.

Pointer 4

Pointer: An offset that points to the byte location in the original 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.

Original

Datagram

Portion

Variable

Original Datagram Portion: As much of the IPv6 datagram as will fit

without causing the size of the ICMPv6 error message (including its own IP

header) to exceed the minimum IPv6 maximum transmission unit (MTU) of

1280 bytes.

Type = 4

Code

(Problem Type)

Checksum

Pointer

Original IPv6 Datagram Portion

(As Much As Will Fit Without Exceeding The 1280-Byte IPv6 Minimum MTU)

4 8 12 16 20 24 28 320

where in the message the problem happened, and the Code field tells it what the nature of

the problem is. The following table shows the three Code values and provides a brief expla-

nation of each:

Key Concept: The ICMPv6 Parameter Problem message is a generic error

message that can be used to convey an error of any type in an IP datagram. The

Pointer field is used to indicate to the recipient of the message where the problem

was in the original datagram.

Table 108: ICMPv6 Parameter Problem Message Interpretation Codes

Code

Value

Message Subtype Description

Erroneous Header Field

Encountered

The Pointer field points to a header that contains an error or

otherwise could not be processed.

Unrecognized Next

Header Type Encountered

Recall that in IPv6 a datagram can have multiple headers, each of

which contains a Next Header field that points to the next header in

the datagram. This code indicates that the Pointer field points to a

Next Header field containing an unrecognized value.

Unrecognized IPv6 Option

Encountered

The Pointer field points to an IPv6 option that was not recognized

by the processing device.

ICMP Version 6 (ICMPv6) Informational Message Types and Formats

In the previous section we explored a number of ICMPv6 error messages, which are sent

back to the originator of an IPv6 datagram when an error is detected in it that makes it

impossible to be delivered. Just as was the case with the original version of ICMP

(ICMPv4), ICMPv6 also defines another class of message: informational messages. These

ICMPv6 messages are used not to report errors, but to allow the sharing of information

required to implement various test, diagnostic and support functions critical to the operation

of IPv6.

In this section I describe eight different ICMPv6 informational messages in five topics (six of

these messages are used in matching pairs, and the pairs are described together). I begin

by describing ICMPv6 Echo Request and Echo Reply messages, used for network connec-

tivity testing. I explain the format of Router Advertisement and Router Solicitation

messages, used to let hosts discover local routers and learn necessary parameters from

them. I then describe ICMPv6 Neighbor Advertisement and Neighbor Solicitation

messages, used for various communications between hosts on a local network, including

IPv6 address resolution. I discuss IPv6 Redirect messages, which let routers inform hosts

of better first-hop routers, and IPv6 Router Renumbering messages.

Several of the ICMPv6 informational messages include additional information that is either

optional, recommended or mandatory, depending on the circumstances under which the

message is generated. Some of these are shared between message types, so they are

described in a separate topic at the end of the section.

In IPv4, the use of many of the ICMP informational messages was described in a variety of

different standards. In IPv6, many of the functions using informational messages have been

gathered together and formalized in the IPv6 Neighbor Discovery (ND) Protocol. The solici-

tation and advertisement of local routers and neighboring hosts, as well as communication

of redirection information are both examples of activities for which ND is responsible. In

fact, five of the ICMP messages described in this section are actually defined in the

Neighbor Discovery standard, RFC 2461.

ND and ICMPv6 are obviously closely related, given that ND describes the use of several of

the ICMP messages: Router Advertisement, Router Solicitation, Neighbor Advertisement,

Neighbor Solicitation and Redirect. Thus, just as ICMPv4 is an important “assistant” to IPv4,

both ICMPv6 and ND are important helpers for IPv6. In this Guide, I provide most of the

description of how these messages are used in the detailed section on ND. In this section, I

provide only a brief summary of their use, while focusing primarily on message format and

the meaning of each of the fields in that format.

Note: In ICMPv6, the Redirect message is informational, and no longer

considered an error message as it was in ICMPv4.