The Rise of NAT: A Necessary Evil in Networking | Chaos Lever

[00:00:00.14]
Ned: Fifth-generation programming languages. At a certain point, generations don't matter anymore. You know how we're an iPhone generation, like 16 and a half or something?

[00:00:12.06]
Chris: At a certain point, people are just making stuff up.

[00:00:15.03]
Ned: Well, people are always making stuff up. That's all of our technology, isn't it?

[00:00:19.13]
Chris: That's right after version one. Version one is like, I have a great idea, and here it is. Everything after that is like, We're just going to wing it. This is all probably Fine.

[00:00:30.26]
Ned: We'll iterate on that idea by just making things slightly faster and moderately worse.

[00:00:37.20]
Chris: What's the old expression, move fast and make things completely incoherent?

[00:00:41.08]
Ned: Well, that is Microsoft's motto indeed. Hello, Alleged Human, and welcome to the Chaos Lever podcast. My name is Ned, and I'm definitely not a robot. I'm probably also not a Microsoft MVP after that comment. With me is Chris, who is also here. Hi, Chris.

[00:01:10.10]
Chris: And incoherent.

[00:01:12.06]
Ned: Cash coherence is the most difficult thing after naming stuff. Speaking of names, we have another guest, Ivan Pepeljnac. He is a CCIE Emeritus, a BGP Titan, and a friendly human. We're very excited to have you here. Hi.

[00:01:28.29]
Ivan: Hi. Thanks for having me.

[00:01:31.18]
Ned: Absolutely. For anybody who is not familiar with you, and that's probably going to be very few people, can you give us just a quick background about yourself? We've got about six hours.

[00:01:42.10]
Ivan: Okay. Where do I start? A networking engineer developer, whatever, since mid-1980s, I think. I just dated myself, Gray Bird. Work I worked on all sorts of crazy stuff. I was running an internet service provider in the '90s. I was the guy running the BGP courses and then OSPF and the IGRP and the ISIS, all the routing protocols staff courses for Cisco Systems. If you were attending the very first version of the CCNP curriculum, those were the courses that we were developing. Probably set It was like the second remote lab system worldwide for routers. The first one was Terry Slettery with Mentor Labs, and we were close behind. Got you. Then semi-retired, then got back, started my own company, started blogging, doing webinars, bitching about the state of networking, which isn't hard these days. Semi-retired, again. Now I'm working on an open-source project that should make networking labs suck less.

[00:03:10.08]
Ned: I am all for that. I recall studying for the CCNA and then the CCNP and trying to use the emulators of the time. This was the early 2000s. It was a little rough, if I'm going to be honest.

[00:03:25.21]
Chris: Emphasis on the word trying.

[00:03:26.14]
Ivan: You're so diplomatic. You definitely It wouldn't be suitable for Trump administration.

[00:03:32.18]
Ned: It's true for so many reasons, but yes. I'm glad to hear that improvements are being made. Maybe someday I'll actually try to get that CCNP again. Unlikely.

[00:03:45.21]
Ivan: No. Now, if anyone wants to go for any certification on that level today, it should be something cloud-related.

[00:03:55.09]
Ned: Is there a certification that you would particularly recommend for people starting?

[00:04:01.00]
Ivan: I have no idea.

[00:04:02.08]
Ned: Yeah, just something cloud-related?

[00:04:04.00]
Ivan: Yeah.

[00:04:05.03]
Ned: No, that does seem to be the general consensus that I'm hearing. But let's dial back. Let's go back to an earlier time. I'm not going to say a simpler time because I don't think it was simpler, but an earlier time. We're different. Yeah. What I wanted to talk to you about, because I think you have some strong opinions on this, is the history of Nat, or a network address translation.

[00:04:27.12]
Ivan: You must hate me.

[00:04:29.06]
Ned: It was a necessary Very evil, maybe, that arose sometime in the '90s. I could be wrong about that. So, Yvonne, please correct me. But it is responsible for the implementation of the Internet as we know it. Could you just help set the stage for what would eventually become NAA?

