IPv6 Essentials, 2nd Edition

General Message Format

There are two classes of ICMP messages:

ICMP error messages: Error messages have a 0 in the high-order bit of their message Type field. ICMP error message types are, therefore, in the range from 0 to 127.
ICMP informational messages: Informational messages have a 1 in the high-order bit of their message Type field. ICMP informational message types are, therefore, in the range from 128 to 255.

An IPv6 header and zero or more Extension headers precede every ICMPv6 message. The header just preceding the ICMP header has a next header value of 58. This value is different from the value for ICMPv4 (which has the value 1).

Tip

The values for the Next Header field are discussed in Chapter 2.

The following message types are described in RFC 4443:

ICMPv6 error messages
- Destination Unreachable (message type 1)
- Packet Too Big (message type 2)
- Time Exceeded (message type 3)
- Parameter Problem (message type 4)
ICMPv6 informational messages
- Echo Request (message type 128)
- Echo Reply (message type 129)

Tip

For the most current list of ICMPv6 message types, refer to the Internet Assigned Number Authority (IANA) at http://www.iana.org/assignments/icmpv6-parameters. All IPv4 ICMP parameters can be found at http://www.iana.org/assignments/icmp-parameters.

All ICMPv6 messages have the same general header structure, as shown in Figure 4-1. Notice that the first three fields for type, code, and checksum have not changed from ICMPv4.

Figure 4-1. General ICMPv6 header format

Type (1 Byte)

This field specifies the type of message, which determines the format of the remainder of the message. Tables 4-1 and 4-2 list ICMPv6 message types and numbers.

Code (1 Byte)

The Code field depends on the message type and allows for more granular information in certain cases. Refer to Tables 4-1 and 4-2 for a detailed list.

Checksum (2 Bytes)

The Checksum field is used to detect data corruption in the ICMPv6 header and in parts of the IPv6 header. In order to calculate the checksum, a node must determine the Source and Destination address in the IPv6 header. If the node has more than one unicast address, there are rules for choosing the address (refer to RFC 4443 for details). There is also a pseudoheader included in the checksum calculation, which is new with ICMPv6.

Message Body (Variable Size)

Depending on the type and code, the message body will hold different data. In the case of an error message, it will contain as much as possible of the packet that invoked the message to assist in troubleshooting. The total size of the ICMPv6 packet should not exceed the minimum IPv6 MTU, which is 1,280 bytes. Tables 4-1 and 4-2 provide an overview of the different message types, along with the additional code information, which depends on the message type.

Table 4-1. ICMPv6 error messages and code type

Message number	Message type	Code field
1	Destination Unreachable	`0` = no route to destination `1` = communication with destination administratively prohibited `2` = beyond scope of Source address `3` = address unreachable `4` = port unreachable `5` = Source address failed ingress/egress policy `6` = reject route to destination
2	Packet Too Big	Code field set to `0` by the sender and ignored by the receiver
3	Time Exceeded	`0` = hop limit exceeded in transit `1` = fragment reassembly time exceeded
4	Parameter Problem	`0` = erroneous header field encountered `1` = unrecognized next header type encountered `2` = unrecognized IPv6 option encountered The pointer field identifies the octet offset within the invoking packet where the error was detected. The pointer points beyond the end of the ICMPv6 packet if the field in error is beyond what can fit in the maximum size of an ICMPv6 error message.
100 and 101	Private experimentation	RFC 4443
127	Reserved for expansion of ICMPv6 error messages	RFC 4443

Note that the message numbers and types have substantially changed compared to ICMPv4. ICMP for IPv6 is a different protocol, and the two versions of ICMP are not compatible. Your analyzer should properly decode all this information, so you do not have to worry about memorizing it.

Table 4-2. ICMPv6 informational messages

Message number	Message type	Description
128	Echo Request	RFC 4443. Used for the ping command.
129	Echo Reply
130	Multicast Listener Query	RFC 2710. Used for multicast goup management.
131	Multicast Listener Report
132	Multicast Listener Done
133	Router Solicitation	RFC 2461. Used for neighbor discovery and autoconfiguration.
134	Router Advertisement
135	Neighbor Solicitation
136	Neighbor Advertisement
137	Redirect Message
138	Router Renumbering	RFC 2894 Codes: `0` = Router renumbering command `1` = Router renumbering result `255` = Sequence number reset
139	ICMP Node Information Query	draft-ietf-ipngwg-icmp-name-lookups-15.txt
140	ICMP Node Information Response
141	Inverse ND Solicitation	RFC 3122
142	Inverse ND Adv Message	RFC 3122
143	Version 2 Multicast Listener Report	RFC 3810
144	ICMP Home Agent Address Discovery Request Message	RFC 3775 ICMPv6 Messages for Mobile IPv6
145	ICMP Home Agent Address Discovery Reply Message
146	ICMP Mobile Prefix Solicitation Message
147	ICMP Mobile Prefix Advertisement Message
148	Certification Path Solicitation Message	RFC 3971 ICMPv6 Messages for SEcure Neighbor Discovery
149	Certification Path Advertisement Message
151	Multicast Router Advertisement	RFC 4286
152	Multicast Router Solicitation
153	Multicast Router Termination
200 201	Private experimentation	RFC 4443
255	Reserved for expansion of ICMPv6 informational messages	RFC 4443

With the exception of the router renumbering message (138), the ICMPv6 informational messages do not use the Code field. It is, therefore, set to zero.

ICMP Error Messages

Every ICMP message can have a slightly different header depending on the kind of error report or information it carries. The following sections outline the structure of each type of ICMPv6 message.

Destination Unreachable

A Destination Unreachable message is generated if an IP datagram cannot be delivered. A Type field with the value 1 identifies this message. The ICMP message is sent to the Source address of the invoking packet. The format of the Destination Unreachable message is shown in Figure 4-2.

Figure 4-2. Format of the Destination Unreachable message

The Type field is set to 1, which is the value for the Destination Unreachable message. The Code field supplies more information about the reason why the datagram was not delivered. The possible codes are listed in Table 4-3. The data portion of the ICMP message contains as much of the original message as will fit into the ICMP message.

Table 4-3. Code values of the Destination Unreachable message (type 1)

Code	Description
0	“No route to destination.” This code is used if a router cannot forward a packet because it does not have a route in its table for a destination network. This can happen only if the router does not have an entry for a default route.
1	“Communication with destination administratively prohibited.” This type of message can, for example, be sent by a firewall that cannot forward a packet to a host inside the firewall because of a packet filter. It might also be sent if a node is configured not to accept unauthenticated Echo Requests.
2	“Beyond scope of Source address.” This code is used if the Destination address is beyond the scope of the Source address, e.g., if a packet has a link-local Source address and a global Destination address.
3	“Address unreachable.” This code is used if a Destination address cannot be resolved into a corresponding network address or if there is a data-link layer problem preventing the node from reaching the destination network.
4	“Port unreachable.” This code is used if the transport protocol (e.g., UDP) has no listener and there is no other means to inform the sender. For example, if a Domain Name System (DNS) query is sent to a host and the DNS server is not running, this type of message is generated.
5	“Source address failed ingress/egress policy.” This code is used if a packet with this Source address is not allowed due to ingress or egress filtering policies.
6	“Reject route to destination.” This code is used if the route to the destination is a reject route.

If the destination is unreachable due to congestion, no ICMP message is generated. A host that receives a Destination Unreachable message must inform the upper-layer process.

Packet Too Big

If a router cannot forward a packet because it is larger than the MTU of the outgoing link, it will generate a Packet Too Big message (shown in Figure 4-3). This ICMPv6 message type is used as part of the Path MTU discovery process that I discuss later in this chapter. The ICMP message is sent to the Source address of the invoking packet.

Figure 4-3. Format of the Packet Too Big message

The Type field has the value 2, which identifies the Packet Too Big message. In this case, the Code field is not used and is set to 0. The important information for this type of message is the MTU field, which contains the MTU size of the next hop link.

RFC 4443 states that an ICMPv6 message should not be generated as a response to a packet with an IPv6 multicast Destination address, a link-layer multicast address, or a link-layer broadcast address. The Packet Too Big message is an exception to this rule. Because the ICMP message contains the supported MTU of the next hop link, the source host can determine the MTU that it should use for further communication. A host that receives a Packet Too Big message must inform the upper-layer process.

Time Exceeded

When a router forwards a packet, it always decrements the hop limit by one. The hop limit makes sure that a packet does not endlessly travel through a network. If a router receives a packet with a hop limit of 1 and decrements the limit to 0, it discards the packet, generates a Time Exceeded message with a code value of 0, and sends this message back to the source host. This error can indicate a routing loop or the fact that the sender’s initial hop limit is too low. It can also tell you that someone used the traceroute utility, which is described later in this chapter. Figure 4-4 shows the format of the Time Exceeded message.

Figure 4-4. Format of the Time Exceeded message

The Type field carries the value 3, specifying the Time Exceeded message. The Code field can be set to 0, which means the hop limit was exceeded in transit, or to 1, which means that the fragment reassembly time is exceeded. The data portion of the ICMP message contains as much of the original message as will fit into the ICMP message, depending on the MTU used.

An incoming Time Exceeded message must be passed to the upper-layer process. Table 4-4 shows the Code fields for the Time Exceeded message.

Table 4-4. Code values for Time Exceeded message (type 3)

Code	Description
0	“Hop limit exceeded in transit.” Possible causes: the initial hop limit value is too low; there are routing loops; or use of the traceroute utility.
1	“Fragment reassembly time exceeded.” If a fragmented packet is sent by using a fragment header (refer to Chapter 2 for more details) and the receiving host cannot reassemble all packets within a certain time, it notifies the sender by issuing this ICMP message.

Code

Description

0

“Hop limit exceeded in transit.”

Possible causes: the initial hop limit value is too low; there are routing loops; or use of the traceroute utility.

1

“Fragment reassembly time exceeded.”

If a fragmented packet is sent by using a fragment header (refer to Chapter 2 for more details) and the receiving host cannot reassemble all packets within a certain time, it notifies the sender by issuing this ICMP message.

The “Hop limit exceeded in transit” message type is commonly used to do the traceroute function. Traceroute is helpful in determining the path that a packet takes when traveling through the network. In order to do this, a first packet is sent out with a hop limit of 1. The first router in the path decrements the hop limit to 0, discards the packet, and sends back an ICMP message type 3, code 0. The source host now knows the address of the first hop router. Next, it sends out a second packet with a hop limit of 2. This packet is forwarded by the first router, which decrements the hop limit to 1. The second router in the path decrements the hop limit to 0, discards the packet, and sends back an ICMP message type 3, code 0. Now the source knows about the second router in the path. Raising the hop limit by one (with every packet sent until the packet reaches the final destination) continues this process. Every router in the path to the final destination sends an ICMP message back to the source host, thereby providing its IP address. It is important to know that if there are redundant paths to the destination, traceroute does not necessarily show the same route for all tests because it might choose different paths.

Parameter Problem

If an IPv6 node cannot complete the processing of a packet because it has a problem identifying a field in the IPv6 header or in an Extension header, it must discard the packet, and it should send an ICMP Parameter Problem message back to the source of the problem packet. This type of message is often used when an error that does not fit into any of the other categories is encountered. The format of this ICMP message is shown in Figure 4-5.

Figure 4-5. Format of the Parameter Problem message

The Type field has the value 4, which specifies the Parameter Problem message. The Code field can contain any of the three values described in Table 4-5. The Pointer field identifies at which byte in the original packet the error was detected. The ICMP message includes as much of the original data as fits, up to the minimum IPv6 MTU. It is possible that the pointer points beyond the ICMPv6 message. This would be the case if the field in error was beyond what can fit in the maximum size of an ICMPv6 error message.

Table 4-5 shows the Code fields for the Parameter Problem message.

Table 4-5. Code values for Parameter Problem (type 4)

Code	Description
0	Erroneous header field encountered
1	Unrecognized next header type encountered
2	Unrecognized IPv6 option encountered

For example, an ICMPv6 message of type 4 with a code value of 1 and a pointer set to 40 indicates that the next header type in the header following the IPv6 header was unrecognized.

An incoming Parameter Problem message must be passed to the upper-layer process.

ICMP Informational Messages

In RFC 4443, two types of informational messages are defined: the Echo Request and the Echo Reply messages. Other ICMP informational messages are used for Path MTU Discovery and Neighbor Discovery. These messages are discussed at the end of this chapter and defined in RFC 2461, “Neighbor Discovery for IP Version 6,” and RFC 1981, "Path MTU Discovery for IP Version 6.”

The Echo Request and Echo Reply messages are used for one of the most common TCP/IP utilities: Packet INternet Groper (ping). Ping is used to determine whether a specified host is available on the network and ready to communicate. The source host issues an Echo Request message to the specified destination. The destination host, if available, responds with an Echo Reply message. Figures 4-8 and 4-9 (later in the chapter) show what a ping looks like in the trace file.

Echo Request Message

The format of the Echo Request message is shown in Figure 4-6.

Figure 4-6. Format of the Echo Request message

The Type Field is set to 128, the value for the Echo Request. The Code Field is not used for this message and is therefore set to 0. The Identifier and Sequence Number fields are used to match requests with replies. The reply must always contain the same numbers as the request. Whether an identifier and a sequence number are used and what kind of arbitrary data is included in the Echo Request depends on the TCP/IP stack you are using. When you analyze trace files with Echo Request and Echo Reply messages and you are familiar with some stacks, you can determine the TCP/IP stack of the sender by looking at the arbitrary data. You can see an example of this in Figures 4-8 and 4-9, later in this chapter.

Echo Reply

The format of the Echo Reply message is very similar to that of the Echo Request, as shown in Figure 4-7.

Figure 4-7. Format of the Echo Reply message

The Type field contains the value 129 for Echo Reply. The Code field is unused and set to 0. The Identifier and Sequence Number fields must match the fields in the request. The data of the Echo Request message must be copied into the reply entirely and unmodified. If an upper-layer process initiated the Echo Request, the reply must be passed to that process. If the Echo Request message was sent to a unicast address, the Source address of the Echo Reply message must be the same as the Destination address of the Echo Request message. If the Echo Request was sent to an IPv6 multicast address, the Source address of the Echo Reply must be a unicast address of the interface on which the multicast Echo Request was received.

ICMPv6 Echo Request and Reply messages can be authenticated, using an IPv6 authentication header. This means that a node can be configured to ignore nonauthenticated ICMPv6 pings and provide protection against different ICMPv6 attacks.

Processing Rules

There are several rules that govern processing of ICMP packets. They can be found in RFC 4443 and are summarized as follows:

If a node receives an ICMPv6 error message of unknown type, it must pass it to the upper layer.
If a node receives an ICMPv6 informational message of unknown type, it must be silently discarded.
As much as possible of the packet that caused the ICMP error message will be included in the ICMP message body. The ICMP packet should not exceed the minimum IPv6 MTU.
If the error message has to be passed to the upper-layer protocol, the protocol type is determined by extracting it from the original packet (present in the body of the ICMPv6 error message). In case the protocol type cannot be found in the body of the ICMPv6 message (because there were too many extension headers present in the original packet, and the part of the header that contained the upper-layer protocol type was truncated), the ICMPv6 message is silently discarded.

An ICMPv6 error message must not be sent in the following cases:

As a result of an ICMPv6 error message.
As a result of an ICMPv6 redirect message.
As a result of a packet sent to an IPv6 multicast address. There are two exceptions to this rule: the Packet Too Big message that is used for Path MTU discovery, and the Parameter Problem with the code value 2 for an unrecognized IPv6 option.
As a result of a packet sent as a link-layer multicast (exceptions just described apply).
As a result of a packet sent as a link-layer broadcast (exceptions just described apply).
As a result of a packet whose Source address does not uniquely identify a single node. This could be an IPv6 unspecified address, an IPv6 multicast address, or an IPv6 address known to be an anycast address.

Every IPv6 node must implement a rate-limiting function that limits the rate of ICMPv6 messages it sends, and it should be configurable. If this function is implemented properly, it protects against Denial of Service attacks.

The ICMPv6 Header in a Trace File

After reading through all that dry information, you deserve something different. The following screenshot (Figure 4-8) shows what a ping looks like in the trace file and provides details of many of the fields discussed so far.

Figure 4-8. Echo Request in a trace file

The two frames in this trace file were captured when my Windows host issued a ping command to a Linux host. Note that the Source address of the second frame, the Echo Reply, is the same as the Destination address in the first frame, the Echo Request. The IPv6 header provides more information. The Version field indicates that this is an IPv6 packet. The Next Header field has the value 58, which is the value for ICMPv6. We can also see source and destination IP address. The prefix fe80: indicates that these two addresses are link-local addresses.

