It could be that they're not actually IPv6 sockets, but normal IPv4 connections to a process that's listening on a socket that understands both inet and inet6. From what I can remember, both apache and openssh behave like this. The give-away is the way the address is formatted:

::ffff:192.168.5.87:22

which is an IPv4 address embedded in an IPv6 format. You can tell this not only because the prefix is ::ffff/96 (designated for embedding IPv4 addresses within the IPv6 address space) but also, if it was a true IPv6 connection, it would be displayed as ::ffff:c0a8:0557 (all hex, and no full-stops).

I'm not sure how the internals of this works in something like openssh that makes it show up like this in `netstat -antp` but I'm fairly certain that you'll find that your ip6tables policy isn't being ignored.

If you still find it, erm, untidy, you can probably fix this instance easily enough. If you look in /etc/ssh/sshd_config you'll probably find that you have either no active (uncommented) "ListenAddress" directives, or you have an active "ListenAddress" directive with an IPv6 address (such as "ListenAddress ::" which listens to all live IPv6 interfaces).

If you edit this file that your sshd is only listening on IPv4 interfaces (by including something like "ListenAddress 0.0.0.0"), then restart your sshd, you should notice that the output of `netstat -antp | grep ssh` now only lists an IPv4 address.

You can handle Apache similarly by playing around with the Listen directive in /etc/apache2/ports.conf (if you're using the debian way of splitting up your apache configuration). I'm sure other service daemons will have similar configuration directives, and it will only become more common as the adoption of IPv6 starts to spread further and wider.

Cheers.
:wq