Multi-homed IPv6 with dynamic addresses

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?

1 Like

Probably not since there is no opkg with the NPTv6 module in the packet repository to my knowledge. I looked for it recently.

1 Like

The NETMAP target is supported and should do the trick using the nat ip6tables.

However I need help with customizing OpenWrt itself, as all that nifty automatic IPv6 stuff doesn't work so well in my scenario.

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:

#!/bin/sh

. /lib/functions/network.sh

LOG=/dev/null

echo ACTION=$ACTION >> $LOG
echo INTERFACE=$INTERFACE >> $LOG
[ -z "$INTERFACE" ] && exit 0
CHAIN=nptv6_$INTERFACE
echo CHAIN=$CHAIN >> $LOG

network_get_prefix6 prefix6 $INTERFACE
echo prefix6=$prefix6 >> $LOG

if [ "$ACTION" == "ifup" ] || [ "$ACTION" == "ifupdate" ]; then
        network_get_device ifdev $INTERFACE
        echo ifdev=$ifdev >> $LOG
        [ -z "$ifdev" ] && exit 0

        [ -z "$prefix6" ] && exit 0

        ip6tables -t nat -N $CHAIN >> $LOG 2>&1
        ip6tables -t nat -F $CHAIN >> $LOG 2>&1
        ip6tables -t nat -A $CHAIN -o $ifdev -j NETMAP --to $prefix6 >> $LOG 2>&
        ip6tables -t nat -D POSTROUTING -j $CHAIN >> $LOG 2>&1
        ip6tables -t nat -A POSTROUTING -j $CHAIN >> $LOG 2>&1
fi
if [ "$ACTION" == "ifdown" ]; then
        ip6tables -t nat -D POSTROUTING -o -j $CHAIN >> $LOG 2>&1
        ip6tables -t nat -F $CHAIN >> $LOG 2>&1
        ip6tables -t nat -X $CHAIN >> $LOG 2>&1
fi

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.

2 Likes

Suppose you only advertise a ULA and then use npt6 for handling the wan. Then at least the clients aren't renumbering constantly?

Or Maybe Just Advertise your main Prefix until It Needs Replacement, Then Advertise The New One

1 Like

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.

1 Like

can you maybe use radvd instead of dnsmasq, and then just rewrite the radvd config with a script, and restart the daemon?

I see there's no radvd package in the package list though...

I guess you could probably just reconfigure the dnsmasq as well and restart it.

1 Like

In my OpenWrt installation, dnsmasq isn't doing any IPv6 router advertisements:

Dnsmasq version 2.73  Copyright (c) 2000-2015 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC loop-detect inotify

That's the task of odhcpd, which seems to be OpenWrt-specific and almost undocumented.

1 Like

Any update on this? I'm worried to face the same issue if any of my 2 ISPs start changing my global prefix, which they don't seem to be doing ATM.

BTW, are you using mwan3?

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.

1 Like

All you asked for an update on a 2 year old thread...then responded to your own post a year later...?

Maybe I'm missing the point of your posts...

I thought NPT6 was experimental. In addition the RFCs note to use a DHCPv6-based solution to solve this issue.

I'm not asking for an update. I made a post to update my situation, that I'm still unable to find a solution.

I was lamenting that nobody else (seems to) found either.

1 Like

:confused:

:point_up: I must have misread.

I guess you didn't read the RFC (nor did you read that it's experimental). Nonetheless, I hope the best for a solution to your "situation"! :slightly_smiling_face:

2 Likes

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.

as for multihoming... it's still an issue yes.

4 Likes

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.

1 Like

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.

2 Likes

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

Conclusion: IPv6 doesn't work multi-homed.

It's more like there is no single canonical method for multihoming. Using NPT would work just fine. It's possible to do but not trivial to set up.

https://datatracker.ietf.org/doc/html/rfc6296