IPB209: SREs Are Breaking IPv6 — And They Don’t Know It Yet

Ed Hoerle (0:10)

Well, welcome to the IPv6 Buzz, where we dare to dive into the 128-bit address-based wormhole. We're glad you joined us today. I'm Ed Hoerle, got Nick Boraleo on.

Tom Cuffein is out on assignment, so you're stuck with all of us today.

Nick Boraleo (0:24)

This is my first video.

Ed Hoerle (0:27)

Yeah, we are doing videos, so if you want to catch us on YouTube, you can see what we look like. I don't know if that's helpful or not, but hey.

Nick Boraleo (0:35)

Probably not helpful. They're going to put us right back to audio only after this one.

Ed Hoerle (0:42)

So we had a couple of things that we were mulling over, and one of the things that sort of came up was really talking about sort of getting across the last bit of the finish line with IPv6 and the fact that there's a gap that exists in terms of getting to sort of v6 only. Even if you've got your network entirely ready, you've got IPv6 mostly, got v6 running in your data center, you got all these related components and network and firewall and everything else, all dialed in. But that last little bit that you have to crawl across is probably going to be pretty painful because you're going to be dealing with teams that you probably don't have ownership over, any control over, and you're hoping that they're just going to come along for the ride and do the right thing, but that might not necessarily be the case, right? And we're going to talk about SREs and developers, right? And what their roles are in helping to get v6 across the finish line. And maybe some of the hurdles that you're going to face when talking to them.

And they've been sort of absent in both the ITF in terms of contributions and sort of the v6 ops groups and any of the related sort of working groups around what needs to happen specifically for IPv6. And as a result, I think you're going to find that you're going to see a bunch of technical debt related to trying to get v6 up and operating for services that they may be responsible for maintaining building and having operational ownership for. So we thought we'd kick it off with that as a topic.

So I guess the salacious thing is maybe the SRE and your developers are sort of breaking your IPv6, but they just don't know it yet.

Nick Boraleo (2:31)

Yeah, I mean, I think that there's probably going to be two diverse paths here, at least in my experience. There's going to be the developers that are just kind of relying on the underlying operating system. They don't care about networking.

They're using DNS names for things.

So if the libraries that they're developing against support IPv6, it will just work in IPv6 only. And then you have the other side of that coin, which is we're developing network applications and we're only considering IPv4 because that's all we've ever done before. And so even in a dual stacked environment, again, we've talked about this many times, how it sort of covers up any type of problems by falling back to the legacy protocol. Once you take that safety net away, none of my stuff is working. Well, you don't have that protocol anymore. And so there's the whole process of educating how to essentially backport all of what they've done to support a new, backport, support a forward-looking protocol. That makes sense. Two steps forward, three steps back. I don't know. Something.

Ed Hoerle (3:47)

Yeah, I think one of the challenges becomes that while the networking stack may be available, and assuming that you're starting a dual stack and then moving to v6-only data center, that stack may have been available for a long time for them to be able to test and validate that their v6 is actually working. They probably never took the step to do that, number one. Right, so that's the first hurdle that you have to overcome of saying like, hey, it's available on the network, you need to test to make sure your application actually functions on v6-only.

And so we're going to provide you a v6-only VLAN to migrate your services over to and confirm that you can function properly. That's a lot of extra work for a team, right? And so you're asking them to basically do a whole set of proof and validation and testing that maybe they never had to do before. So you're going to get resistance on that front. Assuming that they're okay with that and they go ahead and set it up, let's say they actually run into a problem. They discover that they have a v4 dependency of some type within their code, within their library. Then you're going to deal with the entire, how long does it take to actually change code in production to fix that related problem? And are they willing to fix that related problem based off of just the fact that it can't work with IPv6?