Ok, wenn das Gateway sich ändert, macht das natürlich Sinn.
Ich stelle einmal die Behauptung in den Raum, dass es auch dann Sinn macht, wenn die valid_lft (nicht zu verwechseln mit der preferred_lft) einer Adresse zu kurz oder zu lang bemessen ist.
Angenommen mein WAN fällt (kurz) aus und der Prefix hängt am WAN:
Im Fall der statischen Konfiguration sehe ich dann im NDP ein neighbor FAILED für den Gateway. Bis sich das erfängt, kann es etwas dauern. Der zugewiesene Prefix ist dann zwar lokal noch verfügbar, solange das interface aktiv ist, was bei einer LAN-Schnittstelle kein Problem darstellt, aber bei non-persistent ppp (pppoe, pptp, ...) schon.
Lasse ich hingegen RA zu, hänge ich zwar weiter von einer erfolgreichen neighbor solicitation ab, bekomme die (Default-)Routen aber angekündigt, die funktionieren, und zwar dann, wenn NDP erfolgreich war. Habe ich nun den Prefix als Alias eingerichtet und nicht an die Schnittstelle gebunden, ist er stets verfügbar, was bei pfsense/OPNsense mit den Watch-Interfaces sonst auch deren Ausfall bewirkt.
Zugegeben, die Auswirkungen sind eher minimal, aber das Design gefällt mir schlicht auch besser als die Statik.
BTW: OPNsense und pfSense implementieren für dieselbe Funktion CARP.
