WHY is it so HARD to have TWO Internet Connections?

[00:00:00]Imagine I'm a small business. Well, I mean I I am a small business, but imagine like a law office or accountant or pizza restaurant or something where having access to the internet is critical to my business functioning, but I'm not really like in the business of networking. So, as a small business, I need reliable internet. So, I go off to a fiber ISP and they give me some all-in-one box like this, hook up their fiber. I get Wi-Fi out, hook up all my laptops, and I'm pretty happy, right?

[00:00:30]But then someday down the road, the fiber eating backhoe might come and eat through my fiber. And that would be a pretty bad day for me. If I'm a restaurant now, I can't do credit card transactions. If I'm an accountant, or maybe I'm bought into Google Drive as the one place for all my documents, now I can't get to those. It's a bad day.

[00:00:46]So, I need a backup. And so I go off to another company, in this case maybe a 5G company, and I get 5G business internet.

[00:00:56]This is my backup. So when the fiber goes down, I can just switch over to this guy and be all happy, right? And they again, they send me an all-in-one router. I just plug it in. I'm good to go. So now I got two different internet connections. These guys are both broadcasting Wi-Fi. I got to plug my computers into this one or I got to plug them into this one. And so if my internet goes down, it's kind of a lot of hassle to switch back and forth. What I really want is it to be automatic. I want my computers to just work on the internet as long as either one of these are working. Now, I'm a technical guy.

[00:01:26]So I take a look at this guy. I'm like, "Wow, that says LAN. That's my local area network. And this guy over here, he says LAN 2, and I want to have one local area network instead of two." So can I just get like a little cable like this and plug them into a LAN port here? And plug them into a LAN port over here. And now I've connected my two LANs together.

[00:01:45]So now I have one LAN, right? And all my computers I can connect them to either side of this switch here and they'll just have both internets. That's what I want, right? Two internets, one LAN. So I'm sure the idea of this exact setup has horrified a whole bunch of you right now. But we were about this close to this being a completely standardized approach to multihoming. So, how do we go from this to the hell we have now where you have to get specialized multihoming, multi-wan routers, have a expert configure them for you because it's not something you can just plug in like this. And how did IPv6 fit into this picture? So, if you're interested in those questions, then come along in this adventure. But first, email. So, when I started Apple's Adventures like 5 years ago or so, I registered my domain and the very first thing I wanted to set up with that new domain was email. even before I had a website, before I had any of that. And I I mean, I could have hosted email myself, but it's kind of hard to deal with email in the modern world. So, I looked for a sort of smaller privacy focused provider. I didn't want to use like Google or Microsoft because I was concerned about my cloud data footprint. So, I settled on Proton 5 years ago. I became a subscriber back then to Proton Mail and I had my email for my small business hosted with them and I still do. And since then, Proton has grown their security and privacy focused footprint.

[00:03:09]They now include calendar, password manager, cloud drive with basic document editing, that sort of stuff, and even a VPN. So, Proton's always had a strong focus on privacy. That's why they're located in Switzerland where they're strong data protection laws. They're also really big on end toend encryption, true end to end. So traditional email can never really be endto-end encrypted unless every other provider agrees to use PGP. With Proton Mail though, all of your data is encrypted on their servers from when they receive it. And if you send mail between two Proton users, it's endend encrypted the whole way. They also support PGP encryption. So, if your other end of the email does support PGP, you can have a truly endto-end encrypted email with the flexibility of a nice web browser UI. So, if you'd like to sign up for Proton Unlimited and get all of their features in one bundle, you get 30% off with my link down in the description below. Now, back to the video.

[00:04:04]Before I jump right into the networking aspects, I want to sort of talk about what's inside of these all-in-one home small business gateway units. So we just have a basic understanding going in. So to start generally when you get an ISP provided box it's going to do four things. It's going to have a modem. It's going to have a router. It's going to have a switch. And it's probably going to have a wireless access point as well.

[00:04:27]So the modem is sort of responsible for interfacing with whatever the layer 1 layer 2 low-level circuit is from our provider and converting that to standard Ethernet. So if you have a modern connection, you probably have like GPON over fiber, maybe DOCIS over cable. If you have a less modern connection, maybe you still have DSL in your part of the world. If you're on the wireless side, maybe you have 4G, 5G, maybe some proprietary wireless or Wi-Fi based solution if you have a WISP, that kind of stuff. Maybe Starlink even. So, that's our modem. Generally, we're not going to worry about that in this video.

