Mark A. Miller, P.E., President, DigiNet Corporation

In the last few installments in this series, we have examined some of the capabilities of the new protocol, including fields within the packet header that support the transport of real time information, plus the optional extension headers that provide a path to future, for yet-to-be-conceived-of applications for this new protocol. But for IPv6 to be effective in its operations, it must rely upon another protocol, ICMPv6, which is the subject of this tutorial.

Packet transmission is not flawless, as anyone who has ever lost an email will attest. The honest truth is that IPv4 was designed to provide connectionless packet delivery service, meaning that it does not establish an end-to-end connection prior to transmitting any data, which also implies that it does not provide any end-to-end error control. That design omission was intentional, as not all applications either require or desire the added overhead that rigorous error control requires. Plus, when additional error control is necessary, that function can always be delegated to a higher layer protocol, such as the Transmission Control Protocol (or TCP), which provides that capability quite well.

IPv6 follows the same design philosophy as IPv4, continuing the line of reasoning that packet delivery should be as efficient as possible. However, packet errors do occur, and some means for diagnosing the packet delivery system is required when that happens. That diagnosis responsibility is the function of the Internet Control Message Protocol, or ICMP, which was originally defined in RFC 792 (see http://www.rfc-editor.org/rfc/rfc792.txt), and published at the same time as the original IP specification (RFC 791, see http://www.rfc-editor.org/rfc/rfc791.txt). Since these are companion protocols, it only stands to reason that if the Internet Protocol migrates to IPv6, that ICMP would migrate to a new version (designated ICMPv6), as well.

ICMPv6 is defined in currently defined in RFC 4443 (see http://www.rfc-editor.org/rfc/rfc4443.txt), which replaced the original document, RFC 2463. In addition to enhancing the ICMP function, ICMPv6 integrates functions from the Internet Group Management Protocol (IGMP, see RFC 3376, http://www.rfc-editor.org/rfc/rfc3376.txt); extensions to the IGMP work, known as Multicast Listener Discovery (MLD, see RFC 3810, http://www.rfc-editor.org/rfc/rfc3810.txt); plus functions defined by the Neighbor Discovery Protocol (see http://www.rfc-editor.org/rfc/rfc4861.txt).

ICMPv6 is used by IPv6 nodes for two functions: reporting errors that occur during packet processing, and performing other Internet-layer functions, such as diagnostics. In order to assure that each IPv6 node has these error reporting and diagnostic capabilities, implementing ICMPv6 on that node is a requirement.

ICMPv6 is implemented using control messages that are divided into two broad categories: ICMPv6 error messages, and ICMPv6 informational messages. The messages are distinguished by a Message Type field that begins each ICMPv6 message, with Type = 0-127 designated error messages, and Type = 128-255 designated informational message. A Code field within that message provides further elaboration on the message purpose.

The error messages are:

Destination Unreachable (Message Type = 1), which 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. The Destination Unreachable message has six Code field values which provide further details:

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

Packet Too Big (Message Type = 2), which is sent by a router in response to a packet that it cannot forward because the packet is larger than the Maximum Transmission Unit (MTU) of the outgoing communications link. The information in this message is used as part of the Path MTU Discovery process [PMTU], which will be the subject of a future tutorial. The Packet Too Big message sets the Code field value to zero.

Time Exceeded (Message Type = 3), which is sent by IPv6 nodes when the packet processing exceeds previously-determined time thresholds, thus indicating a fundamental issue with packet delivery. The Time Exceeded message has two possible Code field values:

0: Hop limit exceeded in transit

1: Fragment reassembly time exceeded

Parameter Problem (Message Type = 4), which is sent when an IPv6 node is unable to complete the processing of a packet because of a problem within one of the IPv6 header fields or extension headers. The Parameter Problem message has three possible Code field values:

0:  Erroneous header field encountered

1:  Unrecognized Next Header type encountered

2:  Unrecognized IPv6 option encountered

The informational messages are:

• Echo Request (Message Type = 128), which is sent by an IPv6 node to test the communication path to another node, and commonly known as a “Ping Request”. The Echo Request message sets the Code field value to zero, but includes Sequence, Identifier and Data fields to correlate with the expected response.
• Echo Reply (Message Type = 129), which is the response sent by an IPv6 node which has just received an Echo Request message, and commonly known as the “Ping Reply”. The Sequence, Identifier and Data field information that are returned are use to match the reply with the request.

Our next two tutorials will examine some of the new IPv6 processes, Neighbor Discovery and Path MTU Discovery that utilize these ICMPv6 functions capabilities.

Author’s Biography 

Mark A. Miller, P.E. is President of DigiNet Corporation®, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including the Internet Technologies Handbook, published by John Wiley & Sons.