Charles M. Kozierok The TCP-IP Guide

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

Addressing of Neighbor Advertisement and Neighbor Solicitation Messages

Neighbor Solicitation messages are sent either unicast to the address of the target device,

or to the solicited-node multicast address of the target. This latter address is a special type

used to allow a device to send a multicast that will be heard by the target whose address it

is trying to resolve, but won't be heard by most other devices; it is explained in the topic on

IPv6 address resolution.

When a Neighbor Advertisement message is generated in response to a Neighbor Solici-

tation, it is sent unicast back to the device that sent the Solicitation, unless that message

was sent from the unspecified address, in which case it is multicast to the “all nodes”

multicast address. If the Neighbor Advertisement message is sent unsolicited (for example,

by a device that wishes to inform others of a change in link-layer address), it is sent to the

“all nodes” multicast address.

ICMPv6 Redirect Messages

Because of the different roles of routers and hosts in an IPv6 internetwork, hosts don't need

to know very much about routes. They send datagrams intended for destinations on the

local network directly, while those for other networks they dump to their local routers and let

them “do the driving”, so to speak.

If a local network has only a single router, then it will send all such non-local traffic to that

router. If it has more than one local router, the host then must decide which router to use for

which traffic. In general terms, a host will not know the most efficient choice of router for

every type of datagram it may need to send. In fact, many nodes start out with a limited

routing table that says to send everything to a single default router, even if there are

several routers on the network.

When a router receives datagrams destined for certain networks, it may realize that it would

be more efficient if such traffic was sent by a host to a different router on the local network.

If so, it will invoke the Redirect function by sending an ICMPv6 Redirect message to the

device that sent the original datagram. This is the last of the functions that in IPv6 are

performed by the Neighbor Discovery protocol, and is explained in a topic on the Redirect

function in that section. Redirect messages are always sent unicast to the address of the

device that originally sent the datagram that led to the Redirect being created.

ICMPv6 Redirect Message Format

The format of ICMPv6 Redirect messages is shown in Table 114 and Figure 162.

Table 114: ICMPv6 Redirect Message Format (Page 1 of 2)

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMPv6 message type; for Redirect messages the

value is 137.

Code 1 Code: Not used; set to 0.

Note: As an aside, the Redirect message has always been somewhat of an

oddball. In ICMPv4, it is considered an error message, but this makes it different

from other error messages. For one thing, it's not really an error, since it doesn't

represent a failure to deliver, only an inefficiency in doing so. For this reason, in ICMPv6 it

was “moved” to the set of informational message types. Here too it doesn't really fit in with

the others, since it is sent in reaction to a regular IP message, and it also includes a copy of

(part of) the datagram that spawned it, like error messages do.

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

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

are not used to alter routes between routers, however.

Checksum 2

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

topic on the ICMP common message format.

Reserved 4 Reserved: 4 bytes sent as zeroes.

Target Address 16

Target Address: The address of the router that the router creating the

Redirect is telling the recipient of the Redirect to use as a first hop for

future transmissions to the destination. Phew. Example time: if router R2

generated a Redirect telling host A that in the future transmissions to host

B should be sent first to router R1, then R1's IPv6 address would be in this

field.

Destination

Address

Destination Address: The address of the device whose future transmis-

sions are being redirected; this is the destination of the datagram that

originally led to the Redirect being generated. Repeating the example

above: if router R2 generated a Redirect telling host A that in the future

transmissions to host B should be sent first to router R1, then host B's IPv6

address would be in this field.

Options Variable

Options: Redirect messages normally include two ICMPv6 option fields:

☯ Target Link-Layer Address: The layer-two address of the Target

Address, if known. This saves the recipient of the Redirect message

from needing to perform an address resolution on the target.

☯ Redirected Header: As much of the IPv6 datagram that spawned

this Redirect 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.

Table 114: ICMPv6 Redirect Message Format (Page 2 of 2)

Field Name

Size

(bytes)

Description

ICMPv6 Router Renumbering Messages

One of the more interesting decisions made in IPv6 was the selection of a very large 128-bit

address size. This provides an address space far larger than what humans are ever likely to

need—and probably larger than was needed for IPv6, strictly speaking. What this wealth of

bits provides is the flexibility to assign meaning to different bits in the address structure.

This in turn serves as the basis for important features such as the autoconfiguration and

automated renumbering of IPv6 addresses.

The renumbering feature in IPv6 is of particular interest to network administrators, since it

has the potential to make large network migrations and merges much simpler. In August

2000, the IETF published RFC 2894, Router Renumbering for IPv6

, which describes a

similar technique to allow routers in an autonomous system to be renumbered, by giving

them new prefixes (network identifiers).

Figure 162: ICMPv6 Redirect Message Format

Type = 135 Code = 0 Checksum

Reserved

Target Address

Destination Address

ICMPv6 Options

4 8 12 16 20 24 28 320

Router renumbering is actually a fairly simple process—especially if we avoid the gory

details, which is exactly what I intend to do. A network administrator uses a device on the

internetwork to generate one or more Router Renumbering Command messages. These