[00:04:58]Now, connected between the provider side, their circuit, and our LAN side is our router. So, our router operates on layer three dealing with internet protocol packets. These are globally routable around the world. We do our firewalling here. Very often we have some other services here like DNS, stuff like that, but that's not strictly part of the router's job. The important thing about the router is that this is where we decide where we're going to forward the packets between multiple networks.

[00:05:26]Below that, we have a switch. Most of these gateways have more than one LAN port you can plug into. So, this is just a standard Ethernet switch kind of shoved into the same box. It might be done on a dedicated switch chip. It might be in the CPU, but it should behave the same way as a dedicated switch, even if it's part of the box.

[00:05:45]The last feature is a Wi-Fi access point. So, this is just probably dualband, maybe even triband Wi-Fi. Now, this again acts like it's plugged into the switch. It shouldn't be doing any separate routing. Maybe unless you have a guest network, but again, that's out of scope. So, basically, all the stuff down here should follow standard switching rules. We should be able to use the access point as an access point, the switch as a switch. And in general, you can take like a home gateway router, turn off the routing, and use it as just an access point. A lot of people do that with their older router when they get a new one. And so then if I have this whole setup here, I could just mirror that on this side for my second ISP. So I again have the other modem. Maybe it's a different physical layer. Maybe I'm doing 5G and fiber. Maybe I'm doing cable and DSL. Whatever I got, I got two routers again. So, this is the two separate providers dealing with their upstream interfaces. I now have two separate switches, but I don't really need two separate switches because I want to have one LAN, right? So, I could just connect them together. And according to standard Ethernet bridging rules, that should be just fine. And I have new Wi-Fi. I could turn the Wi-Fi off or I could use it as a second network or whatever I want. I mean, maybe we could put these on opposite sides of the house so we get better coverage and two ISPs at the same time.

[00:06:58]So all of the layer 2 side, the switches, the Wi-Fi, that sort of stuff, that's all really robustly handled. IE 802.1D I think is the standard for bridging.

[00:07:09]That standard deals with MAC addresses.

[00:07:11]We're not really bringing in any MAC address questions here. All of our questions involve routing. How do the clients which are connected somewhere to this layer 2 segment, how do they figure out what router they're going to route packets to? And how do they figure out what addresses to use? How do they get their address configuration when there's two routers in question? Stuff like that. And since many don't seem to know this, it's actually rather encouraged for a host to have multiple IP addresses, at least in the current version, IPv6. So, if I have a computer here, it will definitely have at least two addresses, a link local address, which is just for local communication, and a global address, and it's probably going to have two global addresses for a private temporary one. But we could have many more addresses here. So if I have two different internet service providers, I could feasibly have an address on both of them and choose which one I want to use on a connection by connection basis. Now this is actually much better than what you usually get with like a multi-wan router because now smart applications like video conferencing, gaming, they can establish a connection over both ISPs at the same time and fail over at the application layer without having to worry about NAT sessions failing or things like that.

[00:08:20]There's of course some quirks which is what this whole video is about. But one of the other quirks is that legacy IP IPv4 didn't make this so easy for us. So back in the olden days of IPv4 we thought it would be fine if every host just had an address because I mean you weren't going to build these super complicated networks back in the 80s were you? So we just had an address. We had a protocol to assign the address DHCP. So in this case, if my host then does a DHCP request, both of the routers will respond with an address. The host will pick whichever one it gets first, probably. You'll end up with essentially two sets of computers on the same physical layer, on the same LAN, but each of them will be bound to one of the two routers, and it's just going to be whoever got the DHCP response out first.

[00:09:06]But in this video, I'm talking entirely about modern IP. Modern IP has a lot of features that can really solve this problem that legacy doesn't. and that's why I'm focusing on it in this video.

[00:09:16]So, I got my test set up here.

[00:09:18]Hopefully, it looks good for you guys on camera. I just got a basic mini PC here monitoring it with a Ethernet KVM because it's only connected to my test network here. My test network is this basic Ethernet switch here which is connected to two mini PCs. This guy is just running Debian. He's got an uplink.

[00:09:34]This guy is my mono gateway. So, that's Tamasha's uh cool project. Video is not about the mono gateway, but I do like it a lot. So this is also just running basic Linux also has an uplink. Each of these guys is advertising their own subnet a single 64 of which we can do stateless auto configuration and we do.

