IPv6 Monitoring and Troubleshooting

Troubleshooting IPv6 connectivity requires familiarity with a new set of command-line tools, understanding of how dual-stack selection works, and awareness of IPv6-specific failure modes that have no IPv4 equivalent. This guide covers the complete toolkit for diagnosing IPv6 problems.

Basic IPv6 Connectivity Testing

ping6 / ping -6

The IPv6 equivalent of ping. On modern systems, a single ping command handles both IPv4 and IPv6 depending on the target address. Use the -6 flag to force IPv6.

# Force IPv6 ping by address
ping6 2001:4860:4860::8888        # Google's IPv6 DNS

# Force IPv6 on systems where ping handles both
ping -6 ipv6.google.com

# On Linux, specify source interface (useful for multi-homed hosts)
ping6 -I eth0 2001:4860:4860::8888

# On macOS
ping6 -b eth0 2001:4860:4860::8888

# Send 5 packets, 1-second interval
ping6 -c 5 2001:4860:4860::8888

# Flood ping (requires root) — useful for packet loss testing
sudo ping6 -f -c 1000 2001:4860:4860::8888

Common failures: - Network unreachable — No IPv6 default route - No route to host — No path to destination prefix - Request timeout — ICMPv6 echo replies being filtered - Destination unreachable (no route) — Router cannot forward the packet

traceroute6 / traceroute -6

Maps the path of IPv6 packets across the network, showing each hop and round-trip time.

# Basic IPv6 traceroute
traceroute6 ipv6.google.com

# Force IPv6 on systems with combined traceroute
traceroute -6 ipv6.google.com

# Use UDP probes instead of ICMPv6 (useful when ICMP is filtered)
traceroute6 -U ipv6.google.com

# Set maximum hops
traceroute6 -m 20 2001:4860:4860::8888

# Windows equivalent
tracert -6 ipv6.google.com

Reading traceroute output:

traceroute6 to ipv6.google.com (2607:f8b0:4004:c17::65)
 1  2001:db8::1 (2001:db8::1)   0.712 ms   0.681 ms   0.674 ms
 2  2001:db8:100::1 (2001:db8:100::1)  1.234 ms  1.198 ms  1.201 ms
 3  * * *    ← router not responding to ICMPv6 probes (may be normal)
 4  2600:1419:be::b875:f4bf  3.201 ms  3.187 ms  3.230 ms

* * * hops indicate routers that do not send TTL-exceeded ICMPv6 messages. This is often intentional firewall policy, not a failure.

IPv6 Address and Interface Diagnostics

Checking IPv6 Address Configuration

# Linux: show all IPv6 addresses
ip -6 addr show

# Show only IPv6 on specific interface
ip -6 addr show eth0

# macOS
ifconfig en0 | grep inet6

# Windows
ipconfig /all | findstr "IPv6"
netsh interface ipv6 show addresses

Look for: - Global unicast (2000::/3) — Routable public IPv6 address - Link-local (fe80::/10) — Always present if IPv6 is enabled; not globally routable - ULA (fc00::/7) — Private routable (similar to RFC 1918) - Temporary addresses — Random IID, preferred source for outbound connections

Checking IPv6 Routing Table

# Linux
ip -6 route show

# Example output:
# default via fe80::1 dev eth0  proto ra  metric 100
# 2001:db8::/64 dev eth0  proto kernel  src 2001:db8::a  metric 256

# macOS
netstat -rn -f inet6

# Windows
route print -6
netsh interface ipv6 show routes

A missing default route (default via ...) explains Network unreachable errors when trying to reach global IPv6 addresses.

Checking NDP Neighbor Cache

# Linux — shows learned neighbor entries (like ARP cache for IPv4)
ip -6 neigh show

# Example output:
# 2001:db8::1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE
# fe80::1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE

# macOS
ndp -an

# Windows
netsh interface ipv6 show neighbors

A neighbor stuck in INCOMPLETE state means NDP is failing — the device cannot resolve the MAC address for that IPv6 address. Check: - Physical layer (link up?) - VLAN configuration (are both devices in the same broadcast domain?) - Firewall rules blocking ICMPv6 135/136 (NS/NA)

DNS Troubleshooting for IPv6

Checking AAAA Records

# Query AAAA record specifically
dig AAAA ipv6.google.com
nslookup -type=AAAA ipv6.google.com

# Query against a specific DNS server
dig AAAA ipv6.google.com @2001:4860:4860::8888

# Check if DNS64 is synthesizing AAAA records
dig AAAA ipv4only.arpa
# If response contains 64:ff9b:: prefix, DNS64 is active

Reverse DNS for IPv6

IPv6 reverse DNS uses ip6.arpa. The address is reversed nibble-by-nibble:

Address: 2001:0db8:0000:0000:0000:0000:0000:0001
Reverse: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

# Query reverse DNS
dig -x 2001:db8::1

Missing reverse DNS is common for IPv6 addresses and can cause slow SSH logins (UseDNS yes in sshd_config attempts PTR lookup). Either add a PTR record or set UseDNS no.

Happy Eyeballs Algorithm

What Is Happy Eyeballs?

When a client resolves a hostname that has both A and AAAA records, it must decide which address to connect to. Naive implementations try IPv6 first and fall back to IPv4 only after a timeout — creating noticeable delays when IPv6 connectivity is broken.

Happy Eyeballs (RFC 6555 / RFC 8305) is an algorithm that races IPv4 and IPv6 connections simultaneously (or with a small delay) and uses whichever completes first. This eliminates the long timeout penalty when one address family is broken.

