Windows handles all these exotic packets correctly, but the Mac does not. This is an expected result--Microsoft has been very diligent about supporting IPv6 for many years, but Apple has been late to it and providing only limited and incomplete IPv6 support.
The trend continues. Apple is several years behind Microsoft in IPv6 support.
The Windows target is a virtual machine running the leaked copy of Windows 8 Blue:
It's listening on port 135, with a manually assigned IPv6 address of 2::3.
It's on a "Private" virtual network with the firewall at its default state (On, allowing exceptions).
The Mac target is a MacBook Air running OS X 10.8.2.
It's listening on both IPv4 and IPv6 on port 135, and has a manual IPv6 address of 2::1.
As far as I can tell, this is a perfect score.
Tests 1 and 2 send normal IPv6 TCP SYN packets, and Windows correctly replies with SYN/ACK.
Test 3 sends a packet which claims to be IPv4 at layer 2, but is actually IPv6 at layer 3. Windows doesn't reply to this packet, which is reasonable.
Tests 4 through 22 add superfluous headers to the packet--"Hop-By-Hop" headers, Atomic Fragmentation Headers, and Destination Headers. All these are correctly ignored by Windows, and it replies to the TCP SYN packet correctly with a SYN/ACK.
Tests 23 through 28 send incomplete groups of fragments, which cannot be reassembled properly. Windows correctly refuses to reply to them with a SYN/ACK.
I'm not sure what is the best response to packets 29 through 31. They confused me. I thought they were invalid, but I couldn't be sure. Windows seems to have interpreted packet 29 as valid, which may be correct.
All the Test 32 packets are valid and Windows correctly replies with SYN/ACK.
The Mac fails to reply to test packets 8 and packets 14 through 22. It can correctly process 2 or 3 superfluous IPv6 packet headers, but large numbers of extra headers cause the Mac to ignore a valid TCP SYN.
The Mac also ignores test packet 29, which Windows replies to, but I'm not sure which OS is right in that case.