IPv6: Why You Should Care (Nick Buraglio at CHI-NOG 13)

I’ve been listening to “you should care about IPv6” talks for two decades. I’ve given a few myself… so when Nick Buraglio took the stage at CHI-NOG 13, I knew the script. Nod politely, agree with the framing, walk out thinking the same things I thought walking in. I was surprised.

Nick is one of the planning and architecture folks at ESnet, the Department of Energy’s research backbone, and co-chair of the IETF’s IPv6 operations working group. He’s been doing this since 2002. He introduced himself with the line “one of my jobs is taking IPv4 out of the network.” Decommissioning it is his day job.

That framing is what flipped my brain on this talk. Most IPv6 evangelism comes from people who write papers and standards. While Nick writes those too, his day job since 2018 has been operating an IPv6-only network at international scale. When he says the FUD around running v6 only doesn’t survive contact with production, he’s saying it from inside production. That carries much more authority than the usual evangelist, who’s never been paged for it but deployed it in a lab once and hasn’t stopped talking about it since.

Half of the internet is already on v6

If you stopped paying attention to the adoption-curve graphs a few years ago, you missed the part where they crossed 50%… On weekends, anyway. The graph sawtooths every seven days, peaking when everyone’s home on residential broadband and dipping when Monday puts them back on corporate networks that never got v6.

Google’s own measurement puts global traffic at the 50% line. Cloudflare and APNIC read a bit lower, in the low 40s, but all of them still have the curve bending up. Nick pointed at 2020 as the moment the curve really starts to ramp, and he named two real drivers. Service providers doing CGNAT hit state-table problems during COVID and decided enabling v6 was cheaper than scaling more boxes. The US federal government mandated the move to IPv6-only across its networks, which dragged every fed contractor and vendor along. Both of those happened. But pull up the graph and look at the slope: the steepest climb is actually 2016 into 2017, and after that the line settles into a steady grind of five-ish points a year. Since 2020 it’s averaged under three. What COVID and the mandate did shows up as the line refusing to flatten. Nick’s better line was the Shawshank one, that v6 deployment is just the study of pressure and time. The graph agrees with that version.

In the US specifically, residential broadband leads even harder. Nick closed his talk with his own home flow data. Gig fiber, two kids, one wife, none of whom know what an IP address is, and 80 to 85% of the inbound traffic is IPv6. It just works for them, and they don’t have to care.

The phone in your pocket has been v6 for at least 10 years, depending on carrier. In a lot of cases, it’s v6 only, with CLAT and NAT64 handling whatever legacy apps your phone still talks to. T-Mobile literally wrote the RFCs. The App Store rejects v4-only apps. The device you trust with your calendar, your messages, your banking… it’s been running production IPv6 for years.

If you’re still framing IPv6 as “the next thing,” you’re a decade behind the data.

ESnet has run IPv6-only in production since 2018

This is the case study that made the talk land differently than every other IPv6 pitch I’ve sat through.

ESnet has been running an IPv6-only management network since 2018. Single stack, straight v6, for the management plane of an international research backbone: PDUs, optical shelves, batteries, the unglamorous gear the network itself runs on. It’s the network that operates the network.

In 2020, Nick’s office moved to IPv6-only as the DOE’s pilot for the federal v6-only push. That was a different beast, and he was honest about it. The management network has no humans on it. It’s hardware talking to hardware over a backbone he controls. An office has people. People have laptops, and laptops have Spotify, and Spotify is one of the apps that hard-codes IPv4 literals into places you can’t see. The web player works fine, it’s the desktop app that face-plants. Which means when a user complains they can’t reach a thing, you’re often debugging somebody else’s software, not your network.

The best story of the talk came out of that office move. One day he walked in and apps that hadn’t worked the week before were working. His first reaction was that somebody plugged v4 back into the network while he wasn’t looking. They hadn’t. Apple had pushed an OS update overnight that turned on CLAT on macOS. The translation layer made the broken apps work again. The fix lived in the operating system, where it should have been the whole time.

