IPv6 prefix change breaks connectivity: RA lifetime issue

RouterOS General
1

Hi everyone,

I have a dual-stack setup where my ISP provides IPv4 (behind CG-NAT) and an IPv6 prefix via DHCPv6-PD over PPPoE. I’m experiencing the same issue described in the following threads:

In short, every time my delegated IPv6 prefix changes, it breaks connectivity for my devices and homelab (especially problematic when I’m away and need to access my self-hosted services). The issue is that both the old and new prefixes remain valid and preferred, since the router does not send a Router Advertisement (RA) with a lifetime of 0 to invalidate the old prefix.
This behavior is exactly what’s described in the two topics above.
Currently, I’ve found two potential workarounds:

  1. Set very short lifetimes for the prefixes (e.g., 90 seconds). In my opinion, this is not an ideal workaround.
  2. Use a script triggered by DHCPv6 when the prefix changes, to send an RA with a lifetime of 0 for the old prefix, as per RFC 7084 . This is the solution I’m currently using.

I’m wondering if there’s a better or more official solution to this issue, or if there’s something wrong with my configuration.
I’d really appreciate any comments, suggestions, or ideas you might have.
Thanks in advance!

2

In this monster thread from a couple of years ago where this was discussed ad infinitum, I wrote and posted such a script triggered by DHCPv6 lease changes that seems to be fairly universally applicable and fairly robust. We also relied on this script for a while.

But then, as hinted at at the end of the thread, ROS 7.9 natively added support for this, such that this script is no longer necessary…from the changelogs:

*) ipv6 - send out RA packet with “preferred-lifetime” set to “0” when IPv6 address is deactivated;
Are you finding this not to be the case? It certainly worked last time I tested it, but I admit I have not kept up on doing detailed testing of every single release since then in order to see if this has ever been regressed.

Is it possible you are still on an older version of ROS?

3

Strange behavior… You are right.

I initially made a mistake when trying to diagnose my connection issues. I used to reboot the router to force an address update because I noticed that simply disabling and re-enabling the PPPoE interface doesn’t always trigger a prefix change. And obviously, rebooting the router does not send a RA packet.

This time, I tested it properly without rebooting the router, and I can confirm that RA packets are being sent as you mentioned. Imperfectly, but they are being sent.

I captured the packets using Wireshark, and the router sends RAs with only the preferred lifetime set to 0. However, it’s still not fully compliant: according to RFC 7084, it should send RAs with both the preferred and valid lifetimes set to 0, or at least with a valid lifetime of 2 hours or less. This doesn’t seem to affect the connection directly, though.

That said, it still doesn’t solve the issue with my server. If I remember correctly, the problem occurred even after the router had been running continuously for several weeks. So something else might still be going on. Interestingly, since I enabled the script, I haven’t experienced a single issue in over two months.

I’ve also noticed that different Linux distros handle multiple preferred addresses differently. For example, some Debian-based systems seem to work fine, they just pick the most recently added address. But others, like openSUSE, don’t seem to handle it well and simply stop working, which might be contributing to the problem.

For now, I’m going to disable the script and start logging every prefix change, just to be sure of what’s actually happening. I’ll post an update if the problem reappears in the near future.

4

In addition to that, RouterOS continues to include old prefix with preferred lifetime of 0 for some time after the change. Thus hosts that were not online at the time when renumbering happened are still notified. Quite possible this is an RFC requirement.