I tried all sorts of things to make it work. ipconfig /renew6, netsh int ipv6 set routerdiscovery=disable then enable. It'd never get a new IPv6 address. Only thing that makes it work is disabling and enabling the interface.
It sounds like your wireless NIC loses the contents of its multicast filter when going to sleep and the driver doesn't restore the filter's contents upon resume, causing it to stop passing multicast packets up to Windows. Since ICMPv6 router advertisements are multicast, the card drops those packets on the floor, and Windows never sees them. Bouncing the interface makes the driver reinitialize the card like it would on power-up (or upon resume from hibernation), so the multicast filter gets programmed correctly.
A way to test my theory would be to install a packet sniffer that allows you to sniff packets without switching the interface into promiscuous mode. If you resume the laptop and IPv6 is broken, fire up the packet sniffer, make it listen for ICMPv6 packets on the wireless interface
without switching the interface into promiscuous mode, and see if the sniffer can see the router advertisements. If you don't see RAs, then the card is dropping those packets before the OS ever sees them.
Alternatively, use the packet sniffer and let it set your wireless interface to promiscuous mode. If IPv6 magically starts working while the sniffer is capturing packets (and stops working shortly after you stop the sniffer and the card gets taken back out of promiscuous mode), then it's probably the same problem.
I don't use Windows enough to know what packet sniffers would work for this. Wireshark would probably work. It looks like there's a Windows port of tcpdump (WinDump), as well -- something like
tcpdump -i wlan0 -s0 -n -p -v icmp6 is what I'd use on Unix.
If it looks like the card is dropping multicast frames after a resume, then it's not Windows's fault, it's the wireless card's driver's fault. Try updating to a newer driver or complaining to whoever wrote the driver.