Charles M. Kozierok The TCP-IP Guide

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

This dependence means that before a host can really participate on an internetwork, it

needs to know the identity of at least one router on the local network. One way to ensure

that this is the case is to just manually configure each host with the address of a local router

as its default router. This method is simple, but has the typical drawbacks associated with

manual processes—it is time-consuming to set up, difficult to maintain, and inflexible.

The Router Discovery Process

It would be better if there were some method whereby a host could automatically discover

the identity of local routers, and learn important information about them. In IP, this process

is called router discovery, and was first defined in RFC 1256, ICMP Router Discovery

Messages. The messages referenced in the RFC title are the ICMP Router Advertisement

message and the Router Solicitation message, and were added to the ICMP message

types defined in earlier standards such as RFC 792.

Routers are responsible for sending Router Advertisement messages. These messages tell

listening devices that the router exists, and provide important information about the router

such as its address (or addresses, if it has more than one) and how long the host should

retain information about the router. Routine Router Advertisement messages are sent on a

regular basis, with the time between messages administrator-configurable (usually between

7 and 10 minutes). Hosts listen for these messages; when an advertisement is received,

the host processes it and adds the information about the router to its routing table.

A host that has no manually-configured routing information will have no knowledge of

routers when it first powers on. Having it sit for many minutes looking for a routine Router

Advertisement message is inefficient. Instead of waiting, the host may send a Router Solic-

itation message on its local network(s). This will prompt any router that hears it to

immediately send out an extra Router Advertisement message directly to that host.

ICMPv4 Router Advertisement Message Format

The ICMPv4 Router Advertisement message format is shown in Table 99 and Figure 148.

Table 99: ICMPv4 Router Advertisement Message Format (Page 1 of 2)

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMP message type. For Router Advertisement

messages the value is 9.

Code 1

Code: Normally set to 0. When a Mobile IP agent is sending a Router

Advertisement with an Agent Advertisement extension, it may set the value

to 16 if the device is a mobile agent only and doesn’t intend to handle

normal traffic. See the discussion of Mobile IP agent discovery for details.

Checksum 2

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

topic on the ICMP common message format.

Num Addrs 1

Number Of Addresses: The number of addresses associated with this

router that are included in this advertisement.

Addr Entry Size 1

Address Entry Size: The number of 32-bit words of information included

with each address. Since in this message format each router address has

a 32-bit address and a 32-bit preference level, this value is fixed at 2.

Lifetime 2

Lifetime: The number of seconds that a host should consider the infor-

mation in this message valid.

Router Address

Entries

Value of

Num

Addrs

field * 8

Figure 148: ICMPv4 Router Advertisement Message Format

Table 99: ICMPv4 Router Advertisement Message Format (Page 2 of 2)

Field Name

Size

(bytes)

Description

Add

ress

es:

num

er o

rou

er a

ress en

es equa

value of the Num Addrs field. Each is 8 bytes and has two subfields:

Subfield

Name

Size

(bytes)

Description

Router

Address

Router Address: A valid address for an interface

to the router sending this message.

Preference

Level

Preference Level: The preference level of this

address. When more than one address is included

in an advertisement, this field indicates which

address the router would prefer that hosts use.

Higher values mean greater preference.

Type = 9

Code = 0

(16 for MobileIP)

Checksum

Number of Addresses Address Entry Size Lifetime

Router Address #1

Preference Level #1

Router Address #2

Preference Level #2

Router Address #N

Preference Level #N

4 8 12 16 20 24 28 320

...

ICMPv4 Router Solicitation Message Format

ICMPv4 Router Solicitation messages are much simpler, because they only need to convey

a single piece of information: “if you are a router and can hear this, please send a Router

Advertisement to me”. The format is therefore just the trivial set of fields shown in Table 100

and Figure 149.

Addressing and Use of Router Advertisement and Router Solicitation Messages

If possible, both Router Advertisement and Router Solicitation messages are sent out

multicast for efficiency. Router Advertisements use the “all devices” multicast address

(224.0.0.1), since they are intended for hosts to hear, while Router Solicitation messages

