This is sort of to be expected with the way the Comcast Netgear CM handles the not really static IPv6 but it is a problem. Two nights ago Comcast did maintenance in my area and the CM was reboot (as evident from the uptime). On reboot it seems to have lost all recollection that it has allocated an IA_PD of a /60 and started bouncing packets. I noticed it yesterday but got around to posting today. Fortunately for me, I'm still using my HE.net IPV6 tunnel as production and the Comcast IPv6 in the testing phase.
The only solution (and not a great one) seems to be to monitor connectivity with pings through the CM and poke dhcp6c (as in /usr/local/etc/rc.d/dhcp6c restart) if pings fail. Continuous pings is not a good solution. A few pings every 5 minutes is also not a great solution. The best solution would be if the CM could take a true static (as in IPv6 static route, which could asl be a /56) or at least if the CM remembered its IPv6 leases and put back the state installed for them after a reboot.
This could also be solved if the CM server sent a RECONFIGURE after reboot to anything it remembers having sent a lease to (but if it remembers and nothing has changed it would be better to just put the state back.
The problem seems to be that unlike IPv4, the CM does not know that its IPv6 allocation is static because it got it using DPCPv6 IA_PD from the CMTS and only the CMTS knows that it is static and not just a lucky rebind to the same prefix. Even so, the CM should attempt the IA_PD request and if it got back the same prefix, then honor prior IA_PD delegations it made, or if it got back a different prefix, then send a RECONFIGURE to each client.
Best of all would be for the IPv6 /56 to be configured on the CM and static routes supported and configured on the CM, eliminating the use of DHCPv6 for statics. Wishful thinking perhaps.