Hacker News Reader

Comment by zerof1l | Hacker News Reader

This article highlights something interesting... it is quite common to get at least one /64 IPv6 block from a hosting provider or ISP. Yet most of the rate-limiting and IP blocking is done for a single IP. Sounds like when dealing with IPv6, an entire block of /64 should be rate-limited or blocked.

View on HN

Even companies which not only should know better, but are actually paid to handle things like this get it hilariously wrong.

The company I work for is a client of a big-ass CDN you've heard of (not the one whose ceo hangs around these parts). Yet, they somehow think it's fine to notify me of "new connections from an unusual IP" when I connect from the same /64 block of ipv6.

It's easier to reuse existing code and simply bump the number of digits required to store the IP address.

I'd be rather surprised if IPv6 hasn't done some damage to the idea of IP blocking on the whole. It's possible, even as a residential Internet user, to request a /56 or /48 automatically with DHCPv6 Prefix Delegation. I have a /56 with Comcast. That's potentially up to 65536 /64 blocks, just from a residential user, so if you're going to attempt IP filtering for IPv6, it's got to be a lot smarter than swapping out your single-IP blocking for /64 blocking.

It is already pretty common to start with IP blocking but upgrade to blocks when the bad behavior continues.

Assuming a /64 as a starting point is an easy win and bumping it up with repeat offenders seems pretty easy in the grand scheme of things.

Doesnt CGNAT make these methods obselete though? All my webscraping is proxied through my phone and I rarely get IP blocked and im very aggressive even on CF protected sites.

That's neat, could you explain how you achieved that?

I tried a year or so ago and had to round trip to my Android over mobile data so it was too high latency for what I needed. If there's a way to connect to a phone on the same LAN/WiFi but scrape using its mobile network I would be very interested.

You can pick up a pulled laptop modem like the T99W175 from China for a low price, drop it into a USB enclosure (you’ll be limited to USB 2.0 speeds), and hook it up to OpenWrt. Or grab a GL.iNet GL-X3000 - the Quectel RM520N is already on board and runs over PCIe, so it’s quicker.

Then you can have basically unlimited IPs.

