4

My question has to do with layering of unicast over multicast and has two parts.

Part 1. IP unicast over MAC multicast

First part of the question is whether there is a standard that prohibits use of IPv4 unicast addresses with multicast MAC address in an ethernet frame ?
I found the following discussion on the topic from 2005. https://forums.tomshardware.com/threads/multicast-mac-and-unicast-ip-address.951449/

And my understanding of the issue after reading through that email chain is that it this not explicitly prohibited. (at-least till 2005) and there are multiple vendors whose clustering solutions rely on this.

I am guessing that as far as standards compliance goes this is still the case. What I would like to know is from practical standpoint of commercially available network equipment and network stacks, how such packets are handled. For example a focus on security in recent years may have resulted in stacks that do not tolerate anything that is not a typical use case.

Part 2. TCP over IP Multicast

This may sound a tiny bit crazy or pointless, please bear with me.

Can stream (TCP) sockets work with multicast IP addresses ?

This basically boils down to two things from a socket application's perspective. Would calling "connect" API specifying a sockaddr that specifies a multicast destination address work ? (Assume that the destination node is designed to reply to ARPs for specific unicast IPv4 addresses with a multicast MAC address)

Also can I expect setsockopt(sd, IPPROTO_IP, IP_ADD_MEMBERSHIP, group address .... ) on a stream socket that is bound and listening on a TCP port (say 0.0.0.0:port) to succeed ?

I had a quick look at search at linux network stack and did not see a specific check that would prevent this, https://elixir.bootlin.com/linux/latest/source/net/ipv4/ip_sockglue.c

In my limited experience working with a network stack in a small RTOS, I would be surprised if the above combination worked out of the box. For example, this would mean the stack received a multicast ethernet frame (having configured any MAC layer hardware filter to allow this) and then looking at protocol field in IPv4 header, associate the payload with a TCP port object without blinking.

Some background. I am not doing this to implement 1:N or N:M TCP sessions. Quite boringly, all I am interested are standard point to point TCP sessions.

Unfortunately, unless I come up with concrete reasons why the above mentioned combination will not work or is undesirable, I will have to deal with layer two hardware that will most probably refuse to forward unicast ethernet frames (based on statically defined forwarding tables for handling TSN streams) and implement application layer protocols some of which use TCP over this network.

One would have thought a straightforward response such as "it will not work!" would be good enough... apparently not any more in this brave new world. and as they say "with enough thrust..."

Many Thanks,

Rakesh

Improve this question
1
  • 1
    The trick of mapping unicast addresses to multicast MAC's has definitely been a thing for certain clustering applications in the past. It's especially notable because it breaks many switching platforms and requires hacks like disabling IGMP snooping or hard-coding MAC addresses to particular ports. It's very much not compliant with standards or best practices and, thankfully, I haven't seen nearly as much of it in the last 5 or so years.
    – rnxrx
    Commented Apr 18, 2020 at 3:25

4 Answers 4

Reset to default
7

First part of the question is whether there is a standard that prohibits use of IPv4 unicast addresses with multicast MAC address in an ethernet frame ?

The problem here is that you are dealing with two different standards on different network layers that are defined and maintained by two completely different groups. Ethernet is IEEE 802.3, but IP is defined by the IETF.

The IEEE standard says that a multicast (including broadcast) address cannot be a source address. The RFC for IPv4 multicast also requires a source address to be a unicast address.

The IEEE protocols have no idea about what is in the payload, and it could be IPv4, ARP, IPX, IPv6, AppleTalk, etc. so ethernet has no idea if the network address is unicast or multicast. IP has no idea what data-link protocol is carrying it, and some data-link protocols have no address and some have no broadcast or multicast, so IP has no idea whether or not the data-link address is a multicast address, or if the data-link protocol even uses any addressing.

A particular host implementation is off-topic here.

Can stream (TCP) sockets work with multicast IP addresses ?

No. TCP sets up a connection between two hosts, and the connection needs both the source and destination IP and TCP addresses to identify the connection. Because an IP multicast address cannot be used a source address, then you will not be able to establish a connection using multicast. A TCP SYN sent to a multicast address would need a SYN/ACK from the multicast address to establish the connection, but the multicast address cannot be the source address, so the SYN/ACK would come from the unicast address of the sending host. That will prevent the establishment of the connection.

Improve this answer
3

Not a direct answer, but I can assure you that TCP over IP over broadcast ethernet works fine.

When bringing up network stacks, on more than one occasion I've brutalised the ARP module to always return ethernet broadcast ff:ff:ff:ff:ff:ff. It annoyed the network people but helped the operating system people.

I don't believe it's usual for the receiving system to notice that an non-broadcast IP packet arrived on a broadcast frame, even today.

Improve this answer
1
  • Essentially, turning the switches into hubs. :-P But that should actually work.
    – Zac67 ♦
    Commented Apr 17, 2020 at 18:18
2

First part of the question is whether there is a standard that prohibits use of IPv4 unicast addresses with multicast MAC address in an ethernet frame ?

There is not a standart that prohibits use of IPv4 unicast with multicast MAC. And technically it is possible because switches don't care about IP headers. As you said it can be used for clustering applications in the same layer2 network. A cluster node can understand and process the IP frame when it strips the multicast ethernet frame.

But if you want to do a multicast stream over a layer3 network, it doesn't work with unicast destination IP address. There is a conversion from multicast IP to multicast MAC and routers follow this standart.

A router strips MAC header of the received packet and it pushes another MAC header before sending it.

IPv4 addresses are 32 bits and first 4 bits are fixed as 1110 for multicast addresses. So 28 bits are available for the mapping.

MAC addresses are 48 bits and first 25 bits are fixed as 01:00:5e (with 25th bit as 0) for multicast. So 23 bits are available for the mapping.

Routers map last 23 bit of the multicast group IP to the available bits in multicast MAC. Since they are mapping 28 bits to 23 bits, there is an overlap possibility which needs to be considered.

As an example if multicast IP of the packet is 239.1.1.1, router pushes a multicast destination MAC of 01:00:5e:01:01:01 before sending it.

So what you are saying is only possible within a layer2 network where IP is not important.

Improve this answer
1

While direct "unicast over multicast addresses" isn't possible as Ron has aptly pointed out, it should be possible to tunnel unicast over a multicast network or, from another perspective, create an unicast-enabled overlay network on a purely multicast one.

You "just" need to find a tunneling protocol that supports multicast destinations, regardless of (unicast) source addresses (which you could - possibly - NAT statically). I'm not at all sure if that even exists but with sufficient effort, it could be created.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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