Understanding ICMPv6 and the Complete Ping6 Process

This article provides a detailed explanation of the ICMPv6 protocol and the full lifecycle of a ping6 operation. It begins with an overview of ICMPv6, describing its role as a fundamental IPv6 protocol for reporting errors and providing control information.

The article then outlines the ICMPv6 message format, highlighting fields such as Type, Code, and Checksum, and explains that ICMPv6 operates at the network layer of the OSI model, encapsulated within an IPv6 header.

Next, the different categories of ICMPv6 error messages are described:

Destination Unreachable (Type 1) with various Code values.

Packet Too Big (Type 2, Code 0) used for Path MTU discovery.

Time Exceeded (Type 3) with codes for hop limit expiration and fragment reassembly timeout.

Parameter Problem (Type 4) with codes for header errors, unrecognizable NextHeader values, and unknown options.

The article also covers ICMPv6 informational messages, focusing on Echo Request (Type 128) and Echo Reply (Type 129), which constitute the ping6 packets.

Following the theory, the article walks through a step‑by‑step illustration of a ping6 transaction between two cloud virtual machines (CVM1 and CVM2). Each step is accompanied by diagrams and explains the actions performed at each OSI layer:

Creation of a 56‑byte Echo Request payload.

Encapsulation of the payload with the ICMPv6 header.

Encapsulation of the ICMPv6 packet within an IPv6 header, specifying source and destination IPv6 addresses.

Routing decision: the destination address is not on the local subnet, so the default route ::/0 is used.

Link‑layer framing: source MAC is the interface’s MAC; destination MAC is resolved via the IPv6 neighbor table.

Neighbor Solicitation (NS) is sent (Type 135, Code 0) to discover the destination MAC, analogous to an ARP request in IPv4.

The virtual gateway replies with a Neighbor Advertisement (NA) (Type 136, Code 0), providing the destination MAC address.

With the MAC address known, the Echo Request is finally transmitted on the link layer.

The request traverses the overlay network tunnels between virtual gateways A and B.

The destination VM receives the frame, passes it to the IPv6 stack, and validates the packet.

The IPv6 stack processes the Echo Request and generates an Echo Reply (Type 129, Code 0).

The reply follows the reverse path, undergoing the same routing, neighbor resolution, and link‑layer encapsulation steps.

The reply reaches the original sender after traversing the virtual gateways.

Both VMs cache the IPv6‑to‑MAC mapping, eliminating the need for further NS/NA exchanges for subsequent packets.

The article concludes with screenshots of the ping6 command output and packet captures, illustrating a successful ping6 exchange and reinforcing the described process.