>ARIN recently handed out a /16 allocation to Capital One. That is one 65,025th of all of IPv6. A reasonable sized /32 allocation [...]
The more one digs, the more egregious it seems. If the NETIFY webpage is accurate, it shows that Capital One already had "/32" and "/36" blocks, and yet they also got "/16" : https://www.netify.ai/resources/networks/capital-one
There doesn't seem to be any public transparency of the approval process to explain how a non-ISP company could justify a "/16" block so it just leaves everybody guessing.
It seems more likely to me that ARIN is following the text of published policy, but Capital One found a way to interpret it that violates its spirit. My guess is that they're treating each customer debit/credit card as a serving site that qualifies for a /48. To address this, ARIN should fix the policy, not raise fees.
It's ARIN's job to call BS on BS justifications, otherwise they're not following the policy, they're following whatever they allow. "The purpose of a system is what the system does" and all.
That's an interesting idea for how they justified it. There might be something like 4 billion active credit/debit cards in the US (but they probably weren't all issued by Capital One).
Too bad ARIN tickets aren't public - I would love to read the one in which that was justified. Reading NRPM 6.5.2.1, it seems that they must have submitted documentation claiming at least 2^28 distinct serving sites in order to qualify for an assignment that large.
I find the insistence of using /64s everywhere for networks frustrating. Any network larger than a /112 seems crazy, that's already 65k IPs per subnet. A /104 for every normal end user (256 subnets per user), or a /80 for massive companies like Capital One (4 billion subnets) should be more than enough.
There is a really practical reason behind this, and it is called "routers". Due to longest prefix match, you'll end up wasting resources on the networking hardware. And you waste both precious and expensive TCAM and LPM latency for matching the prefixes. So routers do optimize for anything shorter than /64, and have special lookup memory for /64 and /128. But nothing in-between.
thankfully I replied to a comment speaking about a tangent (/64s) and not to its parent. /s
Snark aside, very much agreed, and I don't like that they got away with it. It's precisely with the mindset of "we'll have enough" that companies like ford have a /8 or the DoD has more /8s that we can count. And with this mindset we'll run out of IPv6 the same we ran out of IPv4.
That's fair enough, in which case ipv6 is really only a /76 (having more than 1000 hosts on a subnet isn't a great thing, even with no broadcast and arp and other traffic, and /76 allows 4000 on a /64)
Those fanboys going "we'll never run out of 2^128 IPs" are being disingenuous when about 2^59 of them have been burnt straight away (I'd guess most subnets have less than 30 devices)
2^64 subnets is a reasonable number, but when they are handed out like candy that number dwindles quickly. ARIN is allocating the equivalent of a /15 every year. That's fine if it's a constant allocation, there's 100,000 years worth, but if that rate grows, the space will be eaten in a matter of a few decades.
It's not being burnt, there are two useful things we're doing with the 64-bit network size:
* Sparse networks. 64 bits is too big to feasibly do a brute force scan on, which reduces how often servers get exploited by random network attacks.
* SEND secures NDP by using those 64 bits for a public key
Reducing network sizes to 12 bits would destroy both advantages.
Having a ludicrously large address space is kinda the point of IPv6.
You're not ment to utilize every address assigned to you. Trying to do so will always lead you to situations where you messed up and need to renumerate.
A reasonable sized /32 allocation would have allowed for giving every ATM they operate worldwide its own globally routable /48.