[00:04:51.14]
Ivan: Okay. Do I start with long, long time ago on a planet far, far away? Possibly. There were networks. Anyway, in those days, IP was just one of the many options. It wasn't even the best option. It was some crazy academic project that no one was taking seriously. Every enterprise vendor had their own stuff. Ibm had their own stuff, Deck had their own stuff, HP had their own stuff. Who else? Siemens. There was this French company that was also making Unix-like systems. Can't remember what it is. Then there was Benion Vines and Apollo and Apple Talk. Of course, Apple had to do things differently. Oh, I remember. Did I mention Novel Network. That was the initial guerrilla product that then started spreading like a fungus across enterprise networks and killed all the joy in the networking engineers because it was so crappy. Anyway.

[00:06:09.05]
Ned: If I remember correctly, Novel used IPX as its protocol? Yeah. I don't know anything about it. I just know that.

[00:06:18.08]
Ivan: No, the real problem... Novel actually had some great ideas, like automatically assigning network addresses based on Mac addresses that we a lot later in IPv6 because they were so jealous that someone else has it, but they don't. We can get into that if you wish. The problem with Novel was that, A, all servers were routers. All the traffic was going through the servers and burning CPU cycles to forward packets that the CPU cycle should really be spent on serving files. A file server is, after a file server, not a router. The other problem was that they had this service advertisement protocol, which is something like Bonjour is today in Apple networks, where everyone is telling everyone else what services they have. Those things were collected by all the servers and re-advertised and all other segments by every server every 30 seconds or so. And you have to keep in mind that in those days, 64 kilobits was a fast link. Two megabits was bloody expensive. Now, imagine having a 64 kilobit link and half of the bandwidth is used by service advertisements. You hate that stuff, by definition.

[00:07:55.04]
Ned: That reminds me a little bit of how early Microsoft networking would also do something similar with... With NetBuy. Netbuy, I think it was.

[00:08:05.23]
Ivan: Netbuy was the original one. It was running straight on Ethernet, and NetBuy was... Oh, that brings us to this topic, NetBuy over IP. Thank you.

[00:08:16.16]
Ned: I did something.

[00:08:19.01]
Ivan: In late '80s, the writing was on the wall. People will use IP. And so enterprises started planning for that. They might still have everything on the Vell or Microsoft or Decknet or IBM stuff or whatever, but they knew that eventually this IP stuff is obviously winning. This OSI stuff is not going anywhere because these IP guys are actually doing something and those OSI guys are meeting every two or four years at exotic locations and wasting everyone's money. The enterprises started thinking really hard about what to do. The first thing you do is you grab part of the address space, which in the good old days was just sending an email to some guy somewhere in US who had a text file, not even an Excel spreadsheet. That guy would look into that text file and add you to that text file and send back an email saying, This is yours. And that was it. The next problem we had in those days was that there was no prefixes in networks. It works. Today, we look at the IPv4 or IPv6 address, and we say the left bits are the prefix, the right bits are the host bits, and the boundary can't be anywhere.

[00:09:59.28]
Ivan: In those days, the boundary could be at the first bite, at the second, so that would be class A network, at the second bite, which would be class B network, or at the third bite, which would be class C network. The The last of the network was coded in the first three bits. Anything from zero to 128 is class A. By the way, the last class A is 127, zero, 00/8, which everyone should be familiar with.

[00:10:34.18]
Ned: Yeah. I have to admit, I only ever use the very first host in that/8.

[00:10:42.10]
Ivan: That seems like a little wasteful. You know why you need all the others for something like vagrant UDP tunnels. If you want to build in KVM a UDP tunnel between two VMs, what, two VM nicks on your server, then you have to send UDP packets from some IP address to some other IP address. Luckily, we have what? 16 million of IP addresses in the loopback subnet. You never run out of the IP addresses for the UDP tunnels between the VMs, because if you ever managed to run 16 million VMs on your server, let me know.

[00:11:25.08]
Ned: I will work on that.

[00:11:26.23]
Ivan: I believe you. Anyway, because of that, people had to grab the next bigger thing that would fit their needs. Enterprises were typically going for Class B. Some people managed to grab Class A like Stanford or DEC or Xerox or MIT, I think. Department of Defense, obviously. It was pretty obvious in the '80s that we will be running out of the IP address space if things will keep going like that. We were pretty far from the cliff, but it was obvious that there is a cliff and that we will have more than 30 mainframes in the world, as IBM once claimed. You remember those things, right?

[00:12:26.29]
Ned: Yeah, we did a whole episode on mainframes.

