1

I been asked the question if it is possible for an a IP host to use multicast to address 224.0.0.1 in order to reach (and get a response from) another host which is not on the local network segment but on another subnet reachable via a ip router (which do just "regular" routing without firewalling, applying policies etc).

E.g: host 192.168.1.100/24 can reach 192.168.222.100/24 via IP unicast through their common gateway router (which has IP addresses 192.168.1.1/24 and 192.168.222.1/24 on each network).

So given the above example, the question I have been asked is if it is possible to configure the gateway so it is possible for 192.168.1.100 to reach 192.168.222.100 just by sending multicast traffic to 224.0.0.1?

(My apologies, I cannot provide any details about the context where this question emerged other than it is something that is completely isolated from the internet)

Based on my understanding of networking, the answer I am ready to provide is:

"No, it is not possible and if it is made possible somehow, it will break critical networking contracts everyone expects to be kept so don't even try. Your options are:

  • redesign the network so both hosts show up on the same network segment
  • use unicast between them. Yes, host 192.168.1.100 must be explicitly aware of the IP address of 192.168.222.100 (directly or via name lookups) so you must configure/implement/architect that awareness if it is not in place
  • use a dedicated multicast address intended to be routed between subnets. Again, this must be implemented/configured/architected in you solution and yes, you must configure the router accordingly as well

Don't try to use 224.0.0.1 (intended for same-subnet multicast communication) for something it was not designed for in the first place (multicast communication with hosts outside the local subnet)"

Is this response to the 3rd party reasonable? Or have I missed out something fundamental when it comes to multicast or missed some clever technology available in modern routers and servers?

I have quite some networking experience, but multicast is an area where I have little hands on experience, I simply don't know how far you can (or even should) push that specific technology.

Then we have the issue of best practices and what technical, maintenance and economical complexities/pitfalls you want to introduce into a larger picture. Just because you somehow can make traffic directed to 224.0.0.1 reach hosts outside your network does not mean it is a good idea from a development, architectural and support perspective.

(Note, the IPs above are made up in order to protect the innocent, of course...)

  • This sounds very much like a schoolwork question, which sadly is off topic here. – Ron Trunk Oct 10 '19 at 6:03
  • It is not a schoolwork situation. I got a CCDP so I have studied the subject. It is from a real life situation with people having a situation where they depend on using 224.0.0.1 to reach certain machines and it turned out that one of those machines happened to be on a different subnet. Hence the question "can you make the network forward it so we don't need to change our stuff?" being asked. There was some actual beliefs that such a functionality existed and I posted this question as a sanity check before saying "No" to them. – IllvilJa Oct 10 '19 at 8:53
  • 2
    To be very non-PC, the person(s) who designed this "solution" are morons who don't know anything about multicast. 224.0.0.1 is "every multicast capable node on the segment", not just the ones interested in whatever your specific application is pushing. (I see this sort of misuse of 224.0.0.x all the time. eg. nuts sending video streams to 224.0.0.1) – Ricky Beam Oct 10 '19 at 16:17
7

Can communication to broadcast 224.0.0.1 be made to reach hosts outside of the local subnet?

First, that is a multicast group, not a broadcast address.

Next, the multicast address is in the Local Network Control Block (224.0.0.0/24), and multicasts sent to groups in that block are limited to the network on which they originate.

So given the above example, the question I have been asked is if it is possible to configure the gateway so it is possible for 192.168.1.100 to reach 192.168.222.100 just by sending multicast traffic to 224.0.0.1?

No. As I explained above, multicasts in that range are not allowed to be routed to a different network. See RFC 5771, IANA Guidelines for IPv4 Multicast Address Assignments, Section 4. Local Network Control Block (224.0.0/24):

4. Local Network Control Block (224.0.0/24)

Addresses in the Local Network Control Block are used for protocol control traffic that is not forwarded off link. Examples of this type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].

Also, see RFC 1112, Host Extensions for IP Multicasting:

The address 224.0.0.0 is guaranteed not to be assigned to any group, and 224.0.0.1 is assigned to the permanent group of all IP hosts (including gateways). This is used to address all multicast hosts on the directly connected network. There is no multicast address (or any other IP address) for all hosts on the total Internet

It is possible to configure multicast routing between networks, but that is very different than unicast routing, and it involves IGMP and a multicast routing protocol, e.g. PIM, and all routers in the path of the multicast traffic must be configured for the multicast routing. That is why you cannot multicast on the public Internet. You can use a tunnel to send multicasts across the internet to a different site, but you cannot multicast on the Internet.

In most cases, you would use a multicast group in the Organization-local Scope (239.0.0.0/8) within a company, even if it involves multiple sites. IANA maintains the IPv4 Multicast Address Space Registry.

| improve this answer | |
  • 2
    Excellent answer. In essence, "...multicasts in that range are not allowed to be routed to a different network" is precisely the piece of information I need to provide to the third party so we can get that (non-)alternative out of the discussions. – IllvilJa Oct 10 '19 at 8:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.