|
|
Subscribe / Log in / New account

5.3 Merge window, part 1

5.3 Merge window, part 1

Posted Jul 16, 2019 23:16 UTC (Tue) by mtaht (subscriber, #11087)
In reply to: 5.3 Merge window, part 1 by naptastic
Parent article: 5.3 Merge window, part 1

1) Amazon AWS treats the entire ipv4 address space as a unicast playground. Very, very few userspace stacks actually do much checking of the IP addresses in the first place.

2) From our testing and from source code inspection of all the source code in the world (amazing what we can do nowadays) we've only found *1* application that used a multicast address in the 225/8 - 231/8 address range, which was reserved for future multicast use and never allocated for anything by iana the great multicast-everything orgy of the late 80s.

Do let us know if the multicast portion of this patch here breaks anything:

https://github.com/dtaht/unicast-extensions/blob/master/p...

After fixing 240/4 last december....

We submitted the 0/8 patch in the hope that we would stimulate discussion of the more advanced patches, and it, um, went right upstream (0/8 really is uncontroversial, and john's been waiting for the standard to be changed since he co-invented bootp), and NOW we're getting the discussion on various forums over the last few days and I'm trying to keep up....


to post comments

5.3 Merge window, part 1

Posted Jul 17, 2019 10:53 UTC (Wed) by naptastic (guest, #60139) [Link] (3 responses)

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)


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds