mmbleh

Yeah, our traffic is more from automated systems/servers, nothing from mobile

It is because the IPv6 rollout has not been consistent. Some assign /64 per machine, some assign /64 per data center. Some even go the other way and do a /56 per machine. We've had to build up a list of overrides to do some ranges by /64 and others by /128 because of how they allocate addresses. This creates extra burden on server operators and it's not surprising that some just choose not to deal with it.

Yeah, absolutely no expectations for the future. My point was more that while there may be clear benefits for users, IPv6 presents real problems for service operators with no clear solutions in sight.

Given that GitHub also offers free services for anonymous users, I can imagine they face similar problems. The easiest move is simply to just not bother, and I can't blame them for it.

Anonymous rate limits for us are skewed towards preventing abusive behavior. Most users do not have a problem, even there is a CGNAT on IPv4.

For IPv6, if we block on /128 and a single machine gets /64, a malicious user has near infinite IPs. In the case of Linode and others that do /64 for a whole data center, it's easy to rate limit the whole thing.

Wrong assumption or not, it is an issue that is made worse by IPv6

IPv6 is very difficult to implement and enforce reliable rate limits on anonymous traffic. This is something we've struggled a lot with - there is no consistent implementation or standard when it comes to assigning of IPv6 addresses. sometimes a machine gets a full /64, other times a whole data center uses a full /64. So then we need to try and build knowledge of what level to block based on which IP range and for some it's just not worth the hassle.

Maybe a different take, but as someone that manages a large public API that allows anonymous access, IPv6 has been a nightmare to try and enforce rate limits on. We've found different ISPs assign IPv6 addresses differently - some give a /64 to every server, some give /64 to an entire data center. It seems there is no standard and everyone just makes up what they think will work. This puts us in an awkward place where we need abuse protections, but have to invest into more complicated solutions that were needed for IPv4. Or we give up and just say if you want to use IPv6, you have to authenticate.

Does anyone have any success stories from the server side handling a situation like this? Looks like cloudflare switched to some kind of custom dynamic rate limiting based on like addresses, but it's unrealistic to expect everyone to be able to do such a thing.

CVE response time is a toss up, they all patch fast. Chainguard can only guarantee zero active exploits because they control their own exploit feed, and don't publish anything on it until they've patched. So while this makes it look better, it may not actually be better

Yep, agree that comms have a lot of room for improvement. We do have initial delete capabilities of manifests available now, but functionality is fairly basic. It will improve over time, along with automated policies.

40/hour is higher than the current limits for authenticated free users.

(I work there) If you have a support contact or AE they can tell you if you need an official source. Marketing communications should be sent out at some point.

These platforms do cache quite a bit. It's just that there is a very high volume of traffic and a lot of it does update pretty frequently (or has to check for updates)

The storage enforcement costs have been delayed until 2026 to give time for new (automated) tooling to be created and for users to have time to adjust.

The pull limits have also been delayed at least a month.

These dates have been delayed. They will not take effect March 1. Pull limit changes are delayed at least a month, storage limit enforcement is delayed until next year.

Step one for me is just educating people on how cloud providers charge for resources. So many people don't understand everything that goes into an AWS bill.

Take AWS for example - everyone seems to account for lambda runtime cost, but a lot of people forget/ignore execution cost, API Gateway cost, bandwidth costs, etc. Or they'll account for S3 storage but not S3 API costs.

While good tagging certainly helps figure out where money is spent, sometimes it's too late since things have been built on bad architectures based on misunderstandings of charges.