My PC didn't have an IPv6 GUA?
These entries were in the pi-hole log
RTR-ADVERT(eth0) <IPv6 prefix> old prefix
Could this cause devices not to create a IPv6 GUA?
IPv6 addresses are created by the DHCP server, so most likely by your router.
No. Pi-hole is the DHCP server, but IPv6 is stateless, hence the router advertisement.
Lately I have seen a lot of talk about the issue 'Old IPv6 Dynamic Prefix sticking too long to Clients and not being replaced by the new one on time' on a couple of Router related forums, so this might be related to it somehow ?!
/EDIT :
Never mind... See below =>
No. The IPv6 prefix has a limited lifetime, but is not changed once that lifetime expires. The lifetime value is just reset.
Apparently dnsmasq doesn't realise this, even though the host machine does.
This message is logged when a change of an IPv6 prefix has been detected.
It indicates that pihole-FTL/dnsmasq (in accordance to RFC 6204 - Basic Requirements for IPv6 Customer Edge Routers) has set the old prefix's preferred lifetime to zero, while the prefix still stays valid for the remainder of its valid lifetime.
A host receiving that message would mark its respective IPv6 address as deprecated, i.e. it would cease to use that address to initiate communications, but would still receive packets destined to that address.
For newly initiated communication, it would use a new IPv6 prefix address created from the new prefix.
You'd only see such RTR-ADVERT messages if you had enabled both Pi-hole's DHCP server as well as its IPv6 support.
However, you typically don't need to tick Enable additional IPv6 support.
With IPv6, it's a router's job to advertise network configuration details for clients to use, including DNS server addresses.
About the only time that option would be helpful would be if your router's only IPv6 DNS option would be to switch RDNSS either on or off completely.
What would happen if the prefix didn't change, and only the lifetime is reset?
Enable additional IPv6 support is not enabled
Instead, I have the following in misc.dnsmasq_lines:
#DHCPv6
dhcp-range=::,constructor:eth0,ra-stateless,ra-names,64
#DNS Servers
dhcp-option=option:dns-server,<pi-hole IPv4 address>,<backup pi-hole IPv4 address>,1.1.1.2
dhcp-option=option6:dns-server,<pi-hole IPv6 address>,<backup pi-hole IPv6 address>,[2606:4700:4700::1112]
And, the router broadcasts only the IPv6 prefix (with the O flag), so that the pi-hole host machine knows what the prefix is.
From the pi-hole log:
dnsmasq-dhcp[501]: RTR-ADVERT(eth0) <IPv6 prefix 1>:: old prefix
dnsmasq-dhcp[501]: DHCPv6 stateless on <IPv6 prefix 1>, constructed for eth0, constructed for eth0
dnsmasq-dhcp[501]: DHCPv4-derived IPv6 names on <IPv6 prefix 1>, constructed for eth0, constructed for eth0
dnsmasq-dhcp[501]: router advertisement on <IPv6 prefix 1>::, constructed for eth0
dnsmasq-dhcp[501]: RTR-ADVERT(eth0) <IPv6 prefix 1>
dnsmasq-dhcp[501]: router advertisement on <IPv6 prefix 1>, old prefix for eth0
dnsmasq-dhcp[501]: RTR-ADVERT(eth0) <IPv6 prefix 1> old prefix
I assume RTR-ADVERT is from the pi-hole, and router advertisement is from my router (hostname: router), and the pi-hole is adding old prefix. Is that correct?
Those lines are the equivalent of what Enable additional IPv6 support what add, but extended by additional IPv6 DNS server addresses, including Cloudflare's DNS server.
This would allow clients to by-pass Pi-hole at their leisure.
What do you need those lines for anyhow?
Your router will broadcast router advertisements to all hosts, not just your Pi-hole machine.
That's correct.
It isn't adding it, it just advertises the information as received by the router, as instructed by your custom configuration.
My router restricts which devices can perform DNS requests.
For situations where the pi-hole is overwhelmed with requests, such that it can't answer any. Or, when it needs to be shut down. In that situation, I can temporarily allow other devices to perform DNS requests.
So the router is advertising that the prefix is old, even though it's unchanged and the lifetime has been reset?
The router regularly advertises prefix information.
An IPv6 host would check an advertised prefix against its list of IPv6 addresses, and if it matches one of its existent IPv6 address prefixes, it would just reset that address's preferred and valid lifetimes (see RFC 4862: IPv6 Stateless Address Autoconfiguration | RFC Editor, section 5.5.3.e) ).
It seems your IPv4 configuration would nicely cover that already?
Did you consider to drop configuring IPv6 on top of that?
AFAIK it's easier to keep SNAT/DNAT rules for DNS redirecting on IPv4 level and since IPv6 Clients can simply use IPv4 for DNS Resolving you don't need any IPv6 DNS Server address at all 
No redirecting. Non-approved devices have DNS queries blocked.
In the future IPv4 could be turned off, eliminating the need for dual-stack, though that future can't occur until all servers are accessible via IPv6. In that world, an IPv6 address for the DNS server will be required.
There are far too many compromises (and add-ons) required to use IPv4 (SECURITY, NAT, CGNAT, etcetera), though these are not visible to the end user.
I've resorted to rebooting my pi-hole server every second day to avoid dnsmasq warnings related to IPv6 prefixes.
Warnings:
no address range available for DHCPv6 request via eth0
RTR-ADVERT(eth0) <IPv6 prefix> old prefix
router advertisement on <IPv6 prefix>, old prefix for eth0
Somebody, on the pihole forums gave me a suggestion to use:
pihole reloaddns
Would this cause the pi-hole (or server) to update the IPv6 prefix, and thus avoid the warnings?