Comment by nine_k
5 days ago
> a cellular backup to your residential DSL connection
Hmm, what's the problem? I suppose your home devices should never be exposed to the public internet, and should only be accessible via a VPN like Wireguard. NAT64 is a thing if your home network is IPv4.
BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?
> BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?
Yes, an interface can hsve two separate IPv6 addresses, but that doesn't make it easy.
If you do the easy and obvious thing of setting up two routers to advertise their prefix with your preferred priority when they're available (and advertise it as unavailable when they're not), your devices are likely to configure themselves for addresses on both prefixes, which is great.
Then when you open a new tcp connection (for example), they'll pick a source address more or less randomly... There's a RFC suggestion to select the source address with the largest matching prefix with the destination address, which is useful if the prefix is pretty long, but not so useful when the prefix is 2001:: vs 2602::
Anyway, once the source address is selected, the machine will send the packet to whichever router most recently sent an announcement. Priorities only count among prefixes in the same announcement. If you manage to get a connection established, future packets will use the same source address, but will be sent as appropriate for the most recently received advertisement.
This is pretty much useless, if you want it to work well, you're better off with NAT66 and a smart NAT box.
This so, and this is the same if you use IPv4. IPv6 does not bring any regression here; sadly, no progress either. If you have a server that listens to requests though, such as an HTTP server, I don't see how this setup would be grossly inadequate for the purpose.
I would experiment with advertising two default routes, one with a significantly higher metric than the other. Most / all outgoing traffic would go through one link then. If you want to optimally load both uplinks, you likely need a more intelligent (reverse) load balancer.
> If you have a server that listens to requests though, such as an HTTP server, I don't see how this setup would be grossly inadequate for the purpose.
That's the problem. It sounds like it would work if you do this. The documentation suggests multi homing like this would work. When your server gets a request, it sends back the response from the address it received on... but the problem is what router it sends to; when it sends to the correct router, everything is good, when it sends to the wrong router, that router's ISP should drop the packets, because they come from a prefix they don't know about.
> I would experiment with advertising two default routes, one with a significantly higher metric than the other.
Sounds like it would work, but as far as I've found, the priority metric only works if the prefixes are in the same advertisement. If each router advertises its own prefix, the actual metric used is most recent advertisement wins as default route.
Thanks for the details. Sounds more like OS level support being crap to me. The OS could and should maintain IPv6 preference tables.
As I recall, I tried Windows, Linux, and FreeBSD and it was circa 2020. 25 years in, bad OS support for a supposed feature means the feature doesn't work.
> BTW what's the trouble with multi-homing? Can't an interface have two separate IPv6 addresses configured on it, the same way as IPv4 addresses?
Because it breaks your network when that router goes away. Your switch ACLs, firewall rules, and DNS records all become invalid because they contain addresses that no longer exist, that your devices continue trying to reach anyway.
Had to move away from pfSense due to this. It just wasn't possible to stop it giving my devices its public IP as DNS.
So every time I got a new prefix, machines would lose connectivity, usually until I rebooted them.
Switched to OpenWRT which respected my ULA.
Ah, I understand what you likely mean saying "small site multihoming": not a Web site (where it would be trivial), but e.g. a small office.
But with multi-homing you would need to actively test which of your uplinks has Internet access anyway, won't you? And you would have to react somehow when one of your uplinks goes down.
It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.
I still assume that you don't want the internals of your office network directly accessible via the public Internet, even when you easily can; VPNs exist for a reason.
In the IPv4 world, it's easy. Just use NAT, and forward everything over your preferred bearer. Have your router ping 8.8.8.8 or something periodically from that WAN interface to verify reachability. If your preferred link goes down, make your backup link the primary route, clear your NAT translation table, and your local devices remain mostly oblivious that anything happened.
> It's easiest to do by abstracting your site away. Make it use a LAN, and do port-forwarding and proxying through a box that knows about the multiple uplinks, and handles the switch-over when one of them goes down. I don't see how it might be easier with IPv4 than with IPv6.
In the IPv6 world, this is pretty much what you have to do. A whole lot of extra complexity and expense that you didn't have previously.
2 replies →
You should be using dynamic DNS and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes.
> You should be using dynamic DNS
That doesn't solve the problem. DNS remains broken until each and every device, assuming VERY generously that it is capable of dynamic DNS at all, realises that one of its prefixes has disappeared and it updates its DNS records. With DNS TTL and common default timeouts for prefix lifetime and router lifetime, that can take anywhere from 30 minutes to 30 days.
> and firewall rules should be on the subnet boundary in this scenario, any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes.
This requires you to assign one VLAN per device, unless perhaps you've got lots of money, space, and power to buy high end switches that can do EVPN-VXLAN so that you can map MAC addresses to SGTs and filter on those instead.
2 replies →
The amount of ignorance in these ipv6 posts is astounding (seems to be one every two months). It isn't hard at all, I'm just a homelabber and I have a dual-stack setup for WAN access (HE Tunnel is set up on the router since Bell [my isp] still doesn't give ipv6 address/prefixes to non-mobile users), but my OpenStack and ceph clusters are all ipv6 only, it's easy peasy. Plus subnetting is a heck of a lot less annoying that with ipv4, not that that was difficult either.
18 replies →
I want to send my ssh via my low latency reliable connection, I want to route my streaming via another connection. That’s just a routing rule and srcnat in ipv4
That’s before you go on to using PBR. I want to route traffic with different dscp via different routes.
Ultimately I want the rout g to be handled by the network, not by the client.
IPv4 and nat makes that a breeze.
8 replies →
> any decent firewall (including referee PFsense/OpnSense) support ACLs that follow IPv6 address changes
In the case of pfSense this is a recent change. It was not supported when I migrated away from it less than five years ago.