"Our IPv6 Is Broken." A Decision-Maker's Guide to Understanding the Diagnosis.

You are in a meeting. Your lead developer pulls up a monitoring alert and says: "IPv6 is down. Ping is failing, the traceroute dies at hop four, and the AAAA record looks stale." You nod, because that is what you do when someone speaks a language you half-understand. But internally you are thinking: what does any of that actually mean, how bad is it, and what do I need to approve to get it fixed?

This guide is written for that exact moment. Not for the person running the commands (they already know how), but for the person who has to understand the results, evaluate the severity, and decide how to allocate time and budget to fix the problem. You will learn what each diagnostic tool actually tells you, translated into business consequences. By the end, you will be able to ask informed questions, recognize whether the proposed fix matches the actual problem, and avoid both under-reacting ("it is just IPv6, nobody uses that") and over-reacting ("shut everything down and call the vendor").

If you have not yet set up separate monitoring for IPv4 and IPv6, start with our step-by-step guide for dual-stack uptime checks. The diagnostics below become most useful once you already know which protocol is failing and need to understand why.

The Three Diagnostic Tools (and What They Actually Tell You)

When your technical team investigates an IPv6 problem, they will typically reach for three tools: ping, traceroute, and DNS lookups. Think of these as three different tests a doctor might run. Each one checks a different layer of your internet infrastructure, and together they narrow down where the problem lives and how serious it is.

Here is the executive summary of each:

Let us walk through each one and what the results mean for your business.

Ping: "Is Anyone Home?"

Ping is the simplest diagnostic. It sends a tiny packet to your server and waits for a reply. If a reply comes back, the server is reachable. If it does not, something between your computer and the server is blocking traffic or the server is not responding.

For IPv6 specifically, your team runs a command like this:

ping6 example.com

Or on some systems:

ping -6 example.com

What the results mean (in business terms)

Your developer will report one of these outcomes. Here is what each one means for you:

The important caveat about ping

Ping tests a specific type of network traffic (ICMP). Your website uses a different type (HTTP/HTTPS over TCP). It is entirely possible for ping to fail while your website works, or for ping to succeed while your website is broken. Ping is a quick first check, not a definitive answer. This is why ping monitoring alone is never enough. Your team should always follow up with application-layer testing.

Traceroute: "Where Does the Connection Break?"

If ping shows a problem, the next question is: where in the chain is it breaking? Is it your server? Your hosting provider? Your CDN? An internet backbone somewhere between here and there?

Traceroute answers this question. It maps every step (called a "hop") that network traffic takes from the testing machine to your server. Think of it as GPS tracking for a delivery truck: you can see every intersection it passes through and identify exactly where it gets stuck.

The command looks like:

traceroute6 example.com

The output is a numbered list of network hops, each showing the router's name and how long it took to respond:

traceroute6 to example.com (2001:db8::1) from 2001:db8::100, 30 hops max
 1  your-router (fd00::1)          0.5 ms   0.4 ms   0.4 ms
 2  isp-gateway (2001:db8:1::1)    3.2 ms   3.0 ms   3.1 ms
 3  transit-hub (2001:db8:2::1)    8.5 ms   8.3 ms   8.5 ms
 4  * * *
 5  * * *
 6  * * *

Reading traceroute results without a networking degree

The key thing to look for is where the list stops showing real results and starts showing stars (* * *). Each star means "no response from this hop." Here is how to interpret the patterns:

The comparison that reveals everything

The most powerful diagnostic technique is running traceroute for both IPv4 and IPv6 to the same destination and comparing them side by side:

# IPv4 path
traceroute example.com

# IPv6 path
traceroute6 example.com

This comparison often reveals the root cause immediately. You might discover that IPv4 takes 8 hops through well-established routes, while IPv6 takes 15 hops through completely different (and less reliable) transit providers. Or that IPv4 goes directly to your CDN's nearest edge, while IPv6 gets routed to a different continent. This kind of insight explains why separate IPv4/IPv6 monitoring catches problems that generic monitoring misses.

DNS Lookups: "Does the Phone Book Have the Right Number?"

Many IPv6 failures have nothing to do with network problems or server crashes. The root cause is much simpler: the domain's DNS record is wrong, missing, or outdated. This is the digital equivalent of your phone book listing a disconnected number.

When your team runs a DNS lookup, they are checking whether your domain name correctly translates to the right IPv6 address:

# Check the IPv6 address (AAAA record)
dig AAAA example.com +short

# Check the IPv4 address (A record) for comparison
dig A example.com +short

What the DNS results mean

For a deeper explanation of how DNS records control IPv4 and IPv6 availability, see our guide on how DNS records affect dual-stack availability.

Beyond the Basic Three: Application-Layer Testing

Ping, traceroute, and DNS lookups test the lower layers of the network. But your actual service runs on top of those layers. A server can be pingable and DNS-correct while still failing to serve web pages over IPv6. This happens when the web server software is not configured to listen on IPv6, or when the SSL certificate is not properly bound to the IPv6 address.

Your team will use additional tools to test these higher layers:

HTTP testing with curl

# Test if the website responds over IPv6
curl -6 -I https://example.com

