::/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?