It's listening on both IPv4 and IPv6 on port 135, and has a manual IPv6 address of 2::1.
The scanning machine is a VMware Fusion machine running Kali Linux. It has a manually configured IPv6 address of 2::2. Network is in Bridged mode.
A complete run of the firewall6 tool shows the same pattern of replies that I saw with Mac OS X 10.7.5.
Atomic headers create potential security problems, as explained in this Internet-draft
Here's a TCP SYN sent over IPv6 with an atomic header, generated by firewall6 test 9:
The first header has a "Next Header" field of 44, indicating that the next header is a Fragmentation Header.
The next header indicates that the Offset is zero, and "More Fragment" field set to 0, indicating that this is the last fragment.
This header should therefore have no effect.
Mac OS X replies with a SYN/ACK, which is the correct behavior.
The fragmentation headers all have Offset=0 and "More Fragment"=0, so they should have no effect. The Fragment ID changes in each header which is a little strange, but shouldn't matter.
Mac OS X replies with a SYN/ACK, as it should.
There are a lot of identical fragmentation headers, easily seen in the hexadecimal view at the bottom as a group of 8 bytes with an ASCII "R" near the end.
At the end of this long packet sits the TCP segment:
Mac OS X does not reply to this packet, which is a failure to currectly process and ignore the atomic fragments.