The whole case study is operational history rather than theory. The compatibility gaps were almost all in third-party software, and most are getting closed by CLAT showing up in every major OS: in preview for Windows, native in Android and Apple, installable in Linux. Windows is bringing up the rear, as it does. Once it ships in GA, the last real argument for v4 on the host is gone.

Most IPv6 talks don’t have that operational ground truth. Any random senior network engineer in that audience could argue against the theory, but it’s a lot harder to argue with somebody who’s spent the better part of a decade running it at scale and telling you what actually broke.

The hyperscaler RFC 1918 problem is the canary

Most of us aren’t out of 10.0.0.0/8. We’ve got room. We tell ourselves we’ll deal with v6 when we’re forced to.

Nick’s point: the people who get forced first are already there. The hyperscalers are running out of RFC 1918 space inside their own infrastructure. They’re stacking CGN’s RFC 6598 100.64.0.0/10 on top of 1918 to buy more headroom. They’re duplicating address ranges across regions, which means every internal connection now needs to know which copy of 10.42.0.0/16 you want, which means more state, more translation, and more places for the next outage to live.

You probably don’t have that problem today. The question is what your network looks like in 2030 when the AI infrastructure rollout has multiplied your endpoint count by some absurd factor. A single model serving cluster runs thousands of nodes, the training side wants any-to-any connectivity, and the inference pipelines want to talk directly to each other. Building that on a substrate of duplicated RFC 1918 space and stacked NAT is how you end up with the “shadow network” Nick described. Overlays on translators on translation pools, where every layer obscures the problem.

For AI infrastructure specifically, the architectural decision is being made right now. The clusters going in this quarter and next quarter are going to be in production for years. Whatever addressing model they’re built on is the addressing model you live with. If that’s stacked RFC 1918, you’ve baked in operational pain for as long as the cluster lives.

The angle I think gets undersold is that the hyperscaler pain is a leading indicator. By the time it shows up at your scale, the people who care about your bonus structure are going to want it fixed quickly, and “quickly” isn’t a good word to use in the same sentence as “v6 transition.”

Dual stack is the trap

Here’s where I want to plant a flag, because I think it’s where most networking organizations are quietly stuck, including some I’ve worked at.

Dual stack was supposed to be the transition. Run them both, get comfortable on v6, eventually turn v4 off. Nick’s framing of it as “Schrödinger’s trap” lands because that second step never happens. Organizations dual stack a network in 2015 and ten years later they’re still running both, which means they’re paying the operational cost of two address families forever, debugging both, securing both, and still paying for v4 addresses they “still need” because nothing got turned off.

Run both and you never get the v6 simplification benefit. You’ve got all the v4 baggage, plus the v6 implementation, plus the new edge cases that show up when both are running at once. The pitch of “v6 is operationally simpler” only pays off if v4 eventually leaves.

The plan has to include the off-ramp from the start. Otherwise dual stack becomes a new permanent state with worse properties than either v4 alone or v6 alone.

The off-ramp is the hard part. Telling leadership “we’re going to spend two years on the v6 implementation” is a normal conversation. Telling them “and then we’re going to spend another two years turning v4 off” is a different conversation, and the second one is the one that doesn’t get scheduled. Then five years pass, the original sponsor moves on, and the new VP wants to know why the network has two address families and double the monitoring tooling. There’s no good answer at that point.

Plan the turn-off when you plan the turn-on.

The performance angle most people don’t know about

This chart caught me off guard. I’d never seen the data laid out this cleanly.

The chart measures browser-to-resource latency to a long list of the sites at the top of everyone’s NetFlow reports. Blue is IPv6, red is IPv4. The v6 box is measurably lower across the board, and the per-site breakdown shows it’s not a single outlier. It’s most of them.

Nick’s test site is at ipv6.army, and he’s been collecting these numbers for a long time. The “why” is a conversation for the bar after the talk. Probably some combination of v6 paths being more direct because the v4 paths are loaded down with CGNAT and middleboxes, and the v6 hot path on modern OSes being the optimized one. But the empirical answer is: it’s faster, on the sites people hit every day, and it has been for a while.

