4 ms·

Why is there a giant blackout after 224.?

by system2 3y ago

lncoyyis 3y ago
multicast, then experimental blocks
- system2 3y ago
  Thanks for creating an account just to answer my question, I guess.
- usr1106 3y ago
  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?
  - zamadatix 3y ago
    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.
    - usr1106 3y ago
      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.
      - pests 3y ago
        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.
        sgjohnson 3y ago
        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.
      - zamadatix 3y ago
        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.
    - KomoD 3y ago
      > 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)
mike_d 3y ago
The solution to IPv4 exhaustion. It is basically unused multicast and "reserved for future use." Only thing standing in our way is the IPv6 proponents who know address space exhaustion is the only thing that will drive adoption of an otherwise shitty idea.
- account-5 3y ago
  Can you elaborate on why ipv6 is so shitty?
  - system2 3y ago
    I'd assume legacy support isn't there for IPv6. At least for our environments, it wasn't feasible.
    - kaliszad 3y ago
      Could you please elaborate, what were some of the major blockers for you? In some cases, you can "just" add a reverse proxy in front of the legacy services or use some kind of NAT64/ DNS64 setup on the server side. Internal systems can expect IPv4 only for addresses for some kind of accounting, configuration etc. But internal systems that you cannot evolve to support current requirements are a burden anyway. There might be other debt that keeps getting postponed because of these things. I have had a client tell me that some services cannot get a different IPv4 because they don't know about all the things that only know it by its IP instead of its DNS name. I am pretty sure that as a man made software system their system could definitely switch to a different address with some preparation but I am not going to push for it too hard. (It would allow improving the segmentation of their network in turn making it easier to firewall things in a simpler manner. Also, with L3 switches now commonplace it is no longer a question of performance.)
- Avamander 3y ago
  Absolutely not the solution, a temporary relief at best. Better to bury this idea.

Why is there a giant blackout after 224.?

lncoyyis 3y ago

multicast, then experimental blocks

system2 3y ago
Thanks for creating an account just to answer my question, I guess.
usr1106 3y ago
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?
- zamadatix 3y ago
  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.
  - usr1106 3y ago
    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.
    - pests 3y ago
      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.
      - sgjohnson 3y ago
        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.
    - zamadatix 3y ago
      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.
  - KomoD 3y ago
    > 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)

mike_d 3y ago

The solution to IPv4 exhaustion. It is basically unused multicast and "reserved for future use." Only thing standing in our way is the IPv6 proponents who know address space exhaustion is the only thing that will drive adoption of an otherwise shitty idea.

account-5 3y ago
Can you elaborate on why ipv6 is so shitty?
- system2 3y ago
  I'd assume legacy support isn't there for IPv6. At least for our environments, it wasn't feasible.
  - kaliszad 3y ago
    Could you please elaborate, what were some of the major blockers for you? In some cases, you can "just" add a reverse proxy in front of the legacy services or use some kind of NAT64/ DNS64 setup on the server side. Internal systems can expect IPv4 only for addresses for some kind of accounting, configuration etc. But internal systems that you cannot evolve to support current requirements are a burden anyway. There might be other debt that keeps getting postponed because of these things. I have had a client tell me that some services cannot get a different IPv4 because they don't know about all the things that only know it by its IP instead of its DNS name. I am pretty sure that as a man made software system their system could definitely switch to a different address with some preparation but I am not going to push for it too hard. (It would allow improving the segmentation of their network in turn making it easier to firewall things in a simpler manner. Also, with L3 switches now commonplace it is no longer a question of performance.)
Avamander 3y ago
Absolutely not the solution, a temporary relief at best. Better to bury this idea.