IPB182: IPv6 Transition Technology Options | Packet Pushers
Transitioning from IPv4 to IPv6, or at least IPv6-mostly, is no easy task. Today's show provides some education and advice about IPv6 transition mechanisms. We cover options such as NAT64, DNS64, PREF64, and more, as well as use cases. Also, if your . . .
Transitioning from IPv4 to IPv6, or at least IPv6-mostly, is no easy task. Today’s show provides some education and advice about IPv6 transition mechanisms. We cover options such as NAT64, DNS64, PREF64, and more, as well as use cases. Also, if your technology vendors aren’t offering some of these mechanisms, ask for them – you’re probably not the only one who has an IPv6 transition project. Episode Links:List of public NAT64+DNS64 providersnat64. xyzRFC 8925: IPv6-Only Preferred Option for DHCPv4RFC 8781: Discovering PREF64 in Router AdvertisementsRFC 6147: DNS64 – DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 ServersRFC 6146: Stateful NAT64 – Network Address and Protocol Translation from IPv6 Clients to IPv4 ServersIPv6 transition mechanism– WikipediaIPv6 CompatibilityEpisode Transcript:This episode was transcribed by AI and lightly formatted. We make these transcripts available to help with content accessibility and searchability but we can’t guarantee accuracy. There are likely to be errors and inaccuracies in the transcription. Ed Horley (0:04 – 0:10)vWelcome to the IPv6 Buzz, where we dare to dive into the 128-bit Azure Space Wormhole. I’m Ed Horley. Nick Buralgio (0:10 – 0:17) And I’m Nick Buraglio. We discuss everything IPv6 on the show from strategy, design, deployment, operations, and even internet standards. Tom Coffeen (0:18 – 0:24) And I’m Tom Coffeen. We’ve spent 20-plus years working with the IPv6 protocol. We work on getting IPv6 working. Ed Horley (0:24 – 0:28) And we’re here to share some lessons learned on how to avoid common mistakes. We’re glad you joined us. We wanted to talk about some of the specific details around transition technologies for the show. Because, you know, and specifically probably why you would use one over the other. There seems to be a little bit of confusion out there about why you would use a given set of transition technologies to solve a given set of problems. And so we wanted to talk through a few of them and just give some thoughts about why you would choose one over the other or why you might not be able to use one over the other. And sort of break it down from there. So I wanted to start off with sort of maybe one of the oldest sets of sort of transition technologies that’s been in use. Which is really NAT64, DNS64 as really sort of the stalwart in the room. It’s been used, proven, and definitely functional. And it seems like there’s some question about whether NAT64 or DNS64 should even be in the transition tool belt. Because of the introduction of PREF64 and option 108 and everyone being super excited about those sets of capability. Which I’m excited about too. I think it’s super useful. But maybe we talk about why you wouldn’t be able to use that and why NAT64 or DNS64 might be something you’re still leaning on. So I’ll open it up from there. Tom Coffeen (1:49 – 2:07) Well, we were just discussing it a little bit before we started recording. And I think there’s agreement that we don’t have a ton of PREF64 support yet in router and switch platforms where we really need to rely on it for IPv6 mostly to function. Nick Buralgio (2:09 – 3:14) Yeah, I mean, I think it’s easy to find software implementations, you know. So if you’ve got like an OpenWrt router or like a Mikrotik router or things that are primarily software based that may or may not have hardware offload. That’s much easier to find an implementation. But if you have a very large installation of major vendor of choice, right? There’s probably a pretty long tail to getting the appropriate support. And it may not be, you know, they may not have that option at all. And whatever, you know, if your platform is nearing its end of life. So I think that that’s a consideration that it’s easy to look at like what’s available for somebody to run at home or, you know, in a Soho environment. It’s very likely based on Linux, which has a pretty robust implementation. And then sort of forget that like there are, you know, like there are major platforms out there that don’t have any support yet. Tom Coffeen (3:14 – 3:15) Yeah. Ed Horley (3:15 – 5:48) Yeah, that’s a really important point. When you’re evaluating, understanding what your products can and cannot support from a base fundamental level is going to be super important. So just jumping on board the PREF64 Option 108 bandwagon because it’s a new shiny object, which, you know, we all want to do. I think might not serve you the best depending on what your topology and hardware and deployment actually looks like. So that’s a great point. I think also, you know, not that PREF64 and Option 108 aren’t particularly proven out, but NAT64, DNS64 we know works at scale in very large environments. And it’s been tested and proven and is supported by many, many major manufacturers for both the NAT64 side and the DNS64 side. And so there are considerations around just support, stability of code, prior implementation experience that might influence your decision about how you want to leverage NAT64, DNS64 to solve a given set of transitions of, you know, IPv6-only clients trying to reach to IPv4 resources, whether those are internet bound resources or whether they’re internal resources. And you can do both with NAT64, DNS64, and obviously the PREF64 options, you can do the same. But I think the reality is these are proven. You might even use a belt and suspenders approach of you’re still going to need a NAT64 device in order to do the PREF64 components, right?Tom Coffeen (4:49 – 4:50) Right, exactly. Ed Horley (4:51 – 5:33) So having DNS64 really isn’t going to hurt you in any, at least as long as you’re not deploying it improperly. I guess I should put that caveat in. But, you know, I think understanding how your apps work is super important. And DNS64 gives you some visibility in terms of how your applications are actually performing or whether they’re doing DNS lookups for the resources they’re accessing. And maybe if they fall through, then your PREF64 and Option 108 stuff might take over from there. And then you get the best of both worlds and you get a capability to be able to log and track and know the difference between them. Nick Buralgio (5:34 – 6:47) I think it’s also important to understand that, you know, IPv6-mostly and PREF64 is probably the ideal. I mean, that’s the goal, right? DNS64, it’s the devil that we know. Right. It clearly scales and you need a NAT64 in either case. So I think one of the things that I think may be clouding some of the understanding is, you know, what does the 464XLAT suite look like? Right. So like, you know, we talk about CLAT all the time, right? Because we desperately want it in every end operating system. But we leave out the NAT64 a lot because we kind of expect that people know that’s what it is. Right. You know, the PLAT part of that. So PLAT, the Provider Address Translator, is the same thing as your NAT64. Those are essentially synonymous. And you have to have that either way, even if you’re running, you know, no DNS64 and PREF64. Ed Horley (6:48 – 7:29) Right. Yeah, there’s some, I think there’s some hesitancy on certain teams to not have some sort of DNS inspect method or some sort of capabilities to understand what’s going on there. And then secondarily, I guess, you might be limited in terms of you might be doing DHCPv6 only options. In which case you might be limited in terms of your support capabilities for CLAT, because those require SLAAC, right? So even if you had a CLAT on the client, if you’re doing DHCPv6 only, and you’re not making use of SLAAC at all, you actually don’t get to leverage the CLAT even if you have it on your machine. Tom Coffeen (7:29 – 7:29) Yeah. Ed Horley (7:29 – 8:15)Which I think is a, it’s one of those weird technical nuance points. But that’s just the reality of the today sort of implementation and standards basis. That’s where things are at. So if you’re in a shop that’s doing DHCPv6, and that is the only method of address allocation assignment that you’re doing, the CLAT isn’t available to you. And so DNS64 and NAT64 really is your only option then because it doesn’t matter if you want a PREF64 and you have option 108. You’re not going to get an address for the CLAT to operate on. Maybe a minor technical point, but an important one for those that might be constrained in that particular way. And don’t realize that that’s a dependency for the CLAT to operate. Tom Coffeen (8:16 – 10:59) So it’s all very dependent on the operational environment as you’re getting at it. Differences in operational environments are going to change what choices you have, what options are available to you. And I think maybe starting from the first case of an enterprise environment where they’re likely dual stack today. Because I don’t know that we’re seeing, it’s not like you’re seeing IPv6 adoption going from, hey, we’re a v4 only shop. We want to get involved in v6 and get it up and running. And they’re going to go straight to attempting IPv6-only or IPv6-mostly. So what we’re really talking about is migrating from a dual stack environment to either. And the goal, we might say, at least initially now because of the new technology with mostly, that that’s the goal. But ultimately the goal is IPv6-only with the recognition that v4 will eventually need to be turned off. And mostly kind of gets us there, gets us as close as we’re going to get to that, while still maintaining sort of IPv4 as a service. But it’s all predicated on what your environment supports and what you have to support in your environment. So for big shops that have a lot of just off the shelf software and applications and SaaS and stuff like that, where they’re not going to run into a scenario where they’ve got old code that’s plugging IPv4 literals into things. And then DNS64 might actually be a great option. But then, of course, you butt up against the lack of support for, say, DNS64 on Microsoft DNS platforms. So unless you’ve actually moved away from that in your environment, then you’re kind of stuck without a good option to run a DNS64, unless you figure out how you’re going to upgrade your DNS infrastructure to a platform that supports it. And so, you know, maybe then v6-mostly looks more appealing based on that lack of support. But anyway, there’s just essentially a bunch of mix and match components within your overall enterprise environment that are going to dictate what’s available to you and on what timeline. And, you know, we always try to be pretty agnostic about it and say, you know, what works? What’s going to get you the operational model and set of models that’s best for your environment? And best, you know, and whatever flavor of v6, whether it’s DNS64, NAT64, you know, or it’s IPv6 mostly, or it’s both. Frankly, you know, you could easily run into scenarios where it makes perfect sense in a data center, say, to do DNS64, NAT64, and maybe on a user segments, it’s, you know, mostly as a better fit. So it just really just depends on the environments. Nick Buralgio (11:00 – 12:59) Yeah, you touched on something there that I think is kind of a dead zone that a lot of folks, I’ve missed it myself. And that, you know, if you’re running, if you have an environment that you control end to end, like say you’re in an enterprise where you control the desktop, you control the software load, you control literally every aspect of IT, then you can get away with a lot more things, right? Because you have full control over it. But I don’t know. I mean, maybe I live in a bubble or whatever, but I have never been in that kind of environment in my entire career. So, you know, you get into these situations where, let’s say, for example, you want to move to IPv6-only via IPv6-mostly, but you don’t control all the systems that are plugging into your network or getting onto your wireless. I would say that’s probably whatever. I’d say it’s a high percentage of environments. You’re going to have to support every aspect because you have to support every scenario. So if you’ve got, you know, Windows 10 systems that are jumping on your network, they’re not going to support, they’re never going to support CLAT. They’re never going to support, you know, a bunch of these transition mechanisms. And so if you put them on an IPv6-mostly network, then they’re going to be dual stack. But then you might have, you know, other scenarios where you have something that does, you know, it will be either by misbehaving or not turn off IPv4, but it doesn’t have a CLAT. So how is it going to get to any IPv4 resources at that point? You have to have a DNS64 in there somewhere to account for those like kind of fringe. I don’t even know if I call them fringe, but let’s call them fringe just for argument’s sake. Those edge cases that just don’t have all the pieces yet. Legacy environments are going to have a lot of this, I suspect. Ed Horley (12:59 – 17:32) Yeah. And IoT and OT platform environments are going to have a lot of that too, because you don’t necessarily know how they’re coding, how they’re doing discovery for resources, whether they’re expecting a certain set of behavior for public services or not. So those are the things that become challenging. I think there’s, and we talk about NAT64, DNS64, and obviously the CLAT side, PREF64 and option 108. We’re really talking about client side. We haven’t talked a tremendous amount about the server side of the equation, but do realize that you still have your trusty utility belt of server load balancers or application delivery controllers to be able to help solve that end of the equation that talks in both directions. You can talk six on one side, four on the other, four on one side, six on the other, six to six, four to four. All the regular options that you have available to you there. So data center looks a little bit more like, almost like a dual stack service block architecture where you can talk either language depending on what the client devices are doing and coming in. And so what you’re really manipulating is from that, how that client is accessing resources at the edge. And does it need an access for DNS64 environment to support what it needs to do to connect to resources? Or can it live with the PREF64 option 108? Either way, you’re trying to get them to sort of stick on v6, even if they’re need to access v4 resources, right? That’s the sort of goal that we’re after in all of this. Otherwise you would just run dual stack and let four be four and six be six and you’d be done with it. And you wouldn’t have to worry about it. That doesn’t really save you from an administrative operation burden standpoint, right? Which is not insignificant, I think. And so the consideration, can we move a large portion of our deployment into a single protocol makes a lot of sense. And moving to v6 using these transition mechanisms helps you to do that. It also helps you to modernize your application stacks because you will identify very quickly something that’s breaking either in DNS or something that’s not making use of DNS or not making use of sort of modern coding practices. And it will allow you to sort of hopefully go back and get rid of some technical debt, right? In terms of applications that might be in need of refresh or replacement or just outright end of life off the network because you don’t need the service anymore, right? So this helps you figure some of that out. I think the other one that we don’t really talk about much is stateless IP ICMP translation, which is basically translating between v4 and v6. We don’t talk about it a lot because it’s probably more applicable for managed service providers or others who have to operate a v6 network themselves because they’re out of resources, but they need to talk to a tremendous number of v4 resources. That might be overlapping RFC1980 space. Maybe they’re doing managed service clients and they want to connect in. So you can just assign a 64 prefix to each one of those related managed services and be able to connect to them remotely and map their v4 addresses into the v6 prefix automatically, which makes them unique, which is sort of cool. And it doesn’t care whether it’s RFC1980 or whether it’s the actual v4 global unicast address sort of scenario. So that works really well. But I would say for most enterprises, unless they’re dealing with a lot of NAT translation, maybe you’ve got a lot of services, a lot of overlapping services, you can make use of SINT within your data center to sort of solve those related problems. So making things unique within a v6 address space so that you don’t have to deal with translation as much and push that service all the way to the edge instead of dealing with like a large NAT related device. I don’t know. Is there other things that we’re missing off the translation list that we should be mentioning? Anything you can think of? We spent the show talking about 464XLAT and what really happens with all of that. So I recommend go back and listen to that specific show around the PLAT and CLAT and what goes on there. And that’s all leveraged by obviously the PREF64 and option 108 to be able to figure that out. But 464XLAT has been in existence for a long time because that’s how every major mobile provider gets you on the IPv4 internet today. Nick Buraglio (17:26 – 17:29) I think that RFC is 12 years old at this point. Ed Horley (17:30 – 17:31) Yeah, if not older. Tom Coffeen (17:32 – 17:35) Yeah, it’s battle tested for sure. Ed Horley (17:35 – 18:00) Yeah, so that was Cameron over at T-Mobile that drafted all of that up. So that stuff is super well tested and proven. I think what’s happening now is we’re seeing that well tested proven technology making its way into the enterprise. That’s what we’re seeing is that transition of leveraging that in that capacity. Nick Buralgio (18:00 – 18:40) Yeah, I mean, I think it’s important. I don’t think it can be understated how well tested and how well supported the 464XLAT suite is. And this is something that I will often bring up when, you know, it doesn’t happen as much anymore. But the inevitable nobody uses IPv6 argument that comes up. It’s like, well, you’ve been carrying around probably an IPv6 only device in your pocket for like a decade. And that technology is extremely well supported and very well understood. So it is not new at all. Ed Horley (18:40 – 18:48) Yeah, you’ve been posting your we don’t need v6 mean tweets via IPv6. Nick Buralgio (18:48 – 18:52) Yeah, yeah. Oh, yeah. There’s a person called Kevin Myers there. He just posted a pretty good one on that. Ed Horley (18:52 – 21:09) But yes, it’s definitely one of those things you need to figure out in the puzzle of what you’re trying to solve for. Things at home look different than things at a small business, look different than the things that enterprise look different than the things that a cloud or a managed service provider. And the given sets of transition technologies that you’re going to use are going to differ based off of what is in your environment and potentially what maturity those things are at in terms of what risk you’re willing to take. I think if I’m in a super regulated environment, I’m probably going to lean on NAT64, DNS64 and make sure that I can see all the records and I can get the data I need. And I might put a backup in there of PREF64 and option 108 for things that fall through the cracks to try and capture them. But I don’t know. There’s different strategies. Do you use a well-known prefix? Do you not use a well-known prefix? And there’s different nuanced decisions around like, well, if I use a well-known prefix, maybe I just capture that and steer that to my main security data center locations. So that way I capture people that are using the well-known prefix without really knowing that they should be. So I at least go and capture the transition and say like, hey, your app is doing this. Were you aware of that? Versus doing a specific prefix from your known block. And then you’re obviously seeing the applications that are using the PREF64 options and getting the right information from the NAT64 side to go out and do the right thing. So that gives you a lot of insight about what your applications are doing inside your network. So there’s a lot more nuanced decisions that need to go on. And then that’s scale. Do I distribute this? Do I centralize it? There’s different scale considerations. The reality is this NAT64 has been proven to scale out very, very well. And DNS64 also. And DNS64 really is not that much of an additional burden on top of the existing DNS resources that you probably are already operating. So you’re going to see pretty good results there. And I think, are both services available? I know DNS64 is available on, I think you can get it from like CloudFlare and a couple others, right? To be able to make use of theirs. Nick Buralgio (21:09 – 21:17) Yeah. Google has it. CloudFlare has one. And they both use the well-known prefix, if I’m not mistaken. Yeah. Ed Horley (21:17 – 21:25) So if you want to leverage them, you can. I don’t know about the NAT64, if there’s actually any NAT64-related open services. Nick Buralgio (21:25 – 21:25) There definitely are. Ed Horley (21:26 – 21:26) Yeah. Nick Buralgio (21:26 – 22:04) I actually run three of my own that are geographically diverse in the U. S. And they have a DNS64 that does not use the well-known prefix. It uses one of mine. Right. Because it’s also out and about, and it directs towards my NAT64s. But there’s, I think it’s called nat64. xyz or something like that. There’s a website that actually, the guy reached out to me when he found mine and said, hey, can I list these? Because he has a list of public NAT64 systems out there. Let’s see if I can figure out what that is. Ed Horley (22:05 – 22:07) Just remember, you’re trusting someone else to translate your traffic. Nick Buralgio (22:08 – 22:13) Yes, there is a huge caveat. You’re transiting a router you do not control. Tom Coffeen (22:14 – 22:17) So watch out for those . ru NAT64. Ed Horley (22:18 – 23:12) Yes, seriously. But I think it’s important for the audience to realize that when we’re talking through use cases scenarios, we’re trying to make sure that we’re talking through ones that we know are mature, well-established, well-supported. We definitely want to keep track of and encourage people to test out, use, and push the envelope on the stuff that’s new and current. But just realize, you may not have that as an option. And you’re only going to be able to design and architect around the things that you have within your utility belt, as it would be. And making sure that you have ones that are well-known and that you have capabilities to leverage. I think those are going to be top of my list. And that is one of the reasons why we talk about NAT64 and DNS64 so much. It’s exactly for that reason. I don’t know, Tom, Nick, anything to add to that?Tom Coffeen (23:12 – 23:37) Yeah, not really. I mean, that sums it up. I think we tend to have a bit of an enterprise network bias in terms of how we look at things and talk through things. And sometimes I think the soho folks and home users maybe wrinkle their brows at what we may be suggesting. But I think that’s, if anything, it’s a bit of an enterprise bias on how we look at things. And larger enterprise, for that matter. Nick Buralgio (23:38 – 24:50) Yeah, I mean, I definitely appreciate the – well, having a million years ago working, running an early broadband ISP, the power users sort of drive a lot of the innovation at a very low level. So I definitely appreciate the folks that are chiming in with the questions and the comments and stuff that are like, or I have a small office and I want to do these – I want these big office features in my small office. Those are the kind of things that we have to just keep hammering on because it’s easy for someone to say justify features when you have a gigantic multinational company that’s buying $500 million worth of equipment. But other people might want some of those features too. And so as people see how things work, it’s okay to ask for those. I would argue you should continue to ask for those things in an increasingly loud volume. Because that’s how we get innovation, right?Ed Horley (24:51 – 25:38) Yeah. And repeating on saying PREF64 is the way forward, or being able to talk to your vendor and understanding what limitations they have and saying, well, how come you aren’t adding this in there? What do we need to do? What should be informing our buying decision because this is something we want? I think those are important conversations to have. So I think those are important things for the audience to do is to go out and say, hey, I don’t have this option available to me because of the fact that you aren’t supporting it in your platform. What’s your roadmap? What does that look like? When is that going to come? And you can make good decisions based off of your knowledge level and where things are at, which is part of what we’re trying to provide is a little bit of context and a little bit of knowledge. A little bit of knowledge will make you dangerous. Nick Buralgio (25:40 – 25:50) That’s right. And if you don’t know if your equipment supports it or if you’re looking to buy equipment and you want to know some more, there’s a website that you can go to and check the compatibility. Ed Horley (25:51 – 26:49) Yeah, you can check the ipv6compatibility. com and browse around and check it out. But yeah, I hope that helps folks in terms of understanding some of the transition stuff because we realized maybe we don’t provide as much context in the show around exactly which use cases make sense. If there’s questions about this specific one or you guys have other interesting nuanced areas around the transition technologies, why you would use one versus the other, at what point, we’d love to hear from you. So definitely do hit packetpushers. net slash fu for the follow up and let us know. We really appreciate all the notes we’ve been getting. We’ve been getting quite a few messages recently, so we really appreciate that because it’s definitely been interesting hearing what everyone is up to and what folks are actually doing. So we really appreciate the feedback. Thanks so much. Nick Buraglio (26:49 – 26:50) Yeah, keep them coming. They’re all good. Ed Horley (26:51 – 27:03) Thanks for joining us for this episode of IPv6 Buzz. If you’ve got feedback or follow up on this topic, send us a message at packetpushers. net slash fu, where fu stands for follow up. We’d love to hear from you and continue the conversation. Nick Buralgio (27:04 – 27:09) Also, at PacketPushers. net, you’ll find a range of other deep dive technical podcasts for IT pros. Tom Coffeen (27:10 – 27:23) There’s a whole lot more on the Packet Pushers site as well, such as tutorial videos and a community Slack channel where you can talk with industry peers and experts. So whether you’re deep in your career or just starting up, PacketPushers is the place to go to grow both your skills and your personal network. Ed Horley (27:23 – 27:26) So long and until next time, we’ll see you on the IPv6 internet.