As noted I have just deployed IPv6 on a personal network. That was so I could reach a production server I've also just deployed with IPv6.

With this very small deployment, I have been assigned 2 /64 IPv6 subnets by two ISPs.

For those unfamiliar with IPv6, that is a lot of addresses. If I've done the math right, two /64 subnets is 3.69e+19 addresses. Nearly 37 septillion addresses. Specifically: 36,893,488,148,419,103,232 unique IP addresses.

So I'm musing on IP blocklists of all kinds, since there are an (effectively) limitless number of IP addresses. Even non-abusers will change addresses from nearly limitless pools, as NICs with autoconfiguration privacy extensions change the outbound address frequently.

For IPv4, we have many IP-based reputation lists: blocklists of prior abusers. Blacklists of known abusers. Greylists of possible abusers. And whitelists of assumed non-abusers.

IPv6 presents significant new challenges for mail systems compared to IPv4. Most importantly, the vast size of the IPv6 space means that approaches that work in IPv4 do not necessarily scale to IPv6. For example, a sender could easily do "spread spectrum" spamming, using a different IP address for every message. Thus a major issue with current DNS based blocklist querying is the memory cache size of DNS resolvers in comparison to the vast numbers of IP addresses spammers will be able to use in IPv6. Although we think we understand the likely issues, neither we nor anyone really knows how both legitimate mail and spam will use IPv6.

Are you managing IPv6 networks today? If so, how are you managing abuse? Blocking entire /64 prefixes? Blocking individual addresses? And if the latter, are you seeing repeat offenders from the same /64?

I'm not doing anything different for IPv6 -- yet. But it's a new server, and I haven't seen any IPv6 abuse in my logs ... so far. Other than my own connection tests, I'm only seeing Google connections to the server using IPv6.

Last edited by jggimi; 18th January 2017 at 02:10 PM.
Reason: typo, some clarity

...To put it one way, there are 250 billion spam messages sent 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 10,000 years and never need to re-use a previous IPv6 address....

The TL;DR of the series is that only whitelisting will be effective, rather than blocklist/blacklists.

Zink foresees manual greylisting (website form-filling with captcha) to consider new whitelist memberships, which I believe would be unworkable at any sort of scale, and is only possible if those seeking whitelisting use static addresses. If autoconfiguration privacy extensions are deployed, even whitelisting is a non-starter unless one whitelists the 64/ subnet.

Giorgio Maone (NoScript): Blacklisting has always been the weakest form of protection in security, on principle. A much larger address space just makes this more evident. But, it's hardly news. For example, Mark Ranum, father of the firewall explains in this old editorial.
I believe statistics method to recognize spam, e.g. Bayesian filters, are the only really scalable solution, for now at least.
[..]
Cameron Schmauch (EdgeWave): In my opinion blacklists and whitelists have been obsolete for several years. This is not so much because it's hard playing whack-a-mole with the spammers, but rather that the lists usually aren't maintained in such a way as to aggressively prevent False Positives (FP).
EdgeWave (Powered by Red Condor) hasn't relied on third-party blacklists for anything other than supplemental information. We do employ methods for sussing out IP blocks that are operated by spammers. Blocking on IP can be very effective and efficient, but it should not be the mainstay technology if keeping FPs to a minimum is your top priority.

Bayesian filters for emails and captchas (or other problems to prove client is a human and not a bot) for www.

__________________
Signature: Furthermore, I consider that systemd must be destroyed.
Based on Latin oratorical phrase

Bayesian filters apply to content-related abuse, such as spam traffic. But they don't apply to other types of abuse, such as SSH authentication attacks, or DDOS.

I noted that two of those polled by the author (Ullrich, Klein) recommend blocking /64s as the equivalent of blocking a single address. Though Johaness Ullrich admitted, "This may lead to some collateral damage but it is probably the only way to make blacklists effective."

I *am* using that server as an MTA, so it is already using both blocklists and Bayesian filtration.