messages provide a list of prefixes of routers that are to be renumbered. Each router

processes these messages to see if the addresses on any of their interfaces match the

specified prefixes. If so, they change the matched prefixes to the new ones specified in the

message. Additional information is also included in the Router Renumbering Command as

appropriate to control how and when the renumbering is done.

If the Command message requests it, each router processing the message will respond

with a Router Renumbering Result message. This message serves as feedback to let the

originator of the Command know whether the renumbering was successful, and what

changes, if any, were made.

The router renumbering standard also defines a few important management features. Many

of these reflect the great power of something that can mass-renumber routers—and hence,

the potential for such power to be abused. It is possible to send commands in a “test mode”,

where they are processed but the renumbering not actually executed. Messages include a

sequence number to guard against replay attacks, and a special Sequence Number Reset

message can be used to reset the sequence number information routers have previously

stored. For added security, the standard specifies that messages be authenticated and

identity-checked.

ICMPv6 Router Renumbering Message Format

The format of Router Renumbering messages is in Table 115 and Figure 163.

Table 115: ICMPv6 Router Renumbering Message Format (Page 1 of 3)

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMPv6 message type; for Router Renumbering

messages the value is 138.

Code 1

Checksum 2

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

topic on the ICMP common message format.

Sequence

Number

Sequence Number: A 32-bit sequence number used to guard against

“replay” attacks by allowing a recipient to detect stale, duplicate or “out of

order” commands.

Code: Indicates the subtype of Router Renumbering message:

Value

(Decimal)

Message Subtype

0 Router Renumbering Command

1 Router Renumbering Result

255 Sequence Number Reset

Segment

Number

Segment Number: Differentiates between valid Router Renumbering

messages within the same Sequence Number.

Flags 1

Max Delay 2

Maximum Delay: Tells a router receiving a message the maximum amount

of time (in milliseconds) it is allowed to delay before sending a reply.

Table 115: ICMPv6 Router Renumbering Message Format (Page 2 of 3)

Field Name

Size

(bytes)

Description

ags:

ags use

o con

e renum

ng process.

our

ags

and S) control the operation of Command messages and in a Result message are

ust copied verbatim from the Command that led to the Result being created. The P

flag is only used in Result messages (0 in Command messages):

Subfield

Name

Size

(bytes)

Description

1/8

(1 bit)

Test Command Flag: When set to 1, flags this

Command as being a test message. This tells the

recipient to only “simulate” processing of the renumber

and not actually do it.

1/8

(1 bit)

Result Requested Flag: When set to 1, requests that

a Result message be sent after processing the

Command, when 0, says not to send one.

1/8

(1 bit)

All Interfaces Flag: When this flag is clear (0), the

Command is not applied to any router interfaces that

have been administratively shut down. When 1, it is

applied to all interfaces.

1/8

(1 bit)

Site-Specific Flag: This flag has meaning only when a

router treats its interfaces as belonging to different

sites. If so, a value of 1 tells it to apply the Command

only to interfaces on the same site as the interface for

which the Command was received. A value of 0 applies

it to all interfaces regardless of site.

1/8

(1 bit)

Processed Previously Flag: This flag is normally 0,

meaning the Command was not previously seen and

the Result message contains the report of processing

it. When 1, indicates that the recipient of the Command

believes it has seen it before and is not processing it.

(Test commands are not included in the assessment of

whether a Command has been seen before.)

Reserved

3/8

(3 bits)

Reserved: Three bits reserved for future flags.

Reserved 4 Reserved: 4 reserved bytes.

Message Body Variable

Message Body: For a Router Renumbering Command, the message body

contains two sets of information. The first is a Match-Prefix Part for the

prefix being renumbered. The second is one or more Use-Prefix Parts that

describe the new prefix for each match. A router receiving a Command

checks its own interface addresses and if they match the Match-Prefix-

Part, they use Use-Prefix Parts data to accomplish the renumbering.

For a Router Renumbering Result, the message body contains zero or

more Match Results entries that describe each prefix that a router matched

from a Router Renumbering Command. Each entry provides information

regarding whether renumbering was successful or not for a prefix.

Figure 163: ICMPv6 Router Renumbering Message Format

Table 115: ICMPv6 Router Renumbering Message Format (Page 3 of 3)

Field Name

Size

(bytes)

Description

Type = 138 Code Checksum

Sequence Number

Segment Number Flags Maximum Delay

4 8 12 16 20 24 28 320

240

Tes t

Com-

mand

Flag (T)

Res ult

Request-

ed Flag

(R)

All Inter-

faces

Flag

(A)

Site-

Specif ic

Flag

(S)

Proces-

sed Pre-

viously

Flag (P)

Reserved

Message Body

Reserved

Addressing of Router Renumbering Messages

Since these messages are intended for all routers on a site, they are normally sent to the

“all routers” multicast address, using either link-local or site-local scope. They may also be

sent to local unicast addresses.

ICMPv6 Informational Message Options

Each of the five ICMPv6 informational messages types defined and used by the Neighbor

Discovery (ND) protocol has an Options field into which one or more options may be

