Chapter 11: ICMPv6 and IPv6

The Internet Control Message Protocol (ICMP) has been totally revised in light of IPv6. Some functionalities that were not in use or didn’t work well were removed, as well as some other functionalities were added, such as the incorporation of multicast control functions of the IPv4 Group Membership protocol (IGMP). Also, some formats had to be added to carry the larger fields of IPv6. At the end of its revision and enhancements, IPv4 ICMP became ICMPv6, which was no longer compatible with the old version.

This chapter discusses about the ICMP and the changes it undertook in other to accommodate IPv6. Thus, in this chapter we:

• Outline the evolution of ICMP in light of IPv6 implementations
• Review the general format of ICMP messages once it became ICMPv6
• ICMPv6 error messages
• Group management

RFC 1885 (December 1995), developed by Alex Conta (Digital Equipment Corporation) and Stephen Deering ( Xerox Palo Alto Research Center), specifies a set of Internet Control Message Protocol (ICMP) messages for use IPv6 of the Internet Protocol.

Introduction

IPv6 uses the Internet Control Message Protocol (ICMP) as defined for IPv4 [RFC-792], however, as mentioned above, with many changes, which made the new and the old version of ICMP incompatible. The Internet Group Membership Protocol (IGMP) specified for IPv4 [RFC-1112] has also been revised to accommodate the larger fields of IPv6. The new ICMP, now known as ICMPv6 has now an IPv6 Next Header value of 58.

Although we describe the format of a set of control messages used in ICMPv6, we do not include any description of the procedures for using these messages to achieve functions like Path MTU discovery or multicast group membership maintenance; such procedures are described in other RFCs, such as RFC-1112 and RFC-1191.

ICMPv6

ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets, and to perform other Internet-layer functions, such as diagnostics and multicast membership reporting. ICMPv6 is an integral part of IPv6 and MUST be fully implemented by every IPv6 node.

Message General Format

All ICMPv6 messages have the same general format, comprised of:

• A type,
• A code,
• A Checksum,
• Variable-length body

ICMPv6 messages are also grouped into two classes:

• Error messages – Error messages are identified as such by having a zero in the high-order bit of their message Type field values. Thus, error messages have message Types from 0 to 127.
• Informational messages - Informational messages have message Types from 128 to 255.

This document defines the message formats for the following ICMPv6 error messages:

ICMPv6 Error Messages

1 Destination Unreachable

2 Packet Too Big

3 Time Exceeded

4 Parameter Problem

ICMPv6 informational messages:

128 Echo Request

129 Echo Reply

130 Group Membership Query

131 Group Membership Report

132 Group Membership Termination

133 Router Solicitation

134 Router Advertisement

135 Neighbor Solicitation

136 Neighbor Advertisement

137 Redirect

Codes 133, 134, 135, 136 and 137 are used by the neighbor discovery and autoconfiguration procedures. Code 128 and 129 define the IPv6 equivalent of the PING function. Codes 130, 131 and 132 are used in the group membership procedures.

An IPv6 header and zero or more IPv6 extension headers precede every ICMPv6 message. The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header.

Message Source Address Determination

A node that sends an ICMPv6 message has to determine both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it must choose the Source Address of the message as follows:

1. If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply must be that same address.
2. If the message is a response to a message sent to a multicast or anycast group in which the node is a member, the Source Address of the reply must be a unicast address belonging to the interface on which the multicast or anycast packet was received.
3. If the message is a response to a message sent to an address that does not belong to the node, the Source Address should be that unicast address belonging to the node that will be most helpful in diagnosing the error.
4. Otherwise, the node's routing table must be examined to determine which interface will be used to transmit the message to its destination, and a unicast address belonging to that interface must be used as the Source Address of the message.

Message Checksum Calculation

The checksum is the 16-bit one's complement of the one's complement sum of the entire ICMPv6 message starting with the ICMPv6 message type field, prepended with a "pseudo-header" of IPv6 header fields, as specified in. The goal of this checksum is to detect transmission errors. The checksum is computed over an imaginary packet, which is the concatenation of the transport packet that is actually transmitted and a pseudoheader. For computing the checksum, the checksum field is set to zero.

Now, the pseudoheader is a representation of a nominal Internet Protocol header. By including both the source and destination address in the checksum, one can detect misdelivery. Very simply, if the value of the pseudoheader does not match with its initial value before transmission, this tells us that either the packet was misdelivered or that the destination or source address were altered while in transit. This is possible to detect because in this case the checksum will fail.

Message Processing Rules

In accordance with RFC 1122, when processing ICMPv6 messages it MUST meet these conditions:

1. If an ICMPv6 error message of unknown type is received, from transport protocols such as TCP or UDP, it MUST be passed to the upper layer.
2. If an ICMPv6 informational message of unknown type is received, it MUST be silently discarded.

Please note that a new version of TCP and UDP pseudoheaders is provided in the IPv6 specification. It includes:

• The source and destination address,
• The next header type, and
• The payload length.

Also note that one of the differences here between IPv6 and IPv4 in this procedure is that IPv6 does not contain any header checksum. That’s why it is necessary, actually mandatory, the use of checksum at the upper layer, even in the case of UDP.

