ICMPv6 main page

IPv6 uses the Internet Control Message Protocol (ICMP) as defined for IPv4 with a number of changes. The resulting protocol is called ICMPv6.
The ICMPv6 (Internet Control Message Protocol version 6 is an integral part of the IPv6 architecture and must be completely supported by all IPv6 implementations.
ICMPv6 combines functions previously subdivided among different protocols, such as ICMP (Internet Control Message Protocol version 4), IGMP (Internet Group Membership Protocol), and ARP (Address Resolution Protocol), and it introduces some simplifications by eliminating obsolete types of messages no longer in use.

ICMPv6 packets have the format shown in the figure below. The 8-bit Type field indicates the type of the message. If the high order bit has value zero (values in the range from 0 to 127), it is an error message; if the high-order bit has value 1 (values in the range from 128 to 255), it is an information message. A list of currently defined message types is shown in the type table 1 below.
The 8-bit Code field content depends on the message type, and it is used to create an additional level of message granularity.
The Checksum field is used to detect errors in the ICMP message and in part of the IPv6 message.

• Message General Format:

  ICMPv6 messages are grouped into two classes:
  1. 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.
  2. informational messages. informational messages have message Types from 128 to 255.
  This toturial defines the message formats for the messages described in table below.
  Many of these ICMP types have a "code" field. Here we list the types again with their assigned code fields.

  ICMPv6 error messages

  Type	Description	References
  1	Destination unreachable:	RFC 2463
  2	Packet too big.	RFC 2463
  3	Time exceeded.	RFC 2463
  4	Parameter problem.	RFC 2463

  ICMPv6 informational messages

  Type	Description	References
  128	Echo request.	RFC 2463
  129	Echo reply.	RFC 2463

  Every ICMPv6 message is preceded by an IPv6 header and zero or more IPv6 extension headers. The ICMPv6 header is identified by a Next Header value of 58 in the immediately preceding header. (NOTE: this is different than the value used to identify ICMP for IPv4.)
  

  The ICMPv6 messages have the following general format:

  00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
  Type								Code								Checksum
  Message Body :::

  The type field indicates the type of the message. Its value determines the format of the remaining data.
  The code field depends on the message type. It is used to create an additional level of message granularity.
  The checksum field is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header.
  The subclass of ICMPv6 messages used for reporting errors, i.e., those with a Type value between 0 and 127, inclusive, all have the following, more specific format:

  00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
  Type								Code								Checksum
  type-specific data (32 bits)
  As much of invoking packet as will fit without the ICMPv6 packet exceeding the minimum IPv6 MTU [IPv6].

• 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. For example, if the message is a response to a packet forwarding action that cannot complete successfully, the Source Address should be a unicast address belonging to the interface on which the packet forwarding failed.

  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 Next Header value used in the pseudo-header is 58. (NOTE: the inclusion of a pseudo-header in the ICMPv6 checksum is a change from IPv4.

  For computing the checksum, the checksum field is first set to zero.

• Message Processing Rules:

  Implementations MUST observe the following rules when processing ICMPv6 messages (from [RFC-1122]):
  1. If an ICMPv6 error message of unknown type is received, it MUST be passed to the upper layer.

  2. If an ICMPv6 informational message of unknown type is received, it MUST be silently discarded.

  3. Every ICMPv6 error message (type < 128) includes as much of the IPv6 offending (invoking) packet (the packet that caused the error) as will fit without making the error message packet exceed the minimum IPv6 MTU [IPv6].

  4. In those cases where the internet-layer protocol is required to pass an ICMPv6 error message to the upper-layer process, the upper-layer protocol type is extracted from the original packet (contained in the body of the ICMPv6 error message) and used to select the appropriate upper-layer process to handle the error.
     If the original packet had an unusually large amount of extension headers, it is possible that the upper-layer protocol type may not be present in the ICMPv6 message, due to truncation of the original packet to meet the minimum IPv6 MTU [IPv6] limit. In that case, the error message is silently dropped after any IPv6-layer processing.

  5. An ICMPv6 error message MUST NOT be sent as a result of receiving:
     1. an ICMPv6 error message, or
     2. an ICMPv6 redirect message [IPv6-DISC], or
     3. a packet destined to an IPv6 multicast address (there are two exceptions to this rule:
        1. the Packet Too Big Message - to allow Path MTU discovery to work for IPv6 multicast, and
        2. the Parameter Problem Message, Code 2 , reporting an unrecognized IPv6 option that has the Option Type highest-order two bits set to 10), or
     4. a packet sent as a link-layer multicast, (the exception from e.3 applies to this case too), or
     5. a packet sent as a link-layer broadcast, (the exception from e.3 applies to this case too), or
     6. a packet whose source address does not uniquely identify a single node -- e.g., the IPv6 Unspecified Address, an IPv6 multicast address, or an address known by the ICMP message sender to be an IPv6 anycast address.
  6. Finally, in order to limit the bandwidth and forwarding costs incurred sending ICMPv6 error messages, an IPv6 node MUST limit the rate of ICMPv6 error messages it sends. This situation may occur when a source sending a stream of erroneous packets fails to heed the resulting ICMPv6 error messages. There are a variety of ways of implementing the rate-limiting function, for example:
     1. Timer-based - for example, limiting the rate of transmission of error messages to a given source, or to any source, to at most once every T milliseconds.
     2. Bandwidth-based - for example, limiting the rate at which error messages are sent from a particular interface to some fraction F of the attached link's bandwidth.
     3. Token-bucket based - for example, allowing up to B back- to-back error messages to be transmitted in a burst, but limiting the average rate of transmission to N messages per second.

     NOTE: THE RESTRICTIONS UNDER section 5 AND section 6 ABOVE TAKE PRECEDENCE OVER ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.
     

     The limit parameters (e.g., T or F in the above examples) MUST be configurable for the node, with a conservative default value (e.g., T = 0.5 second, NOT 0 seconds, or F = 2 percent, NOT 100 percent).

A node that forwards an ICMP message has to determine both the source and the destination IPv6 addresses for the ICMP message.
Particular care must be put into the choice of the source address. If a node has more than one unicast address, it must choose the source address of the message as follows:

• n If the message is a response to a message sent to one of the node unicast addresses, the Source Address of the reply must be that same address.
• n If the message is a response to a message sent to a multicast or anycast group to which the node belongs, the Source Address of the reply must be a unicast address belonging to the interface on which the multicast or anycast packet was received.
• n 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 the unicast address belonging to the node that will be the most helpful in checking the error (for example, the unicast address belonging to the interface on which the packet forwarding failed).
• n In other cases, the node routing tables must be examined to determine which interface will be used to transmit the message to its destination, and the unicast address belonging to that interface must be used as the Source Address of the message.

When an ICMP node receives a packet, it must undertake actions that depend on the type of message (RFC 1885 dealing with this subject).
Moreover, the ICMP protocol must limit the number of error messages sent to the same destination to avoid network overloading. For example, if a node continues to forward erroneous packets, ICMP will signal the error to the first packet and then do so periodically, with a fixed minimum period or with a fixed network maximum load.
An ICMP error message must never be sent in response to another ICMP error message.

• Error Messages:

  ICMPv6 error messages are similar to ICMPv4 error messages. They belong to four categories: Destination Unreachable, Packet Too Big, Time Exceeded, and Parameter Problems.We will analyze them further in the following subsections.

  • Destination Unreachable:

    The Destination Unreachable message, which is illustrated in Figure 1,is generated when the network must discard a IPv6 packet because the destination is unreachable. The IPv6 destination address of the ICMP packet is therefore the source address of the discarded packet. The Type field value is 1.
    The Code field can assume values reported in Table 2 described below.
    

    Destination Unreachable Figure:

    00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
    Type								Code								Checksum
    Unused
    As much of invoking packet as will fit without the ICMPv6 packet exceeding the minimum IPv6 MTU [IPv6].

    The Unused field, of course, is not used;
    it is initialized to zero during the transmission and ignored on reception.
    The first part of the IPv6 packet that caused the generation of the ICMP packet follows. Because being able to transmit the ICMP packet on any link must be possible, the packet must not exceed 576 octets (the IPv6 header and eventual extension headers included).
    This type of message can be generated either by a router or by a destination node that cannot deliver the message; the router or node is therefore forced to discard the message. A packet is dropped without generating a message of this type only when the network is congested; generating ICMP messages will make the congestion worse.

    The reasons for the failure in delivering a packet are as follow:

    • n No route to destination: A router cannot find a matching entry for the destination address in its routing table, and therefore it doesn't know on which interface to retransmit the packet.
    • n Communication with destination administratively prohibited: The message is dropped by a firewall that is, by a router that contains a set of rules that forbid some communications.
    • n Not a neighbor: The message contains a Routing header, the next destination address has the Strict / Loose bit equal to Strict, and the next destination address doesn't belong to any of the router links (it is not a neighbor).
    • n Address unreachable: The destination address is unreachable for other reasons for example, for an interface error or for the inability to compute the link layer address of the destination node.
    • n Port unreachable: The packet reached the destination node, but the layer 4 protocol (for example, UDP) to which the packet should be delivered (the port) is unreachable.

  • Packet Too Big:

    The Packet Too Big message, which is illustrated in Figure 2, is generated when the network must discard an IPv6 packet because its size exceeds the MTU of the outgoing link. The information contained in the ICMP packet is used as part of the Path MTU Discovery procedure.
    

    Packet Too Big Figure:

    00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
    Type								Code								Checksum
    Unused
    As much of invoking packet as will fit without the ICMPv6 packet [IPv6].

    The IPv6 destination address of the ICMP packet is therefore the source address of the dropped packet.
    The Type field has value 2.
    The Code field always has value zero.
    The 32-bit MTU field indicates the MTU of the link on which transmitting the packet was impossible.
    The first part of the IPv6 packet that caused the ICMP packet follows.
    Because being able to transmit the ICMP packet on any link must be possible, the packet must not exceed 576 octets (the IPv6 header and eventual extension headers included).

    Table 2

    Code	Meaning
    0	No route to destination.
    1	Communication with destination administratively prohibited.
    2	Not a neighbor.
    3	Address unreachable.
    4	Port unreachable.

  • Time Exceeded:

    The Time Exceeded message, which is illustrated in Figure 3, is generated when a router must discard an IPv6 packet because its Hop Limit field is zero or decrements to zero. This message indicates that either a routing loop or an initial Hop Limit value is too small.

    Time Exceeded Figure:

    00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
    Type								Code								Checksum
    Unused
    As much of invoking packet as will fit without the ICMPv6 packet exceeding the minimum IPv6 MTU [IPv6].

    Another reason is the impossibility to reassemble a fragmented packet within the allowed time limit. The IPv6 destination address of the ICMP packet is therefore the source address of the dropped packet.
    The Type field has value 3.
    The Code field can have the values reported in Table 4 below.
    The Unused field is unused for all code values, and it must be initialized to zero by the sender and ignored by the receiver.
    The first part of the IPv6 packet that caused the ICMP packet follows.
    Because being able to transmit the ICMP packet on any link must be possible, the packet must not exceed 576 octets (the IPv6 header and eventual extension headers included).

    Table 3

    Code	Meaning
    0	Hop limit exceeded in transit.
    1	Fragment reassembly time exceeded.

  • Parameter Problems:

    The Parameter Problem message, which is illustrated in Figure 4, is generated when an IPv6 node must discard a packet because it detects problems in a field of the IPv6 header or of an extension header. The IPv6 destination address of the ICMP packet is therefore the source address of the dropped packet.
    

    Parameter Problem Figure:

    00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
    Type								Code								Checksum
    Pointer
    As much of invoking packet as will fit without the ICMPv6 packet exceeding the minimum IPv6 MTU [IPv6].

    The Type field has value 4.
    The Code field can have the three values reported in Table 3.
    The Pointer field identifies the octet in the original message where the error was detected.
    The first part of the IPv6 packet that caused the ICMP packet follows. Because being able to transmit the ICMP packet on any link must be possible, the packet must not exceed 576 octets (the IPv6 header and eventual extension headers included).

    The following three errors can be detected:

    • Erroneous header field: A field in a header holding an illegal value has been detected.
    • Unrecognized Next Header: A Next Header is unrecognized for the IPv6 implementation present on the node.
    • Unrecognized IPv6 option: The packet holds an unrecognized option for the IPv6 implementation present on the node.

  Informational Messages:

  A second type of ICMP message is the informational message. These messages are subdivided into three groups: diagnostic messages, messages for the management of multicast groups, and Neighbor Discovery messages.

  • Echo Request Message:

    The Echo Request message and its corresponding Echo Reply message are ICMP diagnostic messages. In particular, these two messages are used to implement the ping diagnostic application that allows us to test whether a destination is reachable. The format of these two messages is the same, as illustrated in Figure 5. The IPv6 destination address can be any valid IPv6 address.
    

    Echo Request Figure:

    00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
    Type								Code								Checksum
    Identifier																Sequence Number
    Data ...

    The Type field has value 129.
    The Code field has value zero.
    The Identifier field is an identifier used to set a relationship between Echo Request and Echo Reply messages. It can also be set to zero.
    The Sequence Number field is a sequence number used to set a relationship between Echo Request and Echo Reply messages. It can also be set to zero.
    The Data field contains zero or more octets of data arbitrarily generated by the diagnostic procedure.

    Table 4

    Code	Meaning
    0	Erroneous header field.
    1	Unrecognized Next Header.
    2	Unrecognized IPv6 option.

  • Echo Reply Message:

    Every IPv6 node must implement an ICMP Echo reply function that receives Echo requests and sends corresponding Echo replies, whose format is illustrated in Figure 6. The IPv6 destination address is set equal to the IPv6 source address of the Echo Request message.
    

    Echo Reply Figure:

    00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
    Type								Code								Checksum
    Identifier																Sequence Number
    Data ...

    The Type field has value 129.
    The Code field has value zero.
    The Identifier field is copied from the field of the same name in the Echo Request message.
    The Sequence Number field is copied from the field of the same name in the Echo Request message.
    The Data field is copied from the field of the same name in the Echo Request message.

  • Group Membership Messages:

    ICMP Group Membership messages are used to convey information about multicast group membership from nodes to their neighboring routers (connected on the same link).
    The IPv6 destination address values change in function for the different types of messages:
    • n In a Group Membership Query message, the destination address is equal to the multicast address of the group being queried or equal to the link local All-Nodes multicast address.
    • n In a Group Membership Report or Group Membership Reduction message, the destination address is equal to the multicast address of the group being reported or terminated.
    The IPv6 header Hop Limit field is set to 1 (packets are exchanged only between adjacent nodes).
    The Type field assumes values 130 (Group Membership Query), 131 (Group Membership Report), or 132 (Group Membership Reduction).
    The Code field has value zero.
    The Maximum Response Delay field expresses a value in milliseconds.
    In Group Membership Query messages, this field indicates the maximum time that the responding Report messages can be delayed. In Group Membership Report or Group Membership Reduction messages, this field is initialized to zero by the sender and ignored by the receiver.
    The Unused field is unused and must be initialized to zero by the sender and ignored by the receiver.

  • Router Solicitation Message:

    ICMP messages that will be introduced from this point to the end of the chapter are messages of Neighbor Discovery type (specified by RFC 19706).
    IPv6 nodes transmit Router Solicitation messages to prompt routers to generate Router Advertisements immediately.
    The source address of a Router Solicitation message is either the unicast address of the interface from which the message is sent or, if this address doesn't exist, the unspecified address. The destination address is typically the All-Router (FF02::2) multicast group.
    The Hop Limit field of the IPv6 header is set to 255. This setting is a form of protection against attack from hackers. In fact, routers verify that this field has value 255, and if not, they discard the packet. A hacker could never forward a message with the Hop Limit equal to 255 from outside the LAN because the router will decrement it by one. Only packets really generated on the LAN can have a Hop Limit equal to 255.
    The Priority field of the IPv6 header is set to 15.
    The Type field is equal to 133.
    The Code field is equal to zero.
    The Reserved field is unused; it must be initialized to zero during transmission and ignored on reception.
    In the Options field can appear the option carrying the layer 2 (link layer) address of the source node, if known .

  • Router Advertisement Message:

    Routers send out Router Advertisement messages periodically or in response to Router Solicitation messages.
    The IPv6 source address is set equal to the link local address of the interface from which the message is sent, and the destination address is equal either to the address of the node that solicited the message or to the All-Node multicast address (FF02::1).
    The Hop Limit field of the IPv6 header is set to 255.
    The Priority field of the IPv6 header is set to 15.
    The Type field is equal to 134.
    The Code field is equal to zero.
    The 8-bit Cur Hop Limit field specifies, to nodes that receive the Advertisement, the default value for the Hop Limit field of the IPv6 header to be used during packet transmission. A value of zero means that the sender's router doesn't suggest any default.
    The 1-bit M (Managed address configuration) field, when set, indicates to nodes that receive the Advertisement that they must use the stateful protocol for address auto configuration in addition to the stateless address auto configuration.
    The 1-bit O (Other Stateful configuration) field, when set, indicates to nodes that receive the Advertisement that they must use the stateful auto configuration protocol for additional information.
    The Reserved field is unused; it must be initialized to zero by the sender and ignored by the receiver.
    The 16-bit Router Lifetime field contains the period of time in seconds for which the router can be used as the default router by receiving nodes. If this field is equal to zero, the router cannot be used as the default router.
    The 32-bit Reachable Time field contains the time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation. This parameter is used by the Neighbor Unreachability Detection algorithm.
    The 32-bit Retrans Timer field contains the time, in milliseconds, between retransmitted Neighbor Solicitation messages. It is used by address resolution and Neighbor Unreach ability Detection algorithms.

    The following options can be present in the Options field:

    • The option that specifies the layer 2 (link layer) address of the source node, if known.
    • The option that specifies the link MTU.
    • The Prefix Information option that specifies prefixes to be used for the address auto configuration . A router should include all its on-link prefixes (except the link local prefix) so that multihomed hosts will correctly autoconfigure themselves.

  • Neighbor Solicitation Message:

    IPv6 nodes transmit Neighbor Solicitation messages to request link layer addresses of Target nodes, while also providing the Target with its own link layer address. Neighbor Solicitation messages are sent to multicast addresses when a node needs to resolve an address (from IPv6 to link layer) or to unicast addresses when a node seeks to verify the reach ability of a neighbor.
    The source address of a Neighbor Solicitation message is either the unicast address of the interface that transmits the message or, during the Duplicate Address Detection procedure, the unspecified address.
    The Hop Limit field of the IPv6 header is set to 255.
    The Priority field of the IPv6 header is set to 15.
    The Type field is equal to 135.
    The Code field is equal to zero.
    The Reserved field is unused; it must be initialized to zero by the sender and ignored by the receiver.
    The 128-bit Target Address field specifies the Target node address— that is, the IPv6 address of the node to which the Neighbor Solicitation message is sent.
    In the Options field can be present the option that specifies the link layer address of the source, if known.

  • Neighbor Advertisement Message:

    When the state of a node changes, it forwards a Neighbor Advertisement message to propagate modifications quickly and in response to a Neighbor Solicitation message.
    The source IPv6 address field is set equal to the address of the interface from which the message is sent, and the destination address is equal either to the address of the node that solicited the message or to the All- Node (FF02::1) multicast address.
    The Hop Limit field of the IPv6 header is set equal to 255.
    The Priority field of the IPv6 header is set equal to 15.
    The Type field is set equal to 136.
    The Code field is equal to zero.
    The 1-bit R (Router flag) field indicates, if set, that the source node is a router.
    The 1-bit S (Solicited flag) field indicates, if set, that the message has been sent as a reply to a Neighbor Solicitation message.
    The 1-bit O (Override flag) field indicates, when set, that the message should update the cached link layer address.
    The 29-bit Reserved field is unused; it must be initialized to zero by the sender and ignored by the receiver.
    The 128-bit Target Address field specifies, for solicited advertisements, the address of the node that prompted this advertisement. For unsolicited advertisements, this field specifies the IPv6 address whose link layer address has changed.
    The Options field can contain the option specifying the Target Link Layer Address that is, the link layer address of the node that sent the Neighbor Advertisement.

  • Redirect Message:

    Routers transmit Redirect messages to inform other nodes of a better first hop toward a destination. Hosts can be redirected to another router connected to the same link, but more commonly to another neighbor (this can be obtained by setting the Redirect message Target Address field and the Destination Address field to the same value).
    The IPv6 source address field is equal to the link local address of the interface from which the message is sent, and the destination address is equal to the source address of the packet that caused the Redirect message.
    The Hop Limit field of the IPv6 header is set equal to 255.
    The Priority field of the IPv6 header is set equal to 15.
    The Type field is equal to 137.
    The Code field is equal to zero.
    The Reserved field is unused; it must be initialized to zero by the sender and ignored by the receiver.
    The 128 bit Target Address field contains, for solicited messages, the address of the node that solicited the response. When the Target Address is the endpoint of a communication that is, the destination is a neighbor the Target Address field must contain the same value as the Destination Address field. Otherwise, the Target Address is the link local address of a better first hop router toward the destination.
    The 128 bit Destination Address contains the IPv6 address of the destination that is redirected to the Target Address.

    In the Options field, the following options can appear:

    • The option containing the link layer address of the Target Address, if known.
    • n The Redirect header that is, the option containing the initial part of the packet that caused the Redirect message, truncated so that the ICMP packet doesn't exceed 576 octets.

  Options Format:

  Neighbor Discovery messages can include zero, one, or more options. Some options can appear multiple times in the same message. The 8-bit Type field specifies the option type, coded as described in Table 5.
  The 8-bit Length field specifies the option length in units of 8 octets. The value zero is invalid, so nodes that receive a Neighbor Discovery packet that contains an option with length zero must discard it.

  Source/Target Link Layer Address Option:

  Type 1 (Source Link Layer Address) and type 2 (Target Link Layer Address) options have an identical format.
  The link layer address is a layer 2 address with variable length. The minimum length (Length = 1) reserves 48 bits for the link layer address; this length is ideal to transport the MAC address on LANs.
  The Source Link Layer Address option contains the link layer address of the sender of the packet. This option is used in Router Solicitation, Router Advertisement, and Neighbor Solicitation messages.
  The Target Link Layer Address contains the link layer address of the target. This option is used in Neighbor Advertisement and Redirect messages.

  Table 5

  Type	Option Name
  1	Source Link Layer Address.
  2	Target Link Layer Address.
  3	Prefix Information.
  4	Redirect Header.
  5	MTU.

  Prefix Information Option:

  The Prefix Information option provide hosts with on-link prefixes for address auto configuration.
  The 8-bit Prefix Length field contains the prefix length. Valid values range from 0 to 128.
  The 1-bit L (on-Link flag) field indicates, if set, that the prefix can be used for on-link determination that is, all addresses belonging to that prefix are on the link. When this field is not set, some addresses can be on-link and others off-link (outside the link).
  The 1-bit A (Autonomous address configuration flag) field indicates, if set, that the prefix can be used for autonomous address configuration.
  The 6-bit Reser. 1 field is unused; it must be initialized to zero by the sender and ignored by the receiver.
  The 32-bit Valid Lifetime field contains the number of seconds that the address generated from the prefix via stateless auto configuration remains valid. The hexadecimal value FFFFFFFF represents infinity.
  The 32-bit Preferred Lifetime field contains the number of seconds that an address generated from the prefix via stateless auto configuration remains preferred. The hexadecimal value FFFFFFFF represents infinity.
  The 32-bit Reserved 2 field is unused; it must be initialized to zero by the sender and ignored by the receiver.
  The 128-bit Prefix field contains an IPv6 address or a prefix of an IPv6 address. Only first Prefix Length bits are significant, so others must be ignored and initialized to zero.
  

  Redirect Header Option:

  The Redirect Header option is used in ICMP Redirect packets to contain the first part of the message that caused the request of redirection.
  The 48-bit Reserved field is unused; it must be initialized to zero by the sender and ignored by the receiver.
  The IP header + data field contains the packet that generated the redirect message. The original packet is truncated to ensure that the size of the redirect message does not exceed 576 octets.
  

  MTU Option:

  The MTU option is used in Router Advertisement messages to ensure that, on links with variable MTU values, all nodes use the same MTU value.
  The 16-bit Reserved field is unused; it must be initialized to zero by the sender and ignored by the receiver.
  The 32-bit Maximum Transmission Unit (MTU) field contains the recommended MTU for the link.
  

• Authentication and Encryption of ICMP messages:

  ICMP protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an Authentication Header when sending ICMP messages if a security association for use with the IP Authentication Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol.
  Received Authentication Headers in ICMP packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored and discarded.
  It SHOULD be possible for the system administrator to configure a node to ignore any ICMP messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. Such a switch SHOULD default to allowing unauthenticated messages.
  Confidentiality issues are addressed by the IP Security Architecture and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-ESP].

• ICMP Attacks:

  ICMP messages may be subject to various attacks. A complete discussion can be found in the IP Security Architecture [IPv6-SA]. A brief discussion of such attacks and their prevention is as follows:
  1. ICMP messages may be subject to actions intended to cause the receiver to believe the message came from a different source than the message originator. The protection against this attack can be achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] to the ICMP message.
  2. ICMP messages may be subject to actions intended to cause the message or the reply to it go to a destination different than the message originator's intention. The ICMP checksum calculation provides a protection mechanism against changes by a malicious interceptor in the destination and source address of the IP packet carrying that message, provided the ICMP checksum field is protected against change by authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message.
  3. ICMP messages may be subject to changes in the message fields, or payload. The authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message is a protection against such actions.
  4. ICMP messages may be used as attempts to perform denial of service attacks by sending back to back erroneous IP packets. An implementation that correctly followed of this specifications, would be protected by the ICMP error rate limiting mechanism.

• Added token-bucket method as an example rate-limiting mechanism for ICMP error messages, and changed default value for the fixed timer approach, parameter T, from 1 second to 0.5 second.

• Added specification that all ICMP error messages shall have exactly 32 bits of type-specific data, so that receivers can reliably find the embedded invoking packet even when they don't recognize the ICMP message Type.

• In the description of Destination Unreachable messages, Code 3, added rule prohibiting forwarding of packets back onto point-to- point links from which they were received, if their destination addresses belong to the link itself ("anti-ping-ponging" rule).

• Added description of Time Exceeded Code 1 (fragment reassembly timeout).

• Added "beyond scope of source address" message to the family of "unreachable destination" type ICMP error messages.

• Added a NOTE in section Message Processing Rules, that specifies ICMP message processing rules precedence.

• Added ICMP REDIRECT to the list in Section Message Processing Rules section 5 of cases in which ICMP error messages are not to be generated.

• Made minor editorial changes in Section Message Checksum Calculation on checksum calculation, and in ICMP Attacks.

HOME