[00:09:53]So let's see how this mini PC reacts to having two routers on the same network.

[00:09:58]So over here at the test system if I just run IPA I can see my addresses. You can see I actually do have five addresses like I thought I would. So I have my F80 that's my link local address. I also have an address from each of my routers. So this 2 AOF B240 10101 that's router one and then 200199A that's router 2 and then we have a temporary for each one as well. So that makes sense. So I got an address assigned by both routers. So in theory I could use both of these internet connections and I have a route to them as well. So I do IP6 route then I can see I have these two routes here. So I have default via FE80662.

[00:10:38]That's my protectly router one. And it says it got metric pref because that's what the router was advertising. It's the high priority router. And similarly down here I get default via FE80 AF6.

[00:10:51]And this is um priority low because that router is claiming it's a low priority router. So now what happens if I try to ping someone? So let's try pinging 2620 FE FE. That's quad 9 DNS. So, that one's not working. How about if we try to ping uh this? So, this is my ISP's DNS server. That's not working either. Now, how about if I ping my own anycast? So, this is in a similar prefix range. So, I'm going to have a longer prefix match.

[00:11:22]And well, that one works. So, some of our addresses work. And I guess the fact that it doesn't work means I better go to Wire Shark, right? So, this is the ping that works.

[00:11:33]This ping doesn't. And also this ping doesn't. So hopefully we have some of those in the wire shark now. Yeah. So here's the uh the different pings going on. So look at the one that worked. So in detail here.

[00:11:48]So it looks like we're an Ethernet 2 frame which we expected. It's an IPv6.

[00:11:53]So our address here is from an address on the 2AF B240 subnet. That's my address. And the destination is going to be 420. Also notice here in the Ethernet frame the destination is protectly. So this is the protectly firewall at 6462.

[00:12:11]So next up let's look at this one. So this is the one that failed. So in this case um my Ethernet 2 again it's sending it to the protectly. So that's router one. But then down here in the IP packet it's sending it from my 200199A address um and to the right destination. So, it looked at these two addresses here and thought they were similar enough that it should use this source address. And this source address is from router 2. So, it's taking an address from router 2 and it's using it along with router one.

[00:12:46]That's probably what's going on with the third address as well. Yeah. So, same with this address. So, 2620 FEF, it also chose to send to router one using an address from router 2 source. So the issue we've just stumbled on to is called reverse path filtering or RP filtering. Basically each of these we assume is a separate internet service provider. And the service providers can't be spoofing the source address of packets. They can't allow their customers to do that. That's how we end up with DOS attacks around the internet.

[00:13:15]So since we don't want our customers to be part of botnetss hopefully we don't let them spoof source addresses. That means both of these routers are reverse path filtering. So they're not allowing traffic from the wrong source to get routed through them. So if this guy is advertising subnet one, he's not allowing traffic that doesn't belong under subnet one to go through him as a router. And same with this guy for subnet 2. This guy's number two. And so they're not letting the traffic go to the wrong router. So this guy says, I have two default routers and I have four IP addresses. It's picking an IP address essentially at random and it's picking a router also essentially at random. And if that IP address doesn't match up with that router, then the router is going to drop the traffic. So that means we essentially have two different avenues we can look at this from. First of all, how do we make sure we pick a source address that goes out the router we want? And second off, how do we make sure if we've picked a source address that that traffic then uses the specific router? And so this comes from two different parts of the IPv6 spec that I guess I should go to on the board a little bit. So source address selection that sort of came up in a roundabout way with this issue, but the issue is source address selection. So taking a step back a bit, imagine my laptop here has both wired Ethernet and Wi-Fi. And I'm connected to two separate networks at the same time, one on Wi-Fi and one on wired Ethernet. You've probably done this before, and it probably works exactly as you'd expect. You can access both networks directly connected just fine. One of those two will end up as your default internet route. Probably wired Ethernet because most operating systems have a bit of a huristic that wired is better than Wi-Fi. Maybe not though, depends on the operating system.

