IPv6 multiplies this problem. We have seen that spammers already possess the ability to hop around IP addresses quickly. They do this because once an IP gets blocked, it is no longer useful to them. There are only so many places they can hide, though — 4.2 billion places they can hide. However, in IPv6, if they are able to do the same pattern of sending out mail and hopping around IP addresses the same way they do in IPv4, then there is virtually unlimited space they can hide in. To put it one way, I've seen estimates that there are 250 billion spam messages sent out per day. Under IPv6, spammers could send out 1 piece of spam per IPv6 address, discard it and then move on to the next IPv6 address for the next 1000 years and never come close to needing to re-use a previous IPv6 address. A mail server could never load a file big enough even for one day's IPv6 blocklist if spammers sent every single spam from a unique IPv6 address. Because spammers could hop around so much, IP blocklists could conceivably encounter the following problems:
This is why no mail receivers are thrilled about the idea of using IPv6 to send mail. It means that they have to allow for the worst case scenario, and that worst case scenario is that spammers will overwhelm their mail servers and drain processing power having to deal with a 10x increase in traffic.
So how do we deal with it?
One idea, as referenced by the writers above, is to use whitelists instead of blocklists. Block all mail from everyone and then maintain a central whitelist of good mail servers that send legitimate mail. The weakness here is that it defeats the whole purpose of email. The purpose of email is that you can hear from new people you haven't heard from before. New mail servers are brought up all of the time. There's no way for you to know about it and the process of having to opt people in is a pain and hassle. This idea could be centralized, but the legitimate mail servers for one set of folks is not going to be legitimate for another set of folks.
Another idea is to take an unmanageable problem and break it down into a manageable one. I haven't really fleshed this out through any working groups, but let's go back and take a look at how CIDR notation works and how blocklists take advantage of them. Consider the IP 220.127.116.11. This can be broken down into four 8-bit octets, and then combined to make one 32-bit number:
A CIDR range is something that is a bit-wise operator. The CIDR range is the number of bits that is common to the range and contains every IP within that range which contains the first xx number of bits (wow, that didn't sound very clear). Let me use an example. Let's take the range 18.104.22.168/24. If we convert this down to the bits that it represents, then this range of IPs is any IP that contains the first 24 bits since the /24 says to take the first 24 bits:
22.214.171.124 is said to fall within the range 126.96.36.199/24 because the first 24 bits of the 32-bit representation of 188.8.131.52 is the same as the first 24 bits of 184.108.40.206/24:
The first 24 bits match, the last 8 do not (illustrated by the 1 in green) but it doesn't matter because we only need to match the first 24 bits. The red and blue parts match up and therefore 220.127.116.11 falls within the range of 18.104.22.168/24. However, if we take a slightly different IP address, 22.214.171.124, that will have a different 32-bit mapping. It will not fall into the /24 range because the last bit does not match:
You can see that specifying things in CIDR notation is a very quick and easy way to list IPs on a blocklist. It makes sense to us humans reading it because we can interpret the numbers "naturally", and it works from a technical perspective because it translates into bit-mapping. This is how PBL and some other lists are able to manage so many IPs. The IP range 126.96.36.199/16 lists any IP that matches 65.55.xx.xx; this is 65,536 IP addresses. They all fall into a logical range.
The number of IPs that falls within a CIDR range is evaluated as 2^(32-n) where n is the CIDR range (the number after the slash). So, a /24 (pronounced slash 24) is 2^(32-24) = 2^8 = 256 IPs, a /12 is 4096 IPs, and so forth. The larger the CIDR range number n, the smaller the range of IPs it covers. To newbies, this is counterintuitive and takes a bit of time to wrap your head around it but after a while you pick up the lingo. The smallest IP range is a /32 (1 IP) whereas the largest is a /1 (every single IP).