5.3 Merge window, part 1 [LWN.net]

5.3 Merge window, part 1

Posted Jul 16, 2019 4:49 UTC (Tue) by riking (subscriber, #95706) [Link] (1 responses)

Clawing back multicast assignments into unicast-routable addresses is an explicit goal of this effort, yes.

5.3 Merge window, part 1

Posted Jul 16, 2019 8:01 UTC (Tue) by naptastic (guest, #60139) [Link]

Is the intended alternative ff00::/8?

5.3 Merge window, part 1

Posted Jul 16, 2019 23:16 UTC (Tue) by mtaht (subscriber, #11087) [Link] (4 responses)

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....

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)

5.3 Merge window, part 1

Posted Jul 16, 2019 23:19 UTC (Tue) by mtaht (subscriber, #11087) [Link] (6 responses)

re: 240/4 (formerly class E), has basically worked on most OSes, except windows, since 2008. In linux, it needed one trivial patch (landed last december) to work correctly with ifconfig (it already worked with ip route) and 240/4 has now been extensively tested in openwrt.

Only a few routing daemons and related routing hw needs to be modified to make 240/4 globally routable. Babeld already has support, the FRR and bird folk have agreed in principle to make it work, juniper works with a flag, cisco's enterprise routers work, smaller scale ones don't. currently.

5.3 Merge window, part 1

Posted Jul 16, 2019 23:40 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

So you're looking at least for 3-4 more years for it to become available. Routers are not updated often and quiet a few Linuxes stay at the same kernel version for years.

Is it worth it now?

5.3 Merge window, part 1

Posted Jul 17, 2019 3:23 UTC (Wed) by mtaht (subscriber, #11087) [Link] (4 responses)

The best linear projection for 100% ipv6 adoption in one country was 7 years. Others, decades. So... yes, I think cleaning up ipv4 as best we can is needed.

5.3 Merge window, part 1

Posted Jul 17, 2019 16:42 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Right now it's at 30% with about 10% YoY growth: https://www.google.com/intl/en/ipv6/statistics.html

So yes, 7 years is about right. However, this assumes linear growth and it's probably not. For example, China has an official plan to move to IPv6 by 2025 with major deployments starting next year.

5.3 Merge window, part 1

Posted Jul 18, 2019 6:19 UTC (Thu) by cpitrat (subscriber, #116459) [Link]

Well, 2025 is in 6 years, so not that far from 7 years ...

5.3 Merge window, part 1

Posted Jul 17, 2019 20:31 UTC (Wed) by farnz (subscriber, #17727) [Link]

The trouble is that if you look at Geoff's IPv4 Address Report, we were consuming more than a /8 per month until we ran out of free-floating addresses. So cleaning up IPv4 needs to provide 84 /8s to get us to 7 years - for decades, you're looking at hundreds of /8s, which is going to get awkward…

5.3 Merge window, part 1

Posted Jul 18, 2019 23:02 UTC (Thu) by naptastic (guest, #60139) [Link]

I'm looking at a map of the Internet as of 2018, and I see a lot of empty space that I wonder if we could get by either asking nicely, offering money, or passing legislation. (I count nine /8's belonging to US agencies that appear completely dark on the map. How much does the US government really need for all its agencies? Every agency in every state plus federal agencies is still less than 2^16. I'd bet companies like Ford, HP, maybe Apple, would be willing take money for smaller allocations; no code has to change; and whoever buys control of those ranges can recoup the cost by selling smaller allocations.) Maybe I'm being Pollyannaish but I see win-win situations that would require nothing more than cooperation.