Have done at around 13:10 today . I'm not sure why it was missed on our testing, so I'll review that as well.
It was an over zealous ACL which was only meant to be blocking customers from sending RA's to our Gateways. The gateways don't respond to the RAs but it does spam the log files a lot. Will see if we can find out which CPE are doing that. Though they do seem to be making it difficult by sourcing the RAs from fe80::1 with src mac of 00:00:00:00:00:00.
The ACL has now been amended to allow the multicast sourced DHCPv6 messages through, so everything should be back to normal following a PPP session reset.
Thanks for the explanation and welcome to the forums. Please hang around, and, assuming that you are Zen staff, please e-mail team (at) thinkbroadband.com to enquire about getting an isp tag.
Whilst you are looking at the ACLs, can you amend the ACLs to allow ICMPv6 echo request / echo reply to the gateway link local addresses from CPE link local addresses (i.e. ICMPv6 types 128 and 129 from fe80::/10 to fe80::/10)? In my experience, such traffic is blocked and I don't think my firewall rules are to blame.
Without the ability to ping6 the gateway link local addresses, the gateway monitoring code in pfSense and possibly in other routers doesn't work without manual configuration of a non-gateway monitoring target.
As has been wished for before, some way of setting rDNS for IPv6 would be very useful. In my case, delegation to a customer run authoritative DNS server would be fine, though not everyone is in a position to run a DNS server.