I'm currently setting up my OpenWrt router with multiple WAN interfaces: one primary WAN link and a metered one to fall back on if the primary link goes down. Both WAN links feature native IPv4 and IPv6 with prefix delegation and dynamic addresses (including dynamic IPv6 prefixes).
With an IPv4-only setup everything works fine. All I had to do was setting the interface metric correctly, so the correct WAN route gets chosen and I'm done. NAT does the rest.
Now OpenWrt's approach of handling IPv6 using source-based routing doesn't really work for me. By default it announces all available WAN IPv6 prefixes as preferred to the LAN and the clients arbitrarily choose one they like, and therefore choose their favorite WAN interface. Even worse if the dynamic prefix changes, they fall back to IPv4 or to the other WAN link.
What I like to happen instead:
Only one preferred IPv6 prefix should be announced to the LAN: That of the best available WAN route (lowest metric). Once a more preferred WAN link is available, the prefix of all other interfaces should be deprecated (but still be usable). The router should always choose the WAN interface to use, not the clients.
Now dynamic IPv6 prefixes add the challenge that at some time one prefix stops working and gets replaced by a new one: OpenWrt deals with this by deprecating the old prefix and advertising the new one. As a result clients still trying to use the old prefix fall back to IPv4. What should happen instead is that if a client uses an outdated prefix, it should be translated by the router to the correct one using stateless NPTv6.
Is it possible to configure OpenWrt to make this work?
I'm one step further I wrote a hotplug-script and put it into /etc/hotplug.d/iface to add the a NETMAP translation rule for each IPv6 WAN interface, which has a IPv6 prefix:
This way, non source-based IPv6 routing works, as long a there is at least one public prefix announced on the LAN interface. When the prefix used by the clients matches the currently assigned prefix, it's passed through 1:1 otherwise it's translated using a 1:1 suffix mapping. (I have forced IPv6 connection tracking to make the return path work as well.)
Now there there is only one problem left: Correct (default) route selection and preferring/deprecating the right IPv6 prefixes. I know barely anything about how to configure odhcpd to make this work.
Unique Local Addresses are not usable for accessing the IPv6 Internet. Clients will automatically prefer IPv4 instead.
However the daily or weekly renumbering isn't the issue as long as the router is smart about outdated prefixes. By transparently mapping them to correct prefix (which my script does), it keeps IPv6 connected, even if client applications don't pick the new prefix up. (The default behavior is to null-route the outdated source addresses breaking clients and have them fall back to IPv4.)
Or Maybe Just Advertise your main Prefix until It Needs Replacement, Then Advertise The New One
Getting OpenWrt to announce only one prefix as preferred and route everything through the best/fastest available WAN interface (lowest metric) is my next step in sorting the whole multi-homed setup out. I'm open to suggestions how to achieve this.
I know this thread is very old, but it's relevant.
It's sad that in 1 year nothing evolved on this, no NPT6 support is officially available on OpenWRT, and the few guys trying to make it work are gone.
I also stopped bothering with it when I was unable to make ping work on my PPPoE link and that breaks mwan from working.
I know, it's all FOSS and I should learn to develop on it and provide help instead of ask for it. I'm just bumping to say that I came back and also never made it work.
lol for "ask for an update" I understood "demanded for ppl to keep working on a solution".
Yeah, when I found this thread on 2019, they were alrdy gone for over a year. So I made a post pointing that I also have this issue.
Now I came back hoping that something had progresses, and was frustrated to see nothing else was made.
If it's relevant, I searched how multi-homing and NPT6 is handled on pfSense and OPNsense, and found that it's not much better. pfSense has native NPT6 support, but it requires ISP(s) to provide fixed prefix. When prefix changes, IPv6 Internet goes down and it requires manual update on settings.
OPNsense has a task for developing support for changing prefix and there was some tough discussion between a user who wanted it done and a voluntary dev who didn't like being demanded.
Well, anyway, I'm gonna lament some more. IPv6 is trash. Its designers dreamt of fixing IPv4 flaws that don't bother anybody on past 20 years and had elegant solutions created, while it neglects or creates very troubling issues that open exploits for ISPs to feast. The few solutions available like NPT6 are indeed experimental and barely supported on any open source router OS.
IMHO, IPv4 shortage will end up being handled with ISP-level NAT on residences and shared addresses on servers.
Yeah I know that a great margin of Internet traffic is alrdy done on IPv6, but that's basic usage as simple video streaming and web usage. What I'd expect from IPv6 is that it should be a better protocol that makes ppl in high expectation and begging to be able to use it, instead of something that most ppl just disable due to issues and those who insist to try find tons of more unsolvable issues.
not my experience at all. I ran ipv6 only for at least a year, and configure most of my LAN services via ipv6 mainly (NFS servers squid proxy vpn etc)
almost all the problems with IPV6 in practice are of the form "it's not the tech it's the people" in particular ISPs not following multi decade old recommendations. some give out just 1 ipv6 address! some give out just one /64 prefix... if ISPs just gave out /56 like they ought to it'd be great. slowly they are getting there.
Sorry, I don't agree with u. The technology, in this case a widespread networking protocol, shouldn't leave holes for ISPs to abuse.
By coupling the ISP delegated global prefix to intranet LAN addresses, IPv6 allows ISPs to abuse. It allows ISP to control and dictate how we design our LAN topology. When they provide only a /64 prefix, they deny us configuring multiple VLANs, which hurts security. When they keep changing the prefix, they make our LAN devices inaccessible to each other as long as they don't update their leases and remain using the old prefix.
The protocol designer can't create holes on it and then just hope or beg for ISPs to not abuse it. There will always be companies, specially those with monopoly, that will use it to abuse.
It's beautiful to say that IPv6 allows all devices in the world to have their own public address, but this coupling creates huge issues, much bigger than using NAT and port forwarding.
If you are concerned about ISPs controlling address spaces, consider to abstract from L3 networking to something like overlay networking.
With all that censorship around the world, the concept might have a good chance to become popular in the near future.
Yeah, Tor and other networks have some nice features, but might also be slow. In case of Tor, which I have a relay running, it doesn't solve our issues here. It relies on Internet working, if ISP breaks our address, it will go down too.
All networks that run over Internet, VPN in example, rely on Internet.
Just an update: I'm not multi-homed anymore and I happen to be on an IPv4-only ISP since 2020.
The problem described in this thread even has its own RFC theorizing about solutions, which could be implemented in client operating systems: https://datatracker.ietf.org/doc/html/rfc7157