Hacker News Reader

Comment by lncoyyis | Hacker News Reader

multicast, then experimental blocks

Yes, I noticed that recently when writing a unit test with with randomly created IP addresses. A significant part where deemed as non-routable by the code under test, so I had to limit the first octet < 224.

But is that huge allocation really extensively used in real life? How?

Or could a significant part just be reallocated for new unicast usage?

The 224.0.0.0/4 multicast space could probably have been made smaller, at least down to a /8 if follow on standards had been written with that kind of size in mind from the beginning, but at this point that'd be like saying "We're going to change 10.0.0.0/8 into 10.0.0.0/16 to free up space everyone, let me know when you've all stopped using it. Thanks!". The space is already in sparse use in corporate networks around the world, you're not going to get everyone to just up and change internal networks to fit less sparsely. If it were that easy IPv6 adoption would be 100% instead of 45%.

240.0.0.0/4 could conceivably be assigned. It's not really in use as it was actually reserved for "future use" from the beginning. That said, if you want to use that space publicly in any reliably usable form you've still got to convince near the entire internet to update their stuff to support/allow it. On this front I'm actually kind of against opening it up even just for internal use as it'd just create another headache to check for and not be particularly reliable. For "extra internal space" 0.0.0.0/8 was in a similar situation and already opened up. If that's not enough for you then you desperately need to move on from IPv4 already.

Well that's true. Probably there are users that use it in violation of the spec, relying on that it would not harm.

Was it 1.1.1.1 that had quite some problems in the beginning of their operation or some similar one? I vaguely remember reading a blog post at the time.

For 240.0.0.0/4 it's not as much existing users violating spec as existing in-spec software and hardware not allowing it. E.g. even if you patched your Linux box and DHCP server to support 224.0.0.0 your hardware router might not forward the packet between zones, your Windows clients might not accept the assignment. In the public case your ISP might not accept it in their router hardware or filters and even if they did it doesn't mean the other 100,000 entities on the internet you're trying to talk to/through do. The same is all true with 224.0.0.0/4 as well plus the fact there is existing in spec use for multicast.

1.1.1.1 was never reserved but it was unassigned until 2010. By that point it had been used improperly so much it received massive amounts of garbage data when advertised (and still does to this day). It's just that "massive" turns to "quite tiny" in context of a giant CDN like Cloudflare so they were able to salvage it.

Yes it was 1.1.1.1. I remember the initial blog post. Before even turning DNS on they just monitored traffic patterns and types to make sure they could handle it.

That’s actually exactly the reason why Cloudflare got it. They were the only ones at that point who could handle all the garbage that was sent to it, and willing to deal with it at their own expense.

> could probably have been made smaller

A lot of reserved ranges could've been made smaller, 127.0.0.0/8 is JUST loopback, that's over 16 million ips just for loopback! 0.0.0.0/8 is also just absurd

224.0.0.0/4 and 240.0.0.0/4 are also crazy... over 500 million ips.

I probably wouldn't care about it if we didn't have ipv4 exhaustion (which is in my opinion is at least partially the US govt's fault, because they're hoarding 200+ million ips)

More than 40 years later it can seem so. But with these you were basically able to just check the first byte, perhaps it was an optimization of some sort. Reserving ~1/8 of the available address space for other use cases or future needs is reasonable and not out of line. The ASCII encoding also uses just 7/8 of a byte to encode letters and thanks to this we were able to make UTF-8 compatible enough. IPv4 could have been 48 bit just like the MAC and we wouldn't have this conversation. Nowadays a /48 prefix (in IPv6) is basically the smallest we hand out.

Of course, we could've used /80 as the smallest possible prefix for auto-negotiation, leaving more room for playing with prefixes but it is what it is. Nobody sane will wait another 20-25 years before any kind of change is widespread in all the stacks. Even less people will care about the reserved/multicast space, 0/32 or 127.0.0.0/24 because it is so much work for little benefit as it will never be supported by all the legacy systems that care about IPv4 since for them there is no IPv6. We should all concentrate on IPv6 and get on with the colossal migration. Even HN supports IPv6 as of this year!

Thanks for creating an account just to answer my question, I guess.

Reply on news.ycombinator.com