Note the first three fields of the ICMPv6 header. They are the fields that are common for every ICMPv6 message: the Type, Code, and Checksum fields. The Type field contains the value 128, which is the value for an Echo Request. The Identifier and Sequence Number fields are unique to the Echo Request and Echo Reply message. The Identifier is not used in this case, and the sender has set the sequence to 38. It has to be identical in the matching reply shown in the following screenshot. The Data field contains arbitrary data that doesn’t need to make sense to anyone.

Oh, I almost forgot that earlier I had promised to show vendor stack-related data in the Echo Request message. What you see here—the alphabet up to the letter “w”—is what Microsoft uses. Whenever you see this in a trace file, a Microsoft stack is sending the request. Figure 4-9 shows the Echo Reply in detail.

Figure 4-9. Echo Reply in a trace file

Again, the IPv6 header shows a value of 6 for the IP version and a Next Header value of 58 for ICMPv6. The Destination address of the previous frame is now the Source address, and the previous Source address is now the Destination address. The Type field in the ICMPv6 header shows a value of 129, which is the value for an Echo Reply. The Identifier and Sequence Number fields, as well as the Data field, match the ones in the Echo Request.

Neighbor Discovery (ND)

Neighbor Discovery (ND) is specified in RFC 2461. The specifications in this RFC relate to different protocols and processes known from IPv4 that have been modified and improved. New functionality has also been added. It combines Address Resolution Protocol (ARP) and ICMP Router Discovery and Redirect. With IPv4, we have no means to detect whether a neighbor is reachable. With the Neighbor Discovery protocol, a Neighbor Unreachability Detection (NUD) mechanism has been defined. Duplicate IP address detection (DAD) has also been implemented. IPv6 nodes use Neighbor Discovery for the following purposes:

For autoconfiguration of IPv6 addresses
To determine network prefixes, routes and other configuration information
For Duplicate IP address detection (DAD)
To determine layer two addresses of nodes on the same link
To find neighboring routers that can forward their packets
To keep track of which neighbors are reachable and which are not (NUD)
To detect changed link-layer addresses

The following improvements over the IPv4 set of protocols can be noted:

Router Discovery is now part of the base protocol set. With IPv4, the mechanism needs to get the information from the routing table.
Router Advertisement packets contain link-layer addresses for the router. There is no need for the node receiving a Router Advertisement to send out an additional ARP request (as an IPv4 node would have to do) to get the link-layer address for the router interface. The same is true for ICMPv6 Redirect messages; they contain the link-layer address of the new next-hop router interface.
Router Advertisement packets contain the prefix for a link (subnet information). There is no longer a need to configure subnet masks; they can be learned from the Router Advertisement.
Neighbor Discovery (ND) provides mechanisms to renumber networks more easily. New prefixes and addresses can be introduced while the old ones are still in use, and the old ones can be deprecated and removed gradually.
Router Advertisements enable stateless address autoconfiguration and can tell hosts when to use stateful address configuration (e.g., DHCP).
Routers can advertise an MTU to be used on a link.
Multiple prefixes can be assigned to one link. By default, hosts learn all prefixes from the router, but the router can be configured not to advertise some or all of the prefixes. In that case, hosts assume that a non-advertised prefix destination is remote and send the packets to the router. The router can then issue ICMP Redirect messages as needed.
Neighbor Unreachability Detection is part of the base protocol. It substantially improves packet delivery in case of failed routers or link interfaces that changed their link-layer address. It solves the issues with outdated ARP caches. ND detects failed connectivity, and traffic is not sent to unreachable neighbors. The Neighbor Unreachability Detection also detects failed routers and switches to live ones.
Router Advertisements and ICMP redirects use link-local addresses to identify routers. This allows hosts to maintain their router associations even in the case of renumbering or use of new global prefixes.
Neighbor Discovery messages have a hop limit value of 255, and requests with a lower hop limit are not answered. This makes Neighbor Discovery immune to remote hosts that try to sneak into your link, because their packets have a decremented hop limit and are thus ignored.
Standard IP authentication and security mechanisms can be applied to neighbor discovery.

This summary gives an idea of what can be expected from this part of the specification. Now let’s discuss the different processes in detail. The Neighbor Discovery protocol consists of five ICMP messages: a pair of Router Solicitation/Router Advertisement messages, a pair of Neighbor Solicitation/Neighbor Advertisement messages, and an ICMP Redirect message (refer to Table 4-2 earlier in this chapter for a summary of ICMP informational message types).

To summarize, the Neighbor Discovery Protocol (NDP) specification is used by both hosts and routers. Its functions include Neighbor Discovery (ND), Router Discovery (RD), Address Autoconfiguration, Address Resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Redirection.

Router Solicitation and Router Advertisement

Routers send out Router Advertisement messages at regular intervals. Hosts can request Router Advertisements by issuing a Router Solicitation message. This will trigger routers to issue Router Advertisements immediately, outside of the regular interval. The format is shown in Figure 4-10.

Figure 4-10. Router Solicitation message

In the IP header of a Router Solicitation message, you will usually see the all-routers multicast address of FF02::2 as a Destination address. The hop limit is set to 255. The ICMP Type field is set to 133, which is the value for the Router Solicitation message. The Code field is unused and set to 0. The following two bytes are used for the Checksum. The next four bytes are unused and reserved for future use. The sender sets them to 0, and the receiver ignores those fields. For a Router Solicitation message, a valid option is the link-layer address of the sending host, if the address of the sending host is known. If the Source address on the IP layer is the unspecified (all-zeros) address, this field is not used. More options may be defined in future versions of ND. If a host cannot recognize an option, it should ignore the option and process the packet.

Routers that receive this Solicitation message reply with a Router Advertisement message. Routers also issue those messages periodically. The format of the Router Advertisement message is shown in Figure 4-11.

Figure 4-11. Router Advertisement message

By inspecting the IP header of the Router Advertisement message, you can determine whether this Router Advertisement is periodic or was sent in reply to a Solicitation message. A periodic advertisement’s Destination address will be the all-nodes multicast address FF02::1. A solicited advertisement’s Destination address will be the address of the interface that originated the solicitation message. Again, the hop limit is set to 255.

The ICMP Type field is set to 134, the value for a Router Advertisement message; the Code field is unused and set to 0. The Current Hop Limit field can be used to configure all nodes on a link for a default hop limit. The value entered in this field will be used as a default hop limit value in outgoing packets by all nodes on the link. A value of 0 in this field means that this option is unspecified by this router—in which case the default hop limit values of the source hosts are used.

The next 1-bit field, the M flag, specifies whether Stateful configuration is to be used. Stateful configuration refers to what we know as DHCP with IPv4. If this bit is 0, the nodes on this link use Stateless autoconfiguration. If the bit is set to 1, it specifies Stateful autoconfiguration. The O-flag configures whether nodes on this link use Stateful configuration other than IP address information. A value of 1 means the nodes on this link use Stateful configuration for non-address-related information. The Mobile IPv6 specification (RFC 3775) defines the third bit, the home address flag (H-flag). When a router sets the H-flag to 1, it means that it is a home agent for this link. For a discussion of Mobile IPv6, refer to Chapter 11. The remaining five bits of this byte are reserved for future use and must be 0.

The Router Lifetime field is important only if this router is to be used as a default router by the nodes on the link. A value of 0 indicates that this router is not a default router and will therefore not appear on the default router list of receiving nodes. Any other value in this field specifies the lifetime, in seconds, associated with this router as a default router. The maximum value is 18.2 hours.

There is an optional extension to the Router Advertisement message, which allows routers to advertise preferences and more specific routes. This makes it possible for hosts to choose the best router in situations where they receive more than one router advertisement. It is also important for multihomed routers, which will be an increasingly important scenario in the IPv6 network. This extension uses the two bits after the H-flag in the router advertisement as a Preference flag and defines a Route Information option. It is specified in RFC 4191.

The Reachable Time field indicates the time in which a host assumes that neighbors are reachable after having received a reachability confirmation. A value of 0 means that it is unspecified. The Neighbor Unreachability Detection algorithm uses this field.

The Retrans Timer field is used by the address resolution and Neighbor Unreachability Detection mechanisms; it states the time in milliseconds between retransmitted Neighbor Solicitation messages. A value of 0 indicates that this router is not configured with a retransmission timer.

For the Options field, there are currently three possible values:

Source link-layer address.
MTU size to be used on links with variable MTU sizes (Token Ring, for example).
Prefix information, important for Stateless autoconfiguration. The router inserts all its prefixes for the link that the nodes on the link need to know.

