Last month the migration towards IPv6 got some attention (again) when the last remaining blocks of IPv4 addresses were allocated, and we were "officially" out of IPv4 addresses. If you only read the headlines, this problem might seem more problematic than it really is, while it's true that the last addresses were allocated they have been given out to secondary organizations that handles the distribution to companies and service providers and with the upcoming after market those who want to pay hard cash will still be able to get IPv4 addresses. The questions is; isn't this a wake up call to start the migration to IPv6 and solve the problem once and for all.
Implementation
This is not the first nor the last call for IPv6 migration, and many of you will probably continue to ignore the problem "like everyone else", but those with a little bit of foresight should start looking into running their infrastructure under dual stacks supporting both IPv4 and IPv6. It's probably easier than you think to get started, the biggest hurdle to overcome is probably your ISP which may or may not be able to deliver IPv6.
On your end, more system services than you think have had support for IPv6 for the last decade. Running mail or web over IPv6 is nothing new or risky. In that sense mail is probably the most error resistant protocol and a great one to start with in your migration.
Halon SPG/VSP supports dual stack, you may run both IPv4 and IPv6 on the same unit, with the same rules and configuration and all you have to do is configure your IPv6 address and gateway and it will try (if possible) to deliver by IPv6 at first and if it can't it won't even cost you a retry count.
While we recommend that you start by running your public services on dual stacks such as mail and web, others have raised the concern about IPv6 spam and how block lists doesn't work with the IPv6 infrastructure. While this is partly true, that's their excuse for not taking IPv6 seriously for the last years and preparing their systems to work with our without black lists (I explain more below). But this is the future we're heading to, no turning back.
Problem description
DNS black lists blocks single IPv4 addresses and in some cases larger subnets of eg. dynamic addresses (/24) with bad reputation and history of sending spam. This technique have proven itself to work great and with the "limited" amount of addresses available for spammers, so everyone running black lists has had a concept of success.
IPv4 address: 213.132.98.98 DNS query: 98.98.132.213.bl.example-blacklist.org
If there is an A record response (normally in the 127.0.0.0/24 subnet) the address should be considered blacklisted.
At a first glance you say think this concept can be copied straight off to IPv6 addresses, That is partly true, and the RFC5872 stands at using the same technique but splitting per nibble.
IPv6 address: 2a01:2b0:1001::2
DNS query: 2.0.0.0.0.0.0.0.0.0.0.0.0.
0.0.0.0.0.0.0.1.0.0.1.0.b.
2.0.1.0.a.2.bl.example-blacklist.org
But after the RFC was published some serious concerns has been raised about the possibility for spammers to use unique addresses for each spam message sent and the stress this would cause on block lists and the DNS infrastructure in general. This will be a possibility since most people will be assigned 2^64 addresses (../64 and that is a lot) to use at home which is more addresses than any DNSBL can hold. And hard-coding to /64 isn't portable for the future, so means of dynamically specifying address granularity for the blacklist (eg. /64) with txt records or wildcards has been suggested but no updated RFC has been released. We will of course follow this closely.
Part of the solution
In the upcoming version of Halon VSP/SPG (2.2.6) our ippolicy service got IPv6 support and will from now on simple query all configured DNSBL for IPv4 or IPv6 and hope for the best. As of today you will probably not find any blocked IPv6 addresses. But we believe this is a matter of chicken and egg. If no one queries these DNSBLs for IPv6, there is no motivation for them to start supporting and collecting spamming IPv6 addresses.
Luckily DNSBL are not the only line of defense, pattern based reputation (RPD) and pattern analysis (SA) works very well with IPv6, but DNSBL sure helps if you receive more traffic than you would otherwise be able to handle.
The conclusion of this, larger mail system and hosting providers running over capacity without DNSBL may want to hold back and wait, while others should try to stay ahead as early adopters.
And who knows, you may learn something :)
- erik's blog
- Login or register to post comments
