← Back to context

Comment by toast0

6 days ago

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