Since the Internet is nearly out of IPv4 addresses, people are finally getting serious about using IPv6. As people start deploying IPv6 we will find new bugs and loopholes that crooks can exploit. Holes like this one that mean that a bot on a network could act as the "man in the middle" for everyone else nearby.
The good news is that, assuming the bot uses the existing IPv4 infrastructure to contact its controllers, an IP reputation service such as ours will block it just as it will block any IPv4 "call home".
But this is probably the limit for most current IP reputation services and is why there have been various claims that IPv6 kills IP reputation. Fortunately ThreatSTOP was designed to handle IPv6 so we are unaffected (indeed anyone who would like to be an IPv6 beta tester is welcome to contact us).
Let me illustrate two additional cases where ThreatSTOP's patent pending mechanisms function in a mixed world. In the case where the enterprise as whole has moved to IPv6 and it is its upstream provider that does the IPv4-IPv6 mapping ThreatSTOP can still work as we can serve up our IPv4 blocklists in IPv6 formats quite easily. So long as we are told of the IPv4-IPv6 mapping used we can simply provide an IPv6 DNS response with the appropriate maps (similar to the way that the MITM attack linked to above works).
Secondly, as more and more of the Internet runs IPv6, we will start to see native IPv6 malware hosts. The reason why people say that IPv6 kills IP reputation is twofold, first, that endpoints are 128 bits long, and that is an unmanageable number to blacklist individually, and second that users get assigned address spaces that are larger than the entire current Internet. If you use IP reputation the way it's done by DNSbls and others, this does, indeed, mean that the method is unlikely to work, because the number of potential /128 addresses an attacker can use is sufficiently large that they will always be able to find one that isn't listed. However, due to the way V6 addresses are assigned, a single end-user is unlikely to have a full /128 address. More likely they will have a /64 (or perhaps a /56). Any of the unmasked addresses can change without effect on the IP route, and so, all you need to filter on is the network, instead of the host, address. The problem for current IP reputation services is that they have no concept of netmask in their query or response mechanism.
If an IP reputation service just did a straightforward change from IPv4 (A record) address to IPv6 (AAAA record) then they won't provide useful blocking information. However ThreatSTOP is able to transmit both the address and mask - it is the same way that we do geo-blocking (blocking say the PRC or Ukraine) - so our subscribers are able to block all IPv6 addresses assigned to a particular host with a single record.
ThreatSTOP is looking forward to IPv6 - we see it as an opportunity, not a challenge - and we built our service to be ready for it from day 1.