More options may be defined in future versions of ND. A trace file later in this chapter shows what the options look like.

Neighbor Solicitation and Neighbor Advertisement

This pair of messages fulfills two functions: the link-layer address resolution that is handled by ARP in IPv4, and the Neighbor Unreachability Detection mechanism. If the Destination address is a multicast address (usually the solicited node multicast address), the source is resolving a link-layer address. If the source is verifying the reachability of a neighbor, the Destination address is a unicast address. This message type is also used for Duplicate IP Address Detection (DAD).

The format of the Neighbor Solicitation message is shown in Figure 4-12.

Figure 4-12. Format of the Neighbor Solicitation message

In the IP header of this message type, the Source address can be either the interface address of the originating host or, in the case of Stateless autoconfiguration and DAD, the unspecified (all-zeros) address. The hop limit is set to 255. The Type field in the ICMP header is set to 135, and the Code field is unused and set to 0. After the two checksum bytes, four unused bytes are reserved and must be set to 0. The target address is used in Neighbor Advertisement and Redirect messages. It must not be a multicast address.

The Options field can contain the link-layer Source address, but only if it is not sent from the all-zeros address. During Stateless autoconfiguration, in a message that uses the unspecified address as a Source address, the Options field is set to 0. The link-layer option must be used in multicast solicitations (link layer address detection) and can be used in unicast solicitations (Unreachability Detection).

Neighbor Advertisement messages are sent as a reply to Neighbor Solicitation messages or to propagate new information quickly. The format of the message is shown in Figure 4-13.

Figure 4-13. Format of the Neighbor Advertisement message

The type of address in the IP header indicates whether the message is the answer to a solicitation or an unsolicited message. In the case of a solicited advertisement, the destination IP address is the Source address of the interface that sent the solicitation. If the message is the reply to a DAD message that originated from an unspecified Source address, the reply will go to the all-nodes multicast address of FF02::1. The same is true for all unsolicited periodic advertisements.

The Type field in the ICMP header is set to 136, the value for Neighbor Advertisement messages. The Code field is unused and set to 0. When the Router flag is set, the sender is a router.

When the Solicited flag is set, the message is sent in response to a Neighbor Solicitation. For instance, if a host confirms its reachability in answer to an unreachability detection message, the S bit is set. The S bit is not set in multicast advertisements. The Override flag indicates that the information in the Advertisement message should override existing Neighbor Cache entries and update any cached link-layer addresses. If the O bit is not set, the advertisement will not update a cached link-layer address, but it will update an existing Neighbor Cache entry for which no link-layer address exists. The O bit should not be set in an advertisement for an anycast address. I discuss the cache entries later in this chapter. The remaining 29 bits are reserved for future use and set to 0.

In solicited advertisements, the Target Address contains the address of the interface that sent the solicitation. In unsolicited advertisements, this field contains the address of the interface whose link-layer address has changed. A possible option for the Options field is the target link-layer address.

Table 4-6 helps you to identify what you are looking at and summarizes the different processes.

Table 4-6. Identification of ND messages

Source address	Destination address	Message type
All-zero (`::0`)	All-routers multicast Solicited node multicast	Stateless autoconfiguration DAD
Unicast	Solicited node multicast Unicast	Resolve link-layer address Unreachability detection

The ICMP Redirect Message

Routers issue ICMP Redirect messages to inform a node of a better first-hop node on the path to a given destination. A Redirect message can also inform a node that the destination used is in fact a neighbor on the same link and not a node on a remote subnet. The format of the ICMPv6 Redirect message is shown in Figure 4-14.

Figure 4-14. Format of the ICMP Redirect message

The Source address in the IP header must be the link-local address of the interface from which the message is sent. The Destination address in the IP header is the Source address from the packet that triggered the redirect message. The hop limit is set to 255.

The Target Address field contains the link-local address of the interface that is a better next-hop to use for the given Destination address. The Destination Address field contains the address of the destination that is redirected. If the address in the Target Address field is the same as the address in the Destination Address field, the destination is a neighbor and not a remote node. The Options field contains the link-layer address for the target (the best next-hop router) if it is known. This is an improvement on the IPv4 version, in which the host needed to issue a separate ARP request to determine the link-layer address of the next-hop router. The remaining bits in the options field contain as much of the redirected header as fits into the minimum IPv6 MTU of 1,280 bytes.

Inverse Neighbor Discovery

Inverse Neighbor Discovery (IND) is an extension to ND. It was originally designed for Frame Relay networks, but it can be used in other networks with similar requirements. IND is specified in RFC 3122. It consists of two messages: the IND Solicitation and the IND Advertisement message. The messages are used to determine the IPv6 address of hosts for which the link layer address is known. IND corresponds to the Reverse Address Resolution Protocol (RARP) used with IPv4. The messages have the same format as the ND messages. The IND Solicitation has a message type of 141 and the IND Advertisement of 142. The code field is always set to 0.

The Options field has the same format as in the ND messages and contains the same options. Two new IND-specific options have been defined. Option Type 9 defines the Source Address list; option Type 10 the Target Address list (see the overview in Table 4-7).

Source Address list—option Type 9: List of one or more IPv6 addresses of the interface, which is specified in the Source Link Layer address option.
Target Address list—option Type 10: List of all IPv6 addresses of the interface, which is specified in the Target Link Layer address list.

When a host wants to determine the IPv6 address of an interface for which it knows the link-layer address, it sends an IND solicitation to the all-nodes multicast address. On the link layer, the message is sent directly to the interface in question. The destination replies with an IND advertisement containing the Target Address list. If the interface has more IPv6 addresses than fit into a single advertisement message, it must send multiple IND advertisements. Like in all other ND messages, the hop limit is set to 255, and messages with a hop limit lower than 255 must be ignored.

Neighbor Discovery Options

Neighbor Discovery messages contain a variable-size Options field that has the format shown in Figure 4-15.

Figure 4-15. Format of the Option field

The Type field indicates what type of option follows. The following types are defined in RFC 2461:

Type 1: source link-layer address
Type 2: target link-layer address
Type 3: prefix information
Type 4: redirected header
Type 5: MTU

The Length field indicates the length of the option. Value 0 is invalid for this field, and packets with this value must be discarded. The calculation of the length includes the Type and Length fields.

Table 4-7 shows an overview of the different options and the message types in which they are used.

Table 4-7. Overview of ND options

Option type	Used in
Type 1 Source link-layer address	Neighbor solicitation Router solicitation Router advertisement IND solicitation/advertisement
Type 2 Target link layer address	Neighbor advertisement Redirect IND solicitation/advertisement
Type 3 Prefix	Router advertisement
Type 4 Redirected header	Redirect
Type 5 MTU	Router advertisement IND solicitation/advertisement
Type 7 Advertisement interval	Router advertisement (defined in Mobile IPv6 specification)
Type 8 Home Agent information	Router advertisement (defined in Mobile IPv6 specification)
Type 9 Source address list	IND Solicitation
Type 10 Target address list	IND Advertisement

Secure Neighbor Discovery

ND can be used for a number of attacks and should therefore be protected. An example of a Denial of Service attack is when a node on the link can both advertise itself as a default router and also send “forged” Router Advertisement messages that immediately time out all other default routers as well as all on-link prefixes.

The first protection is that packets coming from off-link (with a hop limit lower than 255) must be ignored. Further, the original ND specification suggests using IPsec to secure ND messages. However, this requires manual setup of security associations or the use of a key management protocol. The number of security associations to be configured for protecting ND can be very large, so this approach may be impractical.

The Secure Neighbor Discovery (SEND) working group was chartered with the goal to define the protocol support needed to secure ND. Three different trust models were outlined, roughly corresponding to secured corporate intranets, public wireless access networks, and pure ad hoc networks. A number of possible threats are discussed relating to these trust models. Refer to RFC 3756 for more details.

The SEND protocol, defined in RFC 3971, is designed to counter the threats to ND. SEND can be used in environments where physical security on the link is not assured (such as over wireless) and attacks on ND are a concern. The following components are specified in RFC 3971:

Certification paths anchored on trusted parties certify the authority of routers. A host must be configured with a trust anchor to which the router has a certification path before the host can adopt the router as its default router. Certification Path Solicitation and Advertisement messages are used to discover a certification path to the trust anchor.
Cryptographically Generated Addresses (CGA) are used to make sure that the sender of a Neighbor Discovery message is the owner of the claimed address. A public-private key pair is generated by all nodes before they can claim an address. A new ND option, the CGA option, is used to carry the public key and associated parameters.
Another new ND option, the RSA Signature option, is used to protect all messages relating to Neighbor and Router discovery.
Two new ND options, the Timestamp and Nonce options, have been introduced to prevent replay attacks.

