Hacker News Reader

Comment by mike_d | Hacker News Reader

ARIN recently handed out a /16 allocation to Capital One. That is one 65,025th of all of IPv6.

A reasonable sized /32 allocation would have allowed for giving every ATM they operate worldwide its own globally routable /48.

View on HN

>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

And if I'm reading the ARIN fees correctly, it only costs $4000 annually for a "/16" allocation: https://www.arin.net/resources/fees/fee_schedule/

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.

John Sweeting from ARIN only confirmed that the "/16" was allocated to Capital One according to policy but he didn't elaborate on the rationale: https://www.mail-archive.com/arin-tech-discuss@arin.net/msg0...

Example reddit discussion : https://old.reddit.com/r/ipv6/comments/17yuqvp/til_capital_o...

> And if I'm reading the ARIN fees correctly, it only costs $4000 annually for a "/16" allocation:

For better or worse, you're not; that's for IPv4 /16. For IPv6 /16, it'd be the X-Large service category, so $16,000/year.

And for $256,000/year you can... exhaust the entirety of 2000::/3?

Yeah, that's not okay. Either the price needs to go up a lot or they need to include factors other than money in the allocation criteria.

> they need to include factors other than money in the allocation criteria

They already do, and simply being able to pay the fee does nothing to qualify you for an allocation: https://www.arin.net/participate/policy/nrpm/#6-ipv6

At least, in theory. I'm not going to attempt to defend the Capital One allocation.

They might have included them in the published policy, but it seems they aren't in whatever policy they're actually following.

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.

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.

This still not justifies a /16 allocation

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.

Except you need at least a /64 for v6 to properly work.

You only need it because that's how the protocol was designed.

You only need it for SLAAC, and only because SLAAC was made that way.

It's not just about the number of devices. Stateless Address Autoconfiguration for example basically needs a /64 subnet.

because it was designed that way. "we need it because we need it".

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.

Reply on news.ycombinator.com