Hacker News new | past | comments | ask | show | jobs | submit login

I think what a lot of people like to miss is that a lot of detection and antispam stuff is not working well on ipv6. A server without any ipv4 is still limited in many more ways than not being able to reach github which probably means there is not a lot of pressure for github yet.



Any quick info on why anti-spam/bot detection is harder on IPv6?


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.


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.


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.


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


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.


A simple HashMap works fine for blocking IPv6 /56.


> 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.


Because IPv6 addresses are free and IPv4 is expensive. Same reason why Google won't let you sign up without SMS verification. If you're caught spamming or breaking TOS you've effectively burned that v4 address or phone number.

v6 is more difficult, by design. The lower half of the address is deliberately not subnettable and it is the explicit design intent that machines on a v6 network can just make up new addresses within a /64 as they please. So you have to burn subnets. Except there isn't really a standard for how subnets are issued: most ISPs hand out /48s, Comcast insists on /64s for residential use, etc. In the IPv4 world you could ban one IP at a time, and only move on to banning entire AS allocations if you needed to. On IPv6, banning a /64 is a lot less impactful, so you have to start with the most drastic and customer-hostile option.


Comcast hands out a /60 for prefix delegation if you ask for it (i.e. software asks for it, no customer service interaction required). In fact Comcast allows you to ask for as many /60's as you want (caveat, there may be a limit, but at one point I made a config mistake that led to asking for 32 /60's and I got all of them, so I am not aware of a limit).


My guess is that each user's IP suffix changes a lot more often




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: