TCP/IP: Internet Control Message Protocol

The IP protocol alone provides no direct way for an end system to learn the fate of IP packets that fail to make it to their destinations.

In addition, IP provides no direct way of obtaining diagnostic information (e.g., which routers are used along a path or a method to estimate the round-trip time).

To address these deficiencies, a special protocol called the Internet Control Message Protocol (ICMP) [RFC0792] [RFC4443] is used in conjunction with IP to provide diagnostics and control information related to the configuration of the IP protocol layer and the disposition of IP packets.

ICMP is often considered part of the IP layer itself, and it is required to be present with any IP implementation. It uses the IP protocol for transport.

ICMP provides for the delivery of error and control messages that may require attention.

ICMP messages are usually acted on by the IP layer itself, by higher-layer transport protocols (e.g., TCP or UDP), and in some cases by user applications.
Note that ICMP does not provide reliability for IP.

Rather, it indicates certain classes of failures and configuration information.
The most common cause of packet drops (buffer overrun at a router) does not elicit any ICMP information.

Other protocols, such as TCP, handle such situations.

Because of the ability of ICMP to affect the operation of important system functions and obtain configuration information, hackers have used ICMP messages in a large number of attacks. As a result of concerns about such attacks, network administrators often arrange to block ICMP messages with firewalls, especially at border routers. If ICMP is blocked, however, a number of common diagnostic utilities (e.g., ping, traceroute) do not work properly [RFC4890].

In IPv6, ICMPv6 is used for several purposes beyond simple error reporting and signaling.

It is used for Neighbor Discovery (ND) [RFC4861], which plays the same role as ARP does for IPv4.
It also includes the Router Discovery function used for configuring hosts and multicast address management.
Finally, it is also used to help manage handoffs in Mobile IPv6.

1. Encapsulation in IPv4 and IPv6
2. ICMP Messages
3. ICMP Error Messages
4. ICMP Query/Informational Messages
5. Neighbor Discovery in IPv6
References

1. Encapsulation in IPv4 and IPv6

ICMP messages are encapsulated for transmission within IP datagrams

Figure 1. Encapsulation of ICMP messages in IPv4 and IPv6. The ICMP header contains a checksum covering the ICMP data area. In ICMPv6, the checksum also covers the Source and Destination IPv6 Address, Length, and Next Header fields in the IPv6 header.

In IPv4, a Protocol field value of 1 indicates that the datagram caries ICMPv4.
In IPv6, the ICMPv6 message may begin after zero or more extension headers. The last extension header before the ICMPv6 header includes a Next Header field with value 58.
ICMP messages may be fragmented like other IP datagrams, although this is not common.

Figure 2. All ICMP messages begin with 8-bit Type and Code fields, followed by a 16-bit Checksum that covers the entire message. The type and code values are different for ICMPv4 and ICMPv6.

2. ICMP Messages

ICMP messages are grouped into two major categories:

those messages relating to problems with delivering IP datagrams (called error messages),
and those related to information gathering and configuration (called query or informational messages).

2.1. ICMPv4 Messages

For ICMPv4, the informational messages include

Echo Request and Echo Reply (types 8 and 0, respectively),
and Router Advertisement and Router Solicitation (types 9 and 10, respectively,

together called Router Discovery).

The most common error message types are

Destination Unreachable (type 3),
Redirect (type 5),
Time Exceeded (type 11),
and Parameter Problem (type 12).

Table 1. The standard ICMPv4 message types, as determined by the Type field*
Type	Official Name	Reference	E/I	Use/Comment
0 (*)	Echo Reply	[RFC0792]	I	Echo (ping) reply; returns data
3 (*)(+)	Destination Unreachable	[RFC0792]	E	Unreachable host/protocol
4	Source Quench	[RFC0792]	E	Indicates congestion (deprecated)
5 (*)	Redirect	[RFC0792]	E	Indicates alternate router should be used
8 (*)	Echo	[RFC0792]	I	Echo (ping) request (data optional)
9	Router Advertisement	[RFC1256]	I	Indicates router addresses/preferences
10	Router Solicitation	[RFC1256]	I	Requests Router Advertisement
11 (*)(+)	Time Exceeded	[RFC0792]	E	Resource exhausted (e.g., IPv4 TTL)
12 (*)(+)	Parameter Problem	[RFC0792]	E	Malformed packet or header

Types marked with asterisks (*) are the most common. Those marked with a plus (+) may contain [RFC4884] extension objects. In the fourth column, E is for error messages and I indicates query/informational messages.

Table 2. Common ICMPv4 message types that use code numbers in addition to 0. Although all of these message types are relatively common, only a few of the codes are commonly used.
Type	Code	Official Name	Use/Comment
3	0	Net Unreachable	No route (at all) to destination
3 (*)	1	Host Unreachable	Known but unreachable host
3	2	Protocol Unreachable	Unknown (transport) protocol
3 (*)	3	Port Unreachable	Unknown/unused (transport) port
3 (*)	4	Fragmentation Needed and Don’t Fragment Was Set (PTB message)	Needed fragmentation prohibited by DF bit; used by PMTUD [RFC1191]
3	5	Source Route Failed	Intermediary hop not reachable
3	6	Destination Network Unknown	Deprecated [RFC1812]
3	7	Destination Host Unknown	Destination does not exist
3	8	Source Host Isolated	Deprecated [RFC1812]
3	9	Communication with Destination Network Administratively Prohibited	Deprecated [RFC1812]
3	10	Communication with Destination Host Administratively Prohibited	Deprecated [RFC1812]
3	11	Destination Network Unreachable for Type of Service	Type of service not available (net)
3	12	Destination Host Unreachable for Type of Service	Type of service not available (host)
3	13	Communication Administratively Prohibited	Communication prohibited by filtering policy
3	14	Host Precedence Violation	Precedence disallowed for src/dest/port
3	15	Precedence Cutoff in Effect	Below minimum ToS [RFC1812]
5	0	Redirect Datagram for the Network (or Subnet)	Indicates alternate router
5 (*)	1	Redirect Datagram for the Host	Indicates alternate router (host)
5	2	Redirect Datagram for the Type of Service and Network	Indicates alternate router (ToS/net)
5	3	Redirect Datagram for the Type of Service and Host	Indicates alternate router (ToS/host)
9	0	Normal Router Advertisement	Router’s address and configuration information
9	16	Does Not Route Common Traffic	With Mobile IP [RFC5944], router does not route ordinary packets
11 (*)	0	Time to Live Exceeded in Transit	Hop limit/TTL exceeded
11	1	Fragment Reassembly Time Exceeded	Not all fragments of datagram arrived before reassembly timer expired
12 (*)	0	Pointer Indicates the Error	Byte offset (pointer) indicates first problem field
12	1	Missing a Required Option	Deprecated/historic
12	2	Bad Length	Packet had invalid Total Length field

2.2. ICMPv6 Messages

Note that ICMPv6 is responsible not only for error and informational messages but also for a great deal of IPv6 router and host configuration.

Table 3. In ICMPv6, error messages have message types from 0 to 127. Informational messages have message types from 128 to 255. The plus (+) notation indicates that the message may contain an extension structure. Reserved, unassigned, experimental, and deprecated values are not shown.
Type	Official Name	Reference	Description
1 (+)	Destination Unreachable	[RFC4443]	Unreachable host, port, protocol
2	Packet Too Big (PTB)	[RFC4443]	Fragmentation required
3 (+)	Time Exceeded	[RFC4443]	Hop limit exhausted or reassembly timed out
4	Parameter Problem	[RFC4443]	Malformed packet or header
100,101	Reserved for private experimentation	[RFC4443]	Reserved for experiments
127	Reserved for expansion of ICMPv6 error messages	[RFC4443]	Hold for more error messages
128	Echo Request	[RFC4443]	ping request; may contain data
129	Echo Reply	[RFC4443]	ping response; returns data
130	Multicast Listener Query	[RFC2710]	Queries multicast subscribers (v1)
131	Multicast Listener Report	[RFC2710]	Multicast subscriber report (v1)
132	Multicast Listener Done	[RFC2710]	Multicast unsubscribe message (v1)
133	Router Solicitation (RS)	[RFC4861]	IPv6 RS with Mobile IPv6 options
134	Router Advertisement (RA)	[RFC4861]	IPv6 RA with Mobile IPv6 options
135	Neighbor Solicitation (NS)	[RFC4861]	IPv6 Neighbor Discovery (Solicit)
136	Neighbor Advertisement (NA)	[RFC4861]	IPv6 Neighbor Discovery (Advertisement)
137	Redirect Message	[RFC4861]	Use alternative next-hop router
141	Inverse Neighbor Discovery Solicitation Message	[RFC3122]	Inverse Neighbor Discovery request: requests IPv6 addresses given link-layer address
142	Inverse Neighbor Discovery Advertisement Message	[RFC3122]	Inverse Neighbor Discovery response: reports IPv6 addresses given link-layer address
143	Version 2 Multicast Listener Report	[RFC3810]	Multicast subscriber report (v2)
144	Home Agent Address Discovery Request Message	[RFC6275]	Requests Mobile IPv6 HA address; send by mobile node
145	Home Agent Address Discovery Reply Message	[RFC6275]	Contains MIPv6 HA address; sent by eligible HA on home network
146	Mobile Prefix Solicitation	[RFC6275]	Request home prefix while away
147	Mobile Prefix Advertisement	[RFC6275]	Provides prefix from HA to mobile
148	Certification Path Solicitation Message	[RFC3971]	Secure Neighbor Discovery (SEND) request for a certification path
149	Certification Path Advertisement Message	[RFC3971]	SEND response to certification path request
151	Multicast Router Advertisement	[RFC4286]	Provides address of multicast router
152	Multicast Router Solicitation	[RFC4286]	Requests address of multicast router
153	Multicast Router Termination	[RFC4286]	Done using multicast router
154	FMIPv6 Messages	[RFC5568]	MIPv6 fast handover messages
200,201	Reserved for private experimentation	[RFC4443]	Reserved for experiments
255	Reserved for expansion of ICMPv6 informational messages	[RFC4443]	Hold for more informational messages

Table 4. ICMPv6 standard message types (i.e., Destination Unreachable, Time Exceeded, and Parameter Problem) with codes in addition to 0 assigned
Type	Code	Name	Use/Comment
1	0	No Route to Destination	Route not present
1	1	Administratively Prohibited	Policy (e.g., firewall) prohibited
1	2	Beyond Scope of Source Address	Destination scope exceeds source’s
1	3	Address Unreachable	Used if codes 0–2 are not appropriate
1	4	Port Unreachable	No transport entity listening on port
1	5	Source Address Failed	Policy Ingress/egress policy violation
1	6	Reject Route to Destination	Specific reject route to destination
3	0	Hop Limit Exceeded in Transit	Hop Limit field decremented to 0
3	1	Reassembly Time Exceeded	Unable to reassemble in limited time
4	0	Erroneous Header Field	Found General header processing error
4	1	Unrecognized Next Header	Unknown Next Header field value
4	2	Unrecognized IPv6 Option	Unknown Hop-by-Hop or Destination option

2.3. Processing of ICMP Messages

In ICMP, the processing of incoming messages varies from system to system.

Generally speaking, the incoming informational requests are handled automatically by the operating system, and the error messages are delivered to user processes or to a transport protocol such as TCP [RFC5461]. The processes may choose to act on them or ignore them.

Exceptions to this general rule include the Redirect message and the Destination Unreachable—Fragmentation Required messages.

The former results in an automatic update to the host’s routing table,
whereas the latter is used in the path MTU discovery (PMTUD) mechanism, which is generally implemented by the transport-layer protocols such as TCP.

In ICMPv6 the handling of messages has been tightened somewhat. The following rules are applied when processing incoming ICMPv6 messages [RFC4443]:

Unknown ICMPv6 error messages must be passed to the upper-layer process that produced the datagram causing the error (if possible).
Unknown ICMPv6 informational messages are dropped.
ICMPv6 error messages include as much of the original (offending) IPv6 datagram that caused the error as will fit without making the error message datagram exceed the minimum IPv6 MTU (1280 bytes).
When processing ICMPv6 error messages, the upper-layer protocol type is extracted from the original or offending packet (contained in the body of the ICMPv6 error message) and used to select the appropriate upper-layer process.

If this is not possible, the error message is silently dropped after any IPv6-layer processing.
There are special rules for handling errors.
An IPv6 node must limit the rate of ICMPv6 error messages it sends.

There are a variety of ways of implementing the rate-limiting function, including the token bucket approach mentioned.

3. ICMP Error Messages

In particular, an ICMP error message is not to be sent in response to any of the following messages: another ICMP error message, datagrams with bad headers (e.g., bad checksum), IP-layer broadcast/multicast datagrams, datagrams encapsulated in link-layer broadcast or multicast frames, datagrams with an invalid or network zero source address, or any fragment other than the first.

The reason for imposing these restrictions on the generation of ICMP errors is to limit the creation of so-called broadcast storms, a scenario in which the generation of a small number of messages creates an unwanted traffic cascade (e.g., by generating error responses in response to error responses, indefinitely).

An ICMPv4 error message is never generated in response to:

An ICMPv4 error message. (An ICMPv4 error message may, however, be generated in response to an ICMPv4 query message.)
A datagram destined for an IPv4 broadcast address or an IPv4 multicast address (formerly known as a class D address).
A datagram sent as a link-layer broadcast.
A fragment other than the first.
A datagram whose source address does not define a single host.

This means that the source address cannot be a zero address, a loopback address, a broadcast address, or a multicast address.

An ICMPv6 error message is never generated in response to:

An ICMPv6 error message
An ICMPv6 Redirect message
A packet destined for an IPv6 multicast address, with two exceptions:
- The Packet Too Big (PTB) message
- The Parameter Problem message (code 2)
A packet sent as a link-layer multicast (with the exceptions noted previously)
A packet sent as a link-layer broadcast (with the exceptions noted previously)
A packet whose source address does not uniquely identify a single node.

This means that the source address cannot be an unspecified address, an IPv6 multicast address, or any address known by the sender to be an anycast address.

When an ICMP error message is sent, it contains

a copy of the full IP header from the offending or original datagram (i.e., the IP header of the datagram that caused the error to be generated, including any IP options),
plus any other data from the original datagram’s IP payload area

such that the generated IP/ ICMP datagram’s size does not exceed a specific value.

For IPv4 this value is 576 bytes, and for IPv6 it is the IPv6 minimum MTU, which is at least 1280 bytes.

Including a portion of the payload from the original IP datagram lets the receiving ICMP module associate the message with

one particular protocol (e.g., TCP or UDP) from the Protocol or Next Header field in the IP header
and one particular user process (from the TCP or UDP port numbers that are in the TCP or UDP header contained in the first 8 bytes of the IP datagram payload area).

3.1. Destination Unreachable (ICMPv4 Type 3, ICMPv6 Type 1) and Packet Too Big (ICMPv6 Type 2)

In ICMPv6, as compared with IPv4, the Fragmentation Required message has been replaced by an entirely different type (type 2), but the usage is very similar to the corresponding ICMP Destination Unreachable message.

3.1.1. ICMPv4 Host Unreachable (Code 1) and ICMPv6 Address Unreachable (Code 3)

This form of the Destination Unreachable message is generated by a router or host when it is required to send an IP datagram to a host using direct delivery but for some reason cannot reach the destination.

This situation may arise, for example, because the last-hop router is attempting to

send an ARP request to a host that is either missing or down.

root@node-0:~# tcpdump -tenv not tcp -i any
ens34 B   ifindex 3 00:0c:29:8c:df:3f ethertype ARP (0x0806), length 66: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.91.120 tell 192.168.91.128, length 46
lo    In  ifindex 1 00:00:00:00:00:00 ethertype IPv4 (0x0800), length 132: (tos 0xc0, ttl 64, id 18662, offset 0, flags [none], proto ICMP (1), length 112)
    192.168.91.128 > 192.168.91.128: ICMP host 192.168.91.120 unreachable, length 92
	(tos 0x0, ttl 64, id 33177, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.91.128 > 192.168.91.120: ICMP echo request, id 60872, seq 1, length 64

x@node-0:~$ ping -c 1 192.168.91.120
PING 192.168.91.120 (192.168.91.120) 56(84) bytes of data.
From 192.168.91.128 icmp_seq=1 Destination Host Unreachable

--- 192.168.91.120 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

For ICMPv6, this message can be the result of a failure in the ND process.

root@node-0:~# tcpdump -tenv ip6 -i any
ens32 Out ifindex 2 00:0c:29:8c:df:3f ethertype IPv6 (0x86dd), length 92: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:29ff:fe8c:df3f > ff02::1:ff8c:df50: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::20c:29ff:fe8c:df50
	  source link-address option (1), length 8 (1): 00:0c:29:8c:df:3f
lo    In  ifindex 1 00:00:00:00:00:00 ethertype IPv6 (0x86dd), length 172: (flowlabel 0xa61cc, hlim 64, next-header ICMPv6 (58) payload length: 112) fe80::20c:29ff:fe8c:df3f > fe80::20c:29ff:fe8c:df3f: [icmp6 sum ok] ICMP6, destination unreachable, unreachable address fe80::20c:29ff:fe8c:df50

x@node-0:~$ ping -c 1 -6 fe80::20c:29ff:fe8c:df50
PING fe80::20c:29ff:fe8c:df50(fe80::20c:29ff:fe8c:df50) 56 data bytes
From fe80::20c:29ff:fe8c:df3f%ens32 icmp_seq=1 Destination unreachable: Address unreachable

--- fe80::20c:29ff:fe8c:df50 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

3.1.2. ICMPv6 No Route to Destination (Code 0)

This message refines the Host Unreachable message from ICMPv4 to differentiate those hosts not reachable because of failure of direct delivery and those that cannot be reached because no route is present.

This message is generated only in cases where an arriving datagram must be forwarded without using direct delivery, but where no route entry exists to indicate what router to use as a next hop.

root@node-1:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
root@node-1:~# ip r
192.168.91.0/24 dev ens32 proto kernel scope link src 192.168.91.130
root@node-1:~# tcpdump -env -t ip and not tcp -i ens32
tcpdump: listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
00:0c:29:8c:df:3f > 00:0c:29:85:26:07, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 7149, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.91.128 > 192.168.92.10: ICMP echo request, id 41837, seq 1, length 64
00:0c:29:85:26:07 > 00:0c:29:8c:df:3f, ethertype IPv4 (0x0800), length 126: (tos 0xc0, ttl 64, id 37553, offset 0, flags [none], proto ICMP (1), length 112)
    192.168.91.130 > 192.168.91.128: ICMP net 192.168.92.10 unreachable, length 92
	(tos 0x0, ttl 64, id 7149, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.91.128 > 192.168.92.10: ICMP echo request, id 41837, seq 1, length 64

3.1.3. ICMPv4 Port Unreachable (Code 3) and ICMPv6 Port Unreachable (Code 4)

The Port Unreachable message is generated when an incoming datagram is destined for an application that is not ready to receive it.

This occurs most commonly in conjunction with UDP, when a message is sent to a port number that is not in use by any server process. If UDP receives a datagram and the destination port does not correspond to a port that some process has in use, UDP responds with an ICMP Port Unreachable message.

x@node-0:~$ echo -n "hello" | nc -4u -w0 10.170.109.10 tftp

root@node-0:~# tcpdump -nvv icmp or port tftp
tcpdump: listening on ens32, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:55:42.158497 IP (tos 0x0, ttl 64, id 9924, offset 0, flags [DF], proto UDP (17), length 33)
    192.168.91.128.37775 > 192.168.91.130.69: [udp sum ok] TFTP, length 5, tftp-#26725
09:55:42.158719 IP (tos 0xc0, ttl 64, id 6641, offset 0, flags [none], proto ICMP (1), length 61)
    192.168.91.130 > 192.168.91.128: ICMP 192.168.91.130 udp port 69 unreachable, length 41
	IP (tos 0x0, ttl 64, id 9924, offset 0, flags [DF], proto UDP (17), length 33)
    192.168.91.128.37775 > 192.168.91.130.69: [udp sum ok] TFTP, length 5, tftp-#26725

x@node-0:~$ echo -n "hello" | nc -6u -w0 fe80::20c:29ff:fe85:2607%ens32 tftp

root@node-0:~# tcpdump -nvvv -s 1500 icmp6 or port tftp
tcpdump: listening on ens32, link-type EN10MB (Ethernet), snapshot length 1500 bytes
10:12:51.993200 IP6 (flowlabel 0x9515e, hlim 64, next-header UDP (17) payload length: 13) fe80::20c:29ff:fe8c:df3f.42714 > fe80::20c:29ff:fe85:2607.69: [udp sum ok] TFTP, length 5, tftp-#26725
10:12:51.993612 IP6 (flowlabel 0x7b8d5, hlim 64, next-header ICMPv6 (58) payload length: 61) fe80::20c:29ff:fe85:2607 > fe80::20c:29ff:fe8c:df3f: [icmp6 sum ok] ICMP6, destination unreachable, unreachable port, fe80::20c:29ff:fe85:2607 udp port 69

3.1.4. ICMPv4 PTB (Code 4)

If an IPv4 router receives a datagram that it intends to forward, and if the datagram does not fit into the MTU in use on the selected outgoing network interface, the datagram must be fragmented.

If the arriving datagram has the Don’t Fragment bit field set in its IP header, however, it is not forwarded but instead is dropped, and this ICMPv4 Destination Unreachable (PTB) message is generated.

Because the router sending this message knows the MTU of the next hop, it is able to include the MTU value in the error message it generates.
This message was originally intended to be used for network diagnostics but has since been used for path MTU discovery.

PMTUD is used to determine an appropriate packet size to use when communicating with a particular host, on the assumption that avoiding packet fragmentation is desirable. It is used most commonly with TCP.

x@node-1:~$ sudo sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

x@node-1:~$ ip link show ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:0c:29:85:26:07 brd ff:ff:ff:ff:ff:ff

x@node-1:~$ sudo ip link set ens32 mtu 900

x@node-1:~$ ip a show ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 900 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:85:26:07 brd ff:ff:ff:ff:ff:ff
    inet 192.168.91.130/24 brd 192.168.91.255 scope global dynamic ens32
       valid_lft 1511sec preferred_lft 1511sec

x@node-0:~$ ip r
default via 192.168.91.130 dev ens32
192.168.91.0/24 dev ens32 proto kernel scope link src 192.168.91.128
x@node-0:~$ ping -c 1 -s 1000 -M do 10.170.109.10
PING 10.170.109.10 (10.170.109.10) 1000(1028) bytes of data.
From 192.168.91.130 icmp_seq=1 Frag needed and DF set (mtu = 900)

--- 10.170.109.10 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

root@node-0:~# tcpdump -nvv -t icmp
tcpdump: listening on ens32, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1028)
    192.168.91.128 > 10.170.109.10: ICMP echo request, id 52044, seq 1, length 1008
IP (tos 0xc0, ttl 64, id 58248, offset 0, flags [none], proto ICMP (1), length 576)
    192.168.91.130 > 192.168.91.128: ICMP 10.170.109.10 unreachable - need to frag (mtu 900), length 556
	IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1028)
    192.168.91.128 > 10.170.109.10: ICMP echo request, id 52044, seq 1, length 1008

