How to Diagnose IPv6 Failures Using Ping, Traceroute, and DNS Lookup Tools

When an IPv6-related outage strikes, your monitoring dashboard tells you that something failed. The next question is where and why. Automated monitoring from UptyBots catches the problem quickly, but resolving it requires the kind of targeted diagnosis that command-line tools provide. This guide walks through the three essential diagnostic tools for IPv6 troubleshooting: ping, traceroute, and DNS lookups. You will learn not just how to run each command, but how to interpret the output and map it to specific failure types.

If you are not yet monitoring IPv4 and IPv6 separately, start with our guide on setting up dual-stack uptime checks. The commands below become most useful when you already know which protocol is failing.

Step 1: Verify Basic Reachability with IPv6 Ping

The first diagnostic step for any connectivity issue is the simplest: can you reach the target host at all? IPv6 ping sends ICMPv6 Echo Request packets to the destination and waits for Echo Reply packets. The command syntax differs slightly across operating systems:

Linux and macOS

ping6 example.com

On modern Linux systems, you can also use ping -6:

ping -6 example.com

Windows

ping -6 example.com

Pinging a specific IPv6 address

If you already know the IPv6 address (from DNS or your server configuration), you can ping it directly. This bypasses DNS resolution and tests only the network path:

ping6 2001:db8::1

Interpreting ping results

A successful ping looks like this:

PING6(56=40+8+8 bytes) 2001:db8::100 --> 2001:db8::1
16 bytes from 2001:db8::1, icmp_seq=0 hlim=64 time=1.234 ms
16 bytes from 2001:db8::1, icmp_seq=1 hlim=64 time=1.156 ms
16 bytes from 2001:db8::1, icmp_seq=2 hlim=64 time=1.289 ms

Pay attention to these fields:

• time (latency): The round-trip time in milliseconds. Compare this to your IPv4 ping to the same host. Significantly higher IPv6 latency suggests the IPv6 traffic is taking a longer routing path.
• hlim (hop limit): The IPv6 equivalent of TTL. A much lower hop limit than expected indicates many intermediate routers, which can mean suboptimal routing.
• packet loss: Any packet loss on IPv6 while IPv4 shows zero loss points to an IPv6-specific network issue.

Common failure scenarios

Important caveat: Many servers intentionally block ICMPv6 echo requests for security reasons. A failed ping6 does not always mean the server is down. It may mean ICMP is filtered. This is why ping monitoring alone is not enough. Always follow up with HTTP or TCP checks if ping fails.

Step 2: Trace the Network Path with Traceroute6

When ping confirms a problem, traceroute tells you where in the network path the failure occurs. It works by sending packets with incrementally increasing hop limits, causing each router along the path to respond in turn.

Running traceroute

# Linux / macOS
traceroute6 example.com

# Alternative on Linux
traceroute -6 example.com

# Windows
tracert -6 example.com

Reading traceroute output

A typical traceroute6 output looks like:

traceroute6 to example.com (2001:db8::1) from 2001:db8::100, 30 hops max
 1  gateway.local (fd00::1)  0.584 ms  0.412 ms  0.398 ms
 2  isp-router.example.net (2001:db8:1::1)  3.217 ms  2.984 ms  3.102 ms
 3  core-router.transit.net (2001:db8:2::1)  8.456 ms  8.321 ms  8.512 ms
 4  * * *
 5  * * *
 6  * * *

Each line represents one hop (router) along the path. The three time values show the round-trip latency for three successive probes to that hop. Here is how to interpret specific patterns:

• Stars (* * *) at a specific hop: That router is not responding to traceroute probes. This can mean the router is configured to not respond (common and not necessarily a problem) or that traffic is being dropped at this point.
• Stars from a specific hop onward: If every hop after hop N shows stars, traffic is likely being dropped at or just after hop N. This is the classic firewall-blocked or routing-hole signature.
• Sudden latency spike: A jump from 5 ms to 150 ms between two hops indicates a geographic hop (e.g., traffic crossing the Atlantic) or congestion at that transit point.
• Latency decrease after a spike: This is normal. Some routers have slow ICMP response generation but forward actual data traffic quickly. The spike is in the router's response, not in the data path.

