IPB196: Is End-to-End Connectivity the Right Goal?

0:00Welcome to the IPv6 Buzz, where we dare to dive into the 128-bit address space wormhole, I'm Ed Horley, and I'm Nick Barolio. We discuss everything IPv6 on the show from strategy, design, deployment, operations, and even internet standards. And I'm Tom Coffey. We've spent 20 plus years working with the IPv6 protocol. We work on getting IPv6 working. And we're here to share some lessons learned and how to avoid common mistakes. All right, welcome everyone to another IPv6 Buzz episode. And we're going to talk about something a little different. We're going to talk about some design principles that I think the industry just assumes overall. And the design principle is really end-to-end connectivity. And so let's sort of talk our way through that because I think the industry has this concept that the end-to-end principle is the brass ring of how the internet should behave and the great thing that we lost

1:00with IPv4 and NAT, when we introduced IPv4 and we needed to do conservation of address space, we introduced network address translation and that we somehow lost some of our core basic principles when we adopted that. He said the industry, but I don't know. They're talking about the IPv6 industrial complex. I don't know if it gives a hoot about end-to-end connectivity. In fact, they richly profit off of not having end-to-end connectivity. Let's talk about the origins way back in the day. From a IPv4 perspective, the original concept, prior to RSC 1918 being introduced and having private address space, everything was a public address in the same way that V6 is. And really the goal was, peer-to-peer connectivity was a thing. You could directly make your resource available on the

2:02public internet. And if you choose to advertise it, it was reachable and you could provide services off that address. And those decisions were yours to make in terms of what you would provide or make available to other individuals. How you choose to advertise it was primarily through DNS, in terms of being able to find that given resource if you wanted to make it globally accessible. That was how things started off. And then there was a shift in the industry as probably more commercialization of the internet occurred. And more consumption of address space was happening. We needed some way to conserve those addresses. And there was also a new manifestation of a large number of networks that were connecting. That didn't have any requirement of providing resources. They just were consuming things off the internet. So they were consumers of the internet, not necessarily providers of services on the internet. And so that changed the dynamic of the relationship and saying, well, I don't need to provide services. In fact, I don't want to provide services at all. I only want my end users to really consume services. So I want to hide everyone

3:06behind, like, instead of addresses or resources. And I don't want them to be able to advertise any resources because I don't want anyone, you know, being able to get into something on our network, like at all. So I think maybe those are sort of the major factor changes that sort of occurred was the conservation of address space and the fact that we had a changing demographic of who was consuming services or providing services on the internet overall. Is that fair or seem like a plausible, at least a plausible story. I'm sure people can poke holes in that one. But I've gotten my pen right here. Let's start poking holes. Yeah. And I've got a soap box. Here comes the hiding on the soap box right now. Here comes the first of many hot takes in this episode. Yeah, there's going to be a few of those. So when I think it's going to be obvious because of the folks that are talking here that most of us sort of got started with that before there was a no shit like everything just had, there was no resource constraints, right. You

4:08could just get the addresses that you needed. And you know, if we even go back from prior to dial up days, you know, it was, this was all like research stuff. And so everybody just essentially had all you could eat everything when it came to addressing. There was very little limits on it then. And then that sort of morphed into, if you kind of skip over the BBS days because that's really sort of a different beast, you go straight into like the dial up internet phase where every end node, these are all consumer nodes, right. They were providing services. They all had to have a specific address on them as you dialed up, but they were ephemeral. So they would come and go, you know, depending on what kind of service you had might be an hour, it might be eight hours, right. You had a limit. You weren't just going to leave it dialed up unless you were like me who had a separate line that ran dial B all the time, right. And so

5:12that just didn't really, like it didn't really matter that you had an address at that point. There were things that sort of popped up like when new can other stuff like that, which of course we all played with and having a public address just sort of made that more doable. But for the most part, I think that whenever this really started to shift, was the advent of broadband networks. And I was in the middle of that when that happened, right. I was in the, you know, worked for internet provider. We were very early doing broadband deployments. And there was no notion of, if you had more than one computer, we basically had to provision you more IP addresses, right. And that was fairly, you know, it was new. But then as broadband started proliferating everywhere, this miracle or whatever happened. Oh, I have computers in my home. How do I get them both on my ESL cable mode and whatever? That's, I think,

