3 ms·

Probably because with IPv6 privacy is built-in somewhat into the protocol, eg you can have a different IP really easy. For example, I can see my desktop right n

Probably because with IPv6 privacy is built-in somewhat into the protocol, eg you can have a different IP really easy. For example, I can see my desktop right now has 7 different addresses. Now, you could truncate this to eg a /64 or /56 range to identify users, but each ISP has different rules. Mine gives a /56, but I also hear many give only a /64 or less. As such, it basically means that you can’t really rely easily on IP addresses anymore for spam detection, rate limiting, etc. Note that I’m not an expert on spam filtering, but I do have quite some networking experience and QoS, and ran into these issues a lot.

londons_explore 4y ago
It's also the fact that having a datastructure that stores few bits per /24 range in RAM is very doable in IPv4. Banning a /24 doesn't have too much collateral damage. Whereas the same in IPv6 isn't feasible. There is no reasonable way to divide the IP space non-sparsely and keep in RAM and still ban without ending up banning a whole ISP.
- zekica 4y ago
  A simple HashMap works fine for blocking IPv6 /56.
- codebje 4y ago
  > Banning a /24 doesn't have too much collateral damage. Even at 128:1 CGNAT ratios a /24 has 32,768 potential users. By comparison, a /56 has 256 potential users on a /64 each.
X-Istence 4y ago
Filtering by /64 is good enough. With a /56 you have 2^8 (256) prefixes, if you spam enough for a /64 to be blocked, you have 255 more tries before all of those are blocked too. With some heuristics of "hey, we saw two /64's from the same /60" you can catch most ISP's that are offering prefix delegation to their customers, and that's only 16 /60's in that /56 before you are fully blocked... It's not that much harder or difficult.
10000truths 4y ago
But this same issue occurs with CGNAT IPv4, whose private address delegation is even more opaque than IPv6's prefix delegation. And CGNAT will become more prevalent going forward as address exhaustion becomes a bigger issue. There's no circumventing the fundamental problem that there is no 1-1 correspondence between IP addresses and "real" users.
- codebje 4y ago
  Collateral damage is accepted for CGNAT, which is widespread already, and will be equally well accepted for v6 /56s (or /60s).

londons_explore 4y ago

It's also the fact that having a datastructure that stores few bits per /24 range in RAM is very doable in IPv4. Banning a /24 doesn't have too much collateral damage. Whereas the same in IPv6 isn't feasible. There is no reasonable way to divide the IP space non-sparsely and keep in RAM and still ban without ending up banning a whole ISP.

zekica 4y ago
A simple HashMap works fine for blocking IPv6 /56.
codebje 4y ago
> Banning a /24 doesn't have too much collateral damage. Even at 128:1 CGNAT ratios a /24 has 32,768 potential users. By comparison, a /56 has 256 potential users on a /64 each.

X-Istence 4y ago

Filtering by /64 is good enough. With a /56 you have 2^8 (256) prefixes, if you spam enough for a /64 to be blocked, you have 255 more tries before all of those are blocked too. With some heuristics of "hey, we saw two /64's from the same /60" you can catch most ISP's that are offering prefix delegation to their customers, and that's only 16 /60's in that /56 before you are fully blocked... It's not that much harder or difficult.

10000truths 4y ago

But this same issue occurs with CGNAT IPv4, whose private address delegation is even more opaque than IPv6's prefix delegation. And CGNAT will become more prevalent going forward as address exhaustion becomes a bigger issue. There's no circumventing the fundamental problem that there is no 1-1 correspondence between IP addresses and "real" users.

codebje 4y ago
Collateral damage is accepted for CGNAT, which is widespread already, and will be equally well accepted for v6 /56s (or /60s).