Traceroute IPv6: traceroute -6 vs ping6 for Diagnosing IPv6 Network Routes

Use traceroute -6 when you need to see where an IPv6 path slows, changes, or fails; use ping6 when you only need to confirm that a host answers. IPv6 routing problems often hide between those two facts. A server can reply to ping while one transit hop is dropping traffic, rate limiting probes, or sending packets through a poor route. IPv6 also uses a fixed 40 octet base header, which affects packet handling and diagnostics [source: RFC 8200].

What ping6 actually proves

ping6 sends ICMPv6 Echo Request packets and waits for Echo Reply packets. That is useful, fast, and simple. If replies come back, the destination is alive enough to respond. If they do not, something is wrong, but the command rarely tells you where.

On many current Linux systems, ping6 is just a compatibility name for ping -6. The result is the same. You can still use it in scripts, but newer documentation often favors ping -6.

A typical command looks like this:

ping6 2001:4860:4860::8888

or:

ping -6 2001:4860:4860::8888

The output gives you key measurements:

• Reachability: did the target reply?
• Round trip time: how long did replies take?
• Packet loss: how many probes failed?
• Jitter: how much latency changes between replies.

That is enough for basic monitoring. It is not enough for route diagnosis. Honestly, it feels like ping gets too much credit in outage calls. A clean ping can make a path look healthy while real traffic still suffers from MTU trouble, filtering, asymmetric routing, or a bad upstream handoff.

What traceroute -6 shows that ping does not

traceroute -6 maps the route to an IPv6 destination by sending probes with increasing Hop Limit values. Hop Limit is the IPv6 version of TTL. Each router that decrements the value to zero should return an ICMPv6 Time Exceeded message. That reply identifies a hop on the route.

A basic command looks like this:

traceroute -6 2001:4860:4860::8888

The result lists hops, response times, and sometimes hostnames. If a hop does not answer, you may see asterisks:

 7  2001:db8:7::1     18.4 ms  18.1 ms  18.3 ms
 8  *                 *        *
 9  2001:db8:9::1     141.2 ms 139.8 ms 140.5 ms

This does not always mean hop 8 is broken. It may simply refuse to answer traceroute probes. Routers often rate limit diagnostic traffic to protect the control plane. Still, the pattern matters. If hops after it respond, the packet passed through.

ICMPv6 is not just a troubleshooting extra. It is part of how IPv6 reports errors, including Time Exceeded messages used by traceroute [source: RFC 4443]. Blocking all ICMPv6 is a common self-inflicted wound. It can break Path MTU Discovery and create strange failures where small pings work but application traffic stalls.

traceroute -6 vs ping6: the practical difference

ping6 answers the question: “Can I reach the target?”

traceroute -6 answers the better question during an incident: “Where does the path behave badly?”

Task	Best tool	Reason
Check if an IPv6 host replies	ping6	Fast reachability test with latency and loss.
Find the failing hop	traceroute -6	Shows each visible router on the path.
Measure simple packet loss	ping6	Easy to run for 50 or 100 probes.
Spot route changes	traceroute -6	Compares hop sequence over time.
Test firewall behavior	Both	Different probe types may be allowed or blocked.

Common traps that waste time

Asterisks are not always outages. A router can forward traffic while ignoring probes. Do not stop at the first * * *. Look at later hops.

Reverse DNS can slow the test. It drives me crazy that a route check can take 10 seconds longer just because the tool waits on name lookups. Use -n to skip DNS and print addresses only:

traceroute -6 -n 2001:4860:4860::8888

IPv6 paths may differ from IPv4 paths. Do not assume traceroute and traceroute -6 cross the same providers. They often do not.

Firewalls may treat probe types differently. Traditional traceroute often uses UDP probes. Some networks block these but allow ICMPv6 Echo. Try ICMP mode if available:

traceroute -6 -I 2001:4860:4860::8888

Some versions also support TCP probes:

traceroute -6 -T -p 443 example.com

That can be useful when testing a web service path because TCP 443 may pass through security gear that drops UDP probes.

A realistic troubleshooting workflow

Start with a simple reachability test:

ping6 -c 10 target.example.com

If packet loss is 0% and latency is stable, check the application next. If latency is high, unstable, or packet loss appears, run traceroute:

traceroute -6 -n target.example.com

Compare the first bad hop with your network boundary. If the delay starts inside your own network, check local routers, ACLs, CPU load, and interface errors. If it starts after your ISP handoff, gather evidence before opening a ticket. Include timestamps, source address, destination address, traceroute output, and ping statistics.

Run the test from both directions if possible. IPv6 routing can be asymmetric. The path from client to server may not match the path back. A server side traceroute can expose a return path issue that the client side test cannot see.

When to use each command

• Use ping6 for quick checks, monitoring probes, packet loss samples, and latency baselines.
• Use traceroute -6 for route visibility, slow hop detection, suspected ISP issues, and path changes.
• Use both when users report “the site is slow” but uptime checks look green.

For a clean report, avoid vague statements such as “IPv6 is broken.” Say: “From 2001:db8:100::25 to 2001:db8:200::10, ping shows 8% loss over 100 probes, and traceroute shows delay rising from 21 ms to 167 ms after hop 11.” That wording is harder to dismiss.

Final guidance

ping6 is the smoke alarm. traceroute -6 is the hallway camera. One tells you something may be wrong. The other helps you see where the trouble begins. For serious IPv6 diagnostics, use ping6 first, then confirm the path with traceroute -6, preferably with DNS disabled and multiple probe types when filtering is suspected.