Banning IPv6 addresses

Any answer to your question will involve some amount of guessing. IPv6 deployments are still few enough that we simply don't know yet, what exactly the threat scenario will look like.

The large number of IPv6 addresses will introduce multiple changes to the threat scenario you will have to consider.

First of all with IPv4 it is entirely feasible for an attacker to scan the default port number for some vulnerable service across all 3700 million routable IPv4 addresses. Such untargeted attacks are not feasible with IPv6. Those attacks you still see will have to be more targeted. Whether this means we'll have to change much in our handling of the attacks remains to be seen.

The primary purpose of banning IPs based on log messages would be to reduce noise in the logs and to some extent to reduce system load. It shouldn't serve as protection against exploits. An attacker who knows a weakness would be inside before the banning kicked in, so to protect against that you have to patch vulnerabilities - just like you have always had to.

Banning individual IPv6 addresses might be sufficient to reduce noise in logs. But that is not a given. It is not unlikely that an attacker might use a new IP address from the range available to them for every connection. If attackers were to behave like that banning individual IPv6 addresses is not only going to be ineffective, but you may even inadvertently cause a DoS attack on yourself by using all your memory for firewall rules.

You can't know the length of the prefix available to each individual attacker. Blocking a too short prefix will cause a DoS attack by covering legitimate users as well. Blocking a too long prefix will be ineffective. Password brute force attempts in particular are likely to use a large number of client IPv6 addresses.

In order to be effective against attackers switching IPv6 address on each request and in order to keep memory usage down, you have to block ranges, and due to not knowing prefix lengths in advance, you have to adjust the prefix lengths dynamically.

It is possible to come up with heuristics already now. How well they'll work we don't know yet.

One heuristic would be for every prefix length to define a threshold of how many IPs it takes to block a prefix of that length. And blocking should only be applied at a specific length, if a longer prefix wouldn't be sufficient. In other words you need enough individually blocked IPs in each of the two halfs in order to actually initiate a block.

For example one might decide that in order to block a /48, there must be 100 blocked IPs in each of the two /49s making up the /48. The longer the prefix the smaller the number of IPs needed to block it would have to be, but in every case they would have to be spread across both halfs.

Banning per /128 does not scale when a subnet of /64 size is used for an attack. You will end up with 2^64 entries in the table, potentially causing a denial of service.

End-users will always receive a /56 per global address assignment policy. Businesses will always receive a /48 per global address

See: https://www.rfc-editor.org/rfc/rfc6177 /128 should never be assigned to a server/user, minimum assignment to another entity (server/vps customer) should be a /64. Minimum assignment to a site should be a /56. Giving out /128s is fundamentally broken and should be considered a configuration error.

I therefore recommend temporary banning per /64, given that a typical end-user will only have access to 2^8 /64s, it should not introduce too many entries in the banning table.

You should stick to banning single addresses.

It's not defined how many addresses will be given to end-users. Some ISPs may give a whole subnet and others only one address.