::/64 advertises deprecated prefixes

[bnutzer]

I'm a customer of the German Telekom. I receive dynamic prefixes for my internal network via dhcpv6, and distribute these prefixes with the ::/64 "special prefix" via radvd on my (Linux) gateway.

When my prefix changes (which happens monthly, as far as I can tell), the old local address on my internal interface is deprecated. However, the system will not drop the address completely (for quite some time, at least). As a result, radvd keeps advertising the respective prefix, although it is not routed any longer by my provider.

From my point of view, radvd should not auto-advertise deprecated prefixes, or there should be some option to change the respective behavior (some people seem to rely on that behavior)?

[reubenhwk]

Sounds reasonable. Too bad your prefix changes so often. Doesn’t your Telekom care that they’re breaking connections?

…

Sent from my iPhone

On May 11, 2018, at 2:00 PM, Bastian Friedrich ***@***.***> wrote: I'm a customer of the German Telekom. I receive dynamic prefixes for my internal network via dhcpv6, and distribute these prefixes with the ::/64 "special prefix" via radvd on my (Linux) gateway. When my prefix changes (which happens monthly, as far as I can tell), the old local address on my internal interface is deprecated. However, the system will not drop the address completely (for quite some time, at least). As a result, radvd keeps advertising the respective prefix, although it is not routed any longer by my provider. From my point of view, radvd should not auto-advertise deprecated prefixes, or there should be some option to change the respective behavior (some people seem to rely on that behavior)? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[robbat2]

@bnutzer Can you review issue #85 and see if this is a duplicate, or if not, what's different?

[stu-gott]

@robbat2 There's two distinct scenarios that radvd might need to account for.

• Address on the interface is deprecated (preferred lifetime set to 0)
• Address on the interface is removed

It's up to you whether you think of those two events as the same thing or not, but in either case the correct response for radvd would probably be to retire the prefix as soon as possible (7205-ish seconds?)

[bnutzer]

Sorry for my late reply. Something was wrong with my notifications.

It was only after my post that I realized why my prefixes change; in contrast to my original assertion, that does not happen monthly, but after forced reconnects every couple of months.

@reubenhwk German Telekom forces re-connects every 6 months (only) for consumer lines. I am reconnecting every 1st of January/May/November to be able to control the reconnect. Makes things better for me, but the original issue remains -- just less often.

@robbat2 My problem is that the address on the router's interface persists, but as a deprecated address -- just as @stu-gott explains.

@stu-gott iproute2 uses a netlink flag IFA_F_DEPRECATED to determine deprecated IPs, but I guess a 0 lifetime should be a good identifier as well.

[MarioVerbelen]

My provider switches more frequently
Also if I restart wide-dhcpv6-client I get a new prefix on my lan interface (/56)
For now I restart radvd if the prefix changes

I guess radvd should verify the interface at a regular interval depending on the advertising vs only at startup

[ruben-herold]

any news here? It would be great if radvd could handle prefix changes issued by dhcp prefix delegations smoothly ...

[ipilcher]

I'm facing the same issue, albeit I'm not using the ::/64 "magic prefix." My setup is a bit more complicated, so I actually have a separate daemon on my "router" that polls my "firewall" for the delegated prefix and generates a new radvd.conf file when it changes.

Getting client devices to start using their new addresses in a timely manner seems to be the final challenge, and I've just discovered the DeprecatePrefix option, which does seem to cause (at least Linux) devices to deprecate the old prefix when they receive an RA with a preferred lifetime set to zero. Those wrestling with this issue may wish to try out this option.

Unfortunately, reloading radvd (by sending it a SIGHUP) doesn't seem to trigger this behavior; it looks like it will be necessary to actually stop and start it to trigger the "stop adverts."

[pyk1998]

Having the same issue when ISP reconnect and assign new prefix...however the client in LAN still uses address with old prefix which lose IPv6 connection until reconnect to the network.

[romanrm]

Unfortunately, reloading radvd (by sending it a SIGHUP) doesn't seem to trigger this behavior; it looks like it will be necessary to actually stop and start it to trigger the "stop adverts."

Just hit this with my multiwan config too. It's really inconvenient that reload is not equal to restart for DeprecatePrefix.

[Neustradamus]

Any news?

[corvus1]

DeprecatePrefix in radvd 2.19 somehow just stops my entire v6 setup from working altogether. Maybe some automation for us dealing to dynamic prefixes? Like, just watching netlink and monitoring ip address changes, and hopefully deprecating the old prefix and start advertising the new one. And hopefully without needing to restart radvd.

[robbat2]

@corvus1 can you provide some detail about how it stopped your entire setup working?

[corvus1]

I'm really not sure what to look for. I added DeprecatePrefix on and then restarted ppp0 to provoke IP change. Everything looked normal on the surface, it's just no ipv6 traffic was going anywhere.

To get a better idea, I'd have to start tcpdump-ing things before and after and comparing them.