x@node-0:~$ ping -c 1 -s 1000 -M do 10.170.109.10
PING 10.170.109.10 (10.170.109.10) 1000(1028) bytes of data.
ping: local error: message too long, mtu=900

--- 10.170.109.10 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

x@node-0:~$ ip r show cache
10.170.109.10 via 192.168.91.130 dev ens32
    cache expires 559sec mtu 900

x@node-0:~$ sudo ip r flush cache

x@node-0:~$ ping -c 1 -s 1000 -M do 10.170.109.10
PING 10.170.109.10 (10.170.109.10) 1000(1028) bytes of data.
From 192.168.91.130 icmp_seq=1 Frag needed and DF set (mtu = 900)

--- 10.170.109.10 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

3.1.5. ICMPv6 PTB (Type 2, Code 0)

In ICMPv6, a special message and type code combination is used to indicate that a packet is too large for the MTU of the next hop.

This message is not a Destination Unreachable message. Recall that in IPv6, packet fragmentation is performed only by the sender of a datagram and that MTU discovery is always supposed to be used.

3.1.6. ICMPv6 Beyond Scope of Source Address (Code 2)

IPv6 uses addresses of different scopes.

Thus, it is possible to construct a packet with source and destination addresses of different scopes.
Furthermore, it is possible that the destination address may not be reachable within the same scope.

For example, a packet with a source address using link-local scope may be destined for a globally scoped destination that requires traversal of more than one router.

Because the source address is of insufficient scope, the packet is dropped by a router, and this form of ICMPv6 error is produced to indicate the problem.

3.1.7. ICMPv6 Source Address Failed Ingress/Egress Policy (Code 5)

Code 5 is a more refined version of code 1, to be used when a particular ingress or egress filtering policy is the reason for prohibiting the successful delivery of a datagram.

This might be used, for example, when a host attempts to send traffic using a source IPv6 address from an unexpected network prefix [RFC3704].

3.1.8. ICMPv6 Reject Route to Destination (Code 6)

A reject or blocking route is a special routing or forwarding table entry, which indicates that matching packets should be dropped and an ICMPv6 Destination Unreachable Reject Route message should be generated.

A similar type of entry called a blackhole route also causes matching packets to be dropped, but usually without generating the Destination Unreachable message.

3.2. Redirect (ICMPv4 Type 5, ICMPv6 Type 137)

If a router receives a datagram from a host and can determine that it is not the correct next hop for the host to have used to deliver the datagram to its destination,

the router sends a Redirect message to the host
and sends the datagram on to the correct router (or host).

That is, if it can determine that

there is a better next hop than itself for the given datagram,
it redirects the host to update its forwarding table so that future traffic for the same destination will be directed toward the new node.

This facility provides a crude form of routing protocol by indicating to the IP forwarding function where to send its packets.

Figure 3. The host incorrectly sends a datagram via R2 toward its destination. R2 realizes the host’s mistake and sends the datagram to the proper router, R1. It also informs the host of the error by sending an ICMP Redirect message. The host is expected to adjust its forwarding tables so that future datagrams to the same destination go through R1 without bothering R2.

The ICMP Redirect message includes the IP address of the router (or destination host, if it is reachable using direct delivery), a host should use as a next hop for the destination specified in the ICMP error message.

Figure 4. The ICMPv4 Redirect message includes the IPv4 address of the correct router to use as a next hop for the datagram included in the payload portion of the message. A host typically checks the IPv4 source address of the incoming Redirect message to verify that it is coming from the default router it is currently using.

x@node-0:~$ ip r
default via 192.168.91.137 dev ens32
192.168.91.0/24 dev ens32 proto kernel scope link src 192.168.91.128

x@node-0:~$ sudo sysctl net.ipv4.conf.all.accept_redirects=1
net.ipv4.conf.all.accept_redirects = 1

x@node-0:~$ ping -c 2 10.170.109.10
PING 10.170.109.10 (10.170.109.10) 56(84) bytes of data.
From 192.168.91.137: icmp_seq=1 Redirect Host(New nexthop: 192.168.91.2)
64 bytes from 10.170.109.10: icmp_seq=1 ttl=128 time=1.02 ms
64 bytes from 10.170.109.10: icmp_seq=2 ttl=128 time=1.14 ms

--- 10.170.109.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.019/1.080/1.142/0.061 ms

x@node-0:~$ ip r show cache
10.170.109.10 via 192.168.91.2 dev ens32
    cache <redirected> expires 264sec

x@node-1:~$ sudo sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

x@node-1:~$ sudo sysctl net.ipv4.conf.all.send_redirects
net.ipv4.conf.all.send_redirects = 1

x@node-1:~$ sudo sysctl net.ipv4.conf.ens32.send_redirects
net.ipv4.conf.ens32.send_redirects = 1

x@node-1:~$ ip r
default via 192.168.91.2 dev ens32
192.168.91.0/24 dev ens32 proto kernel scope link src 192.168.91.137