[00:12:28.14]
Ivan: The IBM CEO was saying, Well, we'll never sell more than 30 of these things. Bill Gates supposedly saying no one ever needs more than 640K of RAM.

[00:12:40.20]
Ned: Yeah, those predictions are adorable. Yeah. Was there any concept of just how big the public Internet was going to get at that point?

[00:12:51.11]
Ivan: Because I mean, yeah, I was going to say- This was pre-web.

[00:12:55.19]
Ned: Right.

[00:12:56.08]
Ivan: The Internet exploded with web. This was still enterprises and enthusiasts and academics and computer vendors. But the enterprises were seeing the writing on the wall and they were getting ready. If nothing else, there was email. So very early, let's say late '80s, early '90s, people who could foresee who could extrapolate curves, let's put it this way, were pretty sure what is going to happen. People started thinking what they could do because it was obvious we would need bigger addresses. There was a proposal, and I found the dates. In 1992, someone brought an RFC, this is RFC 1347, where they said, Well, let's just run tcp and udp over clns, the OSI stuff. The OSI addresses are variable length and the minimum length is something like 10 bytes or something. No problem. We can squeeze anything you wish in there. There were people implementing that stuff almost immediately because router vendors already had the OSI stack because the transport gear, the Sonet and the SDH gear, was managed through the a size stack. If you wanted to build a management network for a service provider, you had to support that stuff. It was there. It was in the code.

[00:14:55.07]
Ivan: It was in Unix networking stacks because people were using Unix systems to manage those networks. All the major vendors had something. Digital was betting the next generation of deck net on that. Stuff was around. It It would be trivial. We would just roll it out, and in a few years, we would have a running product and problem solved.

[00:15:24.08]
Ned: Just to clarify, CLNP would be a replacement for IP?

[00:15:29.06]
Ivan: For IP, Yes.

[00:15:30.27]
Ned: This isn't a bolt on to alter IP in any way. It's totally separate protocol.

[00:15:34.27]
Ivan: No, this is like IPv6 is replacement for IPv4 with TCP and UDP running on IPv6. This would be CLMP replacement for IPv4 with TCP and UDP running on CLMP.

[00:15:48.17]
Ned: I'm going to assume, because I'm not familiar with CLMP, that it didn't take off.

[00:15:54.04]
Ivan: There was this famous It's a high-level IETF meeting somewhere in Japan that no one wants to talk about. You can't find anything about it on the web apart from certain mentions of the Kobe incident. I think it's Kobe incident. I found a small book, I think is the elements of networking style. I'll send you the ISPN. It's not digital. You have to buy a hard copy. It's from a guy that was on the IP side of the world, but it's an interesting book. It gives you the mindset in those days. Anyway, there was this meeting and they said, Yeah, this makes sense. Let's move ahead. This is how we should do things. Then they had the grassroots revolt of the make IP great again, folks. They said, No, we will not take anything from the enemy. We don't care if that thing works. We don't care if it's okay. It's the enemy. We will not take anything from the enemy. We will develop our own stuff. Now, let me give you the timeline. That proposal to run a TCP and UDP over CLMP was made in 1992. I'm pretty sure the production code was in Cisco iOS release in January 1994.

[00:17:36.24]
Ivan: Ietf got their act together in June 1994, when someone managed to publish the first draft of the technical criteria for choosing IP, the next generation. Two years after we had a solution, ITF finally decided they need need some set of requirements. Then in September 94, and the final RFC was published in January 95, they produced, based on those requirements, the recommendation for the IP next generation protocol, where they took three different ideas, slightly mixed and matched them, because that always works so well in committees, that's how we got 48-bit ATM cells. Not 32, not 64, 48. This was the start of the IPv6 development process. Then instead of just saying, We'll replace 32 bit addresses with... Initially, the proposal was, let's replace the 32 bit addresses with 64 bit addresses.

[00:19:09.13]
Ned: Okay.

[00:19:10.08]
Ivan: Then someone said, No, let's make it 128 bits so we will be as cool as Novel.

[00:19:18.01]
Ned: All right.

[00:19:18.27]
Ivan: Because the first 64 bits will be the prefix, and the second 64 bits will be the Mac address.

[00:19:25.11]
Ned: That's where the 128 came from. They wanted to use the Mac address for... Yeah. Okay.