The SEND protocol uses Cryptographically Generated Addresses. SEND currently does not support the protection of ND messages for nodes configured with a static address or with addresses configured through IPv6 Stateless autoconfiguration mechanisms. All new option types and messages are specified in RFC 3971.

Cryptographically Generated Addresses (CGA) are specified in RFC 3972, which defines a method for binding a public signature key to an IPv6 address in the SEND protocol. CGA are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters.

ND in the Trace File

At this point, you all deserve a refreshment. The following trace file shows what ND looks like in the real world and illustrates what we have been talking about.

The screenshot in Figure 4-16 shows the details of a Router Advertisement with two Option fields. This trace file was taken when we had just set up our router. Besides initializing the IPv6 stack and configuring it for the prefix, we have not changed any of the configuration parameters. The options used in this case are options 1 (source link-layer address) and 3 (prefix information). Note the format of the Option fields.

Figure 4-16. The Router Advertisement in a trace file

The Type field is set to 134, the value for a Router Advertisement. The Current Hop Limit has a value of 64. All nodes on this link will use this value for their Hop Count field. The M and O flags are not set by default. The Router Lifetime is set to 1800, which indicates that this is a default router. The first Option listed is type 1. The link-layer address in the detail screen contains the link-layer address of the router interface. The second Option is of type 3 for prefix information. Note all the additional information that can be given with a prefix. The Prefix Length field specifies the number of bits valid for the prefix (i.e., the length of the subnet mask). The L bit is the on-link flag. If set, it indicates that this prefix can be used for on-link determination. If it is not set, the advertisement does not make a statement, and the prefix can be used for on- and off-link configuration. The A bit is the autonomous address configuration flag. If set, it indicates that the prefix can be used for autonomous address configuration. In this case, the host will generate an address by adding the interface identifier to the prefix or, if the privacy options are used, by adding a random number. The Valid Lifetime field specifies how long this prefix is valid. A value of all Fs means infinity. The Preferred Lifetime specifies how long the address being configured with this prefix can remain in the preferred state. Here as well, a value of all Fs means infinity. The last field shows the prefix of caff:ca01:0:56:: advertised by this router.

Link-Layer Address Resolution

Link Layer Address Resolution is the process that happens when a node wants to determine the link-layer address of an interface for which it knows the IP address. With IPv4, this is the functionality of ARP. Link Layer Address Resolution is performed only for nodes that are known to be on the same link (neighbors) and is never performed for multicast addresses.

With IPv6, this is a functionality accomplished with ND messages. A node wanting to resolve a link layer address sends a Neighbor Solicitation message to the solicited node multicast address of the neighbor. This solicitation message contains the link-layer address of the sender in the ND option field. If the destination is reachable, it replies with a Neighbor Advertisement message containing its link-layer address. If the resolving node does not receive an answer within a preconfigured number of attempts, the address resolution has failed.

Neighbor Unreachability Detection (NUD)

A neighbor is considered reachable if the node has recently received a confirmation that packets sent to the neighbor have been received by its IP layer. This confirmation can come in one of two ways: it can be a Neighbor Advertisement in response to a Neighbor Solicitation, or it can be an upper-layer process that indicates the successful connection (e.g., an active TCP connection). In this case, the receipt of TCP acknowledgements implies the reachability of the neighbor.

To keep track of active and reachable connections, IPv6 nodes use different tables. Two important tables relating to ND are the Neighbor and Destination Caches, which I discuss in the next section.

Neighbor Cache and Destination Cache

IPv6 nodes need to maintain different tables of information. Among these tables, the Neighbor Cache and Destination Cache are particularly important. Depending on the IPv6 stack you are working with, the implementation and the troubleshooting utilities will be different. But the information must be available on every IPv6 node.

Neighbor Cache: The Neighbor Cache maintains a list of neighbors to which traffic has been sent recently. They are listed by their unicast IP addresses, and each entry contains information about the neighbor’s link-layer address and a flag that indicates whether the neighbor is a router or host. This can be compared to the ARP cache in an IPv4 node. The entry also contains information about whether there are packets queued to be sent to that destination, information about the neighbor’s reachability, and the time the next neighbor unreachability detection event is scheduled to take place.
Destination Cache: This table maintains information about destinations to which traffic has been sent recently, including local and remote destinations. The Neighbor Cache can be seen as a subset of Destination Cache information. In case of remote destinations, the entry lists the link-layer address of the next-hop router. The Destination Cache is updated with information received by ICMP Redirect messages. It can also contain additional information about MTU sizes and roundtrip timers.

The Neighbor and Destination Caches have been mentioned in regard to the Override flag that can be set in a Neighbor Advertisement message. If the Override flag is set, the information in the Advertisement message should override existing Neighbor Cache entries and update any cached link-layer addresses in the cache of the host that receives the advertisement. If the O bit is not set, the advertisement will not update a cached link-layer address, but it will update an existing Neighbor Cache entry for which no link-layer address exists.

The screenshot in Figure 4-17 shows the Neighbor Cache entries of our Cisco router. There were two hosts on the link at the time the screenshot was taken.

Figure 4-17. Neighbor Cache entries on a router

According to RFC 2461, a Neighbor Cache entry can be in one of five states. The five states are explained in Table 4-8.

Table 4-8. States of Neighbor Cache entries

State	Description
Incomplete	Address resolution is currently being performed and awaiting either a response or a timeout. Specifically, a Neighbor Solicitation has been sent to the solicited-node multicast address of the target, but the corresponding Neighbor Advertisement has not yet been received.
Reachable	This neighbor is currently reachable, which means positive confirmation was received within the last `ReachableTime` milliseconds that the neighbor was functioning properly.
Stale	More than `ReachableTime` milliseconds have elapsed since the last positive confirmation that the forward path was functioning properly was received. No action will take place regarding this neighbor until a packet is sent.
Delay	This neighbor’s Reachable Time has expired, and a packet was sent within the last `DelayFirstProbeTime` seconds. If no confirmation is received within the `DelayFirstProbeTime` seconds, send a Neighbor Solicitation and change the neighbor state to Probe state. The use of `Delay` allows upper-layer protocols additional time to provide reachability confirmation. Without this extra time, possible redundant traffic would be generated.
Probe	A reachability confirmation is being actively attempted by sending Neighbor Solicitations every `RetransTimer` milliseconds until reachability is confirmed.

If you are interested in the details about the timers, default values, and configuration options, refer to RFC 2461.

Autoconfiguration

The autoconfiguration capability of IPv6 saves network administrators a lot of work. It has been designed to ensure that manually configuring hosts before connecting them to the network is not required. Even larger sites with multiple networks and routers should not need a DHCP server to configure hosts. The autoconfiguration features of IPv6 will be a key feature of the protocol when all sorts of devices—such as televisions, refrigerators, DVD players, and mobile phones—use IP addresses. You don’t want to depend on a DHCP server to use your home devices.

IPv6 knows both Stateless and Stateful autoconfiguration. Stateful autoconfiguration is what we call DHCP in the IPv4 world; it is discussed in Chapter 9. What’s really new with IPv6 is that hosts can autoconfigure their IPv6 addresses without any manual configuration of the host. Some configuration might be done on the routers, but no DHCP servers are required for this configuration mechanism. To generate its IP address, a host uses a combination of local information, such as its MAC address or a randomly chosen ID, and information received from routers. Routers can advertise multiple prefixes, and hosts determine prefix information from these advertisements. This allows for simple renumbering of a site: only the prefix information on the router has to be changed. For instance, if you change your ISP and the new ISP assigns a new IPv6 prefix, you can configure your routers to advertise this new prefix, keeping the subnet IDs that you used with the old prefix. All hosts attached to those routers will renumber themselves through the autoconfiguration mechanism. You can find more on renumbering networks later in this chapter. If there is no router present, a host can generate only a link-local address with the prefix FE80, but this address is sufficient for communication of nodes attached to the same link.

Stateless and Stateful autoconfiguration can also be combined. For instance, a host can use Stateless autoconfiguration to generate an IPv6 address but then use Stateful autoconfiguration for additional parameters.

An IPv6 address is leased to a node for a certain lifetime. When the lifetime expires, the address becomes invalid. To make sure an address is unique on a link, a node runs the Duplicate Address Detection (DAD) process. The DAD algorithm is defined in RFC 2462. An IPv6 address can have different states:

Tentative address: This is an address that has not yet been assigned. It is the state prior to the assignment, when uniqueness is being verified (during DAD). A node cannot communicate in the network using a tentative address. The only messages that can be processed with a tentative address are ND messages relating to the autoconfiguration process.
Preferred address: This is the address that has been assigned to an interface and can be used without any restrictions for the lifetime assigned.
Deprecated address: The use of this address is discouraged but not forbidden. A deprecated address might be one whose lifetime is about to expire. It can still be used to continue a communication that would disrupt a service if the address changed. It is no longer used as a Source address for newly established communications.
Valid address: This term is used for both the Preferred and Deprecated address.
Invalid address: An invalid address is not assigned to an interface. A valid address becomes invalid when its lifetime expires.

Tip

Autoconfiguration as defined in RFC 2462 only applies to hosts, not to routers. Routers should be configured in a different way. A router can use Stateless autoconfiguration for the generation of its link-local addresses, and it must use the DAD process for each of its addresses.

When a node is autoconfigured, the following steps are performed:

A link-local address is generated by using the link-local prefix of FE80 and appending the interface identifier. This address is a tentative address.
The node joins the following multicast groups: the all-nodes multicast group (FF02::1) and the solicited-node multicast group for the tentative address (from step 1).
A Neighbor Solicitation message is sent out with the tentative address as the target address. The IP Source address of this message is the all-zeros address; the IP Destination address is the solicited-node multicast address. This detects whether another node on the link already uses this address; i.e., this is DAD. If there is such a node, it replies with a Neighbor Advertisement message, and the autoconfiguration mechanism stops. In this case, manual reconfiguration of the host is required. If there is no answer to the Neighbor Solicitation, it is safe to use the address; the address is assigned to the interface and the state of the address changes to “preferred.” IP connectivity on the local link is now established. So far, the process is the same for hosts and routers, but only hosts perform the next step.
In order to determine which routers are out there and what the prefix is, the host sends a Router Solicitation message to the all-routers multicast group of FF02::2.
All routers on the link reply with a Router Advertisement. For each prefix in Router Advertisements with the Autonomous Configuration flag set, an address is generated, combining the prefix with the interface identifier. These addresses are added to the list of assigned addresses for the interface.

All addresses must be verified with a Neighbor Solicitation message (DAD) before they are assigned. If the link-local address was generated through the autoconfiguration mechanism using the interface identifier, uniqueness has been verified in step 3 and may not need to be repeated for additional addresses that use the same interface identifier. All other addresses configured manually or through Stateful configuration need to be verified individually. Multihomed hosts perform autoconfiguration for each interface.

The trace shown in the screenshot in Figure 4-18 was taken during the autoconfiguration process of Marvin, our Windows host. Figure 4-18 shows some of the processes and message types discussed earlier, and the discussion of the trace summarizes the concepts in this section.

Figure 4-18. Autoconfiguration in the trace file

As long as the booting host does not have a valid IPv6 address it sends all packets from its unspecified all-zeros address, represented as ::0.0.0.0 in the trace file.

First packet: With the first packet, the booting host registers for its solicited node multicast address based on its MAC identifier. The packet contains a Hop-by-Hop Options header with option type 5 for MLD messages. The hop limit is set to 1.
Second packet: With the second packet, it sends a Router Solicitation message to the all-routers multicast address FF02::2.
Third packet: In packet three, it sends a Neighbor Solicitation to the solicited node address in order to perform DAD. The Target Address field of the ICMPv6 header contains the link local address of FE80::206:1BFF:FECC:1734. If another node on the link already used this address, it would reply with a Neighbor Advertisement message.
Fourth packet: The router sends a Router Advertisement to the all-nodes multicast address of FF02::1, because the host does not have a valid IPv6 address yet. This Router Advertisement has the Autonomous Address Configuration flag set to one and contains the prefix 2001:8E0:ABCD:E2::/64.
Fifth packet: With this packet, the host registers for the solicited node multicast address of FF02::1:FF5F:FA11. This is not the interface ID used in packet one. Microsoft has implemented the privacy option and it is enabled by default, so this is the randomly generated interface ID.
Sixth packet: The host performs the DAD test for the address formed by combining the prefix sent in the Router Advertisement (packet four) with the randomly generated interface ID. The packet is sent to the solicited node multicast address. The IPv6 address can be seen in the highlighted line in the detail window opened for packet six.
Seventh packet: The host performs the DAD test for the IPv6 address formed by combining the prefix learned from the Router Advertisement and the MAC identifier. The Target Address field contains the IPv6 address 2001:8E0:ABCD:E2:206:1BFF:FECC:1734.
Eighth and ninth packets: The host uses its MAC identifier based IPv6 address that is in preferred state to register for its two solicited node multicast addresses. Both packets contain the Hop-by-Hop Options header with option type 5 for MLD messages.

When you take your own traces to analyze a boot process and use different operating systems, you will also find differences in the process shown in the trace file. Figure 4-18 is what the boot process looks like with a Windows XP host with SP1 and the advanced networking pack. The differences come from the fact that the RFCs leave room for interpretation of the standard, which can be implemented slightly differently by different vendors. As long as the “must-use” rules in the RFCs are followed, compliance should not be an issue. Note the “should”; this is where your trace file analysis expertise will be helpful in case of failures. Another reason for differences is that the implementation behavior depends on what level and state of the standardization has been implemented. If Microsoft implements the privacy option, this stack will obviously behave differently from a stack that has not implemented the privacy option. So when you analyze processes of a specific operating system, get enough information from the vendor about which RFCs (and sometimes drafts) have been implemented. And if the vendor states that it implemented something, you can use your trace files to verify whether the stack works as it should.

Tip

To configure hosts that use Stateless autoconfiguration for additional information (e.g., DNS servers), a Stateless DHCP server has been specified. See the description in Chapter 9 of upper-layer protocols.

Network Renumbering

With the mechanisms given by ICMPv6, renumbering a network in an IPv6 world may become a lot easier in the future. Currently there is not much operational experience.

Renumbering a network means replacing an old prefix with a new prefix. This can become necessary for a number of reasons, a common one being a change of provider, which usually implies a change of prefix.

Renumbering a network may encompass the following steps:

Each link in the network must be assigned a subprefix from the new prefix before beginning the procedure. This is important for the overall process, in order to ensure proper configuration of all relevant devices and services such as routers, switches, interfaces, DNS, DHCP, etc.
The DNS database must be updated with the addresses for interfaces from the new prefix, and addresses for interfaces from the old prefix must be removed. Obviously the changes to DNS must be coordinated with the changes to addresses assigned to interfaces. The propagation of this new information can be controlled by parameters such as the “Time to Live” (TTL) for DNS records and the update interval between primary and secondary DNS servers.
Switches and routers are prepared for the new prefix. All necessary changes in the routing infrastructure for the new prefix are added in parallel to the old prefix, while the old prefix is still used for datagram services. This includes not only routers and switches, but also firewalls, ingress and egress filters, and all other filtering functions. For propagating subnet prefix information to routers, the IPv6 Prefix option for DHCPv6 (RFC 3633) may be used. In the case where hosts use Stateless autoconfiguration, the routers are not configured to advertise the prefix for autoconfiguration yet (meaning that the Autonomous Address Configuration flag is not set). This will be done once stable routing for the new prefix has been verified.
All access lists, route maps, and other network configuration options (e.g., name services other than DNS) that use IP addresses should be checked to ensure that hosts and services that use the new prefix will behave as they did with the old one.
Test and verify network infrastructure and routing for the new prefix.
Advertise the new prefix outside of the corporate network. Configure all border defense systems accordingly to protect the new prefix from outside attacks.
Assign addresses from the new prefix to interfaces on hosts while still retaining the addresses from the old prefix. If Stateless autoconfiguration is used, the “autonomous address-config” flag is set for the new prefix, so hosts configure addresses for the new prefix in addition to the old addresses. DHCP now assigns addresses from both prefixes if it is used. The new information can be propagated by using the DHCP Reconfigure message, which will cause every DHCP client to contact the DHCP server. The addresses from the new prefix will not be used until they are inserted into DNS.
When the new prefix has been fully integrated into the network infrastructure and tested for stable operation, hosts, switches, and routers can begin using the new prefix. Once the transition has completed, the old prefix will not be in use in the network and can be removed step by step from DNS.

Special attention has to be given to applications and devices that do not get their IP addresses from DHCP or DNS, or that cache or store IP address information locally.

