IPv4 vs IPv6: Address Exhaustion, NAT and How to Diagnose Both
2026-09-05 · undefined min
The internet runs on two versions of the IP protocol. IPv4, the older one, has been the foundation of networking for decades and still carries most traffic. IPv6 is its successor, designed to solve the central problem that has shaped modern networking: IPv4 addresses are a finite, exhausted resource. Both run in parallel today, and understanding how they differ is essential for anyone who diagnoses networks.
The differences go beyond the length of an address. IPv4 uses 32-bit addresses, which gives about 4.3 billion possible addresses - nowhere near enough for every device. IPv6 uses 128-bit addresses, providing a practically limitless pool. This change, and the workarounds it forced, explains NAT, address complexity and much of the confusion you encounter when troubleshooting.
1981
IPv4 is standardized
RFC 791 defines the 32-bit addressing scheme that will carry the internet, with roughly 4.3 billion addresses.
1998
IPv6 is introduced
RFC 2460 defines the 128-bit successor, aiming to solve the impending address shortage with an effectively unlimited pool.
2011
The IPv4 pool runs out
The Internet Assigned Numbers Authority allocates the last IPv4 address blocks, accelerating the transition to IPv6.
2020s
IPv6 becomes mainstream
Major ISPs, cloud providers and operating systems enable IPv6 by default, and it carries a growing share of global traffic.
The fundamental difference: address space
The core difference between IPv4 and IPv6 is the size of their address space. IPv4 uses 32-bit addresses, written as four decimal numbers separated by dots, such as 192.168.1.1. This gives about 4.3 billion unique addresses. IPv6 uses 128-bit addresses, written as eight groups of hexadecimal digits separated by colons, which yields an effectively unlimited number of addresses.
This difference is not cosmetic. The exhaustion of IPv4 addresses forced the development of techniques like NAT and address sharing, which add complexity and break end-to-end connectivity. IPv6 was designed from the ground up with enough addresses for every device to have a globally routable address, removing the need for those workarounds.
How IPv4 addresses ran out
IPv4 was designed in the early 1980s, when the internet was a research network with a few hundred computers. Nobody anticipated billions of devices. By the 1990s it became clear that 4.3 billion addresses would not suffice, and measures like subnetting, CIDR and private address ranges were introduced to delay the exhaustion.
The private ranges - 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 - are the foundation of home and office networks. They are reused everywhere, and Network Address Translation (NAT) maps them to a single public address. NAT allowed the internet to keep growing, but it introduces complexity, breaks some peer-to-peer connections, and is one of the most common sources of troubleshooting headaches.
The 32-bit IPv4 format compared with the 128-bit IPv6 format.
Reading and diagnosing IPv4 and IPv6
The two address formats demand different habits. An IPv4 address is easy to recognize and commonly appears in logs, while IPv6 addresses are long, include hexadecimal letters, and often contain long runs of zeros that can be compressed. Correctly interpreting them is the first step in diagnosing connectivity problems, since a missing bracket in a URL or a wrong prefix will break a connection.
Diagnosing also means checking whether IPv6 is actually in use. Many networks have both stacks running, and a failure in one can go unnoticed while the other still works. Tools like ping, traceroute and ipconfig or ip addr reveal which address family is active, and whether a host has an IPv6 address, a default gateway, or is falling back to IPv4.
What the transition means for you
For most users, IPv6 is invisible: their operating system, router and ISP handle both protocols automatically. The practical impact shows up when things break. A service that only listens on IPv4 may be unreachable over an IPv6-only connection, and some networks fail to route IPv6 correctly, causing delays and connectivity that silently falls back.
The takeaway is to treat IPv4 and IPv6 as two separate networks that must both work. When troubleshooting, check both address families, verify routing and DNS resolution for each, and remember that a symptom on one version does not prove the other is healthy.
The takeaway
IPv4 and IPv6 are two networks sharing one internet. Knowing how their addresses differ, why NAT exists, and how to check both families turns confusing failures into clear, fixable problems.
Your public IP address and network location, detected automatically.
Loads automatically when you open NetChecks — no input needed. Use the Refresh button to re-check after switching networks or reconnecting your VPN.
Your browser
All-in-One Scan
Runs every relevant check against one IP or hostname in a single pass: DNS, whois, ping, traceroute, a well-known-ports scan (1-1024), HTTP headers and the SSL certificate.
Enter a domain or IP address and run it to check DNS, whois, ping, traceroute, common ports, HTTP headers, and the SSL certificate all at once.
Most checks run in parallel - typically finishes in about 30 seconds, longer if the target is slow or unreachable.
The port scan step only runs once the consent checkbox above is checked - every other check runs regardless.
Ping
Send ICMP echo requests to a host to check reachability and latency.
Enter a hostname or IP address and press Ping to send ICMP echo requests and measure round-trip latency.
Learn more about Ping
What it is
Ping sends ICMP Echo Request packets to a host and measures how long it takes for ICMP Echo Reply packets to come back. It is the most basic network connectivity test there is: it answers exactly one question, "is this machine reachable, and how quickly?" The ICMP protocol (RFC 792) was designed back in 1981 specifically to carry control and diagnostic messages over IP networks, outside of any application traffic - Ping is its best-known and most universally available implementation, present on virtually every operating system and network device since their earliest versions.
How it works
Every ICMP packet carries a TTL (Time To Live) field decremented by one at each router it crosses; if it hits zero before reaching the target, the packet is dropped and an error is sent back to the sender. The round-trip time (RTT) measured in milliseconds reflects the cumulative network latency over the entire round trip, not just the last leg near the target - a point that is often misunderstood, since slow ping results can have their root cause anywhere along the path, not necessarily near the server being tested. A ping typically sends several packets in a row rather than just one, which lets you tell a one-off latency spike apart from a recurring problem and calculate a packet loss rate over the sample.
Reading the results
A stable, low RTT - a few milliseconds on a local network, 10 to 50 ms for a destination within the same country, and noticeably more for an intercontinental link - indicates a healthy connection. Even a small amount of packet loss (above 1-2%) is particularly damaging for latency-sensitive uses like VoIP or interactive remote sessions, where every dropped packet shows up as a glitch or audible cutout. Highly variable latency from one packet to the next (jitter) is often more of a problem for these same use cases than latency that is high but perfectly stable. "Request timed out" means no reply arrived within the allotted time - the host could genuinely be down, a firewall could be silently blocking ICMP, or a route could be broken somewhere along the path; "Destination unreachable" is different and more informative: an intermediate router explicitly sent back a message saying it could not forward the packet, which helps narrow down where the problem actually sits.
Common mistakes
The most common misreading is concluding a host is "down" the moment a ping fails, when in fact a great many servers and devices - especially behind a properly hardened firewall, or hosted with major cloud providers - deliberately block inbound ICMP as a matter of policy while being fully operational and reachable on their actual services (HTTP, a database, and so on). A missing ping reply is therefore only meaningful evidence of downtime when combined with other signals, such as the application itself also failing to respond. Conversely, a successful ping is no guarantee whatsoever that the application service hosted on that machine is working correctly - these are two entirely independent layers of the network stack.
When to use it
The first thing to check before escalating a ticket: does the machine respond at all, before digging any further? Confirming connectivity after a firewall rule or routing table change, to make sure the change did not break access. Establishing a baseline latency measurement before a VoIP rollout or a carrier link failover, so there is an objective point of comparison if call quality complaints come in later. A lightweight, low-overhead periodic health check for an MSP monitoring several client sites in parallel, always as a complement to - never a replacement for - deeper application-level monitoring.
Traceroute
Trace the network path (hop by hop) to a destination host.
Enter a hostname or IP address and run it to see every network hop between this server and the destination, with latency per hop.
DNS Lookup (Nslookup)
Query DNS records: A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA.
Enter a domain, choose a record type (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, or CAA), then look it up.
Whois
Look up registration information for a domain or IP address.
Enter a domain or IP address to look up its registration details — registrar, owner organization, and important dates.
Blacklist Check
Check whether an IP address or domain is listed on public spam/abuse blocklists (DNSBL).
Enter an IPv4 address or domain and run it to check 7 public DNSBL/RBL blocklists at once - each shows as listed, not listed, or check failed.
TCP Port Scan
Check whether TCP ports are open on a host or IP: common ports, a custom list, or the full 1-65535 range.
Enter a host or IP, pick common ports, a custom list, or the full range, then scan to see which TCP ports respond.
A full range scan can take up to ~100 seconds. Large scans (more than 100 ports, including custom ranges/lists) are limited to 1 per minute per visitor.
Open ports (0)
HTTP Header Inspector
Fetch the HTTP response status and headers for a URL.
Enter a URL to fetch its HTTP response status code and every response header the server sends back.
SSL / TLS Certificate Checker
Inspect a host's TLS certificate: issuer, validity dates, and days remaining.
Enter a hostname to inspect its TLS certificate — issuer, validity dates, and days remaining before it expires.
Geo-IP Lookup
Look up the geographic location and network info for an IP address. Leave empty to look up your own public IP.
Enter any IP address, or leave it empty to look up your own, to see its approximate location and network/ISP info.
Computed entirely in your browser — no data sent to the server.
Enter an IP address and CIDR prefix (e.g. 192.168.1.0/24) to instantly compute the network range, broadcast address, and usable host count.
Speed Test
Basic download/upload throughput test against this server (accuracy depends on the server's own uplink).
Press Start to measure download and upload throughput against this server. Accuracy depends on this server's own connection.
Country Code Dictionary
ISO 3166-1 alpha-2 country codes — searched entirely in your browser.
Search or browse the list of ISO 3166-1 alpha-2 country codes, looked up entirely in your browser.
Country
ISO Code
Phone Dialing Code Dictionary
International calling codes by country — searched entirely in your browser.
Search or browse international calling codes by country, looked up entirely in your browser.
Country
Dial Code
World Clock
Pick a time zone to see the current time — drag the globe to spin it.
Pick a time zone from the list, or drag the globe, to see the current time there.
Your time
--:--:--
—
—
Selected time
--:--:--
—
—UTC±00:00
Difference vs. you—
—
Drag to rotate the globe.
French Mobile Network Status
Mobile antenna sites down or under maintenance in France, by operator (Orange, Free, SFR, Bouygues Telecom), from ARCEP's public data. Snapshot updated once a day by ARCEP - not a minute-by-minute feed.
Browse mobile antenna and fibre outage data by French operator — no input needed, updated automatically from ARCEP's public data.
Source: ARCEP, "Sites indisponibles" dataset, published under Licence Ouverte / Etalab 2.0 - commercial reuse explicitly allowed, unlike the IODA/CAIDA data this tab used before. The Normal/Watch/Alert badge is an in-house estimate (today's outage count vs. the median of prior days), not an official ARCEP classification. Source links below.
Most affected departments
Number of sites currently down or under maintenance, by department. Click an operator above to filter.
Fibre (FTTH) network quality by operator: reported-outage rate and connection-failure rate, from ARCEP's public data. Monthly indicators, 6-month rolling average - not a live feed like the mobile section.
Source: ARCEP, "Qualité des réseaux en fibre optique" dataset, published under Licence Ouverte / Etalab 2.0 - commercial reuse explicitly allowed. Source links below.
By operator (parent group)
Averages over the last 6 available months, per infrastructure-operator parent group.
NetChecks is provided for legitimate network diagnostics and educational purposes only, on systems, domains, and IP addresses that you own or are explicitly authorized to test.
Running port scans, DNS/whois lookups, traceroutes, or other checks against third-party systems without authorization may violate computer misuse laws in your jurisdiction (for example the Computer Fraud and Abuse Act in the US, the "Loi Godfrain" in France, or equivalent local legislation). You are solely responsible for ensuring you have the right to test any target you enter here.
This site and its results are provided "as is", without warranty of any kind. The operator of this site accepts no liability for any direct, indirect, or consequential damages, legal consequences, or misuse arising from the use of this site.
Requests are rate-limited to prevent abuse. The operator of this instance may optionally enable request-activity logging - if so, each tool request (your IP address, timestamp, the tool used, and the target/query entered) may be recorded in a database for security, abuse-prevention, and usage-analytics purposes; this is disabled by default. By using this site you agree to these terms; if you do not agree, do not use it.
Programmatic (API) use of this site is subject to these same terms, including the authorization requirement above.
Send feedback
Report an issue, leave a comment, or suggest a new feature.
This site uses ads and, if you accept, ad-partner cookies to help fund hosting. You can decline and keep using every tool ad-free.