[00:19:31.10]
Ivan: Of course, in those days, they didn't realize that if you... Because nothing was portable in those days. There were no laptops.

[00:19:41.11]
Ned: Right.

[00:19:42.15]
Ivan: They didn't realize that if you always put your Mac address in the lower part of the IPv6 address, we don't need tracking cookies or anything else. We can just track you based on the Mac address.

[00:19:56.18]
Ned: Right.

[00:19:58.01]
Ivan: Which is why we We have now so many privacy-enhanced IPv6 addresses. We change them every time you power on your iPhone or iPad. It gets a different address.

[00:20:14.20]
Ned: Despite the idea being that it would be linked to your Mac address, that's ultimately not how we chose to implement it.

[00:20:21.24]
Ivan: Well, no, we implemented that, and then a decade or two later, we had an oh, shit moment. That's the whole story of IPv6 in a nutshell. People came with all these academic ideas, like infinite extension headers, and extension headers that would be looked at on every router along the way, and extension headers that the routers could change along the way, and all sorts of crazy ideas. All that It got baked into IPv6, and that, of course, made it somewhat hard to implement.

[00:21:08.01]
Ned: Yeah, you're talking 1994, and I'm trying to think about the hardware of that being able to process a 120-bit address.

[00:21:17.16]
Ivan: Hardware guys were pretty smart in those days. Cisco already had a prefix-based forwarding implemented in, I think, It worked for IPv4 and CLMS and later for IPv6. But the infinite extension headers that obviously doesn't fly. The moment you want to do any filtering on TCP or UDP port numbers, and I can just shift TCP or UDP port numbers anywhere in the packet, good luck. Of course, the academics thought that you could obfuscate the TCP port numbers, and so people wouldn't be able to filter you anymore. Now, I would use an undiplomatic It's a weird word, but I won't. The people in the middle just said, We don't care about your obfuscation attempts. We'll just drop your packets. Of course, those The US never worked. They do work great for the bad guys. It took the industry a decade or so to implement a proper router advertisement guard. Because you don't want anyone to just say, I'm the router, send the packets to me. But that's how IPv6 works. They said, Well, now we will implement some in the switches that if a router advertisement comes from the untrusted port, we'll kill it. Then along comes Fernando Gont, that's a security researcher focusing on IPv6, saying, If I add an extension header, you won't see this is a router advertisement, but the host will.

[00:23:22.18]
Ned: Sneaky.

[00:23:23.23]
Ivan: Then they go like, Okay, we can fix that. He goes like, Yeah, but not if I fragment. We can fix that, but not if I overlap the fragments. The whole IPv6 is so-called second system effects. You build something first and it's crap, like IPv4 was crapped before the HCP and classless routing and all that. Now, you get the opportunity to do it again and you the most bloated thing the Earth has ever seen because you want to fix every error and insert every great idea you ever had without testing it out in reality. By the way, people should look at the second system effect on Wikipedia. It comes from a book by a guy who was the manager of operating system development for IBM mainframes, and he experienced that firsthand. On the Wikipedia page, IPv6 deployment is, quote this as an example of the second system effect. We got an overbleoted protocol full of academic ideas, not implemented anywhere, not tested anywhere. We were running out of IPv4 addresses. A few people, practical engineer said, Gee, we are giving Class Bs to Siemens and Coca-Cola and Pepsi and who knows what else. Those guys are never going to use those addresses because they're not crazy enough to connect their hosts directly to the public internet.

[00:25:21.13]
Ivan: They will just number their hosts internally, and they don't really need public addresses for that. What if we would assign Network 10 for private addresses? And that was started in March 1994. That was the first RFC saying, Let's use Network 10.

[00:25:53.11]
Ned: Okay.

[00:25:54.00]
Ivan: And immediately after that, there was a counter RFC from the rich guys who believe that this was the believed in religious purity saying, No, we shouldn't do that because we will kill the end-to-end connectivity. Now, those guys were coming from Apple, SGI, and Sun. And guess what? Those companies had tons of IP addresses because they grabbed them in the initial rush. So obviously, it was easy for them to say, No, No, you couldn't use Netfro 10. That would be so offensive. Anyway, RFC 1918 eventually happened. The other thing you have to understand is that in those days, nobody was planning to use direct end-to-end connectivity between the clients. Even today, honestly, why do you need direct connectivity between the clients? It's just for the voice call server. Now it's video calls and BitTorrent. Everything else is client server.

