4 ms·

While at it, I feel like we could also squeeze the 224.0.0.0–239.255.255.255 multicast range to maybe 224.0.0.0/8 if not tighter. For reference here is a list

by rixrax 7y ago

While at it, I feel like we could also squeeze the 224.0.0.0–239.255.255.255 multicast range to maybe 224.0.0.0/8 if not tighter. For reference here is a list of reserved ipv4 addresses[0]. [0] https://en.m.wikipedia.org/wiki/Reserved_IP_addresses https://en.m.wikipedia.org/wiki/Reserved_IP_addresses

Aloha 7y ago
This would break a ton of existing applications
simcop2387 7y ago
This can't be done, there's a number of devices out there that do multicast on fixed multicast IPs and so doing this would break them. In particular I've got a series of HDMI<=>IP devices that forcefully go to 239.255.42.[42..141] depending on their settings.
- Dylan16807 7y ago
  I wonder, though, how many of those fixed multicast IPs are outside of both 224/8 and 239/8.
- dtaht 7y ago
  225/8-231/8 were reserved for future multicast use and never allocated by iana. As near as we can tell by grepping the entire world's source they are entirely unused. 128m addresses....
  - simcop2387 7y ago
    yea that'd probably be reasonable to try to reclaim then. probably only useful for private use unfortunately though, i bet there's a lot of stuff that'll improperly route them given the range.
    - dtaht 7y ago
      We've had 225/8-231/8 up and running for 6+ months, with patches for various routing daemons. Running a gauntlet with 240/4 and 0/8 now working seemed best. In our exploration of converting these 120m addresses from a multicast definition to unicast, we only had to change the kernel with two tiny patches, and recompile 89 fedora packages. Openwrt was less. The patches for frr and bird, straightforward.
    - dtaht 7y ago
      As for private or public use, certainly there is demand for a larger CGNAT address space, somewhere, and allocation of a portion of 225-231 for that might drive adoption there. Still, the addresses need to become routable, and from there (aside from politics and depoloyment delay), globally routable is the dream for most of these new addresses, in 5-10 years.
ikiris 7y ago
or you could just move to fucking v6, its not that hard.

by rixrax 7y ago

Aloha 7y ago

This would break a ton of existing applications

simcop2387 7y ago

This can't be done, there's a number of devices out there that do multicast on fixed multicast IPs and so doing this would break them. In particular I've got a series of HDMI<=>IP devices that forcefully go to 239.255.42.[42..141] depending on their settings.

Dylan16807 7y ago
I wonder, though, how many of those fixed multicast IPs are outside of both 224/8 and 239/8.
dtaht 7y ago
225/8-231/8 were reserved for future multicast use and never allocated by iana. As near as we can tell by grepping the entire world's source they are entirely unused. 128m addresses....
- simcop2387 7y ago
  yea that'd probably be reasonable to try to reclaim then. probably only useful for private use unfortunately though, i bet there's a lot of stuff that'll improperly route them given the range.
  - dtaht 7y ago
    We've had 225/8-231/8 up and running for 6+ months, with patches for various routing daemons. Running a gauntlet with 240/4 and 0/8 now working seemed best. In our exploration of converting these 120m addresses from a multicast definition to unicast, we only had to change the kernel with two tiny patches, and recompile 89 fedora packages. Openwrt was less. The patches for frr and bird, straightforward.
  - dtaht 7y ago
    As for private or public use, certainly there is demand for a larger CGNAT address space, somewhere, and allocation of a portion of 225-231 for that might drive adoption there. Still, the addresses need to become routable, and from there (aside from politics and depoloyment delay), globally routable is the dream for most of these new addresses, in 5-10 years.

ikiris 7y ago

or you could just move to fucking v6, its not that hard.