Comparing IPv4 and IPv6 traceroutes

One of the most powerful diagnostic techniques is running both traceroutes side by side:

# IPv4 path
traceroute example.com

# IPv6 path
traceroute6 example.com

Compare the results. You will often discover that:

• IPv4 and IPv6 take completely different paths through different transit providers.
• IPv6 may traverse more hops because peering arrangements are less established.
• IPv6 traffic may exit your ISP to a different upstream provider, one that has issues reaching your server's network.
• The IPv6 path may cross geographic regions that the IPv4 path avoids entirely.

This comparison often reveals the root cause of IPv6-specific performance issues or timeouts that separate IPv4/IPv6 monitoring initially detected.

TCP traceroute for firewalled hosts

If the target server blocks ICMP (making standard traceroute useless), use TCP traceroute to probe a port you know is open:

# TCP traceroute to port 443 over IPv6 (requires root)
sudo tcptraceroute -6 example.com 443

# Alternative using nmap (if tcptraceroute is unavailable)
sudo nmap -6 --traceroute -p 443 example.com

TCP traceroute is especially useful for diagnosing issues where the server responds on IPv4 port 443 but not on IPv6 port 443, because it tests the exact same port and protocol that real HTTPS traffic uses.

Step 3: Investigate DNS Resolution

Many IPv6 failures originate in DNS. If the AAAA record is missing, stale, or pointing to the wrong address, no amount of network debugging will help because the client never gets the correct destination address in the first place.

Using dig for AAAA records

# Query the AAAA record
dig AAAA example.com

# Short form (address only)
dig AAAA example.com +short

# Query a specific nameserver
dig AAAA example.com @8.8.8.8

# Query with full details including TTL
dig AAAA example.com +noall +answer

A healthy response includes an ANSWER section with the IPv6 address and its TTL (time-to-live):

;; ANSWER SECTION:
example.com.    300    IN    AAAA    2001:db8::1

Using nslookup (Windows-friendly)

nslookup -type=AAAA example.com
nslookup -type=AAAA example.com 8.8.8.8

What to look for in DNS results

Checking propagation across multiple resolvers

DNS answers can differ depending on which resolver you query. To check propagation, query several public resolvers:

# Google Public DNS
dig AAAA example.com @8.8.8.8 +short

# Cloudflare DNS
dig AAAA example.com @1.1.1.1 +short

# Quad9
dig AAAA example.com @9.9.9.9 +short

# Your ISP's resolver (default)
dig AAAA example.com +short

If results differ, the DNS change has not fully propagated. UptyBots detects this automatically through its multi-location monitoring, where probes in different regions resolve DNS independently and will show different results if propagation is incomplete.

Step 4: Test HTTP/HTTPS Connectivity Over IPv6

Ping and traceroute test ICMP reachability, but your actual service runs over TCP. A host can respond to ping over IPv6 while failing to serve HTTP. Use curl to test the actual application layer:

# Force curl to use IPv6
curl -6 -I https://example.com

# Verbose output showing connection details
curl -6 -v https://example.com 2>&1 | head -30

# Test with a specific timeout (10 seconds)
curl -6 --connect-timeout 10 -I https://example.com

# Show timing breakdown
curl -6 -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.com

The timing breakdown is especially valuable. Compare it with the IPv4 version:

# IPv4 timing
curl -4 -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.com

# IPv6 timing
curl -6 -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.com

If the IPv6 connection is significantly slower at the DNS or connect phase, the issue is in the network path. If the TLS phase is slow or fails, the issue is with the SSL configuration on the IPv6 socket.

Common curl error messages for IPv6 failures