[00:27:12.15]
Ned: Right.

[00:27:13.17]
Ivan: Which means that having clients with global addresses reachable through the public internet is plain stupid and security risk. People understood it in those days, and everyone was building their networks with a sandwich. The way we were building firewalls in the good old days was two routers with a proxy server in the middle. You would have packet filters on the two routers. Insight would only be allowed to connect to the proxy server. The proxy server could only open connections to the outside world, not to the Insight. Every application protocol It would be proxied. That allowed people to use Network10 internally and then have a /24+c because you couldn't get a smaller prefix for the DMZ, for the proxy server and the two routers, and then the proxy server would connect to the internet. Problem solved. You can be, I don't know, Coca-Cola worldwide, and you would only need a Class C network to connect the whole enterprise organization to the global internet. Well, maybe with regional exit points, but let's not go there. The only problem with that was that you had this application proxy in the middle. So web worked well, FTP worked well, email worked well, but you wanted to deploy a new protocol, it didn't go through.

[00:29:02.05]
Ivan: So someone had this great idea saying, Yeah, but if I look at the... Did you ever work, by the way, with the old telephone exchanges?

[00:29:13.22]
Ned: Oh, Not particularly.

[00:29:16.05]
Ivan: Where you would have one phone number for the whole organization, and everyone calling out would appear to be coming from the same phone number.

[00:29:27.17]
Ned: Yeah.

[00:29:28.14]
Ivan: And then Then you would have some extension for direct in dialing, where if you would know the extension number, you could dial in and get to a certain person.

[00:29:40.29]
Ned: I remember I was working on a phone system. It was one of my first jobs, and they were talking about DIDs, and I was like, What's DID? Yeah, exactly. I'd never heard that acronym before. Then the guy explained to me, he's like, People who get DIDs, you can direct dial them from the outside. Everybody else, you have to dial the main number and then they're extension.

[00:30:01.06]
Ivan: That was the exact same situation with the early Internet access. There were a few people who had special applications, and they would need direct access to the Internet. Everyone else was just using email and web. For those few people, you just assigned them IP addresses from the DMZ, but they were inside. You had to translate the inside addresses into DMZ addresses so that they could get to the outside world. And voila, we have Net. It was initially used really just for the exceptions. Those few people who needed direct internet connectivity from an organization that they couldn't use the proxy servers, then would use Net. Then, of course, once you invent something like that, and by the way, NET was documented as an RFC in 1993. Net is older than the private address space and way older than IPv6. Because we were solving a different problem. It just so happened that this tool could also solve the lack of IPv4 addresses because of the IPv6 blunder. When you have the tool, when you have a hammer, everything starts looking like a nail. The next thing that happened was that people said, Well, you know what? We have net.

[00:31:50.12]
Ivan: Can we just skip the proxy server, please? Because it's faster if you go direct. Links were becoming faster, and the proxy server was becoming a bottleneck. It was like, Yeah, let's say I get four Class C, so I have 1,000 addresses, and I'll share them across people who want to go to the internet. There will never be more than 1,000 people. And you will get an IP address when you start using it, and when you stop using it, it will time out, and someone else will grab it. As you can imagine, that didn't end well.

[00:32:28.29]
Ned: Right.

[00:32:30.01]
Ivan: We severely underestimated. Someone smart said, You know what? What if we would mix multiple people into the same IP address and use different TCP and UDP port numbers. Because in theory, a host can open 64,000 TCP or UDP sessions to one IP address. It can open millions of sessions to different IP addresses. What if we would be really smart and reuse the IP address with different TCP/UDP port numbers, and so we could squeeze more than one person through one IP address. And so the net, as we know it today, was born. And then, obviously, the residential internet started. We were all using dial-up over the phone lines with the squicky modems. You ever use that modem when you could hear the modem sound when you dialed in?

[00:33:40.10]
Ned: Oh, yeah, for sure.

[00:33:43.14]
Ivan: Those days. That was okay. You got your IP address when you dialed in, and then when you disconnected, you lost your IP address, and someone else would get the IP address. And from the service provider perspective, you needed one IP address per modem, not per user.

[00:34:07.05]
Ned: Or concurrent user.

