After previously exploring the basics of UDP broadcasting, why IPv4 subnets are an exciting feature that you really want to dive into, as well as the contentious topic of IPv6, there are still plenty of elephants to admire and cans of sardines to crack open. One of them being the topic of broadcasting versus multicasting, which at first glance sounds rather similar and may even have some wondering why you’d even bother with multicasting if you can just send-and-forget with IPv4 broadcast address.
Of course, we already found out that IPv4 broadcast addresses come in a few flavors, and that’s before you start even considering the implications of subnets and routing limits. When we then consider that in IPv6 broadcast addresses were dropped completely in favor of link-local multicast addresses, and that IPv4 also supports multicast, then this raises the question whether using IPv4 multicast’s own take on ‘link-local’ doesn’t make more sense.
Or perhaps more succinctly put, is IPv4’s take on link-local broadcasting as straightforward as IPv6’s?
CIDR
Before diving into multicasting, there is one important topic that has been absent from the IPv4 discussions so far. This being that of CIDR, which stands for Classless Inter-Domain Routing. This forms part of IPv4’s evolution, with CIDR in 1993 replacing the previous classful network architecture, with the goal to slow the growth of routing tables and with it IPv4 address exhaustion on the Internet. It’s also the reason for some of IPv4’s quirks.
The most obvious implication of CIDR is that it is the reason why we write IPv4 addresses the way that we do today, yet the classes from classful networking have left their traces to this day, including the reason why some companies hold large chunks of classful allocations. This is where Class A, B and C addresses come from, with Class D address being the multicast range.
A lot of IPv4 addresses were incidentally wasted with the classful system because the three available classes provide blocks that are effectively always unfortunately sized. CIDR addresses this with subnets, creating CIDR blocks that can thus be more appropriately sized to the target application or customer instead of handing a company a small 8-bit Class A or a very large (216) Class B block.
Although I would never claim to be an expert on this subject matter, CIDR would seem to be a solid improvement here that probably postponed the death of IPv4 to – at this rate – probably a few days after the heat death of the universe. It’s apparently such a good idea that even IPv6 uses CIDR.
IPv4 Multicast
If we now look at the IPv4 multicast addresses, a lot becomes suddenly clear. The main thing probably why IPv4 multicast addresses all are in the 224.*.*.* to 239.*.*.* range, as this is the pre-CIDR multicast range.
Next it’s important to note that these multicast address are sub-divided into blocks, either with a specific function or left as simply Reserved. Unless we have any pressing business outside of doing multicast things outside of a local subnetwork, the multicast address range we are interested in is thus the 224.0.0.0 to 224.0.0.255 range.
The next question then is what we can do with all of these addresses, essentially what the special meaning is that has been assigned to each of these.
That too is defined in the above referenced Wikipedia page, though one’s eyes may slide casually over to the Pv6 side to see how different it is. At first glance it would seem that in either case you can just mash in the ‘all hosts’ multicast group address, or link-local as IPv6 calls it. For IPv4 this thus means that sending a message to the 224.0.0.1 multicast address should reach every single node on the same network, with routers happily not routing it to other network segments.
To Broadcast Or To Multicast
With these findings in mind, this then leaves us with the question of why we’d bother with IPv4 broadcasting at all. Is this simply an archaic legacy from a time before multicasting became fully implemented by IPv4 software stacks, considering that it’s a technically optional feature?
Looking around for an overview of why to prefer one over the other I could not find any direct comparisons, with multicast on IPv4 seemingly almost always being used for sending to a specific group of receivers using the Internet Group Management Protocol (IGMP). This is quite useful for e.g. video streaming to multiple receivers and similar applications where it’s much more efficient to just duplicate the same packet a few times as it’s being routed.
IGMP contrasts with IPv6’s Multicast Listener Discovery (MLD), which is an integral part of IVMPv6 rather than an IP encapsulation protocol, so one could presume there to be some more overhead to IPv4 multicast compared to its broadcast features.
IPv4’s Three Options
Thus, after all is said and done we end up with a grand total of three options in IPv4 if we want to do UDP broadcasting for service discovery or other purposes:
- Determining the interface’s broadcast address and broadcasting on that.
- Use the local broadcast address
255.255.255.255. - Use the multicast address for all nodes:
224.0.0.1.
It would seem that the first option is what most guides seem to suggest, though many also will happily tell you to always assume a /24 network, so your mileage will vary heavily there.
The second option is obviously braindead simple, and actually is another fun pre-CIDR legacy item as the standard broadcast address, established before directed broadcast became a thing. This is probably why there’s the implicit threat that a sysadmin will kick in your door if you so much as think about using it.
Finally multicast to all nodes as the IPv4 take on link-local multicast would seem to be much closer to the local broadcast address in its basic usage. Of course, this all assumes that IGMP is supported and functioning correctly.
Take-Away For Now
After spending some time researching all of these options I cannot say that from a software developer point of view I feel very reassured about which option is ‘the best’. While in IPv6 it’s very much a ‘take it or leave it’ kind of deal with its take on broadcasting, in IPv4 you get the legacy option, the directed ‘legacy’ option and the shiny new IGMP-based multicast option, all of which seem to come with their own set of issues, advantages and potential complications.
In a way I would say that a directed broadcast option is the preferred approach for something like service discovery, to which I can also add that there’s been a response to my bug ticket on the Poco Project tracker regarding it not reliably returning an interface’s netmask, never mind its broadcast address. This issue should be addressed in the upcoming 1.16.0 release, with a workaround possible until then.
Directed broadcast has the definite advantage that you know which interface you’re sending the broadcast on, which makes it easier to sort through responses. This is also rather part of the original design of NyanSD, so retaining that feature without in-depth refactoring is a nice benefit.
Of course, it’s quite possible that I misunderstood something here, and multicast in IPv4 is actually the cat’s pajamas. Feel free to sound off in the comments with your thoughts on your favorite IPv4 broadcast method.
Â
This articles is written by : Nermeen Nabil Khear Abdelmalak
All rights reserved to : USAGOLDMIES . www.usagoldmines.com
You can Enjoy surfing our website categories and read more content in many fields you may like .
Why USAGoldMines ?
USAGoldMines is a comprehensive website offering the latest in financial, crypto, and technical news. With specialized sections for each category, it provides readers with up-to-date market insights, investment trends, and technological advancements, making it a valuable resource for investors and enthusiasts in the fast-paced financial world.