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.