[00:34:10.21]
Ivan: Until DSL came along. The always on internet connectivity for the masses. There, you had to assign one IP address per customer, which was still okay. As long as you were connecting your PC to your DSL modem, that was good. But then, Wi-Fi came along. All of a sudden, people wanted to connect multiple devices from the home to the internet. But nobody would give you more than one IP address for the same amount of money. Why should they? But gee, we have this hammer and this looks like a nail, so let's use it. That's why everyone today is using Net to access the internet. Apart from the mobile phones of the operators that were early enough in the game that they grabbed enough IP addresses. For example, I know that Telecom Italia has every phone on a global IP address. Because Italian population is not growing. They reach the peak penetration of mobile users. No one has more than one phone active at the same time. Apart from certain people that have to use burner phones, but let's hope they are a minority even in Italy. And so they grabbed enough IP addresses early on and they can afford that.

[00:36:11.10]
Ivan: Whereas all the new operators, they were late to the game, they can barely get some IP addresses or they have to buy them. So all the new operators are forced to use so-called carrier-grade net. In the good old days, a customer would get one IP address, and then you would use net in your home on your WiFi to connect 20 devices. Today, in many cases, there's another layer of that inside the service provider. A customer is not getting one IP address. A customer is getting maybe a portion of one IP address, maybe a thousand ports of that IP address. That's why the mobile operators are so keen to move to IPv6.

[00:37:12.15]
Ned: I'm thinking about the Carrier grade net, and then I'm thinking about the number of devices I have in my house. If I multiply that out to all the houses around me, having a fraction of an IP address doesn't work anymore. I need more than that.

[00:37:29.17]
Ivan: Well, Effectively, you get something like 1,000 ports, or maybe you get 4,000 ports.

[00:37:38.10]
Ned: That's still close.

[00:37:39.09]
Ivan: No, remember that you can reuse the same. If your net device is smart, it can reuse the same port for different destination IP addresses.

[00:37:51.19]
Ned: Oh, okay.

[00:37:53.28]
Ivan: As long as you're going to Apple and AWS and Netflix and Cloudflare, you're good. If everything is behind Cloudflare, you have a problem.

[00:38:11.02]
Ned: Right. And they're using Unicast.

[00:38:14.02]
Ivan: It's all Unicast these days. Multicast is used in scenarios like video surveillance networks, where multiple people can watch the same video camera and they using Multicast because the camera cannot produce more than one feed. Or it's used internally in the service provider networks for the direct IPTV. The live stuff. The moment you get into replay mode or you want to skip something or you want to go back five minutes or you're on any streaming service, it's all Unicast. The other big user of Multicast are the stock exchanges. Stock feed is sending out as Multicast so that every broker receives it at the same time.

[00:39:15.19]
Ned: Right. Instead of giving one an advantage over the other.

[00:39:19.10]
Ivan: There were even stock exchanges where they measured the fiber cable so that every broker had the fiber cable of exactly the same length.

[00:39:28.26]
Ned: It It matters.

[00:39:30.25]
Ivan: Yeah, it matters.

[00:39:34.11]
Ned: We got the story of Nat now where it became necessary for a number of different reasons. But because as you mentioned, the carriers are switching to IPv6 for a lot of what they're doing. Are they still using Nat in any way? Or once you make the jump to IPv6, does that remove the need to run Nat?

[00:40:00.09]
Ivan: Unfortunately not because so much of the content is still on IPv4. As long as there is some content on IPv4, and if you're a service provider, you want to avoid the support calls. If there is more than one service provider in a certain town, which I'm told is not the case in US sometimes. Sometimes. But in Europe, we do have a freedom of choice. If one of them would be blocking access to IPv4 sites, you know what will happen? Everyone will go to the other one. You can't afford not to run that. What they're trying to do, though, is to avoid the bandwidth going through net as much as possible because that's costing you. The CGM box is expensive. Terra a bit of netded traffic is bloody expensive. If they can push as much traffic over to IPv6 as possible, they are making more profit.

[00:41:18.13]
Ned: That's what's truly going to drive IPv6 adoption.

[00:41:21.12]
Ivan: Yeah, and that's why you have Facebook and YouTube and Netflix and all the video streaming on IPv6. Because it's in everyone's interest that it's on IPv6, because if it would be on IPv4, then some users would go through Carrier grade net and their performance would suck. So if Netflix works great for me and Disney doesn't, guess what? I will cancel one of those services.

