bin/60979: rtadvd(8) does not properly deal with prefix changes

["martin%NetBSD.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60979
>Category:       bin
>Synopsis:       rtadvd(8) does not properly deal with prefix changes
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Nov 07 08:00:00 +0000 2026
>Originator:     Martin Husemann
>Release:        NetBSD 11.99.9
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD big-apple.aprisoft.de 11.99.9 NetBSD 11.99.9 (POWERMAC_G5.MP) #167: Thu Oct 29 14:25:04 CET 2026 martin%seven-days-to-the-wolves.aprisoft.de@localhost:/work/src/sys/arch/macppc/compile/POWERMAC_G5.MP macppc
Architecture: powerpc
Machine: macppc
>Description:

I have a customer grade "dynamic" internet connection with dual stack
support. Every few weeks the delegated IPv6 prefix changes.

The IPv6 connection on the firewall itself adjusts properly (pppoe(4)),
the prefix is dealt with by dhcpcd(8) with a prefix delegation rule
configured to configure a /64 from the new prefix on interface equos0.

So far this all works.

I then have in rc.conf:
rtadvd=YES      rtadvd_flags=eqos0

and that publishes the delegated /64 to the internal network.

This all works fine initially, but whenever the prefix (and IPv6
address) on equos0 changes, rtadvd doesn't seem to fully adjust.
I would expect it to note the change immediately (via the routing
socket) and revoke the old delegations, and then start answering
with the new prefix.

However, it seems to still advertize the old prefix (I think
additionally, haven't reproduced this in a lab setup yet and traced the
actual RAs). Will do that, but filing this PR to remind me :-)

This causes all clients on the internal network to keep using adresses
from the old prefix and lose IPv6 connectivity untill manual
intervention.

	
>How-To-Repeat:
s/a

>Fix:
n/a