Thank you for looking into your router's RAs as well.
In the meantime, I was also able to trigger Pi-hole's dnsmasq to advertise a deprecated prefix by forcing my router to switch its GUA prefix.
My observation differs from yours, as I had the chance to observe the complete evolution of RAs during the prefix replacement process.
Router-RA **before** prefix change, GUA prefix ends in`:f900`
#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::464e:6dff:fe24:68ac
# received by interface eth0
#
interface eth0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag on;
AdvOtherConfigFlag on;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 255;
AdvDefaultLifetime 0;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvLinkMTU 1492;
AdvSourceLLAddress on;
prefix 2a02:1c24:7d39:f900::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 3600;
AdvOnLink on;
AdvAutonomous off;
AdvRouterAddr off;
}; # End of prefix definition
prefix fd08:bce3:1a6a:9c08::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 3600;
AdvOnLink on;
AdvAutonomous off;
AdvRouterAddr off;
}; # End of prefix definition
route 2a02:1c24:7d39:f900::/56
{
AdvRoutePreference medium;
AdvRouteLifetime 1800;
}; # End of route definition
route fd08:bce3:1a6a:9c08::/64
{
AdvRoutePreference medium;
AdvRouteLifetime 1800;
}; # End of route definition
}; # End of interface definition
Router-RA upon requesting prefix change, with prefix lifetime set to zero
The prefix is getting deprecated as its AdvPreferredLifetime becomes 0, and the corresponding route has been withdrawn:
#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::464e:6dff:fe24:68ac
# received by interface eth0
#
interface eth0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag on;
AdvOtherConfigFlag on;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 255;
AdvDefaultLifetime 0;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvLinkMTU 1492;
AdvSourceLLAddress on;
prefix 2a02:1c24:7d39:f900::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 0;
AdvOnLink on;
AdvAutonomous off;
AdvRouterAddr off;
}; # End of prefix definition
prefix fd08:bce3:1a6a:9c08::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 3600;
AdvOnLink on;
AdvAutonomous off;
AdvRouterAddr off;
}; # End of prefix definition
route fd08:bce3:1a6a:9c08::/64
{
AdvRoutePreference medium;
AdvRouteLifetime 1800;
}; # End of route definition
}; # End of interface definition
Router-RA as the new prefix (`:f300`) becomes active, still including the deprecated one (`:f900`):
#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::464e:6dff:fe24:68ac
# received by interface eth0
#
interface eth0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag on;
AdvOtherConfigFlag on;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 255;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference high;
AdvLinkMTU 1492;
AdvSourceLLAddress on;
prefix 2a02:1c24:7917:f300::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 3600;
AdvOnLink on;
AdvAutonomous off;
AdvRouterAddr off;
}; # End of prefix definition
prefix 2a02:1c24:7d39:f900::/64
{
AdvValidLifetime 7199;
AdvPreferredLifetime 0;
AdvOnLink on;
AdvAutonomous off;
AdvRouterAddr off;
}; # End of prefix definition
prefix fd08:bce3:1a6a:9c08::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 3600;
AdvOnLink on;
AdvAutonomous off;
AdvRouterAddr off;
}; # End of prefix definition
route ::/0
{
AdvRoutePreference high;
AdvRouteLifetime 1800;
}; # End of route definition
route 2a02:1c24:7917:f300::/56
{
AdvRoutePreference high;
AdvRouteLifetime 1800;
}; # End of route definition
route fd08:bce3:1a6a:9c08::/64
{
AdvRoutePreference high;
AdvRouteLifetime 1800;
}; # End of route definition
}; # End of interface definition
Next regular router-RA doesn't contain deprecated prefix anymore
#
# radvd configuration generated by radvdump 2.17
# based on Router Advertisement from fe80::464e:6dff:fe24:68ac
# received by interface eth0
#
interface eth0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag on;
AdvOtherConfigFlag on;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 255;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference high;
AdvLinkMTU 1492;
AdvSourceLLAddress on;
prefix 2a02:1c24:7917:f300::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 3600;
AdvOnLink on;
AdvAutonomous off;
AdvRouterAddr off;
}; # End of prefix definition
prefix fd08:bce3:1a6a:9c08::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 3600;
AdvOnLink on;
AdvAutonomous off;
AdvRouterAddr off;
}; # End of prefix definition
route ::/0
{
AdvRoutePreference high;
AdvRouteLifetime 1800;
}; # End of route definition
route 2a02:1c24:7917:f300::/56
{
AdvRoutePreference high;
AdvRouteLifetime 1800;
}; # End of route definition
route fd08:bce3:1a6a:9c08::/64
{
AdvRoutePreference high;
AdvRouteLifetime 1800;
}; # End of route definition
}; # End of interface definition
It is worth noting that - just as Pi-hole's dnsmasq - my router advertises the deprecated prefix, but only for a single complete cycle until after the new GUA prefix becomes active.
But dnsmasq continues to announce the deprecated prefix, as that will still be attached to the network interface of its hosts until its valid_lifetime expires.
So while dnsmasq does correctly advertise the deprecated prefix, it would do so for a much longer time than the router.
There are two parameters that would make this misbehaviour more obvious in your configuration:
Your router's AdvDefaultLifetime 180 is comparably short (180 seconds, where mine advertises 1,800 or 30 minutes - Pi-hole's dnsmasq's is always 0, to indicate that it isn't a router), and the retired GUA prefix has a comparably long AdvValidLifetime of 604,800 (a week, where mine is 7,200 (2 hours) - a week seems overly long for a deprecated IPv6 address to persevere).
Together, this would force those RAs to be issued considerably more often over a considerably longer period of time. So where I would hardly notice them, I can see how they can become a real nuisance for you.
And as your prefix's AdvPreferredLifetime is at 86,400 (or a day), that would mean that 6 additional deprecated addresses would potentially pile up on every network interface of every IPv6-capable client over the course of a week, before the first deprecated address would finally wither away.
Note, however, that this multitude of addresses would happen by virtue of your router's own RAs, regardless of Pi-hole coming into the mix.
You could try to quieten RAs a bit by adjusting those parameters - provided your router would expose the corresponding configuration options (mine doesn't).
Alternatively, you could consider to disable Pi-hole's IPv6 support.
This would require your router to still offer SLAAC and DHCPv6 services for your network, and you should also double-check that your router advertises one of your Pi-hole's stable IPv6 addresses.
That would have been just as important before, but now your router's RA becomes the only source of RDNSS messages.
The multitude of addresses would stay, but it seems your router wouldn't continue to advertise deprecated prefixes.
On first impulse, I do think that the observed behaviour is unintended and also undesirable, and probably should be addressed by dnsmasq.
I do think so because during my tests, I have verified that a client that was powered on well after the prefix change and freshly joined the network would indeed pick up the deprecated prefix and use that for constructing a deprecated IPv6 address.
This seems unnecessary, as I have a hard time imagining how a peer would have learned to talk to a deprecated address that never has seen active duty before.