[00:41:57.02]
Ned: Not if you have little kids. Ask me how I know.

[00:42:00.28]
Ivan: Yeah. We went into Disney Plus for Star Wars.

[00:42:12.22]
Ned: Looking towards the future, is there going to be a time where we abandon that at all levels? No. No? Okay. No.

[00:42:24.10]
Ivan: If we all go to IPv6, which we will all switch from cobalt to what? Python in what year?

[00:42:39.13]
Ned: Never.

[00:42:41.05]
Ivan: Exactly. When we all switch to IPv6, then theoretically, we will never use net again. Unfortunately, that's not true. Even in pure IPv6 world, there are two cases where you absolutely need net. One is load Balancers. Load Balancer presents one IP address on the outside and distributes that IP address to many IP addresses on the inside side. How do you think it does that?

[00:43:21.29]
Ned: Well, I know. Yeah, it's net.

[00:43:24.20]
Ivan: There's no way around it. Technically, it can be a TCP proxy or it can be a net device. Tcp proxy is slower than net, so guess what's implemented? The other issue is if I want to have two uplinks from my home. I want to have a connection to, I don't know, I'm making this up. T-mobile or For Verizon and Comcast for redundancy reasons. We are all working from home and some of us are making money with that. If your internet link is down, you have a problem. You can't do everything from the coffee shop. You want to have two uplinks. Small Both sides of serious companies have the same problem. For example, I was once speaking with the networking architect from a probably Fortune 100 company, and he that he has tens of thousands of stores worldwide, and each one of them has to have redundant internet connectivity. We We knew about this problem since 1990s. How much do you think we did to solve it in the meantime? I'm suspecting that one. Apart from academic ideas don't count. Okay. Nada. An RFC was published a few months ago, yet again describing the issues with multiple uplinks.

[00:45:32.22]
Ivan: Issues, not solutions. This was the requirement document. Ipv6 is old enough, it can get drunk in US. And we are still writing requirement documents for multi-homing solutions.

[00:45:54.07]
Ned: What you're saying is that NAD isn't going anywhere, and we might as well get used to it.

[00:45:58.22]
Ivan: Yeah, because the only way The way to solve multi-homing in IPv6 today is with Net. You get two prefixes from two service providers. You have inside addresses, whatever they are, and then based on the uplink you decided to use, you change your source IP address into the prefix that the service provider likes. Otherwise, the return traffic is never coming back. Right.

[00:46:30.09]
Ned: Well, this has been a fascinating journey through the world of Nat, and I want to take a moment and thank you, Yvonne, for sharing your wealth of knowledge and history in this topic. If people want to know more about you, I know you said you're semi-retired, but you have this open-source thing. Is there anything you want to promote or point people towards?

[00:46:50.19]
Ivan: Well, so there are three or four things. For general networking, IP blog. Ipspace. Net. Blog. Ipspace. Net is still regularly updated. There are tons of webinars on the website, and although you can't buy them anymore, I'm making more and more of them public. People who never had account on my server can just watch those. For the networking labs, it's netlab. Tools. Tons of documentation, it's It's an open-source project, so anyone can contribute. I love people who appear out of the blue sky, never heard about them, with a PR saying, Oh, this doesn't work. This is how I fixed it. Can we merge this? Sure. Cool, dude. Thank you. The last thing, if you want to learn more about BGP or ISIS, I use that tool to create tons of labs for BGP. I think it's like 40 different labs exploring different BGP features. It's all set up with NetLab, so you just download the repository and you install NetLab and you're good to go. Or you can run the labs for free in GitHub Codespaces.

[00:48:30.04]
Ned: Very cool. All right, well, we will include links to all of that in the show notes. Thank you. Thank you once again for being a guest today on Chaos Lever. And hey, listeners, thanks for listening or something. I guess you found it worthwhile enough if you made it all the way to the end. So congratulations to you, friend. You accomplished something today. Now you can go sit on the couch, fire up two different routers, and set up Nat for your internet connection. You have earned it. You can find more about the show by visiting our LinkedIn page, just search Chaos Lever, or go to our website, chaoslever. Com, where you'll find show notes, blog posts, and general Tom Fouhry. We'll be back next week to see what fresh hell is upon us. Ta-ta for now.