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

Welcome 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

with 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

public 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

behind, 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

could 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

that 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,

what 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

firewall 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

about 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,

what 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

over 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

connectivity 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

consideration, 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

deal 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

performance, 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,

one 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

and 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,

but 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

in 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

device 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,

and 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

are 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,

I 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,

but 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

manufacturers 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.

Why 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

slack 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.