ICMPv6 Messages Types

In this section we provide you with a brief overview of ICMPv6’s message types. For a detailed version of it, we strongly recommend you to read the RFC 1885, which can be found at InterNic (http://www.internic.org), among many other places.

Type 1: Destination Unreachable Message

Example of a packet that cannot be delivered to its destination address for reasons other than congestion

A Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion. If the reason for the failure to deliver is lack of a matching entry in the forwarding node's routing table, the Code field is set to 0 (NOTE: this error can occur only in nodes that do not hold a "default route" in their routing tables).

If the reason for the failure to deliver is administrative prohibition, such as in the case of encountering a firewall on its way, the Code field is set to 1. But if the reason for the failure to deliver is that the next destination address in the Routing header is not a neighbor of the processing node but the "strict" bit is set for that address, then the Code field is set to 2. By the same token, if there is any other reason for the failure to deliver, such as inability to resolve the IPv6 destination address into a corresponding link address, or a link-specific problem of some sort, then the Code field is set to 3. A code 4 will be issued if in case of a response to a packet for which the transport protocol (e.g., UDP) has no listener, if that transport protocol has no alternative means to inform the sender.

As for an Upper layer notification, a node receiving the ICMPv6 Destination Unreachable message MUST notify the upper-layer protocol.

Type 2: Packet Too Big Message

Type 2: Packet too big

A Packet Too Big MUST be sent by a router in response to a packet that it cannot forward because the packet is larger than the MTU of the outgoing link. The information in this message is used as part of the Path MTU Discovery process as defined on RFC-1191.

Sending a Packet Too Big Message makes an exception to one of the rules of when to send an ICMPv6 error message, in that unlike other messages, it is sent in response to a packet received with an IPv6 multicast destination address, or a link-layer multicast or link-layer broadcast address.

As for Upper layer notification, an incoming Packet Too Big message MUST be passed to the upper-layer protocol.

Type 3: Time Exceeded Message

Type 3: Time exceeded

If a router receives a packet with a Hop Limit of zero, or a router decrements a packet's Hop Limit to zero, it MUST discard the packet and send an ICMPv6 Time Exceeded message with Code 0 to the source of the packet. This indicates either a routing loop or too small an initial Hop Limit value.

The router sending an ICMPv6 Time Exceeded message with Code 0 SHOULD consider the receiving interface of the packet as the interface on which the packet forwarding failed in following rule for selecting the Source Address of the message.

As for the Upper layer notification, an incoming Time Exceeded message MUST be passed to the upper-layer protocol.

Type 4: Parameter Problem Message

Type 4: Parameter problems

If an IPv6 node processing a packet finds a problem with a field in the IPv6 header or extension headers such that it cannot complete processing the packet, it MUST discard the packet and SHOULD send an ICMPv6 Parameter Problem message to the packet's source, indicating the type and location of the problem.

The pointer identifies the octet of the original packet's header where the error was detected. For example, an ICMPv6 message with Type field = 4, Code field = 1, and Pointer field = 40 would indicate that the IPv6 extension header following the IPv6 header of the original packet holds an unrecognized Next Header field value.

As for the Upper layer notification, a node receiving this ICMPv6 message MUST notify the upper-layer protocol.

Type 128: Echo Request Message

Type 128: Echo request

Every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and sends corresponding Echo Replies. A node SHOULD also implement an application-layer interface for sending Echo Requests and receiving Echo Replies, for diagnostic purposes. As for Upper layer notification, a node receiving this ICMPv6 message MAY notify the upper-layer protocol.

Type 129: Echo Reply Message

Type 129: Echo reply

Every node MUST implement an ICMPv6 Echo responder function that receives Echo Requests and sends corresponding Echo Replies. A node SHOULD also implement an application-layer interface for sending Echo Requests and receiving Echo Replies, for diagnostic purposes.

The source address of an Echo Reply sent in response to a unicast Echo Request message MUST be the same as the destination address of that Echo Request message. Thus, an Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast address. The source address of the reply MUST be a unicast address belonging to the interface on which the multicast Echo Request message was received.

The data received in the ICMPv6 Echo Request message MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message, unless the Echo Reply would exceed the MTU of the path back to the Echo requester, in which case the data is truncated to fit that path MTU. As for Upper layer notification Echo Reply messages MUST be passed to the ICMPv6 user interface, unless the corresponding Echo Request originated in the IP layer.

Types 130, 131 and 132: Group Membership Messages

The ICMPv6 Group Membership Messages have the format as shown on figure 11.7.

Format of a group membership message

The ICMPv6 Group Membership messages are used to convey information about multicast group membership from nodes to their neighboring routers. The details of their usage is given in the RFC-1112.

From Here

In the next chapter, "IP Security for IPv6 and IPv4," various aspects of IP security in both environments are discussed, including but not limited to:

• A quick summary of the IPv6 features pertinent to security.
• An introduction to the IP security protocol suite
• A description of the Internet Protocol security services for IPv4 and IPv6
• A discussion of the different ways to use IP security and some of its limitations