6:14what changed everything? Because that's when two things happened. You had all of these vendors started popping up with little boxes that you could buy for $100, put it in and it did IP masquerading. And not to be confused with, you know, other versions of NAT, which is now another soap box that I'm going to step over onto is that you've got all these different versions of NAT. But what everyone calls NAT is actually masquerading, right. It's taking a bunch of hosts and hiding them behind one address. And that was simply to solve the problem of, I have two computers on my DSL. You know, there might be enterprises out there that were doing some things, you know, and I'm sure there were. I worked on a few of them that actually had like, oh, we need two slash 24's for our enterprise. And then we're able, and we could just give it to them, right, because we had a whole bunch of address space. But that, what that did was that conflated

7:19firewall and security with masquerading. They're not the same thing and I'll dial that hill, but they are and have been marketed that way for 27 years or so now. And so there's multiple generations of folks that just, they can't decouple those two things. And so that's why one of the reasons in my opinion is why we are, it have the environment that we have now. If you top that on to the fact that we ran out of addressing. Yeah, I mean, that's in some ways there are two simultaneous problems, or not problems, but engineering issues that went on and the client overload for hydro space was definitely a big one of, big one of them. And so the masquerading that occurred or network address translation that occurred was really a, like you indicated, a combination of misplaced thought process around that being security. It basically blocked the end-end principles. So, so people think that's security, right? Because people can't access resources directly. And there are, there's obviously people in a different camp who think very differently

8:25about that and think that, and, and principles should be up to the end host related device, and then enterprise environments, they can manage their network anyway. They want to, but that the default should be that you should have an end conductivity if it's so desired for everyone else who's who participate on the internet. And obviously, if you're behind corporate manage resources, they can decide to do whatever they want to do based off of their policies and their organization structure. But the thought is, is that everyone else should have the capability to participate in the internet in any way, shape or form that they see fit, which means also providing services if they care to, right? It doesn't necessarily become a governance thing, though, more. Yeah. Like, because from a technical standpoint, there's any number of, you know, historical precedents we can cite for why we are where we are and why it isn't really a thing, and hasn't been a thing in any significant way. But I guess, you know, when you look at why it hasn't really taken off, then you quickly enter the realm, in my opinion, of, you know, what is the,

9:29what is the governance around this, the governance around internet access, the governance around how services are provided and what traffic is privileged on the network, and all of those thorny issues that that, you know, just sort of exist that layer 8 and above the OSI model. So, yeah. Yeah. I guess, I guess the question or the debate, if you play devil's advocate for any of that stuff, I guess the question or debate is really around, do we design something that's constrained or do we design something that's open? And so, I think the ITF would argue, we want to design stuff that's open. We want to design the capability to be there, and it's up to the operator to choose whether to turn something off or the administrator of, like, the network to turn something off. I would think there are many geopolitical and government actors who would disagree with that, probably, right? In terms of, like, centralized control and, you know, the ability to really maybe have more bottlenecks involved in terms of, you know, geopolitical and demographic control

10:33over content and how services are distributed and, you know, law enforcement requirements and a bunch of other things. But the reality is, is that I think the ITF has fought very hard to continue to have the end-to-end connectivity principle be adhered to an IPv6, even in terms of rejecting proposed, you know, network address translation methodologies and other design considerations that would be useful for enterprises, for large organizations to have available to them, has a standard so that they could work with all the networking vendors and manufacturers to get the best support possible sort of, you know, sort of uniform support possible across, you know, different sets of manufacturers and technologies, because there's a uniform standard that's been written from a well-known body. But the reality is, is that I don't think that's been something that's been adhered to, particularly well. And I think they've fought very hard against the anything breaking the end-to-end