This is a high-level view of a renumbering process and obviously—as all network administrators know well—there are many details and possible pitfalls to be considered. Thorough and careful planning of this process is a must. RFC 4192 describes this process.

Path MTU Discovery

With IPv4, every router can fragment packets if needed. If a router cannot forward a packet because the MTU of the next link is smaller than the packet it has to send, the router fragments the packet. It cuts it into slices that fit the smaller MTU and sends it out as a set of fragments. The packet is then reassembled at the final destination. Depending on the network design, an IPv4 packet may be fragmented more than once during its travel through the network.

With IPv6, routers do not fragment packets anymore; the sender takes care of it. Path MTU discovery tries to ensure that a packet is sent using the largest possible size that is supported on a certain route. The Path MTU is the smallest link MTU of all links from a source to a destination. The discovery of the Path MTU is described in RFC 1981.

The discovery process works like this. First, a host assumes that the Path MTU is the same as the MTU of the first hop link and it uses that size. If the packet is too big for a certain router along the path to deliver the packet to the next link, the router discards the packet and sends back an ICMPv6 Packet Too Big message. Recall that this message type includes the MTU size of the next hop link. The host now uses this MTU for sending further packets to the same destination. The host will never go below the IPv6 minimum MTU size of 1280 bytes, however. The process of receiving a Packet Too Big message and reducing the size of the packets can happen more than once before the packet reaches its destination. The discovery process ends when the packets arrive at the final destination.

The path from a given source to a given destination can change, and so can the Path MTU. Smaller MTU sizes are discovered by getting Packet Too Big messages. An IPv6 host will try to increase the MTU size from time to time in order to be able to detect a larger Path MTU. Path MTU discovery also supports multicast destinations. If the destination is multicast, there are many paths that copies of the packets may travel, and each path can have a different Path MTU. Packet Too Big messages will be generated just as with a unicast destination, and the packet size used by the sender is the smallest Path MTU of the whole set of destinations.

Multicast Listener Discovery (MLD)

Multicast has been available in IPv4 since 1988 and is used to address a certain group of hosts at the same time. Instead of sending out a broadcast, which is not routable and has to be processed by every node on the subnet, the multicast packet is addressed to a multicast group address out of the Class D address range. Only the hosts that are members of that multicast group will process the packet. Multicast messages can be forwarded over routers. In order to make this routing efficient, a multicast group management protocol ensures that routers only forward multicast packets over interfaces to links with members of the multicast group.

In IPv6, multicast is an integral part of the protocol and is available on all IPv6 nodes. A new multicast address format has been defined with a prefix of FF and with added functionality by using scopes in addition to the group address. For example, a multicast group address can be in a link-local scope (FF02), a site-local scope (FF05), or a global scope (FF0E). For an explanation of the multicast address format and a list of scope identifiers, refer to Chapter 3.

Multicast group management in IPv4 is done through Internet Group Management Protocol (IGMP). Version 2 of IGMP is defined in RFC 2236. IPv6 uses ICMPv6 messages for the same functionality; initial development was based on the IGMPv2 specification. It is now called Multicast Listener Discovery (MLD). Version 1 of MLD is defined in RFC 2710. In 2004, MLD Version 2 was defined. It extends MLD Version 1 to support the use of Source Specific Multicast (SSM). It is based on IGMPv3 (RFC 3376) and is specified in RFC 3810. MLDv2 is compatible with MLD Version 1.

MLD is the protocol that allows multicast listeners to register for multicast addresses they want to use, to ensure efficient routing. Therefore, a routing mechanism is needed to manage the forwarding of multicast messages. PIM (Protocol Independent Multicast, RFC 2362) can be used with IPv6 with minimal changes. To find information about the status of PIM, go to the IETF working group at http://www.ietf.org/html.charters/pim-charter.html.

MLD is an asymmetric protocol. The behavior of listeners , i.e., nodes that want to receive messages destined for a specific multicast group, differs from the behavior of routers. For multicast addresses where a router is a listener, it uses both parts of the protocol. Routers use MLD to discover which multicast addresses have listeners on each of their links. For each attached link, the router keeps a list of listener addresses. It does not keep track of how many members are listening to an address. A multicast address is listed as long as there is at least one member on the link. A listener sends member reports for its multicast addresses. With these messages, it registers with routers on the link to receive the messages addressed to the respective multicast group. If the multicast address is not in the routers list for this link, the router adds the address to its list of multicast addresses to be forwarded over this interface. With a Done message, a listener deregisters for a multicast address. When the last member of a group deregisters for a multicast address, the router removes the address from its list for this link.

All MLD messages are sent with a link-local IPv6 Source address and a hop limit of one to make sure they remain on the local link. The packet has a Hop-by-Hop Options header with the Router Alert flag set. Thus, routers will not ignore the packet, even if they are not listening to the multicast group address in question. Refer to Chapter 2 for more information on Extension headers.

MLDv1

The following message types have been specified for MLDv1 (RFC 2710):

Multicast Listener Query—type 130: Used by an IPv6 router to query the multicast addresses on a link. There are two types of queries: the general query used to determine the multicast addresses that have listeners on the link (in the general query, the multicast address field is set to zero) and the address specific query used to find out whether there are members for a specific multicast address on a link (the multicast address field is set to the multicast address for which the query is done).
Multicast Listener Report—type 131: Used by a listener to register for a multicast group. This can be an unsolicited registration or the answer to a multicast listener query from the router.
Multicast Listener Done—type 132: Sent by a listener to deregister for a multicast address. When a router receives a Multicast Listener Done message from the last member of the multicast address on a link, it will delete the multicast address from its list of multicast addresses to be forwarded over this interface.

All three message types of MLDv1 have the same format, which is shown in Figure 4-19.

Figure 4-19. MLD message format

The Type field is 130 for Multicast Listener Queries, 131 for Multicast Listener Reports, or 132 for Multicast Listener Done messages. The Code field is set to 0 by the sender and ignored by the receiver. The Maximum Response Delay field is used only in query messages. This is the maximum allowed delay (in milliseconds) in which a node has to send a report if it has a listener. In all other messages, this field is set to 0. The Multicast Address field is set to 0 in a general query. In an address-specific query, it contains the multicast group address to be queried. In report and done messages, this field contains either the multicast group to which a member listens (report message) or the group it is leaving (done message).

Routers send general queries to the link-local scope all-nodes multicast address FF02::1. Any station that wants to send a report in answer to a query starts a timer when it receives the query and is supposed to wait some random delay before sending the report. The maximum delay is the one specified in the Maximum Response Delay field in the query. If the station sees another station sending a report within that delay, it stops the process. Thus, multiple reports for the same address can be avoided. Group membership join reports and terminations are sent to the address in question.

The link-local scope all-nodes address (FF02::1) is a special address. It never sends a membership report or a done message. If an address has a scope of 1 (interface-local), MLD messages are never sent. Table 4-9 summarizes the message types and their Destination address.

Table 4-9. Message types and their destinations

Message type	IPv6 Destination address
General Query	Link-local scope all-nodes (`FF02::1`)
Multicast Address-Specific Query	The multicast address being queried
Report	The multicast address being reported
Done	Link-local scope all-routers (`FF02::2`)

RFC 2710 contains a lot of interesting and detailed information. It discusses various states that nodes can go through and includes state transition diagrams. There is also much detailed information on timers: how they are used, their default values, and how they can be configured.

MLDv2

MLD Version 2 has been specified in RFC 3810. It is based on IGMPv3 (RFC 3376). MLDv2 adds the ability for a node to do source filtering , which means to report interest in listening to packets with a particular multicast address from only specific Source addresses or from all sources except for specific Source addresses. This is also referred to as Source Specific Multicast (SSM) as opposed to Any Source Multicast (ASM), which is the name for the previous version, based on IGMPv2 (MLDv1).

There are two message types for MLDv2:

Multicast Listener Query—Type 130
Version 2 Multicast Listener Report—Type 143 (RFC 3810)

To be interoperable with MLDv1, MLDv2 implementations also need to support Version 1 Multicast Listener Report (Type 131) and Version 1 Multicast Listener Done (Type 132) messages.

For MLDv2 query messages, the MLD header shown in Figure 4-19 is extended with the following fields, which are appended after the Multicast Address field shown in Figure 4-19:

Reserved—4 bits: Must be set to zero.
S-Flag (Suppress Router-Side Processing)—1 bit: When set to one, the S-Flag indicates to any receiving multicast routers that they have to suppress the normal timer updates they perform upon hearing a Query.
QRV (Querier’s Robustness Variable)—3 bits: If non-zero, the QRV field contains the Robustness Variable value used by the Querier. This value affects timers and the number of retries. Included in queries in order to synchronize all MLDv2 routers connected to the same link.
QQIC (Querier’s Query Interval Code)—8 bits: The Querier’s Query Interval Code field specifies the Query Interval used by the Querier. Included in queries in order to synchronize all MLDv2 routers connected to the same link.
Number of Sources—16 bits: The Number of Sources (N) field specifies how many Source addresses are present in the Query. This number is zero in a General Query or a Multicast Address Specific Query, and nonzero in a Multicast Address and Source Specific Query.
Source Address—variable length: Contains the Source addresses. Length is defined by the number of addresses specified in the N-Field.

MLDv2 Listener Done messages have the following format:

Type Field—1 byte, set to 143
Reserved—1 byte
Checksum—2 bytes
Reserved—2 bytes
M-Field (Number of Multicast Address Records)—2 bytes
Multicast Address Records—variable length

Each Multicast Address Record is a block of fields that contain information on the sender listening to a single multicast address on the interface from which the Report is sent. It includes a field specifying the number of sources and the list of sources for a particular multicast address.

There are different types of multicast address records that can be included in a Report message (RFC 3810; description follows).

A node that receives a Query on an interface responds with a Current State Record to report the state of the interface regarding the multicast address in question. The Current State Record can have one of two values:

Value 1—MODE_IS_INCLUDE: Indicates that the interface has a filter mode of INCLUDE for the specified multicast address
Value 2—MODE_IS_EXCLUDE: Indicates that the interface has a filter mode of EXCLUDE for the specified multicast address

If there is a change of the filter mode, a node sends a Filter Mode Change Record. This record is included in a report sent from the interface where the change occurred. The Filter Mode Change Record can have one of two values:

Value 3—CHANGE_TO_INCLUDE_MODE: Indicates that the interface has changed to INCLUDE filter mode for the specified multicast address. The Source Address fields in this Multicast Address Record contain the interface’s new source list for the specified multicast address, if it is nonempty.
Value 4—CHANGE_TO_EXCLUDE_MODE: Indicates that the interface has changed to EXCLUDE filter mode for the specified multicast address. The Source Address fields in this Multicast Address Record contain the interface’s new source list for the specified multicast address, if it is nonempty.

If there is a change of source list, a node includes a Source List Change Record in a report sent from the interface where the change occurred. The Source List Change Record can have one of two values:

Value 5—ALLOW_NEW_SOURCES: Indicates that the Source Address fields in this Multicast Address Record contain a list of the additional sources that the node wishes to listen to, for packets sent to the specified multicast address. If the change was to an INCLUDE source list, these are the addresses that were added to the list; if the change was to an EXCLUDE source list, these are the addresses that were deleted from the list.
Value 6—BLOCK_OLD_SOURCES: Indicates that the Source Address fields in this Multicast Address Record contain a list of the sources that the node no longer wishes to listen to for packets sent to the specified multicast address. If the change was to an INCLUDE source list, these are the addresses that were deleted from the list; if the change was to an EXCLUDE source list, these are the addresses that were added to the list.

Version 2 Multicast Listener Reports are sent with an IP Destination address of FF02:0:0:0:0:0:0:16. All MLDv2-capable multicast routers listen to this address.

Tip

For more information about Multicast and Anycast Group Membership, refer to the IETF Magma Group at http://www.ietf.org/html.charters/magma-charter.html.

Multicast Router Discovery (MRD)

Multicast Router discovery is a general mechanism that allows for the discovery of multicast routers. It does not depend on a specific multicast routing protocol. It is specified in RFC 4286 and introduces three new message types:

Multicast Router Advertisement (message type 151): This message is sent by routers to advertise that IP multicast forwarding is enabled. It is sent from a link-local Source address to the All-Snoopers multicast address (FF02:0:0:0:0:0:0:6A).
Multicast Router Solicitation (message type 152): This message is sent by devices in order to solicit Advertisement messages from multicast routers. It is sent from a link-local Source address to the all-routers multicast address (FF02:0:0:0:0:0:0:2).
Multicast Router Termination (message type 153): This message is sent by routers to advertise that it stops IP multicast routing functions on an interface. It is sent from a link-local Source address to the All-Snoopers multicast address (FF02:0:0:0:0:0:0:6A).

All MRD messages are sent with an IPv6 Hop Limit of 1 and contain the Router Alert Option.

Now that you know how all the cool functionality of IPv6 works, the next chapter discusses what you need to know about security with IPv6.

References

Here’s a list of the most important RFCs and drafts mentioned in this chapter. Sometimes I include additional subject-related RFCs for your personal further study.

RFCs

RFC 1191, "Path MTU Discovery,” 1991
RFC 1981, "Path MTU Discovery for IP version 6,” 1996
RFC 2236, “Internet Group Management Protocol, Version 2,” 1997
RFC 2362, “Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification,” 1998
RFC 2365, “Administratively Scoped IP Multicast,” 1998
RFC 2461, “Neighbor Discovery for IP Version 6,” 1998
RFC 2462, “IPv6 Stateless Address Autoconfiguration,” 1998
RFC 2463, “Internet Control Message Protocol (ICMPv6),” 1998
RFC 2710, "Multicast Listener Discovery (MLD) for IPv6,” 1999
RFC 2715, “Interoperability Rules for Multicast Routing Protocols,” 1999
RFC 2894, “Router Renumbering for IPv6,” 2000
RFC 3041, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” 2001
RFC 3122, “Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification,” 2001
RFC 3306, “Unicast-Prefix-based IPv6 Multicast Addresses,” 2002
RFC 3353, “Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment,” 2002
RFC 3376, “Internet Group Management Protocol, Version 3,” 2002
RFC 3484, “Default Address Selection for Internet Protocol version 6 (IPv6),” 2003
RFC 3569, “An Overview of Source-Specific Multicast (SSM),” 2003
RFC 3590, “Source Address Selection for the Multicast Listener Discovery (MLD) Protocol,” 2003
RFC 3756, “IPv6 Neighbor Discovery (ND) Trust Models and Threats,” 2004
RFC 3810, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” 2004
RFC 3971, "SEcure Neighbor Discovery (SEND),” 2005
RFC 3972, “Cryptographically Generated Addresses (CGA),” 2005
RFC 3973, “Protocol Independent Multicast—Dense Mode (PIM-DM): Protocol Specification (Revised),” 2005
RFC 4065, “Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations,” 2005
RFC 4191, “Default Router Preferences and More-Specific Routes,” 2005
RFC 4192, “Procedures for Renumbering an IPv6 Network without a Flag Day,” 2005
RFC 4213, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” 2005
RFC 4286, "Multicast Router Discovery,” 2005
RFC 4443, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” 2006

Drafts

Drafts can be found at http://www.ietf.org/ID.html. To locate the latest version of a draft, refer to https://datatracker.ietf.org/public/pidtracker.cgi. You can enter the draft name without a version number and the most current version will come up. If a draft does not show up, it was either deleted or published as an RFC. Alternatively, you can go to the new Internet drafts database interface at https://datatracker.ietf.org/public/idindex.cgi. http://tools.ietf.org/wg is also a very useful site. More information on the process of standardization, RFCs, and drafts can be found in the Appendix.

Here’s a list of drafts that I refer to in this chapter, along with interesting drafts that relate to the topics in this chapter:

draft-ietf-ipv6-2461bis-06.txt (obsoletes RFC 2461), Neighbor Discovery for IP Version 6 (IPv6)
draft-ietf-v6ops-onlinkassumption-04.txt, IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
draft-ietf-ipngwg-icmp-name-lookups-15.txt, IPv6 Node Information Queries
draft-ietf-pim-sm-v2-new-12.txt, Protocol Independent Multicast—Sparse Mode (PIM-SM): Protocol Specification (Revised)
draft-ietf-pim-anycast-rp-07.txt, Anycast-RP Using PIM
draft-ietf-ssm-arch-07.txt, Source-Specific Multicast for IP
draft-holbrook-idmr-igmpv3-ssm-08.txt, Using IGMPv3 and MLDv2 for Source-Specific Multicast
draft-ietf-magma-igmpv3-and-routing-05.txt, IGMPv3/MLDv2 and Multicast Routing Protocol Interaction
draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt, Best Current Practice for Filtering ICMPv6 Messages in Firewalls