[00:14:59]But one of those two will be your internetbound router and the other they'll both just basically work. So now imagine we're essentially condensing that into both of them are on one interface and now we have connections to both routers. So it's a similar question but slightly more nuanced. This question also doesn't really exist in IPv4. IPv4 just doesn't cover this scenario. So, sorry about that legacy people. So, IPv6 has a formal rule that you should prefer whatever your outgoing interface is. So, if we have Wi-Fi and wired, IPv6 says if we have an address on both interfaces, we should prefer the one we're actually using for the route. So, if we already know the packet's going to leave via wired Ethernet, we should use our wired Ethernet address as our source. Makes sense. Same for Wi-Fi. Now, where it falls apart is if we have two different routers, each of those has assigned us an address. It doesn't explicitly say we have to choose the address that came from the corresponding router. It doesn't say we shouldn't. It says we should instead of we shall. So, that distinction is because IPv6 back in the '90s didn't formally require that we actually tracked which router assigned us which prefix. So they couldn't make it a shall requirement because that would add more burden on the operating system to track that. Now realistically every operating system does track that.

[00:16:24]So it's not a burden for them to have to track what the next top router is. They already have to do that lookup anyway to know what interface it's going out on.

[00:16:33]Now they just have to narrow that down to not just an interface but also a next top router. So Linux doesn't do this by default. Not the kernel, not network manager, not systemd networkd. I tried all of them. Mac OS and iOS don't appear to do this either. Strangely though, Windows does. So, what does this look like on Windows? So, back over here to talk about how that works. And I got a new mini PC out. Not cuz I didn't like the old one, but this one runs Windows.

[00:17:01]And Windows has a bit of a different behavior. So, they're actually following the RFC even though it's optional. And they're doing everything well correctly, which is a big shock for Microsoft here.

[00:17:11]So I guess if you had this theoretical network of only Windows business PCs, you could do multihoming with IPv6 just natively. The only wrinkle there is that Microsoft doesn't do 464X lot yet like every other operating system. But um baby steps, we're getting there. So over on Windows here, I can run IP config again. And you can see I again have both addresses from both routers. So I got the 2001 and the 2 AF. I see both routers as my default gateways. So, EAF6 and 6662.

[00:17:42]And I can ping all of these addresses.

[00:17:44]So, if I ping 2620 FEF, look like that one's working. If I ping 2 AFB240, look like that one's working. And if I ping the what is it? And if I ping 2001 98, that one is also working. So, we take a look at Wireshark here and we filter for just ICMPv6.

[00:18:03]So, we can see what are we doing here.

[00:18:05]So, we're sending a ping and we're sending it from the 2 AFB240. So that's my preferred router, but this is a very close subnet to my not preferred one, but it still chose the preferred router anyway because that's where its next top is going to be. And so it did that same choice for all of the pings here all the way down the trace. So it it did the right thing. So now what if I tell ping to force a source address of 200199A?

[00:18:29]So this is my address. It's just the address that I'm not preferring. So it should send it to the not preferred router, but it looks like it's not. So, I'm not getting a response back. And if I look in Wireshark, you can see what happens. So, it's this packet here. So, it has the source address that I told it to, the 2001 99ia, but the Ethernet 2 frame, it's still sending it to the primary router. So, even though I picked a source address from the secondary router, it's still sending the packet on the wire to the primary one. So, Microsoft has done correctly is they've chosen a source address from the preferred router. So if router one is the preferred router, we should be trying to use a source address by default that we would use for the preferred router. So we're using the preferred next top. What broke down though is when the application forced a IP address from the unpreferred router.

[00:19:20]So hold on there. What do I mean by the application choosing the wrong router?

[00:19:24]So taking a step back at what most of you have probably heard about. If you've ever tried to implement like dual WAN, so two internet service providers, we are not doing BGP. It probably involved network address translation for IPv4. So with that method, we have a pool of clients. They have legacy addresses. We have one router. The router knows both of the upstreams. It's doing some sort of monitoring to decide which upstream is up or down. and then it's translating packets from my interior subnets to one of the two exterior addresses. So the hosts have no idea any of this is happening. They might have a connection that's alive and then one second it transferred over to a different source address and broke. Then their video calls get interrupted. Crap like that.

[00:20:07]We're also relying on the two gateways to be detected properly by the multan.

[00:20:11]So if it's pinging google.com every 5 seconds or something, Google's not going to like that very much. But it also means that if that detection fails, we might not fail over correctly or something like that. It's all a bunch of headache involved in the system. So what if we just let the video chat application be aware that we had two internet connections and if it was like a video chat or real-time game or something, the developers could put effort into making it work across two internet connections if it was important to their app. So essentially every video chat ever in the modern world uses WebRTC. WebRTC is done by Google, Firefox. Every web browser uses the same library. So if WebRTC were to support two different internet connections, suddenly a whole class of apps would be able to natively support sending packets over both connections. And WebRTC already does for two address families.