use the “all routers” multicast address (224.0.0.2). If the local network does not supports

multicast, messages are instead sent out broadcast (to address 255.255.255.255).

It is important to remember that just like ICMP Redirect messages, Router Advertisement

messages are not a generalized method for exchanging routing information. They are a

support mechanism only, used to inform hosts about the existence of routers. Detailed infor-

mation about routes is communicated between routers using routing protocols, like RIP and

OSPF.

I should also mention that while I suggested router discovery was the alternative to manual

configuration of a host's default router, there are other alternatives as well. For example, a

host configuration protocol like DHCP can allow a host to learn the address of a default

router on the local network.

Table 100: ICMPv4 Router Solicitation Message Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMP message type. For Router Solicitation messages

the value is 10.

Code 1 Code: Not used; value 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.

Reserved 4 Reserved: 4 reserved bytes sent as 0.

Figure 149: ICMPv4 Router Solicitation Message Format

Type = 10 Code = 0 Checksum

Reserved

4 8 12 16 20 24 28 320

Finally, note that when Mobile IP is implemented, Router Advertisement messages are

used as the basis for Mobile-IP-aware routers to send Agent Advertisements. One or more

special extensions are added to the regular Router Advertisement format to create an

Agent Advertisement. This is discussed extensively in the topic on Mobile IP agent

discovery.

Key Concept: ICMP Router Advertisement messages are sent regularly by IP

routers to inform hosts of their presence and characteristics, so hosts know to use

them for delivery of datagrams to distant hosts. A host that is new to a network and

wants to find out immediately what routers are present may send a Router Solicitation,

which will prompt listening routers to send out Router Advertisements.

ICMPv4 Address Mask Request and Reply Messages

When the Internet Protocol was first developed, IP addresses were based on a simple two-

level structure, with a network identifier and host identifier. To provide more flexibility, a

technique called subnetting was soon developed that expands the addressing scheme into

a three-level structure, with each address containing a network identifier, subnet identifier

and host identifier. The subnet mask is a 32-bit number that tells devices (and users) which

bits are part of the subnet identifier, as opposed to the host identifier. All of this is described

in considerable detail in the section on IP addressing.

To function properly in a subnetting environment, each host must know the subnet mask

that corresponds to each address it is assigned—without the mask it cannot properly

interpret IP addresses. Just like determining the identity of a local router, a host can be

informed of the local network's subnet mask either manually or automatically. The manual

method is to simply to have the subnet mask manually assigned to each host. The

automatic method makes use of a pair of ICMP messages for subnet mask determination,

which were defined in RFC 950, the same standard that defined subnetting itself.

To use this method, a host sends an Address Mask Request message on the local network,

usually to get a response from a router. If it knows the address of a local router it may send

the request directly (unicast), but otherwise will broadcast it to any listening router. A local

router (or other device) will hopefully receive this message and respond back with an

Address Mask Reply containing the subnet mask for the local network. This process is

somewhat similar to the mechanism used by a host to solicit a router to respond with a

Router Advertisement, except that routers do not routinely send subnet mask information; it

must be requested.

ICMPv4 Address Mask Request and Address Mask Reply Message Format

The Address Mask Request and Address Mask Reply, like some other request/reply pairs,

have the same basic format—the host creates the request with all fields filled in except the

subnet mask value itself, and the router supplies the mask and sends the reply back to the

host. The format is described in Table 101 and Figure 150.

The Identifier and Sequence Number fields can be used to match up requests and replies,

as they are for Echo and Echo Reply messages. However, a host won't normally send

multiple requests for subnet masks the way it might send Echo messages for testing. For

this reason, the Identifier and Sequence Number fields may be ignored by some

implementations.

Table 101: ICMPv4 Address Mask Request and Address Mask Reply Message Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMP message type. For Address Mask Request

messages the value is 17; for Address Mask Reply messages, it is 18.

Code 1 Code: Not used for either 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.

Identifier 2

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

Address Mask Request and Address Mask Reply messages.

Sequence

Number

Sequence Number: A sequence number to help in matching Address

