Is it time to stop taking restrictive actions based on the user's IPv4 address?

Question

In 2012, this question was asked requesting to stop banning by IP address. (This was the only question I could find directly related to this issue on Meta.) I'd like to revisit basically the same topic, but I'll phrase it a bit more generally: rather than just talking about banning based on IPv4 address, I'd like to talk about any action taken against a user to limit, control, or restrict their experience on Stack Exchange sites based on their IPv4 address.

It seems that a lot of Stack Exchange site functionality is based on the user's IP address. A few that I'm aware of:

• Automatic question/answer bans seem to involve the user's IP (although Stack Overflow hasn't publicly stated such, it does seem to be one ingredient in the parameters of these automatic bans.)
• Rate limiting the number of questions you can ask, as in this issue.

IPv4 address space is exhausted. We're only keeping the IPv4 ship afloat by using increasing levels of NAT.

If the goal is to control the behavior of one individual person by taking some action in the system based on an IP address, doing so could be unfair to users in any of the following scenarios:

• Since pretty much forever, residential customer premises equipment (CPE) edge routers/modems do NAT, so you end up restricting/rate limiting/banning an entire domicile worth of users based on the behavior of potentially one user.
• The number of people under any given IPv4 address is increasing rapidly as the value of each public IPv4 address increases due to their scarcity.
• Institutions and companies that used to have huge address spaces and would give each person their own IP, are now starting to sell off their address space to hosting companies like AWS and Google for huge amounts of cash. Once they no longer have a huge IP space, they implement NAT for all their users, putting hundreds or thousands of users under a single public IP. This is happening more and more every day.
• Carrier-grade NAT. The longer we stay on IPv4, the more this will become a necessity; ISPs that have been resisting deploying CGN due to its many disadvantages will soon have to cave in and implement it so they don't have to start telling customers "Sorry, you can't get on the IPv4 Internet right now because we can't give you an IP".
• Those who try to avoid the pitfalls of CGNs, local NATs, etc. by using a VPN are often using a shared IP with other VPN users, or at least a floating IP that has been used by others in recent history.

In short, for a great number of reasons all ultimately related to IPv4 exhaustion, the probability that any random Internet user will be uniquely identified by an IPv4 address is asymptotically approaching 0.

If that wasn't bad enough, for the same reasons as stated above, the average number of users represented by each IPv4 address is increasing substantially.

In addition, the severity of the issue depends on where you live. Some countries' ISPs have not done a great job of securing very many IPs for their country vs. the internal demand for Internet access, so they really do not have the address space whatsoever to even come close to giving each user their own IP. CGN, or even "Country-grade NAT" is sometimes a necessity in these places.

(This section was recently edited.) In developing nations, each year, many people are getting access to the Internet who didn't have it before. While millions more people get on the Internet each year, the number of IPv4 addresses we have isn't increasing.