[00:21:03]It'll do matchmaking over V4 and V6 and choose one of the connections based on what works. So if suddenly now in addition to V4 and V6, it knows one of the hosts has two different internet connections. it can try both of them and see which one's better. So this is bypassing that the network has one as the preferred router. The application because it's aware of both connections in IPv6. It's able to specifically assign a source address from the wrong router. And this is super powerful because it means that the application now has the freedom to choose its failover behavior. Maybe it sends it out both interfaces to guarantee data always makes it. If you're gaming, that might be a good approach. The data is relatively low bandwidth but very latency sensitive. Maybe for video chatting, you could periodically send packets out both interfaces to make sure they're awake. That kind of stuff. So, that's pushing a lot of really cool abilities down into the host application developers now that we've given them the ability to use both internet connections together. But it also means if we're going to send packets from the non-preferred connection, we have to send them to the right router. So what Windows was doing was it was sending all the packets to the preferred router even if an application chose to use the non-preferred address. So it should be sending them to the non-preferred router that gave it that address. Now fortunately here there's a little bit of a bodgege that the network can do. If these two routers are aware that each other exists, they can create a route to the other one. So if I'm sending all of my packets to the default router, most of them will go to the default router.

[00:22:35]But if some of them should have gone to the non-default router, the default router can just kind of kick them over here. And I can do that over the LAN interface. It doesn't need a dedicated connection for this. So I could add that to my Linux routers. And we can see if that works. And so I did exactly that.

[00:22:50]So this is the main router, the protectly. So I add an IP6 rule that says from the less popular subnet 20019A lookup 200. So that means use a different routing table. And then here I see that routing table. So route show table 200. So we're taking default via the other router. So basically if a packet comes in and it has this source address of the other router, we send it across to well the other router over Ethernet. And so now on Windows the ping from the wrong address, it works. Neat.

[00:23:26]So with that hurdle out of the way, I guess the only thing left is for failover to work. So, I have two routers, two upstreams. When one of my upstreams dies, especially my primary upstream, if we just kind of unplug it here, we expect all the traffic will now fail over to the secondary. And that's mostly true. Plug this guy back in. And so, how this works in IPv6 is both of these routers are advertising themselves as a default router candidate. They're advertising their priority, low, medium, high. So, we really only have to be able to set the priority of one of them because most devices default to medium.

[00:24:00]So we can either set the secondary as low or the primary as high or both if we want.

[00:24:06]And so they advertise this with a lifetime. Now usually we set this lifetime to like 24 hours. So devices when they go to sleep don't have to think about getting a new address again and wait that wait time to rediscover their address when they wake up. But we can always lower it. So if we send out an advertisement that updates the wait time, devices will honor it immediately even if their older address shouldn't have expired. So this router can check its upstream and when the upstream goes down it can advertise itself as having a lifetime of zero. So that means that all these mini PCs here should withdraw their route to this router and that means now that this is not a valid route. This low priority router becomes the only option. So they use a low priority router. And so if devices were already multihoming aware like application software like WebRTC, it would already be using this router for some of its traffic and it could fail over. As soon as it detects packet loss, but for everyone else, we're monitoring the upstream gateway. We're monitoring the link status on Ethernet. When those go down, this router withdraws, everything transfers over. So we could do this with BFD if our provider supports that. We could do it with gateway pinging. if we have direct Ethernet connection. We can see when the Ethernet link goes down, stuff like that. So, let's see how that looks. So, I've got a ping going on here. So, we're just pinging this guy forever. And let's see what happens when my gateway turns off. I don't have automation for this yet, so I'm just logging in manually and shutting it off. Okay, so we got one packet lost and we're back. Okay, so we lost about two seconds of connectivity there. It's not too bad, is it? When I restart the new gateway, old sessions can still use the failover internet if they were already established. Uh I'm not sure what point it'll switch back over to this gateway, but uh look here. Yep, it's already failed back over, so no loss on return.

[00:25:57]So there we have it. I have completely simulated a multi-wan setup with IPv6 without using network address translation and it worked. So talking to networking experts who don't want to deploy IPv6, some of the reasons are purely political or whatever, but if they have a technical reason why they don't want to support IPv6, it's almost always this exact setup. They're running networks for businesses. They're probably like a managed service provider, that sort of tier. Their customers are small businesses. They're not doing BGP. They want to have redundant internet. In IPv4, they do that withNAT. In IPv6, we don't do NAT.

