Dual Internet Connections Are Still Needlessly

I've had a video call die mid-client presentation because a guesthouse in Medellín ran its entire building off one sketchy DSL line and somebody's microwave apparently hated Zoom. My backup plan at the time was a local SIM card in my phone set up as a hotspot — which I had to manually switch to, then re-join every app, then explain to the client why I had suddenly become a pixelated ghost for 45 seconds. Real smooth.

That is the nomad version of the problem the host of apalrd's adventures unpacks in a recent 31-minute deep-dive: you have two internet connections, and actually using both of them — automatically, seamlessly, without a networking degree — is somehow still an unsolved problem in 2024. His framing is a small law office or pizza restaurant. Mine is anyone who's ever run a local SIM alongside a roaming eSIM and discovered that "backup connection" mostly means "connection you frantically switch to manually after things have already gone wrong."

The elegant version of this — the one that should exist — is simple: two ISPs, two routers, one LAN, plug everything into a switch, and your devices just use whichever connection is working. No configuration wizard. No managed service provider charging you to set up a multi-WAN appliance. Just works. The video asks why we don't have that, and the answer is annoying in a very specific way.

The actual problem is routing, not hardware

The layer-2 stuff — ethernet bridging, switches, Wi-Fi — is all fine. Bridging two ISP routers into a single LAN is straightforward. The chaos starts one layer up, when your device has to figure out which router to send packets through and, critically, which source IP address to put on those packets.

With IPv6, a device on a network with two routers will automatically pick up addresses from both. That's genuinely great — in theory, your laptop has a live address on both ISPs simultaneously, and could use either one. The problem is what happens next. When your laptop goes to send a packet, it picks a source address and a router. And it might pick ISP-1's address but accidentally route through ISP-2's gateway. ISP-2 looks at the packet, sees a source address that belongs to ISP-1's subnet, and drops it. This is reverse-path filtering, and it's not a bug — it's how ISPs prevent customers from spoofing addresses and contributing to DDoS attacks. Annoying that it breaks our setup, but the alternative is worse.

So the fix needs two things to happen simultaneously: pick the right source address and route through the corresponding gateway. IPv6 actually has a rule for this — Rule 5.5 in the source address selection spec says you should prefer the address that matches your outgoing router. The keyword is "should," not "shall." In RFC language, that's a meaningful distinction. "Shall" is mandatory. "Should" is a suggestion. The reason it's a suggestion is that when the spec was written, requiring OS developers to track which router assigned which prefix felt like too much overhead to mandate.

Here's where it gets genuinely funny: Linux doesn't follow the optional rule. macOS doesn't either. Neither does iOS. The one operating system that actually does this correctly, that tracks source addresses and routes them to the right gateway by default?

Windows.

Windows. I'll give that a moment.

The host of apalrd's adventures is clearly as bewildered as I am: "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." He demonstrates it live with Wireshark — Windows picks the right source address, routes it to the right gateway, pings succeed. Linux just... guesses, basically, and gets it wrong about half the time.

The NAT status quo is embarrassing

Before getting into what IPv6 could do, it's worth being blunt about what the current solution actually looks like. If you've ever tried dual-WAN with IPv4, you've run into NAT-based failover: one router in the middle that knows about both upstreams, monitors them, and translates your internal addresses to whichever upstream IP is currently working.

The monitoring part is where it gets embarrassing. A lot of these setups detect failover by pinging google.com every few seconds. The host clocks this correctly: "Google's not going to like that very much." And if that detection glitches — if the ping succeeds but the actual connection is broken, or the ping fails but the connection is fine — your failover doesn't trigger correctly. Meanwhile your video call is already dead. Your clients are staring at a frozen frame of your face. You're restarting apps and apologizing.

The deeper problem is that with NAT-based failover, your devices have no idea the switch happened. One moment they had a working connection, the next their source address changed underneath them and all their sessions broke. The network absorbed the complexity, badly, and handed you broken sessions as a result.

What IPv6 multihoming actually enables

The IPv6 approach flips this. Instead of one router managing everything invisibly, your devices know about both connections. Applications can be built to take explicit advantage of this — and the host points out that WebRTC, which is what basically every video call in existence runs on, already does something like this for IPv4/IPv6 dual-stack. It tries both address families and picks what works.

Extend that logic to multihoming and suddenly a video call application could maintain connections over both ISPs simultaneously and fail over at the application layer the moment it detects packet loss on one — before you even notice. As the host puts it: "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."

For a nomad running Zoom on a local SIM with an eSIM backup, that's the difference between a two-second blip and a 45-second nightmare.

How close are we

The host demonstrates a working setup — two mini PCs acting as routers, one Linux test machine, Wireshark running. With some source-specific routing rules added to the primary gateway (basically: if you see a packet with ISP-2's source address, kick it across to ISP-2's router over the LAN), even the Windows edge case resolves. He pulls the primary router's ethernet cable mid-ping and loses about two seconds of connectivity before the secondary takes over. Not bad.

Failover works through IPv6 router advertisements — each router broadcasts its priority and a lifetime. When the primary detects its upstream is down, it advertises a lifetime of zero, clients withdraw their route to it, and the secondary becomes the only option. Clean. No polling google.com. No NAT session management. The video cites an active IPv6 draft proposing to make the Rule 5.5 behavior mandatory rather than optional — which would require Linux and macOS to finally do what Windows already does.

For IPv4 compatibility, the answer is 464XLAT: a translation layer that wraps IPv4 packets in IPv6, carries them over the v6 network, and unwraps them on the other side. Mobile networks have been running this for years — T-Mobile is a notable example, according to the video — and it means you can run a fully IPv6 internal network while still reaching IPv4-only destinations. Android, iOS, and macOS have supported 464XLAT for years; Windows just got it in tech preview for standard interfaces.

The single-router question comes up too, and the answer is cleaner than you'd expect: you don't actually need two physical routers. One router with two link-local addresses, sending separate router advertisements for each ISP's prefix, would behave identically from the client's perspective. One box, two upstream connections, correct source address selection, cross-routing between them internally. The architecture doesn't require new hardware.

The gap between "works in a lab" and "works at the guesthouse"

What the video demonstrates is a proof of concept that requires Linux routers you configure yourself, an understanding of source-specific routing tables, and at least one device running Windows if you want out-of-the-box correct behavior. That's not nothing — for the technically inclined it's genuinely useful. But it's also not the "plug two routers into a switch and it just works" future that the spec almost enabled.

The missing piece is the Rule 5.5 upgrade landing in Linux and macOS — and then consumer router firmware actually implementing the cross-routing logic. Neither is technically hard. Both require someone deciding it's worth doing.

Until then, you're still switching hotspots manually at the worst possible moment, explaining to clients that no, you're not actually in a wind tunnel, and wondering why the networking stack on your laptop can't figure out something Windows solved quietly sometime in the last decade.

Tomas Reyes-Kim covers budget travel and digital nomad infrastructure for BuzzRAG.