IPv6 WAN fail-over without IPv6 NAT

Feature Requests
30

It's not simultaneous dual homing but yeah you still have two global connections.

I see what you're trying to do here. It seems like it would be a good thing for there to be router advert daemons that understood and facilitated this use case.

31

SCTP tunnel over both IPv6 uplinks.... requires an upstream SCTP terminating node but should allow what you want...

Sidenote, I was under the impression that OpenWrt already offers IPv6 multihoming via SADR and or babel? Without some multipath tunnel connections over the unavailable uplink will behave oddly, like linger on or result in unhappy applications but that might well be acceptable.

32

OpenWrt provides multi-homing via source-based routing, but not in a useful way. What's achieved is reachability of LAN hosts over both uplinks, which I don't care about. What's achieved is different from what I want - the use of the most performant available uplink, and only it, for outgoing connections, without the unnecessary NAT.

33

Morning, did you have already tried to use the trigger option on the prefix in radv?
And, had you looked at radvd and it's behaviour?

34

Good morning!

radvd was my first thought, but it is not in OpenWrt. Regarding the trigger option, according to the documentation and blog posts that mention it, it is unsuitable due to the following:

  • It works the opposite way: we want to announce the LTE prefix when the fiber prefix goes away, but the trigger option would only let us say: "announce the LTE prefix if the route to the trigger prefix is also available".
  • It would only help with static prefixes.
  • We would still need something to check connectivity, to avoid the situation when the fiber is up and has a default route, but doesn't actually work.

On the other hand, the default netifd/odhcpd has the ip6class list-option that I can set on the LAN, which governs which WAN interfaces should have their delegated prefixes announced. All that is missing is the ability to set this dynamically to the single best WAN that is available at the moment and works - as opposed to a static list, or to the default of including everything.

35

Sounds like this functionality should be factored out into a link monitoring process which then dynamically drives this value.

Netifd could be extended with additional ubus procedures that allow modifying ip6class without the need to touch configuration.

1 Like
36

There is a workaround for that.

37

But this has no Effekt on hosts
However at home I have IPv4, gua and ULA and observed that for instance all my ssh sessions within the lan use ULA :man_shrugging:

38

SSH connections within the lan using the internal hostname? Well, that is expected.

39

But if it hols true that v4 is preferred over ULA, why is it that ULA is used?

40

I think you are confusing it with the scenario where you have private IPv4 and IPv6 and you are trying to reach a public address. In this case the host prefers the IPv4 because it will most likely be NATed, but the lack of GUA IPv6 means there is no upstream IPv6 connectivity, as NAT6 is not considered.

41

Ah make sense. Then I got the shortened memo only. I understood it as v4 is preferred over ULA in every situation. Thanks for the hint.

1 Like
42

351 / 5.000

Resultados de tradução

Resultado da tradução

star_border

I would like a suggestion for failover configuration and load balancing using mwan3 with ipv6, because so far I haven't found any configuration for two links that distribute ipv4 + ipv6 on the provider, so much so that I leave my openwrt only with ipv4. If anyone in this thread has any ready-made scripts or configuration suggestions, please let me know.

43

Given that I also have just started to read it but maybe https://www.rfc-editor.org/rfc/rfc7157 IPv6 Multihoming without NAT can give us some hints?

44

Thanks for finding that RFC 7157, it is really well-written, especially the problem-description part. However, it defers to other RFCs (in particular RFC7078) regarding the implementation, specifying how to push the address selection policy to end hosts, and I could not find any client-side implementations of it. So, in the practical sense, it's still a dud.

It got me thinking though. In particular, Scenario 1 (two routers, with one uplink each) vs Scenario 2 (one router with two uplinks, i.e. the scenario that OpenWrt finds itself in) have a different set of problems. Maybe, by using macvlan interfaces, and pretending to be multiple routers, announcing one prefix each, with the correct router preference, we could communicate that to the end hosts? I have not tried this idea.

Still, such split-router multihoming, if it is helpful, would be a separate feature request. Let's keep this one restricted to pure fail-over, without the end-hosts ever seeing multiple globally-routable prefixes with non-zero lifetime at the same time.

46

No, you misunderstood. I haven't even tried, as that would simply match the default useless OpenWrt behavior.

47

According to https://serverfault.com/questions/768932/can-linux-be-made-to-honour-ipv6-route-advertisement-preferences#768970 the use of priorities is (or at least was at the time) a compile time kernel option, which isn't much help.

48

Well... indeed, on Puppy Linux this option (CONFIG_IPV6_ROUTER_PREF) is not set. I don't know which reaction would be more correct, so here are both:

  1. It may be a good idea to retest Ubuntu and Arch Linux, both of which have this option enabled.
  2. One uncooperative client is still enough to bury the idea for good. The low-priority prefix is not to be used, so easiest way to achieve this would be not to announce it at all. This feature request is specifically about fail-over, not about multi-homing.
49

I agree, although maybe a client ignoring the priority could be considered broken and ignored.

I looked at the manual page for dnsmasq too and while I think you could announce multiple prefixes on a single interface, it only allows the priority to be set for the whole interface and not per prefix. Is this a protocol limitation perhaps?

50

It is indeed a protocol limitation. The router preference is global, there can be only one in the packet. In a Prefix Information option, there are only these fields:

  • Type: that's how we know that it is a Prefix Information option.
  • Length: just in case if somebody wants to ignore the content.
  • Prefix length: well, 64 is the typical value.
  • Flags: nothing related to preference.
  • Valid lifetime.
  • Preferred lifetime.
  • A reserved field.
  • The prefix itself.

I.e., nothing that could be used to say "Use this prefix for source IPs, but actually no, please use anything else if possible".