11:35connectivity design principle. And I think, this is my opinion, but I think to their detriment in this particular case, the end-to-end principle has been eroded and it's gone away for IPv4 in its, in totality. I think we can all agree that that is just not a thing for IPv4 in any, in any structural sense of the word and, and, and, and the reality is that they supported those sets of capabilities in the standards, the first time around with IPv4. Obviously, they're trying to correct some of that with what's going on with IPv6. But I think because of the precedence that was set with IPv4 and the capabilities that masquerading and network address translation provides, which is very useful in certain design principles of, of building high available sites that maybe don't have BGP and you want to, you know, solve certain problems, network address translation definitely helps you to be able to do that. And having a well-written standard, you can still provide guidance that says we don't recommend that this be the normal thing that you do, right? Like we can impose our belief that an end principle is an important

12:40consideration, but the industry needs something that's standardized and let's go ahead and publish something that's standardized. That is strictly 100% my opinion. I don't, I don't think that's something that's, you know, I'm trying to say the, the industry has an, an interest in doing, you know, based off of, you know, how I feel about it. But I do believe there's enough other people who are operating networks out there who probably have the same sensibilities and probably more pragmatic approach around it and would like to see something standardized from written that way. I don't know how you guys feel about it, but that's, that's sort of where I land on it right now. I think that I've got, so my fairly firm opinion is that if the mechanism solves the problem, then it's worth sort of standardizing it. I would, and I, this is the argument that I had made in the past, but within that group is I would rather control that conversation, then have it just, I'm a cassari happened, right? I'd rather have input or control the conversation, then have to

13:45deal with a wild west implementation that it's not repeatable, it's not supportable, or it's, or even worse, it's close source commercial. I don't know what it's doing. You know, it may do practical magic under the hood, and I don't know what that is. I'd rather, I'd rather have, I'd rather control that if possible, even if it's something I don't necessarily agree with, which I don't necessarily disagree with it either. I mean, if it's a, if it solves a problem, then it solves a problem, and then it's just, you know, you can't discount that. I think my issue is that there's, like, I just want to raise the awareness that you don't have to do it, even in IPV4, like, I run big, like massive networks that just don't do it. And I'm not talking about service provider networks either. I'm talking about very large, high performance computing data centers where there is, you can't put it in the middle because it's such, like, it's so high

14:47performance, it would just impede the purpose of the computation. So it is doable. It's not for everybody, obviously, but, you know, I think the biggest problem I have is that it has been sold as a complete package that you have to have for security. And that is not the case at all. I gave a talk. You can go find it on YouTube, like 12 or 13 years ago about how you can essentially run a, you know, run a high performance network or run a any kind of network without, without NAT in the middle of it. Actually, I think it's even without running it without a firewall, because a lot of times firewalls are in departments as well. I want to see 12 to 13-year-old ago, Nick, presenting. Not that doesn't look that different. I, we could put a, you know, we can, I can send you, I can send you a link to it. It's on yeah, let's put it in the show notes. I think, I think what's important is that, or maybe what the,

15:49one my question really is about is, is the end end connectivity principle something that the idea should be adhering to and sticking to strictly, you know, in a way that that prevents some of the, you know, maybe generation of standards that that would help the industry overall, is that the right argument or hill to be on right now? I don't know the answer. I'm just bringing it up as saying, like, hey, maybe that's a debate that more people should be getting involved with and, and voice an independent about, because it seems like the brass ring event end connectivity is, continues to be exactly that, the brass ring, right, the goal of what they're trying to achieve, and maybe a more pragmatic approach is, is saying that while that's the goal from a design basis, we need to also account for the other things that need to really happen in the process of how people does actually design and deploy networks today, right, and to meet their new requirements. Yeah, I guess a question that comes up, though, is the particular networking environment that we're really talking about with enterprises in mind, and, you know, there's always this sort of discussion