Mask Request and Address Mask Reply messages.

Address Mask 4

Address Mask: The subnet mask for the local network, filled in by the

router in the Address Mask Reply message.

Figure 150: ICMPv4 Address Mask Request and Address Mask Reply Message

Format

Type = 17 or 18 Code = 0 Checksum

Identifier Sequence Number

Address Mask

4 8 12 16 20 24 28 320

Use of Address Mask Request and Address Mask Reply Messages

The use of Address Mask Request and Address Mask Reply messages is optional, just as

the router discovery described in the previous topic is. Other methods besides these

messages or manual configuration may be used to tell a host what subnet mask to use.

Again, a common alternative to ICMP for this is a host configuration protocol like the TCP/IP

Dynamic Host Configuration Protocol (DHCP). Routers do have to be able to respond to

Address Mask Requests for hosts that choose to send them.

ICMPv4 Traceroute Messages

The Echo and Echo Reply messages we explored earlier in this section are used for the

most basic type of test that can be conducted between two devices: checking if they can

communicate. A more sophisticated test can also be performed, to see not just if the

devices are able to talk, but discover the exact sequence of routers used to move

datagrams between them. In TCP/IP this diagnostic is performed using the traceroute (or

tracert) utility.

The first implementation of traceroute used a clever application of Time Exceeded error

messages. By sending a test message to a destination first with a Time To Live value of 1,

then 2, then 3 and so on, each router in the path between the source and destination would

successively discard the test messages and send back a Time Exceeded message,

displaying the sequence of routers between the two hosts. This bit of “trickery” works well

enough in general terms, but is suboptimal in a couple of respects. For example, it requires

the source device to send one test message for each router in the path, instead of just a

single test message. It also doesn't take into account the possibility that the path between

two devices may change during the test.

Recognizing these limitations, a new experimental standard was developed in 1993 that

defined a more efficient way to conduct a traceroute: RFC 1393, Traceroute Using an IP

Option. As the title suggests, this method of doing a traceroute works by having the source

device send a single datagram to the destination, containing a special Traceroute IP option.

Each router that sees that option as the test message is conducted along the route,

responds back to the original source with an ICMP Traceroute message, also defined in

RFC 1393.

ICMPv4 Traceroute Message Format

Since the Traceroute message was specifically designed for the traceroute utility, it was

possible to incorporate into it extra information of use to a host tracing a route. The

message format is as shown in Table 102 and Figure 151.

Table 102: ICMPv4 Traceroute Message Format

Field Name

Size

(bytes)

Description

Type 1 Type: Identifies the ICMP message type, in this case 30.

Code 1

Code: Set to the value 0 if the datagram the source device sent was

successfully sent to the next router, or 1 to indicate that the datagram was

dropped (meaning the traceroute failed).

Checksum 2

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

topic on the ICMP common message format.

ID Number 2

ID Number: An identification field used to match up this Traceroute

message to the original message sent by the source (the one containing

the Traceroute IP option).

Unused 2 Unused: Not used, set to 0.

Outbound Hop

Count

Outbound Hop Count: The number of routers the original message has

already passed through.

Return Hop

Count

Return Hop Count: The number of routers the return message has

passed through.

Output Link

Speed

Output Link Speed: The speed of the link over which the Traceroute

message is being sent, in bytes per second.

Output Link MTU 4

Output Link MTU: The Maximum Transmission Unit (MTU) of the link over

which the Traceroute message is being sent, in bytes.

Figure 151: ICMPv4 Traceroute Message Format

Type = 30 Code = 0 or 1 Checksum

ID Number Unused

Outbound Hop Count Return Hop Count

Output Link Speed

Output Link MTU

4 8 12 16 20 24 28 320

Why Traceroute Messages Are Not Widely Used

Note that while this method of implementing traceroute indeed has advantages over the

older Time Exceeded method, it has one critical flaw as well: it requires changes to both

hosts and routers to support the new IP option and the Traceroute ICMP message. People

aren't big on change, especially when it comes to the basic operation of IP. For this reason,

