The IETF published the first widely deployed IPv6 specification as RFC 1883. It defined the new packet header format and core behavior for IPv6 as the long-term successor to IPv4, whose 32-bit address space was already expected to become limiting.
The IETF published RFC 1933 to describe practical ways to run IPv6 in an Internet that was still mostly IPv4. It documented approaches such as dual stack (running IPv4 and IPv6 together) and tunneling (carrying IPv6 packets inside IPv4 packets) to bridge gaps during the transition.
RFC 2460 replaced RFC 1883 and became the main IPv6 protocol specification for many years. This update clarified parts of the protocol and served as the stable reference for implementations as IPv6 slowly moved from research to production networks.
RFC 2893 updated and replaced RFC 1933 with a more detailed set of compatibility tools for IPv6 hosts and routers. The document reinforced that the transition would take a long time and emphasized methods that keep IPv4 working while IPv6 is added.
RFC 3056 specified 6to4, an automatic tunneling method that let sites connect to IPv6 across IPv4 networks using a special IPv6 prefix derived from a public IPv4 address. It helped early adopters experiment with IPv6 reachability, even when native IPv6 service was limited.
RFC 4291 defined the IPv6 addressing model (unicast, multicast, anycast) and standard text formats such as compressed notation. Clear addressing rules were important for consistent network design and for deploying IPv6 in operating systems, routers, and DNS.
IANA distributed the last blocks from the central IPv4 pool to the five Regional Internet Registries (RIRs), marking global exhaustion of IANA’s available IPv4 space. This milestone increased pressure on network operators and service providers to accelerate IPv6 deployment.
The IETF published key standards enabling IPv6-only networks to reach IPv4-only services using translation. RFC 6146 defined stateful NAT64 (translation between IPv6 clients and IPv4 servers), and RFC 6147 defined DNS64 (synthesizing IPv6 AAAA records from IPv4 A records to steer traffic through NAT64).
On World IPv6 Day, many major websites and network operators enabled IPv6 on their public services for a coordinated 24-hour test. The event aimed to surface real-world problems—especially with home networks and DNS—before broader, permanent deployment.
World IPv6 Launch coordinated major ISPs, equipment makers, and web companies to leave IPv6 enabled permanently on production services. It marked a shift from testing to routine operation, helping normalize “dual-stack” Internet access at global scale.
RIPE NCC began allocating IPv4 addresses from its last /8 block, triggering strict rationing (such as limiting the size of new allocations). This milestone illustrated how IPv4 scarcity was becoming a regional operational constraint and reinforced the need to deploy IPv6.
ARIN announced it had issued the final IPv4 addresses from its free pool, meaning new allocations could no longer be met from readily available stock. After this point, organizations increasingly relied on waiting lists, transfers, and shared-address techniques while continuing IPv6 rollouts.
The IETF published RFC 8200, which obsoleted RFC 2460 and reclassified the core IPv6 protocol specification as an Internet Standard (STD 86). It consolidated years of updates and errata into a refreshed, stable reference for implementers and operators.
RIPE NCC announced it had made its final IPv4 allocation from the last remaining addresses in its available pool. Afterward, new IPv4 allocations depended mainly on addresses returned to the registry, increasing the practical value of IPv6 and transition architectures.
LACNIC announced that its IPv4 pool was exhausted, after reserving and assigning the last remaining address block under its exhaustion policies. From then on, allocations depended on recovered or returned space, pushing networks in the region toward IPv6-first planning.
RFC 9673 updated RFC 8200 by defining more practical procedures for processing IPv6 Hop-by-Hop Options headers in routers and hosts. This addressed long-standing operational concerns (like performance impact) and reflects continued technical evolution of IPv6 after widespread deployment began.
Google’s public IPv6 statistics page provides an ongoing measure of how many users reach Google over IPv6. These measurements became a widely used benchmark for tracking real-world IPv6 deployment and for comparing adoption across countries and regions.
IPv4 to IPv6 Transition and Global Adoption Timeline (1996–2025)