As a good friend pointed out to me in chat, we can't continue to NAT our way to practically infinite IPv4 users, because there can only ever be on the order of (2^32 * 65000 / 2) = ~140 trillion bidirectional "sockets" (e.g. TCP sockets) in public IP space at any given time. This is because each TCP connection requires an inbound port on the requestor's (public) IP, so if you had a million users on a single IP, not all of them would be able to communicate bidirectionally at once (in fact, only a small fraction would, as that's 1 million / 65535 = only one in 15 users on average could have a single TCP connection.)

To conclude my exposition in favor of not blocking / rate limiting / etc. based on IPv4, I will say: once you consider all the above factors, acting to control/limit/ban a user based on their IPv4 address seems very unfair. We're restricting the ability of potentially millions of users from engaging on the site, and it's only going to get worse.

Now, here are a few points anticipating objections to this argument, and other notes:

• One might say that we need a way to replace the banning effectiveness of IPv4 with some other tool/filter/algorithm. I counter that the absence of another technique is orthogonal to the issue at hand, which is the wrongful restriction of a great many potential contributors to the site. The present issue might increase the need for an alternative, which is fine, but the lack of an alternative shouldn't by itself be a cause for inaction on this issue.
• I would argue that this will not have any meaningful negative impact on spam, because we have fantastic client-side tools like SmokeDetector and many dedicated users who put in a lot of effort to both automatically and manually scan, curate and flag content. We also have a lot of server-side tools that prevent spam questions from being asked in the first place. The automated tools, in particular, scale very well, both user-driven tools and those that run on the SE servers. The humans may not scale as well, but our automated tools are really great with the frankly staggering scale we're already operating at.
• You might say that users would then just be able to create a new account and get around automated question/answer bans. I would counter that spam prevention algorithms, cookie sniffing, question/answer content analysis, and other, novel techniques should be employed as countermeasures, and simply remove the IPv4 address from the equation. We might be increasing the number of "non-spam bad questions" on the site in the short term, but users can already clear their browser cookies and use a VPN to get around that if they're determined enough; some can even reset their modem/router to get a new floating IP from their ISP.
• That leads me to the other part of why we should do this: IPv4 addresses are really, really bad at actually blocking or restricting the person we intended to block or restrict, because it's still quite easy to get a different IP address in many cases, with almost no technical knowledge or expense. So not only do we get a huge number of false positives; IPv4 also has loads of false negatives.
• Stack Exchange doesn't currently support IPv6. When/if it ever does, for users who access Stack Exchange sites via IPv6, I think it's perfectly fine to act based on their IPv6 address (you'll probably have to ban at the /64 level based on the fact that most IPv6 individual allocations are at the /64 level right now.) This will be a useful way to block/ban individual computers or at least domiciles for a long time to come, as IPv6 almost certainly will not be putting hundreds or thousands of people behind a single IP or even a single /64. Once IPv4 goes away, IPv6 banning/restricting will be quite useful, except where users are able to get a new IPv6 allocation by resetting their CPE or using a VPN.
• If you're doubtful of SE supporting IPv6 within a reasonable number of years in the future, or doubtful of the deprecation and eventual removal of IPv4 support, this is all the more reason to expect that treating users in IPv4 space fairly will become a more important issue in the coming years. If, on the other hand, it were realistic to expect IPv4 decommissioning in the next year or two, changing our posture re: IPv4 bans might be a waste of time/effort. Please correct me if I'm wrong, but I don't think IPv4 is going anywhere within the next decade, maybe even two decades.

Answer 1

First, thank you for your well-researched, well-reasoned initiation for this discussion.

I agree that IPv4 is not particularly reliable as a way to identify a person; at best it's akin to guessing what's in a package by way of the postmark on the outside. For many postmarks there are potentially thousands of possible senders, and even if you were to guess the right one you can't really be sure what they sent without opening the package.

...Of course, if you make a habit of buying things online, you probably make guesses as to the contents of packages based on their origin all the time - it's a pretty good heuristic if you combine it with a few other pieces of information, such as the time at which it was sent. And that's usually how we should be treating IPv4 addresses: as a heuristic, not a unique identifier.

In fact, that's usually how we do treat IPv4 addresses. For instance, we don't generally do permanent IP bans; if a given source IP is sending us a large amount of expensive requests, we'll stop serving them for a few minutes and then resume honoring those requests. This handles a host of common problems (poorly-written scripts, poorly-written browsers, badly-configured proxies) that would otherwise hurt the performance of the site for everyone else, while doing so in a way that doesn't excessively penalize businesses, NATs, etc. (we can also increase the limit for networks that we know have many unique users behind a single address).

Similarly for spam, the blocks age away after a few days and only apply to certain actions on the site - as a result, plenty of people connect from spam-blocked IPs and networks daily without ever noticing.

For question/answer rate-limits, the situation is a bit less ideal: we did start building a system akin to the one used for spam a few years back, but never fully implemented it - as a result, it's still entirely possible to block your whole company from asking questions for 40 minutes or so simply by... Asking a question. Sadly, until we get the time and resources to overhaul this it's the lesser of two evils: things got kinda ugly when we inadvertently disabled it a while back.

It's worth remembering too that while it's trivial to work around a simple block, doing so imposes additional time and effort: this is critical for things like spam, where a 10x increase in the time needed to post a single message can make us a much less inviting target.

Going forward, I expect we'll increasingly rely on IPv4 as just one piece of the puzzle when trying to mitigate abuse; it's hardly a magic bullet, but ignoring it entirely gives up a great deal of contextual information that would be hard to obtain otherwise.