# Compare response times between protocols
curl -4 -w "Total: %{time_total}s\n" -o /dev/null -s https://example.com
curl -6 -w "Total: %{time_total}s\n" -o /dev/null -s https://example.com

This tells your team whether the web server actually serves pages over IPv6, and how the response time compares to IPv4. Common error messages and what they mean:

• "Could not resolve host" = No AAAA record in DNS. This is a DNS problem.
• "Connection refused" = The server exists but is not accepting web connections on IPv6. The web server needs to be configured to listen on the IPv6 address.
• "Connection timed out" = A firewall is silently dropping IPv6 web traffic. Someone needs to update firewall rules.
• "SSL connect error" = The network connection works but the SSL/TLS certificate handshake fails on IPv6. The SSL configuration needs updating.

SSL certificate verification

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

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

Both commands should return the same certificate information. If the certificates differ, the IPv6 endpoint may be serving an expired certificate, a certificate for the wrong domain, or no certificate at all. This is more common than you might expect, especially with CDN configurations that deploy certificates to IPv4 and IPv6 edges on different schedules.

Port scanning

# Check which ports are open on IPv6
nmap -6 -p 80,443 example.com

A common finding: port 80 is open on IPv6 but port 443 is not, because the HTTPS configuration was only set up for IPv4. Or both ports are open on IPv4 but neither is open on IPv6, because the server's firewall rules only allow IPv4 traffic.

The Diagnostic Workflow: What Your Team Should Do (and What to Ask Them)

When UptyBots alerts you that an IPv6 monitor is down, your technical team should follow this systematic approach. As the person making decisions, here are the questions you should ask at each step:

1. Step 1: Check DNS. "Is the AAAA record present and pointing to the correct address?"
   If the answer is no, the fix is a DNS update. This is typically quick (minutes to make the change, hours for full propagation).
2. Step 2: Ping the server. "Can we reach the server over IPv6 at the network level?"
   If not, the problem is at the network or firewall layer. Ask: "Is this our firewall, our hosting provider's network, or an upstream routing issue?"
3. Step 3: Run a traceroute. "Where exactly does the IPv6 path break?"
   If it breaks at your server, it is your team's problem to fix. If it breaks in the middle of the internet, it is a transit issue that your hosting provider may need to address.
4. Step 4: Test HTTP/HTTPS. "Does the web server actually respond over IPv6?"
   If ping works but the website does not, the server's web software needs configuration changes.
5. Step 5: Verify SSL. "Are we serving the same SSL certificate over IPv6 as over IPv4?"
   If not, the SSL setup needs to be updated for the IPv6 listener.
6. Step 6: Check ports. "Are the necessary ports (80, 443) open on IPv6?"
   If not, the server's firewall rules need to be updated to allow IPv6 traffic on those ports.

This sequence moves from the most basic check (does the address even exist?) to the most specific (is the SSL certificate correct?). Each step either identifies the problem or eliminates a possible cause, narrowing down the diagnosis.

How to Evaluate Severity: Is This a Hair-on-Fire Emergency or a Background Fix?

Not every IPv6 issue requires dropping everything. Here is a framework for evaluating how urgently you need to act:

Why Manual Diagnostics Are Not Enough on Their Own

The tools described in this guide are powerful for understanding what went wrong. But they have fundamental limitations that matter for your business:

• They test from one location. Your developer runs these commands from the office or from a single server. If the IPv6 problem only affects users in Southeast Asia, tests from a European office will show everything as healthy.
• They test at one point in time. A traceroute right now tells you the current state. It does not tell you what happened at 3 AM when your monitoring tool detected the failure. Intermittent problems may not be visible when someone gets around to testing.
• They are reactive. Nobody runs these commands until after a problem is already reported. By then, customers have already been affected.
• They produce no historical record. Manual tests do not generate the long-term data you need to identify patterns, measure improvement, or calculate the business impact of past incidents.

This is why automated monitoring and manual diagnostics work together, not as alternatives to each other. UptyBots runs IPv4 and IPv6 checks continuously from multiple locations around the world, alerting you the moment something fails. Your team then uses the diagnostic tools described here to pinpoint the root cause and fix it. The monitoring catches the problem. The diagnostics solve the problem.

For more on the difference between basic ping checks and full application monitoring, read common ICMP ping monitoring mistakes. To put a dollar figure on the downtime you might be experiencing, try our Downtime Cost Calculator.

The Questions to Ask in Your Next Incident Review

After an IPv6 incident is resolved, use these questions in your post-mortem to prevent recurrence:

1. "How long was IPv6 down before we detected it?" If the answer is "we do not know" or "a user reported it," your monitoring setup needs to include separate IPv6 checks.
2. "Did our monitoring tool alert us, or did we find out another way?" If monitoring did not catch it, the tool is likely only checking IPv4.
3. "What was the root cause: DNS, network, firewall, or application?" This determines whether the fix is a 5-minute DNS update or a larger infrastructure project.
4. "How many users were affected?" Cross-reference the downtime period with your analytics to estimate the traffic and revenue impact.
5. "What process change prevents this from happening again?" Common answers include: adding AAAA record updates to the migration checklist, setting up dual-stack monitoring, or configuring alerts for protocol-specific failures.

See setup tutorials or get started with UptyBots monitoring today.