Android messes with your traffic far more than a bare modem (there's unavoidable NAT for one), and it has tighter thermal limits, so higher latency is expected.

You can run an ssh server in termux and run whatever programs you want from there.

There's several options for storage, as well: - connect an external drive via USB (The /Android/media directory on both the internal and external SD card is generally accessible from both termux and other apps on the phone) - if you're rooted you can mount a network storage in termux (or system-wide, but then you have to figure out sandboxing) - if you're not rooted, mount in reverse (mount your phone storage over the network)

Yes, if you're interested its not too difficult, but I don't really want to put it here on HN (my business kinda relies on these methods, and I'm increasingly worried they will start working on this problem). If you email me at mynameisamodel@gmail.com I'll send you details.

It actually makes things a easier for both blocking and allocating (e.g. VPS hoster) side.

Once the "oh no, we can't afford that many unique allocations" excuse is away, algorithms that enforce quotas for every prefix size at the same time (with no excuses for CGNAT weirdness) stop being too ruthless.

You can distribute your addresses as needed, and I can track successful and failing attempts - at whatever distribution scheme you use. E.g. group your "unverified" or "trial" accounts at a larger prefix size, so they get each other blocked - but not your paying customers.

How are you getting a /56 from Comcast? I can only request up to a /60 from them, any larger and I get a /60 rather than whatever I requested.

Good question, I checked just now and I am indeed getting only a /60. At some point in the past they gave me a /56 but no longer. I didn't notice the change because I have fewer than 16 networks, and networkd handled delegating /64s to them automatically.

Shame, I was hoping I could get on the /56 train too lol. Thanks for checking!

Rate limiting on /64 for IPv6 is well known and I know Google does it for other services. Sounds like this was not properly updated when they put IPv6 into play.

I'm on a relatively large Indian ISP, and my home network gets an IPv6 network assigned, which is directly routable. Didn't think about it until tailscale told me it was connecting over a direct IPv6 connection and I wondered how that was possible. Sounds like 90s network rampage may be back here.

Well yes, natting is not normal on ipv6 - that’s a major feature.

Direct connections are a good thing and how the Internet is supposed to work. NAT is the only reason IPv4 has lasted this long.

Blocking inbound connections using connection tracking is orthogonal to NAT. It's just that NAT implies the former by default due to its nature.

The problem here is, that also larger networks (eg. student wifi at some university) uses a /64 for maybe even hundreds of students connected at the same time. Hold a lecture, tell the students to go to github to download some tool, and the first 10 will succeed, and the rest will get rate limited.

The same is true now with NAT (where they're all behind a single ip or a very small pool of IPs), but IPv6 should make these things better.

Even that isn’t sufficient, as it’s very easy to get ahold of /48 blocks. To do a good job of this, you need to actually break things down by ASN and look at their policies for handing out IP addresses to figure out what granularity to use.

Effectively a /64 is the new /32.

Your isp should really be giving you a /56 or /48.

I had assumed that most people would block by /64. Probably safest to count distinct abusive/noisy IPv6s per /64 and block/throttle when it hits a threshold.

Ratio of abuse traffic per IPv6 from a /64 might also make a good threshold.

Yes that does happen to be what is commonly done

[BuyVM](https://my.frantech.ca/cart.php?gid=37), a popular host for shady operators, gives a /48 even with their cheapest plans ($2/month, though only $7/month is in stock right now)

A bit more context: BuyVM is a legitimate business, popular with hobbyists, and has features that are hard to get elsewhere (e.g., BGP sessions). They do take a pro-free speech stance but they are a far cry from bulletproof hosting ("shady operators"). An imperfect comparison at a massively bigger scale would be Cloudflare's prominence in certain contexts.

they are pretty well-known as a "DMCA ignored" hosting site. Search "dmca ignored buyvm lowendtalk" and you'll find lots of forum threads of people recommending buyvm for hosting pirated content. They were also once mentioned by the RIAA for ignoring copyright law https://www.musicbusinessworldwide.com/files/2025/01/USTR-20... There's also at least one mention I can find of them hosting a CSAM website.

"Dmca ignored" is substantially not the same as "shady operators"

Why would a Canadian company care about American laws?

What if the user only get one address, how to separate the two? Seems like a need to share if a larger block (providor) is handing out based on blocks or single addresses…

Say what? IPv6 was designed that first 64 bits are network, last 64 bit are host.

Since /64 is smallest network in IPv6 and because of that most providers hand out /64 when you ask for IPv6 public address because A) Most Rate Limiting uses /64 and B) IPv6 has so many IPs, no one cares.

Vultr has at least one /32 I was able to find (2001:19F0::/32) which if you cut that into /64 comes out ~4.2 Billion different networks or same amount of IPv4 address that exist.

ARIN will hand anyone who asks a /48 IPv6 subnet which 65,536 unique networks and getting larger prefix is not hard.

> Since /64 is smallest network in IPv6

A /64 is not the smallest network in IPv6. Nothing stops you having a /112 or a /126 or whatever you like.

It is the only network size on which SLAAC works however, so it's a good choice for lan sizes.

I'm talking practical. I know you can reduce networks further BUT there is plenty of stuff that could break.

GCP for example hands out /96s to each VM, so this isn’t a theoretical or niche usecase.

Yes, but for GCP all the VMs with a /96 in the same /64 will be closely related: in the same project, same VPC network, same cloud region.

So from the point of abuse logic it's appropriate to treat the whole /64 as a single unit. (That was the starting point of the thread, even though I realize that due to thread drift that's probably not what your comment was about.)

What stuff?

Crappy network devices may not handle it properly, SLAAC obviously, I'm sure there are IPv6 tools that expect /64 for host, almost all blacklist setups for IPv6 assume /64.

This RFC has things that may not work properly not to use /64. https://datatracker.ietf.org/doc/html/rfc7421#section-4.2

The RFC only mentions issues with a shorter prefix, not a longer one. There should be no issues whatsoever with longer prefixes.

IP rate limiting hasn't been a serious misuse prevention tool for 15-20 years

Can you elaborate? As one tool among many it seems to me to be a perfectly serviceable tool in the toolbox, with a sufficiently high rate limit to account for shared IPs.

Reply on news.ycombinator.com