IPv6 Crosses 50% — Technology Diffusion Takes Longer Than You Think

I noticed the 50% figure on Google's IPv6 stats page https://www.google.com/intl/en/ipv6/statistics.html on 4/16/2026, flagged on Hacker News https://news.ycombinator.com/item?id=47777894. A milestone worth pausing on, even if the headline buries the lead: it took roughly 20 years from IPv6's formal definition (RFC 2460, 1998) to get halfway there.

The culprit is obvious in retrospect — NAT gave IPv4 a decade-long second life and removed any burning platform. Why pay migration cost when carrier-grade NAT works fine?

From a firmware perspective, the story is actually a bright spot. RFC 5970 https://www.rfc-editor.org/rfc/rfc5970.txt standardized network boot over IPv6 (DHCPv6/PXE) in 2010, and the firmware stack moved quickly. I was part of the team that implemented dual-stack IPv4/IPv6 network boot support in EDK2 https://github.com/tianocore/edk2 — the open-source UEFI reference firmware — had it certified at the UNH Interoperability Lab https://www.iol.unh.edu/, and codified in the UEFI specification. That code has been fully deployed since the RFC landed and ships today in the host firmware of most PCs, servers, and devices like the NVIDIA Jetson. The iPXE project https://ipxe.org/ is the other prominent host-side implementation and likewise supports RFC 5970. The IPv6 TFTP/PXE boot foundation was then leveraged for HTTP boot, which is the modern evolution now widely used for network-based firmware provisioning.  I journaled bit of this in places like https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf, https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf, and https://uefi.org/sites/default/files/resources/A_Tale_of_Two_Standards_0.pdf.

So firmware did its job — standards written through the IETF and UEFI Forum, code certified, silicon shipping, HTTP boot built on top. The 50% adoption story is really about everything above the firmware layer: ISP rollout, enterprise network operations, and the long tail of IPv4 infrastructure that NAT kept alive just long enough to delay the transition by a decade.

That's the part that still surprises me. When the firmware stack is ahead of the network, you know diffusion is the bottleneck, not implementation.

Specifications and a New Book

I recently came across http://electronicdesign.com/embedded/what-s-difference-between-de-jure-and-de-facto-standards which reminded me of the world of firmware. Specifically, there is an interplay of de jure standards, such as the UEFI 2.6 specification, and then de facto standards, including open and closed source behaviors.

I'll give a quick example where these two venues collided. Specifically, during the drafting of the UEFI 2.5 specification, there was an operating system request to make the UEFI run time code produced in a way such that the hypervisor or OS could apply page protection. Recall that UEFI runtime code and data are co-located in ring 0 with the OS kernel. This change entailed several things, including the OS making the UEFI run time code read-only and the data pages non-executable. To that end, the EDKII was updated to align the UEFI runtime driver sections on a 4KiB boundary and not merge the code and data pages. In addition, the UEFI memory map was updated to have a memory descriptor for each code and data page, creating several descriptors for each UEFI runtime image, versus the former behavior of having one memory descriptor for the entire set of PE images.

We codified this behavior in UEFI 2.5 with the memory properties table

This bit let the OS know that the code was factored into these separate pages and validated by the firmware producer to be truly pure code and data (e.g., no self-modifying code). This was a de jure UEFI 2.5 specification addition.

What happened?  Namely, why did we move to the EFI_MEMORY_ATTRIBUTES_TABLE in UEFI 2.6 and add language to the specification?

After publishing the 2.5 specification and upstreaming patches responsive to this properties table, many OS kernels started to crash. Uh oh.

What we learned was that when OS kernels invoke SetVirtualAddress to map the UEFI runtime entries from a 1:1 pre-OS setting to a non-1:1 OS kernel mapping, the relative distance between entries were not preserved. This didn't appear in earlier implementations since one memory descriptor covered a single image. In fracturing the single descriptor covering the PE image into multiple entries, the un-documented requirement to keep relative offsets between sections of a PE/COFF image during the SetVa call was surfaced.  We essentially discovered a de facto requirement to have a single descriptor covering a single PE/COFF image.

Thus the change in the UEFI 2.6 de jure specification to have an 'alternate' table to the UEFI memory map (e.g.,  EFI_MEMORY_ATTRIBUTES_TABLE) and maintain the single descriptor per image given the circa 1999 and beyond OS's and their SetVa expectations.

This new attributes table is also called out in some OS requirements https://msdn.microsoft.com/windows/hardware/commercialize/design/minimum/device-guard-and-credential-guard.

This doesn't moot the value of the de jure specification, of course. OS and device vendors appreciate standards so that long-term support (LTS) variants of the OS can have an expectation that platforms produced during the support lifetime, such as 10 years, will be compatible. Given the complexity of modern systems, the de jure specification cannot always cover all of the system details. Thus the value of open source and products providing some de facto standardization, too, to complement the formal standard.

Speaking of industry standard firmware and code, I'd also like to let people know that the "Beyond BIOS" book is now available at https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1501514784 and https://www.degruyter.com/view/product/484468. Since the original publication in 2006, many things have changed, including scaling of the industry standards efforts, but the basics remain the same.  And those areas that have evolved are deftly treated in the updated text.

This book serves as a good launching point for someone just diving into the world of industry standard firmware. I was happy to have the opportunity to work with my old friends and co-authors Mike Rothman and Suresh, along with new friends like Jeffrey, Megan, and others from De Gruyter. De Gruyter also allowed for me to share a sample chapter https://github.com/vincentjzimmer/Documents/blob/master/Beyond_BIOS_3rd_Ed_Chapter-7-9781501505690.pdf, too.

If you have the time please take a look.

And interactions of modern systems don't always behave as expected, too.

You can learn more about the UEFI Shell, which is nicely staged in the picture above, in a update of the UEFI Shell book later this year https://www.degruyter.com/view/product/484477.