B.6. ICMPv6 Message Types and Code Values (Chapter 4, RFC 2463)
Table B-7 provides an overview of the ICMPv6 error message types, along with the additional code information, which depends on the message type.
Table B-7. ICMPv6 error messages and code type
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
Code field set to 0 by the sender and ignored by the receiver
0 = hop limit exceeded in transit
1 = fragment reassembly time exceeded
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
Reserved for expansion of ICMPv6 error messages
Table B-8 provides an overview of the ICMPv6 informational messages.
Table B-8. ICMPv6 informational messages
RFC 4443. Used for the ping command.
Multicast Listener Query
RFC 2710. Used for multicast goup management.
Multicast Listener Report
Multicast Listener Done
RFC 2461. Used for neighbor discovery and autoconfiguration.
0 = Router renumbering command
1 = Router renumbering result
255 = Sequence number reset
ICMP Node Information Query
ICMP Node Information Response
Inverse ND Solicitation
Inverse ND Adv Message
Version 2 Multicast Listener Report
ICMP Home Agent Address Discovery Request Message
RFC 3775 ICMPv6 Messages for Mobile IPv6
ICMP Home Agent Address Discovery Reply Message
ICMP Mobile Prefix Solicitation Message
ICMP Mobile Prefix Advertisement Message
Certification Path Solicitation Message
RFC 3971 ICMPv6 Messages for SEcure Neighbor Discovery
Certification Path Advertisement Message
Multicast Router Advertisement
Multicast Router Solicitation
Multicast Router Termination
Reserved for expansion of ICMPv6 informational messages
Table B-9 lists the possible code values of the Destination Unreachable message (type 1).
Table B-9. Code values of the Destination Unreachable message (type 1)
"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.
"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.
"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.
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.
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.
"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.
"Reject route to destination."
This code is used if the route to the destination is a reject route.
Table B-10 shows the Code fields for the Time Exceeded message.
Table B-10. Code values for Time Exceeded message (type 3)
"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.
"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.
Table B-11 shows the Code fields for the Parameter Problem message.
Table B-11. Code values for Parameter Problem (type 4)
Erroneous header field encountered
Unrecognized next header type encountered
Unrecognized IPv6 option encountered
Table B-12 shows an overview of the different Neighbor Discovery options and the message types in which they are used.
Table B-12. Overview of ND options
Source link-layer address
Target link layer address
Router advertisement (defined in Mobile IPv6 specification)
Home Agent information
Router advertisement (defined in Mobile IPv6 specification)
Source address list
Target address list
A Neighbor Cache entry can be in one of five states according to RFC 2461. The five states are explained in Table B-13.
Table B-13. States of Neighbor Cache entries
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.
This neighbor is currently reachable, which means positive confirmation was received within the last ReachableTime milliseconds that the neighbor was functioning properly.
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.
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.
A reachability confirmation is being actively attempted by sending Neighbor Solicitations every RetransTimer milliseconds until reachability is confirmed.