Skip to content
IPB208: IPv6 Address Management Is Broken artwork

IPB208: IPv6 Address Management Is Broken

The Everything Feed - All Packet Pushers Pods

September 17, 2026

Traditional IPAM and DDI tools struggle to handle IPv6 at scale because they were originally designed around IPv4. Today Ed and Tom examine the visibility challenges posed by SLAAC  addresses, broken DNS integrations, and massive prefix allocations.

Speakers Ed Hoerle, Tom Kauffman

TopicsTechnology

Ed Hoerle (0:10)

This episode is sponsored by Megaport. Eligible new customers can get one month free on one eligible Megaport port, and Megaport Cloud Router to test private connectivity and cloud routing in their own environment. Visit megaport.com/buzz to get started. Terms and eligibility apply.

Welcome to the IPv6 Buzz Podcast, where we dare to dive into the 128-bit address space wormhole. I'm Ed Hoerle, Tom Kauffin is on with me, and Nick Baraglio is out on assignment. As usual, beautification, making himself look better.

Tom Kauffman (0:43)

Looks maxing. It's what everyone's doing these days.

Ed Hoerle (0:47)

So we wanted to chat about whether your IPAM and your DDI tools are ready for IPv6 scale. Because I think most folks probably are using some sort of DDI solution set, or maybe doing a one-off and just doing maybe some DNS and DHP configuration, maybe not doing the IPAM portion.

But it's one thing to get it up and working in a lab, and just to get it functional, which is definitely a doable thing. And you can absolutely get that up and working. But there's a whole different set of challenges that come along with trying to do it at scale. And I guess we should define what we mean at scale. For most enterprises that are running a distributed DDI platform configuration of some type, whether that's a commercial product or they're doing it themselves, bake from open source, the reality is that coming up with high availability, redundancy, how do you build in redundancy, how do you deal with all the related dependencies that are going on with allocations and scope management and hygiene and address tracking and all that other stuff, actually becomes a really hard architecture and design problem to figure out about how you want to do it at scale. And so we wanted to just take a little bit of time and talk our way through some of the things that we think are maybe major issues or things to consider in working our way through that. So I guess we'll kick it off and start from there and really talk about maybe some of the first challenges that go on for everything that we talk about with V4 and V6, which is the scale difference. There's just a fundamental scale difference between V4 and V6. So if we talk about that first, like what are the things that are different?

And maybe just some of the obvious ones for things like maybe DNS. You're probably not going to use Origin and just pre-build a bunch of stuff or do the same thing in your DHCP V6 platform. You're not going to pre-build to the 64th addresses in a database and figure you're not going to assign them. I think you're going to want to have that be dynamic and not something that you set out handing out addresses one by one, which we're probably very familiar with doing in IPv4, right? Is actually knowing that we can assign all the addresses in a slash 24 is a relatively easy and reasonable task that you could do even in a spreadsheet. You don't even need an actual tool to do that, but that becomes an impossibility in the V6 world. And I guess that would be the first place to start, and that's where the tools make the most sense, right? In terms of actually leveraging those tools.

Tom Kauffman (3:44)

I think there's another more fundamental problem in that you don't have kind of operational model choice in the V4 space that impacts scale in the way that you do in V6, where you have to make decisions about how you're going to allocate IPv6 addresses and you have to use the technologies that are available to allow you to do that, which are Slack and DHCPv6. But that environment is by no means super deterministic for all enterprises in terms of, well, just turn this on and it'll work in the way that you've been managing your IPv4 resources and endpoints with IPv4.

You have to make some operational choices that have pros and cons that mean that a lot of enterprises, I think, that we've run into in agencies, they haven't really gotten to the point where they've made firm decisions about what that operational model is going to look like. And so even before you get to the scale question, you're like kind of stuck in this limbo of like, well, which operational model are we going to use? And now it's to the good that we have IPv6 mostly coming on the radar here, across the board with endpoints, OS endpoints. But it further complicates the question. It's like, which...

Ed Hoerle (5:03)

Well, I guess I would argue it actually provides clarity to the question because it forces you in one direction. If you want to use IPv6 mostly, you can only use Slack, and therefore, at least in the current implementations in the RFC standards, that's the only option that you have.

24 more minutes of transcript below

Thousands of transcripts fetched by people building searchable podcast archives

Fetch the whole transcript

The demo key returns a sample episode in full, no card needed:

request
curl -H "x-api-key: pt_demo" \
  https://spoken.md/transcripts/1000651996090

Markdown with the speakers named, for your notes, your knowledge base, or anything that makes HTTP calls.

From $0.10 per transcript. No subscription. Credits never expire. Prices exclude VAT, added at checkout for EU customers. Not what you expected? Email us within 14 days with 20 or fewer credits used and we refund the pack in full.

Using your own key:

request
curl -H "x-api-key: YOUR_KEY" \
  https://spoken.md/transcripts/1000790389228