RFC 1393 never moved beyond “experimental” status, and most IP devices still use the

older method of implementing traceroute. It is possible that you may encounter ICMP

Traceroute messages, however, so it's good to know they exist.

Key Concept: ICMP Traceroute messages were designed to provide a more

capable way of implementing the traceroute (tracert) utility. However, most TCP/IP

implementations still use ICMP Time Exceeded messages for this task.

ICMP Version 6 (ICMPv6) Error Message Types and Formats

The original ICMP defines for version 4 of the Internet Protocol (IPv4) a number of error

messages to allow communication of problems on an internetwork. When IP version 6

(IPv6) was developed, the differences between IPv4 and IPv6 were significant enough that

a new version of ICMP was also required: the Internet Control Message Protocol (ICMPv6)

for the Internet Protocol Version 6 (IPv6), currently specified in RFC 2463. Like ICMPv4,

ICMPv6 defines several error messages that let a source be informed when something

goes wrong.

In this section I describe the four ICMPv6 error messages defined in RFC 2463. I first

discuss ICMPv6 Destination Unreachable messages, used to tell a device a datagram it

sent could not be delivered for a variety of reasons. I describe Packet Too Big error

messages, which are sent when a datagram can't be sent due to being too large for an

underlying network it needs to traverse. I explain the use of Time Exceeded messages,

which indicate that too much time was taken to accomplish a transmission. I conclude with

a look at messages, which provide a generalized way of reporting errors not described by

any of the preceding ICMPv6 error message types.

Note: Three of the four ICMPv6 error messages (all except Packet Too Big) are

equivalent to the ICMPv4 error messages that have the same names. However, to

allow this section to stand on its own, I describe each one fully, in addition to

pointing out any significant differences between the ICMPv4 and ICMPv6 version of the

message.

ICMPv6 Destination Unreachable Messages

Version 6 of the Internet Protocol (IPv6) includes some important enhancements over the

older version 4, but the basic operation of the two protocols is still fundamentally the same.

Like IPv4, IPv6 is an unreliable network protocol that makes a “best effort” to deliver

datagrams, but offers no guarantees that they will always get there. Just as was the case in

IPv4, devices on an IPv6 network must not assume that datagrams sent to a destination will

always be received.

When a datagram cannot be delivered, recovery from this condition normally falls to higher-

layer protocols like TCP, which will detect the miscommunication and re-send the lost

datagrams. In some situations, such as a datagram dropped due to congestion of a router,

this is sufficient, but in other cases a datagram may not be delivered due to an inherent

problem with how it is being sent. For example, the source may have specified an invalid

destination address, which means even if resent many times, the datagram will never get to

its intended recipient.

In general, having the source just re-send undelivered datagrams while having no idea why

they were lost is inefficient. It is better to have a feedback mechanism that can tell a source

device about undeliverable datagrams and provide some information about why the

datagram delivery failed. As in ICMPv4, in ICMPv6 this is done with Destination

Unreachable messages. Each message includes a code that indicates the basic nature of

the problem that caused the datagram not to be delivered, and includes all or part of the

datagram that was undelivered, to help the source device diagnose the problem.

ICMPv6 Destination Unreachable Message Format

Table 103 and Figure 152 illustrate the specific format for ICMPv6 Destination Unreachable

messages:

ICMPv6 Destination Unreachable Message Subtypes

There are a number of different reasons why a destination may be unreachable. To provide

additional information about the nature of the problem to the device that originally tried to

send the datagram, a value is placed in the message's Code field. One interesting

difference between ICMPv4 and ICMPv6 Destination Unreachable messages is that there

Table 103: ICMPv6 Destination Unreachable Message Format

Field Name

Size

(bytes)

Description

Type 1

Type: Identifies the ICMPv6 message type; for Destination Unreachable

messages this is set to 1.

Code 1

Code: Identifies the “subtype” of unreachable error being communicated.

See Table 104 for a full list of codes and what they mean.

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 that are 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 152: ICMPv6 Destination Unreachable Message Format

Type = 1

Code

(Error Subtype)

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