Happy Eyeballs v2 (RFC 8305)

The updated algorithm: 1. Query DNS for both A and AAAA records in parallel 2. Wait up to 50ms for AAAA response after A response arrives 3. Attempt IPv6 connection first 4. If IPv6 connection has not succeeded after 250ms, start IPv4 connection in parallel 5. Use whichever connection completes first; cancel the other

Debugging Happy Eyeballs

When connections to dual-stack hosts are slow or intermittent, Happy Eyeballs may be masking an IPv6 failure:

# Force IPv4 only
curl -4 https://www.google.com

# Force IPv6 only
curl -6 https://www.google.com

# Show which address was used
curl -v --http2 https://www.google.com 2>&1 | grep "Connected to"
# > Connected to www.google.com (2607:f8b0:4004:c17::65) port 443

# Measure time with both protocols
time curl -4 -s -o /dev/null https://www.google.com
time curl -6 -s -o /dev/null https://www.google.com

# Python — check what address family getaddrinfo returns first
python3 -c "import socket; print(socket.getaddrinfo('google.com', 443))"

Common Happy Eyeballs debugging scenario: - Web requests to dual-stack sites occasionally take 250-300ms extra - Cause: IPv6 address is reachable at DNS level but TCP SYN packets are being dropped silently - Test: curl -6 -v https://site.com — hangs at "Trying 2001:..." - Fix: Identify where IPv6 TCP is being dropped (firewall rule? broken MTU?)

IPv6 MTU and PMTUD Issues

Path MTU Discovery (PMTUD) is more critical in IPv6 than IPv4 because IPv6 routers cannot fragment packets. If a packet exceeds the MTU of any link on the path, the router drops it and sends a Packet Too Big (ICMPv6 Type 2) message back to the source.

If ICMPv6 Type 2 messages are blocked by a firewall, PMTUD breaks. This causes the classic black hole symptom: connections establish successfully (TCP SYN/SYN-ACK are small) but data transfer hangs once large packets are sent.

# Check effective MTU for a path
# Linux: use ping6 with packet size
ping6 -s 1400 ipv6.google.com  # 1400 byte payload + 48 byte header = 1448 bytes
ping6 -s 1452 ipv6.google.com  # Near Ethernet MTU limit

# If large pings fail but small pings succeed, PMTUD is broken

# Manually clamp TCP MSS to avoid fragmentation issues (iptables)
sudo ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

IPv6-Aware Monitoring Tools

Network Monitoring Systems

Most modern NMS platforms support IPv6:

Prometheus Blackbox Exporter

Ideal for monitoring HTTP/TCP/ICMP over IPv6:

# blackbox.yml
modules:
  ipv6_icmp:
    prober: icmp
    icmp:
      preferred_ip_protocol: ip6
      ip_protocol_fallback: false

  ipv6_http:
    prober: http
    http:
      preferred_ip_protocol: ip6
      ip_protocol_fallback: false
      valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]
      valid_status_codes: [200]

# Test the prober manually
curl "http://localhost:9115/probe?module=ipv6_icmp&target=2001:4860:4860::8888"

Flow Monitoring

NetFlow/IPFIX and sFlow all support IPv6. Ensure your collectors and analyzers are IPv6-aware:

• ntopng — Full IPv6 support in all versions
• nfdump/nfcapd — Native IPv6 flow collection
• Elastiflow — Grafana-based, full IPv6 support

# Capture IPv6 flows with tcpdump
sudo tcpdump -i eth0 ip6 -w ipv6_capture.pcap

# Analyze with tshark
tshark -r ipv6_capture.pcap -T fields -e ipv6.src -e ipv6.dst -e tcp.dstport

Dual-Stack Debugging Workflow

When a dual-stack host has connectivity problems, follow this systematic approach:

Step 1: Isolate the Address Family

# Test IPv4 directly
curl -4 https://target.example.com
ping -4 target.example.com

# Test IPv6 directly
curl -6 https://target.example.com
ping6 target.example.com

Step 2: Verify DNS Resolution

# Does it have both A and AAAA?
dig target.example.com A
dig target.example.com AAAA

Step 3: Check Routing

# Verify IPv6 default route exists
ip -6 route show | grep default

# Trace the path
traceroute6 target.example.com

Step 4: Check MTU and ICMPv6 Filtering

# Test with large packets
ping6 -s 1400 target.example.com

# Verify Packet Too Big messages are not blocked
# (Examine firewall rules for ICMPv6 type 2)

Step 5: Inspect Neighbor Discovery

# Check neighbor cache for the gateway
ip -6 neigh show
# If gateway is INCOMPLETE or FAILED, NDP is broken

Step 6: Check System Logs

# Linux kernel IPv6 messages
dmesg | grep -i ipv6
journalctl -k | grep -i ipv6

# Network manager logs (if used)
journalctl -u NetworkManager | grep -i ipv6

IPv6 Reachability Testing Services

These public tools test your IPv6 connectivity from external vantage points:

# Command-line reachability tests
curl -6 https://ipv6.icanhazip.com  # Returns your IPv6 address if connected
curl -6 https://api64.ipify.org     # Returns IPv6 if available

Quick Reference: IPv6 Troubleshooting Commands

Effective IPv6 troubleshooting requires the same systematic methodology as IPv4 debugging — isolate the layer, test assumptions, and use the right tool for each diagnostic question. The additional complexity of dual-stack environments demands extra care: always determine which address family is actually being used before drawing conclusions.