5.3 Merge window, part 1

Posted Jul 17, 2019 10:53 UTC (Wed) by naptastic (guest, #60139)
In reply to: 5.3 Merge window, part 1 by mtaht
Parent article: 5.3 Merge window, part 1

I can understand how designers of the Internet would be cautious and disallow 0/8, fearing ambiguity. That was a wise choice. Now that we know more, and we're confident 0/8 will work, we're allowing it. This is a wise choice.

Thinking about it more, my anxiety about multicast isn't warranted. All my applications that use multicast are IPv6-capable. If I, as the system administrator, am not willing to set up my network for IPv6 multicast, I have no room to complain.

So... before this thread, I was opposed to reclaiming multicast IPv4 ranges, but having learned more from you wonderful folks, I am now totally indifferent on the matter. Thank you!

(It might be mildly inconvenient if I have to reconfigure my firewall if other classes of networks get reclaimed. Meh: Progress necessitates inconvenience. MEH, I SAY!)

5.3 Merge window, part 1

Posted Jul 17, 2019 16:41 UTC (Wed) by luto (guest, #39314) [Link] (2 responses)

The CME uses multicast. See here, for example:

ftp://ftp.cmegroup.com/SBEFix/Production/Configuration/co...

5.3 Merge window, part 1

Posted Jul 17, 2019 21:34 UTC (Wed) by mtaht (subscriber, #11087) [Link]

The 224/8 and 239/8 ranges were allocated and used for some still common multicast applications. 232/8-238/8 are mapped for a variety of mostly, but not entirely obsolete: https://www.iana.org/assignments/multicast-addresses/mult...

As I said, 225/8-231/8 appear to be entirely unused in the world. 120m addresses.

Let's make 'em unicast!

5.3 Merge window, part 1

Posted Jul 17, 2019 21:35 UTC (Wed) by mtaht (subscriber, #11087) [Link]

(to be clear, that particular multicast application uses addresses in the 233 range)