The “no real advantage” framing some people still trot out is wrong. Latency is measurable, it’s better, and you can run the tests yourself.

The SMB multi-homing problem is real, and the solution isn’t well known

I’ll give credit to the question from the audience that got the room nodding. The questioner asked about the small-to-medium business case. You don’t have BGP. You don’t have provider-independent space. You want to multi-home. What’s the story?

Nick was direct that this is a hard problem and there’s no elegant answer yet. Single-homed v6 with prefix delegation from one upstream is basically solved. Multi-home with two upstreams and no BGP is where the story gets ugly.

The options are written down, mostly because Nick wrote them down. He authored an IETF draft years ago cataloging how to multi-home a site without BGP. The pairing that matters for the SMB case: ULA (Unique Local Addresses, RFC 4193) gives you stable internal numbering that doesn’t change when your upstream does, and NPTv6 (RFC 6296) does prefix translation at the edge so those internal hosts map cleanly to whichever upstream prefix is currently providing connectivity. No BGP, no PI space. Nick’s own grade for the options was “not pretty” but supportable, and he’s employed them himself. Almost nobody knows about any of this, because the SMB world has been told for a decade that v6 multi-homing is impossible without BGP.

For the transition story more broadly, the toolbox is bigger than people realize. 464XLAT is what your phone is already doing. MAP-T, DS-Lite (RFC 6333), and NAT64+DNS64 (RFC 6147) cover most of the other deployment shapes. The mobile operators have been running these in production at hundreds of millions of subscribers for years.

The mandate clock is ticking

50-plus countries have either a v6-only mandate or a strong push to enable v6 across all networks by 2030. The US federal backbone is already mandated. The DOE pilot Nick’s office was part of is a piece of that.

You can argue with whether mandates work. You can’t argue with “the federal government is one of your customers and they’ve told you what their network looks like by 2030.” If you sell into government, healthcare, defense, or energy, you’ve got a hard date. If you don’t, your peering partners and your transit providers do, which means the upstream pressure shows up regardless.

The window for “we’ll do it when we have to” is now narrower than the timeline of an enterprise network refresh cycle.

What changed my mind

Going in, I’d have said the IPv6 problem was mostly a training problem and a political problem, and the technology was fine. I still think that’s mostly right. What changed for me sitting in the room was the timeline.

The “we’ll train people when we have to” position is now a 30-year-old position. The hyperscalers, the federal mandate, and the AI buildout are all moving on this decade’s timeline. The dual-stack-forever organizations are going to find themselves paying for both stacks indefinitely while the rest of the internet moves on without them.

The barriers Nick laid out are real. The SMB multi-homing gap, the third-party software gap, the training gap, all of them are organizational and educational now, which means they get solved the only way those problems ever do: people deciding to do the work.

Nick’s advice for the room was “be the squeaky wheel.” Ask your vendors for v6 parity. Tell your leadership the plan needs an off-ramp from v4 to go with the on-ramp. Start your pilot this year, even if it’s a tiny corner of the network. The protocol works. The barrier is that nobody made you do it yet.

The IPv6 textbook he co-edits is free and open at ipv6textbook.com. His test site is ipv6.army. Read both.

If you’ve been hearing the v6 pitch and tuning it out, this is the one I’d point you at. Plenty of folks have been beating this drum just as hard. Nick stands out because he’s running it at scale, and he can tell you what broke and what didn’t.

I’m planning my first v6-only lab corner this quarter, which should have happened years ago.

The full talk

The recording is live, and it’s the v6 pitch I keep telling people to go watch.

Disclosure: I attended Nick Buraglio’s session at CHI-NOG 13 in Chicago. CHI-NOG didn’t comp my registration or travel. ESnet didn’t buy me anything. The opinions here are mine. For more, please read my full disclaimer.