[00:26:37]So, how do you do it? The guidance that I've heard generally so far is to essentially network prefix translate one way or the other way or there's a couple different approaches to that. This approach, if all of the operating systems implemented rule 5.5 and the routers could cross route to each other and the clients could pick the correct router, this would completely solve that problem. For IPv6 multihoming, clients would select the correct router and the correct source address based on the router priority. So all you have to do is configure two routers for different priority and the different way interfaces take over.

[00:27:14]The applications can still choose to use both interfaces if they'd like. So applications that are multihoming aware like WebRTC potentially would be able to take full advantage of this whole setup.

[00:27:26]We're not breaking endtoend network translation. Everything is pretty good.

[00:27:30]Unfortunately, that rule 5.5 quirk is still there. Now, if you're in a setup where both of your WAN interfaces are relatively equal or you're not trying to force all of the traffic down just one interface, then you actually don't really care. So, source address selection, they're not picking randomly.

[00:27:47]They're picking based on longest prefix match. So, in my case, one of my subnets was a 2 and one one was a 2A. So, addresses that are closer to 2A will end up taking the 2A router. address is closer to 20, we'll end up picking 20 router. So, if these are two separate fiber providers or maybe fiber and cable where they're relatively balanced, I might say I don't care as long as I'm routing out to the correct router. Maybe I need a high-speed link between these two routers or something for that to happen. Then they're going to essentially load balance based on their IP address randomization.

[00:28:20]And that's fine. And another question I'm sure I'm going to get asked is people like using one single router on their network because that's how they've always done it. In this scenario, I've used two. And I've used two to demonstrate that essentially we're tracking which router gave us which address in IPv6. So we need them to appear separate. But there's no reason why this router couldn't be like a container on the other router or even just a virtual interface. So, as long as we give this single router two link local addresses and it sends its router advertisements, two separate ones from two separate link local addresses, it could be one router with one set of routing tables, cross routing correctly internally, stuff like that. We could implement that if we wanted to. And of course, I'm sure I'm going to hear a lot about what about IPv4. And I think the easy answer to that is use 464XLAT.

[00:29:10]So, most modern operating systems now support 464XLAT. Linux just got it in network manager. I run Taigga. If you need help on Linux, I can help you with that. Or FreeBSD. Mac OS and iOS and Android have all had it built in for like 10 years. Windows just got it in tech preview on normal interfaces. It's had it on Huawei and interfaces, cellular for like 10 years. Also, 464 XLAT translates IPv4 packets into V6, carries them over the V6 network, and then translates them back. So we can have each of these routers doing NAT 64 to the provider's public IPv4 and then the clients will do the same choose they'll they'll choose the 464XLAT router of their preferred next top use that for IPv4 connectivity they'll fail back to the other router over 464XLAP everyone will be happy um so I think this is really where IPv6 and multihoming in general should be going because with this setup, just being able to buy a 5G router and plug it into my LAN as a LAN port, that is like really, really easy. That's something that a lot of small business owners could benefit from. And we're so incredibly close as IPv6 standards authors, things like that, to having this being a totally working setup. So, I hope we can continue pushing these standards across the line. There's an IPv6 draft right now to change the rule 5.5 behavior or rule 5 in general to require that operating systems track source address correctly like Windows does. I anticipate and there's already patches for Linux for to make Linux do it. I anticipate Apple would follow right away because they're generally very good about standards compliance for IPv6. For everyone that says 464XLAT's not like widely deployed or whatever, it's been deployed by T-Mobile for 13 years now and most mobile networks at this point are running 464Xlad or something very similar to it. So there's no reason we can't have it running on all of our home small business networks like the big guys. Also, by the way, I am an IPv6 Sage from Hurricane Electric and I got the shirt from it. Uh I don't have this shirt for sale, but if you'd like one of my other uh shirts, you can check out my merch store link down below for that.

[00:31:21]Feel free to comment on this video, like and subscribe, all that good stuff. It boosts engagement. If you want to have a longer discussion, you can reach me out on my Discord server, link down below for that. And I guess I'll see you guys on the next adventure. Also, 30% off Proton Unlimited. Link down below for that as well.