Multi-WAN IPv6 Prefix Deprecation Problem

[ciaduck]

I'm having some issues with multi-wan failover using IPv6.

WAN is DHCPv6

WAN2 is set to SLAAC via LTE Modem, I'm not as concerned that this doesn't seem to work for ipv6 at the moment. I've been able to get things to work with NPT, but I think I will assign dedicated NAT addresses in the future, because NPT needs to also be updated every time the WAN prefix changes.

LAN is set to "Track Interface"

I'm using radv "Router Advertisements" in the services.
It set to "Assisted" with "Automatic" source address.
I've not set any advanced options, everything is default.

I tested my failover by unplugging the cable from my cable modem. When service was restored, the gateway monitoring functioned, and fail to LTE was fine. Once I plugged it back in, I noticed a lot of delay trying to get to test-ipv6.com

I had the same issue on my phone. I cycled the wifi connection on and off and it solved it.

I can see from a windows client that I still have the old prefix/address.

What can I do to solve this issue? I'd like to have clients properly deprecate/abandon an old address when the WAN flaps.

Here is an example output from ifconfig. The c881 is the new address, and the c800 is the old one.

Code Select Expand

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : home.arpa
   IPv6 Address. . . . . . . . . . . : 2601:281:c881:fb80:1a7a:5927:4cd4:e21b
   IPv6 Address. . . . . . . . . . . : 2601:281:c800:3910:3e2f:a436:d203:d072
   Temporary IPv6 Address. . . . . . : 2601:281:c800:3910:a512:d226:8873:46cb
   Temporary IPv6 Address. . . . . . : 2601:281:c881:fb80:a857:a7c4:21fe:3929
   Link-local IPv6 Address . . . . . : fe80::d1fd:217e:6ec2:961%25
   IPv4 Address. . . . . . . . . . . : 192.168.1.161
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1
Should I set radv lifetimes to something more aggressive than the defaults?

[meyergru]

Using an aggressively short validity timespan sure helps, however, you should probably try setting "Deprecate Prefix" to on. That way, radvd will announce a zero lifetime upon restart for the old prefix.

Note however, that this has ill effects when a prefix is being reused - your clients will not accept it any more. IPv6 was never designed for dynamic prefixes, even less for failover situations with different prefixes. Thus, you will die on the road you choose.

Probably the only way to go would be to use NAT66 in order to keep local IPv6 ranges constant, but do not bother using ULAs. There are lots of threads about that, take a look around.

[ciaduck]

Thanks for the reply. There were a few changes I made and things appear to be more stable. I'll have to wait a bit longer to be sure. Over the last few months I've been having to power cycle the router to fix a "split brain" situation with the networks.

The 2 things that seem to have made a difference.

1 - In verifying my settings, I didn't have any DNS server set in [system] > [settings] > [general]. I've corrected this and set them to the same servers as I have in the gateway monitoring.

2 - I've set more aggressive timeouts for RADV. I'm now using:

Code Select Expand

Minimum Interval = 10
Maximum Interval = 30
AdvPreferredLifetime = 60
AdvRouteLifetime = 90
I've disabled any settings for NPTv6 from the [Firewall] > [NAT], because of my GUA prefix changing. Thanks for your feedback about ULAs. I know there are issues with dual stack networks, and it seems this would be one of those cases where using ULA for NPT would simply result in no IPv6 going out the secondary WAN due to "happy eyeballs" and IPv4 preference.

I'll look into NAT66. I'm also researching using a reserved GUA (like 2000:db8:: ) for NPT, but this would be a hack.

Thanks for the time and feedback.

[ciaduck]

Just one final update. Sorry to bump this thread. But I wanted to get the info out there.

I've simply decided to ignore having any IPv6 on the backup LTE via SLAAC. This has simplified the gateway monitoring, routes, and switching.

I've noticed that part of the issue with the LTE modem is the ISP will drop the IPv6 connection if any traffic originates from it that isn't from the assigned /64 SLAAC address. This is part of why NPT wasn't great. I could set up NDP in the future to provide addresses for the SLAAC interface, but that just doesn't seem worth it for the few hours per month the backup is in play.

The prefix issue still exists, but is far less catastrophic to the network. The short times appear to help, but I still notice some Windows clients getting stuck with the old prefix and therefore unable to route IPv6 traffic after the primary WAN is restored. I could probably detect and solve this problem with a script, but I'm pretty busy and my family probably doesn't have the patience for that.

Thanks for the great product and support.