inserted. This probably isn't the best name for these sets of data, since they are only

optional in certain cases. In fact, in some cases the “option” is actually the entire point of the

message. For example, a Neighbor Advertisement message containing a link-layer address

for address resolution carries it in an “option”, but the message wouldn't be of much use

without it.

Each option has its own structure of subfields based on the classical “type, length and

value” triplet used in many message formats. The Type subfield indicates the option type

and the Length field indicates its length so the device processing the option can determine

where it ends. The “value” is not a single field, but rather one or more that contain the actual

information for which the option is being used.

Some options are used for only one kind of ICMPv6 message, while others are used for

more than one variety. So, they are best thought of as “modular components” used in

different types of messages as needed. I describe the format of each of these five options

below.

Source Link-Layer Address Option Format

This option carries the link-layer address of a device sending an ICMPv6 message, as

shown in Table 116 and Figure 164. Used in Router Advertisement, Router Solicitation and

Neighbor Solicitation messages:

Table 116: ICMPv6 Source Link-Layer Address Option Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMPv6 option type. For the Source Link-Layer

Address option, the value is 1.

Length 1

Length: The length of the entire option (including the Type and Length

fields), expressed in units of 8 octets (64 bits).

Source Link-

Layer Address

Variable

Source Link-Layer Address: The link-layer (layer two) address of the

device sending the ICMPv6 message.

Target Link-Layer Address Option Format

The counterpart of Source Link-Layer Address, this option carries the link-layer address

corresponding to the Target Address field in Neighbor Advertisement and Redirect

messages; see Table 117 and Figure 165.

Figure 164: ICMPv6 Source Link-Layer Address Option Format

Table 117: ICMPv6 Target Link-Layer Address Option Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMPv6 option type. For the Target Link-Layer

Address option, the value is 2.

Length 1

Length: The length of the entire option (including the Type and Length

fields), expressed in units of 8 octets (64 bits).

Target Link-

Layer Address

Variable

Target Link-Layer Address: The link-layer (layer two) address of the

target device.

Figure 165: ICMPv6 Target Link-Layer Address Option Format

Type = 1 Length

4 8 12 16 20 24 28 320

Source Link-Layer

Address

Type = 2 Length

4 8 12 16 20 24 28 320

Target Link-Layer

Address

Prefix Information Option Format

This option provides a prefix and related information in Router Advertisement messages.

This is the longest and most complex of the options, as you can see in Table 118 and Figure

166.

Table 118: ICMPv6 Prefix Information Option Format (Page 1 of 2)

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMPv6 option type. For the Prefix Information option,

the value is 3.

Length 1

Length: The length of the entire option (including the Type and Length

fields), expressed in units of 8 octets (64 bits). The Prefix Information

option is fixed in size at 32 bytes, so the value of the Length field is 4.

Prefix Length 1

Prefix Length: The number of bits in the Prefix field (below) that are

considered part of the network identifier (the remainder are used for the

host identifier and ignored). See this overview discussion of IPv6 address

notation for details on prefix lengths.

Flags 1

Valid Lifetime 4

Valid Lifetime: The amount of time, in seconds, that the recipient of the

message containing this option should consider the prefix valid for

purposes of on-link determination (see description of the “L” flag just

above). A value of all 1s means “infinity” (“forever”).

Preferred

Lifetime

Preferred Lifetime: When the recipient of this prefix uses it to automati-

cally generate addresses using address autoconfiguration, specifies the

amount of time, in seconds, that such addresses remain “preferred”

(meaning, valid and freely usable). A value of all 1s means “infinity”

(“forever”).

Flags: A pair of flags that convey information about the prefix:

Subfield

Name

Size

(bytes)

Description

1/8

(1 bit)

On-Link Flag: When set to 1, tells the recipient of the

option that this prefix can be used for on-link determi-

nation. This means the prefix can be used for deciding

whether or not an address is “on-link” (on the

recipient's local network). When 0, the sender is

making no statement regarding whether the prefix can

be used for this or not.

1/8

(1 bit)

Autonomous Address-Configuration Flag: When

set to 1, specifies that this prefix can be used for IPv6

address autoconfiguration.

Reserved

6/8

(6 bits)

Reserved: 6 “leftover” bits reserved and sent as

zeroes.

Reserved 4 Reserved: 4 unused bytes sent as zeroes.

Prefix 16

Prefix: The prefix being communicated from the router to the host in the

Router Advertisement message. The Prefix Length field indicates how

many of the 128 bits in this field are significant (part of the network ID).

Only these bits are placed in the Prefix field, the remaining bits are cleared

to zero.

Figure 166: ICMPv6 Prefix Information Option Format

Table 118: ICMPv6 Prefix Information Option Format (Page 2 of 2)

Field Name

Size

(bytes)

Description

Type = 3 Length Prefix Length Flags

Valid Lifetime

Preferred Lifetime

4 8 12 16 20 24 28 320

240

On-Link

Flag

(L)

Auto-

nomous

Address

Config

Flag (A)

Reserved

Prefix

Reserved