• curl: (6) Could not resolve host -- No AAAA record in DNS.
• curl: (7) Failed to connect to example.com port 443: Connection refused -- The server is not listening on IPv6 port 443.
• curl: (7) Failed to connect to example.com port 443: Network is unreachable -- Your local machine has no IPv6 route to the internet.
• curl: (28) Connection timed out after X milliseconds -- A firewall is silently dropping IPv6 packets.
• curl: (35) SSL connect error -- The TLS handshake failed on the IPv6 connection.

Step 5: Check SSL Certificates on Both Protocols

Use openssl to inspect the certificate served on each protocol. The certificates should be identical:

# Check certificate over IPv4
openssl s_client -connect example.com:443 -4 2>/dev/null | openssl x509 -noout -subject -dates

# Check certificate over IPv6
openssl s_client -connect example.com:443 -6 2>/dev/null | openssl x509 -noout -subject -dates

Compare the output. If the subject, issuer, or expiry dates differ, the IPv6 endpoint is serving a different (possibly incorrect) certificate. This is more common than you might expect, particularly with CDN configurations that deploy certificates to IPv4 and IPv6 edges on different schedules.

Step 6: Test Port Connectivity

To check whether specific TCP ports are open on the IPv6 address, use nmap or nc (netcat):

# Scan specific ports over IPv6 with nmap
nmap -6 -p 80,443 example.com

# Quick check with netcat
nc -6 -zv example.com 443

# Check if port is open on a specific IPv6 address
nc -6 -zv 2001:db8::1 443

This is the fastest way to confirm whether the web server is actually listening on IPv6 for the ports it should be. A common finding: port 80 (HTTP) is open on IPv6 but port 443 (HTTPS) is not, because the SSL virtual host was not configured with listen [::]:443 ssl;.

Step 7: Putting It All Together -- A Diagnostic Workflow

When UptyBots alerts you that an IPv6 monitor is down, follow this systematic workflow:

1. Check DNS first: Run dig AAAA example.com +short. If empty or wrong, the issue is DNS. Fix the record and wait for propagation.
2. Ping the IPv6 address: Run ping6 [address]. If unreachable, the issue is at the network or firewall layer.
3. Traceroute to locate the break: Run traceroute6 example.com. Find the hop where packets stop. If it is at or near the server, suspect a firewall. If it is in the middle of the internet, suspect a routing issue.
4. Test HTTP/HTTPS: Run curl -6 -v https://example.com. If ping works but curl fails, the issue is at the application layer (web server not listening on IPv6, SSL misconfiguration).
5. Check SSL: Run openssl s_client -connect example.com:443 -6. If the certificate is wrong or the handshake fails, the issue is in the SSL/TLS configuration for IPv6.
6. Check ports: Run nmap -6 -p 80,443 example.com to verify which ports are actually open on IPv6.

This workflow moves from the most basic layer (DNS) to the most specific (application and SSL), narrowing the cause at each step.

When Manual Tools Are Not Enough

Manual diagnostics are essential for root cause analysis, but they have inherent limitations:

• Single location: Your terminal runs from one location. An IPv6 issue affecting users in Asia will not show up when you test from Europe.
• Single point in time: You test now. The failure happened at 3 AM and may be intermittent.
• Reactive only: You run these commands after users report a problem, not before.
• No historical data: Manual tests do not build the response time graphs and uptime percentages that help you identify patterns over time.

This is why manual tools and automated monitoring are complementary, not competing. UptyBots runs IPv4 and IPv6 checks continuously from multiple global locations, alerting you to problems the moment they begin. You then use the manual tools described here to diagnose and resolve the specific issue. Together they provide both breadth of coverage and depth of diagnosis.

For more on the difference between ping-only monitoring and comprehensive checks, read common ICMP ping monitoring mistakes. To understand the business impact of the downtime you might be missing, try our Downtime Cost Calculator.

See setup tutorials or get started with UptyBots monitoring today.