root@node-0:~# tcpdump -ntv host 192.168.91.128 and icmp
IP (tos 0x0, ttl 64, id 4851, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.91.128 > 10.170.109.10: ICMP echo request, id 35246, seq 1, length 64
IP (tos 0xc0, ttl 64, id 43486, offset 0, flags [none], proto ICMP (1), length 112)
    192.168.91.137 > 192.168.91.128: ICMP redirect 10.170.109.10 to host 192.168.91.2, length 92
	IP (tos 0x0, ttl 63, id 4851, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.91.128 > 10.170.109.10: ICMP echo request, id 35246, seq 1, length 64

IP (tos 0x0, ttl 63, id 4851, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.91.128 > 10.170.109.10: ICMP echo request, id 35246, seq 1, length 64
IP (tos 0x0, ttl 128, id 23335, offset 0, flags [none], proto ICMP (1), length 84)
    10.170.109.10 > 192.168.91.128: ICMP echo reply, id 35246, seq 1, length 64

IP (tos 0x0, ttl 64, id 4897, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.91.128 > 10.170.109.10: ICMP echo request, id 35246, seq 2, length 64
IP (tos 0x0, ttl 128, id 23336, offset 0, flags [none], proto ICMP (1), length 84)
    10.170.109.10 > 192.168.91.128: ICMP echo reply, id 35246, seq 2, length 64

Figure 5. The ICMPv6 Redirect message. The target address indicates the IPv6 address of a better next-hop router for the node identified by the destination address. This message can also be used to indicate that the destination address is an on-link neighbor to the node sending the message that induced the error message. In this case, the destination and target addresses are the same.

In ICMPv6, the Redirect message (type 137) contains the target address and the destination address, and it is defined in conjunction with the ND process.

The Target Address field contains the correct node’s link-local IPv6 address that should be used for the next hop.
The Destination Address is the destination IPv6 address in the datagram that evoked the redirect.

3.3. ICMP Time Exceeded (ICMPv4 Type 11, ICMPv6 Type 3)

Every IPv4 datagram has a Time-to-Live (TTL) field in its IPv4 header, and every IPv6 datagram has a Hop Limit field in its header. Any router must decrement the TTL field by at least 1.

ICMP Time Exceeded (code 0) messages are generated when a router discards a datagram because the TTL or Hop Limit field is too low (i.e., arrives with value 0 or 1 and must be forwarded).

This message is important for the proper operation of the traceroute tool (called tracert on Windows).

Figure 6. The ICMP Time Exceeded message format for ICMPv4 and ICMPv6. The message is standardized for both the TTL or hop count being exceeded (code 0) or the time for reassembling fragments exceeding some preconfigured threshold (code 1).

Another less common variant of this message is when a fragmented IP datagram only partially arrives at its destination (i.e., all its fragments do not arrive after a period of time).

In such cases, a variant of the ICMP Time Exceeded message (code 1) is used to inform the sender that its overall datagram has been discarded.

Recall that if any fragment of a datagram is dropped, the entire datagram is lost.

x@node-0:~$ sudo traceroute -I -m 2 10.170.109.10
traceroute to 10.170.109.10 (10.170.109.10), 2 hops max, 60 byte packets
 1  192.168.91.130 (192.168.91.130)  0.315 ms  0.189 ms  0.160 ms
 2  192.168.91.2 (192.168.91.2)  0.190 ms  0.173 ms  0.164 ms

root@node-0:~# tcpdump -nvv -t icmp
tcpdump: listening on ens32, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP (tos 0x0, ttl 1, id 37515, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.91.128 > 10.170.109.10: ICMP echo request, id 6913, seq 1, length 40
...
IP (tos 0x0, ttl 2, id 37518, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.91.128 > 10.170.109.10: ICMP echo request, id 6913, seq 4, length 40
...
IP (tos 0xc0, ttl 64, id 28770, offset 0, flags [none], proto ICMP (1), length 88)
    192.168.91.130 > 192.168.91.128: ICMP time exceeded in-transit, length 68
	IP (tos 0x0, ttl 1, id 37515, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.91.128 > 10.170.109.10: ICMP echo request, id 6913, seq 1, length 40
...
IP (tos 0x0, ttl 128, id 16816, offset 0, flags [none], proto ICMP (1), length 88)
    192.168.91.2 > 192.168.91.128: ICMP time exceeded in-transit, length 68
	IP (tos 0x0, ttl 1, id 37518, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.91.128 > 10.170.109.10: ICMP echo request, id 6913, seq 4, length 40
...

3.4. Parameter Problem (ICMPv4 Type 12, ICMPv6 Type 4)

ICMP Parameter Problem messages are generated by a host or router receiving an IP datagram containing some problem in its IP header that cannot be repaired.

When a datagram cannot be handled and no other ICMP message adequately describes the problem, this message acts as a sort of catchall error condition indicator.

4. ICMP Query/Informational Messages

The only remaining popular ICMP query/informational messages are the Echo Request/Response messages, more commonly called ping, and the Router Discovery messages.

Even the Router Discovery mechanism is not in wide use with IPv4, but its analog (part of Neighbor Discovery) in IPv6 is fundamental.

In addition, ICMPv6 has been extended to support Mobile IPv6 and the discovery of multicast-capable routers.

4.1. Echo Request/Reply (ping) (ICMPv4 Types 0/8, ICMPv6 Types 129/128)

One of the most commonly used ICMP message pairs is Echo Request and Echo Response (or Reply).

In ICMPv4 these are types 8 and 0, respectively, and in ICMPv6 they are types 128 and 129, respectively.

ICMP Echo Request messages may be of nearly arbitrary size (limited by the ultimate size of the encapsulating IP datagram).

With ICMP Echo Reply messages, the ICMP implementation is required to return any data received back to the sender, even if multiple IP fragments are involved.

As with other ICMP query/informational messages, the server must echo the Identifier and Sequence Number fields back in the reply.

Figure 7. Format of the ICMPv4 and ICMPv6 Echo Request and Echo Reply messages. Any optional data included in a request must be returned in a reply. NATs use the Identifier field to match requests with replies.

Implementations of ping set the Identifier field in the ICMP message to some number that the sending host can use to demultiplex returned responses.

In UNIX-based systems, for example, the process ID of the sending process is typically placed in the Identifier field.

This allows the ping application to identify the returned responses if there are multiple instances of ping running at the same time on the same host, because the ICMP protocol does not have the benefit of transport-layer port numbers.
This field is often known as the Query Identifier field when referring to firewall behavior.

When a new instance of the ping program is run, the Sequence Number field starts with the value 0 and is increased by 1 every time a new Echo Request message is sent.

ping prints the sequence number of each returned packet, allowing the user to see if packets are missing, reordered, or duplicated.

Recall that IP (and consequently ICMP) is a best-effort datagram delivery service, so any of these three conditions can occur.

ICMP does, however, include a data checksum not provided by IP.

The ping program also typically includes a copy of the local time in the optional data area of outgoing echo requests.

This time, along with the rest of the contents of the data area, is returned in an Echo Response message.
The ping program notes the current time when a response is received and subtracts the time in the reply from the current time, giving an estimate of the RTT to reach the host that was pinged.
Because only the original sender’s notion of the current time is used, this feature does not require any synchronization between the clocks at the sender and receiver.
A similar approach is used by the traceroute tool for its RTT measurements.

x@node-1:~$ sysctl net.ipv4.icmp_echo_ignore_broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 0
x@node-1:~$ ip a s ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 900 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:85:26:07 brd ff:ff:ff:ff:ff:ff
    inet 192.168.91.130/24 brd 192.168.91.255 scope global dynamic ens32
       valid_lft 1780sec preferred_lft 1780sec

x@node-0:~$ sudo ip neigh flush all

x@node-0:~$ ping -c 2 -b 192.168.91.255 # ICMPv4 Echo Request to the subnet broadcast address.
WARNING: pinging broadcast address
PING 192.168.91.255 (192.168.91.255) 56(84) bytes of data.
64 bytes from 192.168.91.2: icmp_seq=1 ttl=128 time=0.449 ms
64 bytes from 192.168.91.130: icmp_seq=1 ttl=64 time=0.480 ms
64 bytes from 192.168.91.2: icmp_seq=2 ttl=128 time=0.436 ms

--- 192.168.91.255 ping statistics ---
2 packets transmitted, 2 received, +1 duplicates, 0% packet loss, time 1008ms
rtt min/avg/max/mdev = 0.436/0.455/0.480/0.018 ms

root@node-0:~# tcpdump -tnv icmp
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.91.128 > 192.168.91.255: ICMP echo request, id 17779, seq 1, length 64
IP (tos 0x0, ttl 128, id 17587, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.91.2 > 192.168.91.128: ICMP echo reply, id 17779, seq 1, length 64
IP (tos 0x0, ttl 64, id 55593, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.91.130 > 192.168.91.128: ICMP echo reply, id 17779, seq 1, length 64
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.91.128 > 192.168.91.255: ICMP echo request, id 17779, seq 2, length 64
IP (tos 0x0, ttl 128, id 17588, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.91.2 > 192.168.91.128: ICMP echo reply, id 17779, seq 2, length 64
IP (tos 0x0, ttl 64, id 55720, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.91.130 > 192.168.91.128: ICMP echo reply, id 17779, seq 2, length 64

4.2. Router Discovery: Router Solicitation and Advertisement (ICMPv4 Types 9, 10)

DHCP can be used for a host to acquire an IP address and learn about the existence of nearby routers.

An alternative option for learning about routers is called Router Discovery (RD).

Although specified for configuring both IPv4 and IPv6 hosts, it is not widely used with IPv4 because of widespread preference for DHCP.

Router Discovery for IPv4 is accomplished using a pair of ICMPv4 informational messages [RFC1256]: Router Solicitation (RS, type 10) and Router Advertisement (RA, type 9).

First, they are periodically multicast on the local network (using TTL = 1) to the All Hosts multicast address (224.0.0.1),
and they are also provided to hosts on demand that ask for them using RS messages. RS messages are sent using multicast to the All Routers multicast address (224.0.0.2).

The primary purpose of Router Discovery is for a host to learn about all the routers on its local subnetwork, so that it can choose a default route among them.

It is also used to discover the presence of routers that are willing to act as Mobile IP home agents.

4.3. Multicast Listener Query/Report/Done (ICMPv6 Types 130/131/132)

Multicast Listener Discovery (MLD) [RFC2710][RFC3590] provides management of multicast addresses on links using IPv6. It is similar to the IGMP protocol used by IPv4.

Figure 8. ICMPv6 MLD version 1 messages are all of this form.Queries (type 130) are either general or multicast-address-specific. General queries ask hosts to report which multicast addresses they have in use, and address-specific queries are used to determine if a specific address is (still) in use. The maximum response time gives the maximum number of milliseconds a host may delay sending a report in response to a query. The destination multicast address is 0 for general queries and the multicast address in question for specific reports. For Report (type 131) and Done messages (type 132), it includes the address related to the report or what address is no longer of interest, respectively.

The main purpose of MLD is for multicast routers to learn the multicast addresses used by the hosts on each link to which they are mutually attached.

MLDv2 extends this capability by allowing hosts to specify particular hosts from which they wish to (or not to) receive traffic.

Two forms of MLD queries (type 130) are sent by multicast routers: general queries and multicast-address-specific queries.

Generally, routers send the query messages and hosts respond with reports, either in response to the queries, or unsolicited if a host’s multicast address membership changes.

The Maximum Response Time field, nonzero only in queries, gives the maximum number of milliseconds a host may delay sending a report in response to a query.

The Multicast Address field is 0 for general queries and the address for which the router is interested in reports otherwise.

For MLD Report messages (type 131) and MLD Done messages (type 132) it includes the address related to the report or what address is no longer of interest, respectively.

4.4. Version 2 Multicast Listener Discovery (MLDv2) (ICMPv6 Type 143)

MLDv2 extends the MLD Query message with additional information pertaining to specific sources. The first 24 bytes of the message are identical to the common MLD format.

5. Neighbor Discovery in IPv6

The Neighbor Discovery Protocol in IPv6 (sometimes abbreviated as NDP or ND) [RFC4861] brings together the Router Discovery and Redirect mechanisms of ICMPv4 with the address-mapping capabilities provided by ARP.

It is also specified for use in supporting Mobile IPv6.

In contrast to ARP and IPv4, which generally use broadcast addressing (except for Router Discovery), ICMPv6 makes extensive use of multicast addressing, at both the network and link layers. (Recall that IPv6 does not even have broadcast addresses.)

ND is designed to allow nodes (routers and hosts) on the same link or segment to find each other, determine if they have bidirectional connectivity, and determine if a neighbor has become inoperative or unavailable. It also supports stateless address autoconfiguration. All of the ND functionality is provided by ICMPv6 at or above the network layer, making it largely independent of the particular link-layer technology employed underneath. However, ND does prefer to make use of link-layer multicast capabilities, and for this reason operation on non-broadcast- and non-multicast-capable link layers (called non-broadcast multiple access or NBMA links) may differ somewhat.

The two main parts of ND are

Neighbor Solicitation/Advertisement (NS/NA), which provides the ARP-like function of mapping between network- and link-layer addresses,
and Router Solicitation/Advertisement (RS/RA), which provides the functions of router discovery, Mobile IP agent discovery, and redirects, as well as some support for autoconfiguration.

A secure variant of ND called SEND [RFC3971] adds authentication and special forms of addressing, primarily by introducing additional ND options.

ND messages are ICMPv6 messages sent using an IPv6 Hop Limit field value of 255. Receivers verify that incoming ND messages have this value to protect against off-link senders that may attempt to spoof local ICMPv6 messages (such messages would arrive with values less than 255).

5.1. ICMPv6 Router Solicitation and Advertisement (ICMPv6 Types 133, 134)

Router Advertisement (RA) messages indicate the presence and capabilities of a nearby router.

They are sent periodically by routers, or in response to a Router Solicitation (RS) message.

Figure 9. The ICMPv6 Router Solicitation message is very simple but ordinarily contains a Source Link-Layer Address option (unlike its ICMPv4 counterpart). It may also contain an MTU option if an unusual MTU value is in use on the link.

The RS message is used to induce on-link routers to send RA messages. RS messages are sent to the All Routers multicast address, ff02::2. A Source Link-Layer Address option is supposed to be included if the sender of the message is using an IPv6 address other than the unspecified address (used during autoconfiguration). It is the only valid option for such messages as of [RFC4861].

Figure 10. An ICMPv6 Router Advertisement message is sent to the All Nodes multicast address (ff02::1). Receiving nodes check to make sure that the Hop Limit field is 255, ensuring that the packet has not been forwarded through a router. The message includes three flags: M (Managed address configuration), O (Other stateful configuration), and H (Home Agent).

The Router Advertisement (RA) message is sent by routers to the All Nodes multicast address (ff02::1) or the unicast address of the requesting host, if the advertisement is sent in response to a solicitation. RA messages inform local hosts and other routers of configuration details relevant to the local link.

5.2. ICMPv6 Neighbor Solicitation and Advertisement (IMCPv6 Types 135, 136)

The Neighbor Solicitation (NS) message in ICMPv6 effectively replaces the ARP Request messages used with IPv4.

Its primary purpose is to convert IPv6 addresses to link-layer addresses.

When used to determine address mappings, it is sent to the Solicited-Node multicast address corresponding to the IPv6 address contained in the Target Address field (prefix f02::1:f/104, combined with the low-order 24 bits of the solicited IPv6 address).
However, it is also used for detecting whether nearby nodes can be reached, and if they can be reached bidirectionally (that is, whether the nodes can talk to each other).

When this message is used to determine connectivity to a neighbor, it is sent to that neighbor’s IPv6 unicast address instead of the Solicited-Node address.

Figure 11. The ICMPv6 Neighbor Solicitation message is similar to the RS message but contains a target IPv6 address. These messages are sent to Solicited-Node multicast addresses to provide ARP-like functionality and to unicast addresses to test reachability to other nodes. NS messages contain a Source Link-Layer Address option on links that use lower-layer addressing.

The NS message contains the IPv6 address for which the sender is trying to learn the link-layer address.

The message may contain the Source Link-Layer Address option.

This option must be included in networks that use link-layer addressing when the solicitation is sent to a multicast address and should be included for unicast solicitations.
If the sender of the message is using the unspecified address as its source address (e.g., during duplicate address detection), this option is not to be included.

Figure 12. The ICMPv6 Neighbor Advertisement message contains the following flags: R indicates that the sender is a router, S indicates that the advertisement is a response to a solicitation, and O indicates that the message contents should override other cached address mappings. The Target Address field contains the IPv6 address of the sender of the message (generally, the unicast address of the solicited node from the ND solicitation). A Target Link-Layer Address option is included to enable ARP-like functionality for IPv6.

The ICMPv6 Neighbor Advertisement (NA) message serves the purpose of the ARP Response message in IPv4 in addition to helping with neighbor unreachability detection .

It is either sent as a response to an NS message or sent asynchronously when a node’s IPv6 address changes.

It is sent either to
- the unicast address of the soliciting node,
- or to the All Nodes multicast address if the soliciting node used the unspecified address as its source address.
The R (Router) field indicates that the sender of the message is a router.

This could change, for example, if a router ceases being a router and becomes only a host instead.
The S (Solicited) field indicates that the advertisement is in response to a solicitation received earlier.

This field is used to verify that bidirectional connectivity between neighbors has been achieved.
The O (Override) field indicates that information in the advertisement should override any previously cached information the receiver of the message has.

It is not supposed to be set for solicited advertisements, for anycast addresses, or in solicited proxy advertisements.

It is supposed to be set in other (solicited or unsolicited) advertisements.
For solicited advertisements, the Target Address field is the IPv6 address being looked up.

For unsolicited advertisements, it is the IPv6 address that corresponds to a link-layer address that has changed.

This message must contain the Target Link-Layer Address option on networks that support link-layer addressing when the advertisement was solicited via a multicast address.

x@node-0:~$ sudo ip -6 n flush all
x@node-0:~$ ping -c 1 -I fe80::20c:29ff:fe8c:df3f%ens32 fe80::20c:29ff:fe85:2607
PING fe80::20c:29ff:fe85:2607(fe80::20c:29ff:fe85:2607) from fe80::20c:29ff:fe8c:df3f%ens32 ens32: 56 data bytes
64 bytes from fe80::20c:29ff:fe85:2607%ens32: icmp_seq=1 ttl=64 time=9.09 ms

--- fe80::20c:29ff:fe85:2607 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.085/9.085/9.085/0.000 ms

root@node-0:~# tcpdump -tvvn -s1500 -p icmp6
tcpdump: listening on ens32, link-type EN10MB (Ethernet), snapshot length 1500 bytes
IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:29ff:fe8c:df3f > ff02::1:ff85:2607: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::20c:29ff:fe85:2607
	  source link-address option (1), length 8 (1): 00:0c:29:8c:df:3f
	    0x0000:  000c 298c df3f
IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:29ff:fe85:2607 > fe80::20c:29ff:fe8c:df3f: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:29ff:fe85:2607, Flags [solicited, override]
	  destination link-address option (2), length 8 (1): 00:0c:29:85:26:07
	    0x0000:  000c 2985 2607
IP6 (flowlabel 0x1bc9d, hlim 64, next-header ICMPv6 (58) payload length: 64) fe80::20c:29ff:fe8c:df3f > fe80::20c:29ff:fe85:2607: [icmp6 sum ok] ICMP6, echo request, id 36469, seq 1
IP6 (flowlabel 0xfb479, hlim 64, next-header ICMPv6 (58) payload length: 64) fe80::20c:29ff:fe85:2607 > fe80::20c:29ff:fe8c:df3f: [icmp6 sum ok] ICMP6, echo reply, id 36469, seq 1
IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:29ff:fe85:2607 > fe80::20c:29ff:fe8c:df3f: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::20c:29ff:fe8c:df3f
	  source link-address option (1), length 8 (1): 00:0c:29:85:26:07
	    0x0000:  000c 2985 2607
IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::20c:29ff:fe8c:df3f > fe80::20c:29ff:fe85:2607: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::20c:29ff:fe8c:df3f, Flags [solicited]

5.3. ICMPv6 Inverse Neighbor Discovery Solicitation/Advertisement (ICMPv6 Types 141/142)

The Inverse Neighbor Discovery (IND) facility in IPv6 [RFC3122] originated from a need to determine IPv6 addresses given link-layer addresses on Frame Relay networks.

It resembles reverse ARP, a protocol once used with IPv4 networks primarily for supporting diskless computers.

Its main function is to ascertain the networklayer address(es) corresponding to a known link-layer address.

Figure 13. The ICMPv6 IND Solicitation (type 141) and Advertisement (type 142) messages have the same basic format. They are used to map known link-layer addresses to IPv6 addresses in environments where this is useful.

The IND Solicitation message is sent to the All Nodes multicast address at the IPv6 layer but is encapsulated in a unicast link-layer address (the one being looked up).
It must contain both a Source Link-Layer Address option and a Destination Link-Layer Address option.
It may also contain a Source/Target Address List option and/or an MTU option.

5.4. Neighbor Unreachability Detection (NUD)

One of the important features of ND is to detect when reachability between two systems on the same link has become lost or asymmetric (i.e., is not available in both directions).

This is accomplished using the Neighbor Unreachability Detection (NUD) algorithm. It is used to manage the neighbor cache present on each node.

The neighbor cache is analogous to the ARP cache; it is a (conceptual) data structure that holds the IPv6-to-link-layer-address mapping information required to perform direct delivery of IPv6 datagrams to on-link neighbors as well as information regarding the state of the mapping.

Figure 14. Neighbor Unreachability Detection helps maintain the neighbor cache consisting of several neighbor entries. Each entry is in one of five states at any given time. Confirmations of reachability are accomplished by receiving Neighbor Advertisement messages or using other higher-layer protocol information, if available. Unsolicited evidence includes unsolicited Neighbor and Router Advertisement messages.

Each mapping may be in one of five states: INCOMPLETE, REACHABLE, STALE, DELAY, or PROBE.

The transition diagram shows the initial states to be either INCOMPLETE or STALE.
When an IPv6 node has a unicast datagram to send to a destination, it checks its destination cache to see if an entry corresponding to the destination is present.
- If so, and the destination is on-link, the neighbor cache is consulted to see if the neighbor’s state is REACHABLE.
  
  If so, the datagram is sent using direct delivery.
- If no neighbor cache entry is present but the destination appears to be on-link, NUD enters the INCOMPLETE state and sends an NS message.
  
  Successful receipt of a solicited NA message provides confirmation that the node is reachable, and the entry enters the REACHABLE state.
The STALE state corresponds to apparently valid entries that have not yet been confirmed.

This state is entered
- when either an entry has not been updated for some time when it was previously REACHABLE,
- or when unsolicited information is received (e.g., a node has changed its address and sent an unsolicited NA message).
  
  These cases suggest that reachability is possible, but confirmation in the form of a valid NA is still required.
The other states, DELAY and PROBE, are temporary states.
- DELAY is used when a packet is sent but ND has no current evidence to suggest that reachability is possible.
  
  The state gives upper-layer protocols an opportunity to provide additional evidence.
- If after DELAY_FIRST_PROBE_TIME seconds (the constant 5) no evidence is received, the state changes to PROBE.
- In the PROBE state, ND sends periodic NS messages (every RetransTimer milliseconds, with constant default value RETRANS_ TIMER equal to 1000).
  
  If no evidence has been received after sending MAX_UNICAST_SOLICIT NS messages (default 3), the entry is supposed to be deleted.

x@node-0:~$ sudo  ip -6 n flush all

x@node-0:~$ ping -c 1 -6 ff02::1%ens32
PING ff02::1%ens32(ff02::1%ens32) 56 data bytes
64 bytes from fe80::20c:29ff:fe8c:df3f%ens32: icmp_seq=1 ttl=64 time=0.022 ms

--- ff02::1%ens32 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.022/0.022/0.022/0.000 ms

x@node-0:~$ ip -6 n
fe80::20c:29ff:fe85:2607 dev ens32 lladdr 00:0c:29:85:26:07 DELAY

x@node-0:~$ ip -6 n
fe80::20c:29ff:fe85:2607 dev ens32 lladdr 00:0c:29:85:26:07 REACHABLE

x@node-0:~$ ip -6 n
fe80::20c:29ff:fe85:2607 dev ens32 lladdr 00:0c:29:85:26:07 STALE

root@node-0:~# tcpdump -tnvv icmp6 -i ens32
tcpdump: listening on ens32, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP6 (flowlabel 0xc865c, hlim 1, next-header ICMPv6 (58) payload length: 64) fe80::20c:29ff:fe8c:df3f > ff02::1: [icmp6 sum ok] ICMP6, echo request, id 52700, seq 1
IP6 (flowlabel 0x3ad83, hlim 64, next-header ICMPv6 (58) payload length: 64) fe80::20c:29ff:fe85:2607 > fe80::20c:29ff:fe8c:df3f: [icmp6 sum ok] ICMP6, echo reply, id 52700, seq 1
IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:29ff:fe85:2607 > fe80::20c:29ff:fe8c:df3f: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::20c:29ff:fe8c:df3f
	  source link-address option (1), length 8 (1): 00:0c:29:85:26:07
	    0x0000:  000c 2985 2607
IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::20c:29ff:fe8c:df3f > fe80::20c:29ff:fe85:2607: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::20c:29ff:fe8c:df3f, Flags [solicited]
IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:29ff:fe8c:df3f > fe80::20c:29ff:fe85:2607: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::20c:29ff:fe85:2607
	  source link-address option (1), length 8 (1): 00:0c:29:8c:df:3f
	    0x0000:  000c 298c df3f
IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::20c:29ff:fe85:2607 > fe80::20c:29ff:fe8c:df3f: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::20c:29ff:fe85:2607, Flags [solicited]

root@node-1:~# ip a show ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:85:26:07 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20c:29ff:fe85:2607/64 scope link
       valid_lft forever preferred_lft forever

root@node-1:~# ip link set ens32 down && ip link set ens32 address 00:0c:29:85:26:10 && ip link set ens32 up

root@node-1:~# ip a show ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:85:26:10 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20c:29ff:fe85:2610/64 scope link
       valid_lft forever preferred_lft forever

x@node-0:~$ ping -c 1 fe80::20c:29ff:fe85:2607%ens32
PING fe80::20c:29ff:fe85:2607%ens32(fe80::20c:29ff:fe85:2607%ens32) 56 data bytes
From fe80::20c:29ff:fe8c:df3f%ens32 icmp_seq=1 Destination unreachable: Address unreachable

--- fe80::20c:29ff:fe85:2607%ens32 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

x@node-0:~$ ip -6 n
fe80::20c:29ff:fe85:2607 dev ens32  FAILED

5.5. ICMPv6 Neighbor Discovery (ND) Options

ND messages may contain zero or more options, and some options can occur more than once. However, with certain messages some of the options are mandatory.

Figure 15. ND options are variable-length and begin with a common TLV arrangement. The Length field gives the total length of the option in 8-byte units (including the Type and Length fields).

All ND options start with an 8-bit Type and an 8-bit Length field, supporting options of variable length, up to 255 bytes.
Options are padded to 8-byte boundaries, and the Length field gives the total length of the option in 8-byte units.
The Type and Length fields are included in the value of the Length field, which has a minimum value of 1.

Table 5. IPv6 ND option types, defining reference, use, and description
Type	Name	Reference	Use/Comment
1	Source Link-Layer Address	[RFC4861]	Sender’s link-layer address; used with NS, RS, and RA messages
2	Target Link-Layer Address	[RFC4861]	Target’s link-layer address; used with NA and Redirect messages
3	Prefix Information	[RFC4861] [RFC6275]	An IPv6 prefix or address; used with RA messages
4	Redirected Header	[RFC4861]	Portion of original IPv6 datagram; used with Redirect messages
5	MTU	[RFC4861]	Recommended MTU; used with RA messages, IND Advertisement messages
6	NMBA Shortcut Limit	[RFC2491]	Hop limit for "shortcut attempt"; used with NS messages
7	Advertisement Interval	[RFC6275]	Sending interval of unsolicited RA messages; used with RA messages
8	Home Agent Information	[RFC6275]	Preference and lifetime to be an MIPv6 HA; used with RA messages (H bit on)
9	Source Address List	[RFC3122]	Host’s addresses; used with IND messages
10	Target Address List	[RFC3122]	Target addresses; used with IND messages
11	CGA	[RFC3971]	Crypto-based address; used with secure Neighbor Discovery (SEND) messages
12	RSA Signature	[RFC3971]	Credential for host signature (SEND)
13	Timestamp	[RFC3971]	Anti-replay timestamp (SEND)
14	Nonce	[RFC3971]	Anti-replay random number (SEND)
15	Trust Anchor	[RFC3971]	Indicates credential type (SEND)
16	Certificate	[RFC3971]	Encodes a certificate (SEND)
17	IP Address/Prefix	[RFC5568]	Care-of or NAR addresses; used with FMIPv6 PrRtAdv messages
19	Link-Layer Address	[RFC5568]	Desired next access point or mobile node’s address; used with FMIPv6 RtSolPr or PrRtAdv messages
20	Neighbor Advertisement ACK	[RFC5568]	Tells mobile about next valid CoA; used with RA messages
24	Route Information	[RFC4191]	Route prefix/preferred router list
25	Recursive DNS Server	[RFC6106]	IP address of DNS server; added to RA messages
26	RA Flags Extension	[RFC5175]	Expands space for RA flags
27	Handover Key Request	[RFC5269]	FMIPv6—request key using SEND
28	Handover Key Reply	[RFC5269]	FMIPv6—key reply using SEND
31	DNS Search List	[RFC6106]	DNS domain search names; added to RA messages
253, 254	Experimental	[RFC4727]	[RFC3692]-style experiments 1/2

References

[1] Kevin Fall, W. Stevens TCP/IP Illustrated: The Protocols, Volume 1. 2nd edition, Addison-Wesley Professional, 2011