[robbat2]

Please do investigate it. Most likely it is something like clients were still using the old prefix for their source address, but that wasn't routable anymore.

[ihipop]

any updates?

[Neustradamus]

Dear all,

All people are welcome to comment the current situation, we are in December 2024, a perfect patch is needed.

It is needed to solves 2 issues before 2.20:

• deprecate prefix on prefix removal from interface #85 @ihipop, @mhanor, @stu-gott
• ::/64 advertises deprecated prefixes #91 @romanrm, @ihipop, @bnutzer, @MarioVerbelen, @ruben-herold, @corvus1, @ipilcher, @stu-gott, @pyk1998

Issues/PRs:

• https://github.com/radvd-project/radvd/issues
• https://github.com/radvd-project/radvd/pulls

All help is welcome...

@agowa, @AdSchellevis, @fichtner, @marjohn56, @bmeirellesRJ, @mhanor, @stu-gott, @wcbonner, @the-j0k3r, @WenChao1Hou, @BrainSlayer, @Mile-Lile, @bnutzer, @stu-gott, @MarioVerbelen, @ruben-herold, @ipilcher, @pyk1998, @romanrm, @corvus1, @ihipop

If you know some IPv6 specialists, please come here, there are several tickets, thanks in advance.

[pyk1998]

After a long time, it still seems hard to solve....I used to find a workaround for this problem, using a script here:

https://community.ui.com/questions/Solution-for-client-losing-IPv6-connectivity-after-PPPoE-re-assign-the-new-prefix/4d6c5132-5f54-492c-a47a-b576182157fe

The ER-X platform uses radvd, and people there also try to solve the same problem.

I hope it may be inspiring for the enhancement of radvd...

[fichtner]

My two cents: for consistency reasons OPNsense no longer uses the "::/64" notation. opnsense/core@165327ba72d2

[pyk1998]

Inspired by #233 , I think the flash-renumbering event is what we have discussed here.

And following the suggestion in https://datatracker.ietf.org/doc/draft-ietf-6man-slaac-renum/, which refers to RFC9096 Section 3.5 (https://datatracker.ietf.org/doc/rfc9096/), maybe record the previous "dynamically learned prefix", and notify all the downstream clients with no less least the "Valid Lifetime" should work for fine. However, currently, radvd only announces the deprecated prefix upon shutdown, which is insufficient and needs more script assistance when using it. Hope we can add this feature inside of radvd to solve this issue entirely.

[ihipop]

currently, radvd only announces the deprecated prefix upon shutdown, which is insufficient and needs more script assistance when using it. Hope we can add this feature inside of radvd to solve this issue entirely.

YES, currently, I have to write a script to check if there are any deprecated address that have been assigned, if it is, delete it and restart radvd to let radvd announces the deprecated prefix as invalid upon shutdown

[pyk1998]

currently, radvd only announces the deprecated prefix upon shutdown, which is insufficient and needs more script assistance when using it. Hope we can add this feature inside of radvd to solve this issue entirely.

YES, currently, I have to write a script to check if there are any deprecated address that have been assigned, if it is, delete it and restart radvd to let radvd announces the deprecated prefix as invalid upon shutdown

This MAY work sometimes, but when in a wireless environment, the downstream clients (cell phones) may go into power-saving mode and sometimes ignore the RA messages containing deprecated addresses. Therefore, it is not stable just to announce the deprecated addresses ONLY ONCE.

Another Router Advertisement Daemon used in OpenWRT is odhcpd, I also go check their implementation, and it seems that they have taken care of this scenario in https://github.com/openwrt/odhcpd/blob/a29882318a4ccb3ae26f7cc0145e06ad4ead224b/src/netlink.c#L215

BTW, I think this is a really common and important scenario to be taken care of for IPv6 wildly used. I have found another RFC 7084 (which has already become a standard), stating that

L-13: If the delegated prefix changes, i.e., the current prefix is
replaced with a new prefix without any overlapping time
period, then the IPv6 CE router MUST immediately advertise the
old prefix with a Preferred Lifetime of zero and a Valid
Lifetime of either a) zero or b) the lower of the current
Valid Lifetime and two hours (which must be decremented in
real time) in a Router Advertisement message as described in
Section 5.5.3, (e) of [RFC4862].

[pyk1998]

After further digging into the code of odhcpd, I found that the support for announcing deprecated prefix is also a newly added feature in the commit in 2022, relevant code can be found here (openwrt/odhcpd@83e14f4), maybe radvd can mimic the same methods?

(Offtopic about more background info: Mikrotik has solved this problem in 2023-05-02, v7.9:

*) ipv6 - send out RA packet with "preferred-lifetime" set to "0" when IPv6 address is deactivated;

and

2023-11-09 v7.12

*) ipv6 - send RA and RA deprecate messages out three times instead of just once;

It seems that it is not too late to be fixed...
)