16:53and debate around enterprise representation within the ITF. We're always pushing for more of it so that we get operational models coming out of the ITF that are functional and usable across the broadest range of enterprise networks, but there's the flip side of that, which is, you know, the, the ITF as the Vanguard and protector of the notion of Indian connectivity, which I agree is important to preserve as a design principle, and to plant that stake in the ground to say, you know, this is something that we want to try to engender as much as we can, but then, you know, where does that fit into the overall enterprise operational model across multiple domains of architecture and involving security? Like, do you think about zero trust and say, like, hyper segmentation, and I'm not saying it can't work, but, you know, just in my mind, as I try to sort of fuzz those two things together, I get, you know, some outputs that don't really make a lot of sense from a design perspective. I guess this is all a long-winded way of saying, I don't know what impact, I want to see more impact at the ITF of, you know, enterprise network designers,

17:55but with enterprise network design prejudice coming in, and to Nick's point, you know, there is, there's still a lot of, you know, dead ending around, you know, natto security, and you'll, I'll take that opinion of the grave, you know, within the ITF, how do you preserve the principle of Indian connectivity in the overall design architecture approach with inputs coming from, you know, the actual network deployers on the enterprise space saying, well, what is what good does this really do us? And I don't even necessarily understand it to the first point, but, you know, if assuming that I do, what is the benefit for me and my network with this particular design approach? Yeah, I guess my answer back to that is if you're taking zero trust seriously, it doesn't matter whether you have a network address translated to address, or whether you're just directly on the internet with a, with a public V6 address, or public V4 address, because the security principles that are policies being applied to you are controlling where your quant device can or cannot connect to, for which is the whole principle put behind zero trust right

18:57in terms of, in terms of how that would play out. So I think actually it matches pretty well with a zero trust policy initiative. There are other ones that maybe it doesn't match as well with from my enterprise design standpoint. And I think the big ones really are hard to do with inadvertently providing services that you may not be aware of, right? And so the goal of the enterprises to protect those individuals that may or may not know necessarily all the capabilities of what they're, you know, the platform that they're operating is capable of providing and then inadvertently providing services that provide an exploit or, or a window. Now supposedly zero trust is supposed to help you address all of that from a security standpoint, from a centralized policy management standpoint on the, on the endpoint devices themselves. And I guess the other one would be maybe, you know, really providing an extra protection level between IOT, you know, poorly designed IOT related devices or OT related devices that maybe don't have the right set of controls and permissions on them and not having them exposed in a way that, you know, provides an exploitation loop. And so that end-to-end principle is like I really don't want that

20:02device any end-to-end kind of thing. I wanted to talk into a gateway only and I'll talk to that gateway to go get, you know, to the things that need to happen. And that's a, that's maybe a discrete network problem as opposed to a, you know, an end-to-end principle problem. Well, and then we could argue that. Yeah. And maybe, maybe the IOT environments have been heavily gatewayed anyway and having sort of their own operational space. But yeah, I guess it's just struggling to come up with this, you know, there's this sort of this, you know, unicorns and rainbow fountains vision of the end-to-end internet with IPv6. But are we focused on, you know, it's a design goal that is just from in the real grizzly world that we live in doesn't, you know, maybe it doesn't have as many applications as we would like to think that it has. And I have these maybe the, you know, the examples seen quite on of that, I don't know. Yeah, I guess you have unicorns and, and, and, and, and, and rainbows on one side. Do we have the clown car and,

21:06and the clown circle around on the other side? Like, I don't know what the, what we're book, what we're book ending here. But, but yeah, I, it's also, I mean, we also have to remember, too, that like, we don't have the notion of the 1918 space in, yeah, not the same way. Right. And so even if you've got, so let's say you're in a prize and you're going to deploy IPv6 and you get a allocation from Aaron, right. You deploy that. It's GUA space. So unless you go out of your way to masquerade that, everything's got GUA address on it anyway. So you're already, you know, unless you go down that route, which I would, you know, cringe and go, okay, have fun, right. But like, you, you have to figure out how to do appropriate filtering inbound and outbound, just like you should, you're going to do with V4 anyway, you just have to also consider the fact that now these

22:08are potentially reachable, which is solvable by a very simple one rule. This is deny all in, right. And it's not, the, the concept's really not terribly different. I think it's just that, it's been 25 years since an engineer has had to deal with a quote unquote public address on, on any given system. And so that's such a foreign concept to them. They have this false sense of protection from, well, you know, it's masqueraded. It's safe, right. Is it safe from, you know, drive-by attacks and browsers? No. And that's probably, I would argue every bit is dangerous if not more than, you know, some random person scanning a netblock. By the way, it's going to be very unlikely. It's not impossible, right. But it's just less likely on, on of these six address. So you're trading one thing for another. You still have to have good, you know, good policy implementation, you know, have good practices, have good logging, have good filtering. It doesn't,

23:12I think I would argue that if you need for that allows, allows folks to sort of let their guard down a little bit more than they probably should anyway. Exactly. Yeah. So yeah, especially when you see stunned in some of the not traversal methods that are very sophisticated, that basically can map your entire internal network. I mean, there's, there's some pretty good tools out there for being able to traverse, you know, depending on the not methods that you're using, they can get a lot of insight into your network without, you necessarily, you know, having any good idea on that one. Yeah. So preserving the end in principle, make sure it preserves operator choice. And then that operator, without operator choice comes operator responsibility for security that, you know, as you're suggesting that I'm not thinking about where where IP masquerading is in effect. And they're calling it something else. Yeah. So I mean, where do we arrive on this? Where, I mean, what does this land us? I guess, I guess I want the ITF to continue to use NN connectivity as a design principle for the base level of the protocol. But I do think they're, I wouldn't say it's negligent,

24:15but I do feel like they're passing up an opportunity to address a segment of need requirement from a standards basis to really address those that need to do some sort of network address translation or some sort of, you know, breakage of the NN principle. Just to get it into the fold from a standards basis, I feel like that's important. I feel, I realize that they probably feel like that's a, you know, tremendous, you know, betrayal of the end principle itself, right? To do something there. But I think at a certain point, you have to reach a pragmatic decision about what's going to happen going forward and the behavior of manufacturers and those that are using the address space itself. And I'm seeing more and more both requests happening from customers to manufacturers saying we need, you know, NAT66, we need MPTV6, we need these sorts of network address translation capabilities to solve these related problems for us. Yes, does it break the NN principle 100% it does, it breaks it. But the reality is these

25:18manufacturers are going to develop the stuff with no standards to guide them to solve these related problems. And I think it will introduce more operational friction over time versus because of the fact that they're not standardized versus versus the tradeoff of not doing anything, right? I don't know. I mean, an application layer, gateway breaks that principle too, but that is a very valid way to basically create a, you know, an ingress egress gateway for, we're let's say, I don't know, an actual security network or some sort of IoT sensor network or whatever. And so I think that there are multiple use cases here that break that model that are very valid design choices. Right. Yeah. There. Do we solve all the problems? We always do. We always do. We always do. I prefer to create them. Oh, we create solving more problems and we're creating.

26:20Why do we invite Nick on the show? Okay. K off agent. Awesome. Well, if the audience has any strong opinions about the end and principle about how they how they think things are going wide, super important, maybe some other ideas that we didn't necessarily address in the show. We'd love to hear from you and go ahead and provide us feedback. So if you hit the website, packupusures.net, and there's a there's a feedback form that's available. We'd love to be able to get some some additional thoughts on it. But you know, this is one of those things that you just sort of see happening in the industry. We felt like it was important to sort of chat around. So we really appreciate the discussion you guys. 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 packupusures.net slash fu where fu stands for follow up. We'd love to hear from you and continue the conversation. Also, packupusures.net, you'll find a range of other deep dive technical podcasts for IT pros. There's a whole lot more on the packupusures site as well, such as tutorial videos and a community

27:21slack channel where you can talk with industry peers and experts. So whether you're deep in your career or just starting up, packupusures is the place to go to grow both your skills and your personal network. So long and until next time, we'll see you on the IPv6 internet.