Linux Ethernet Bridging - Jan 2017 - [Bridge] [PATCH net-next] bridge: multicast to unicast

On Mon, 2017-01-02 at 20:32 +0100, Linus L?ssing wrote:
> Implements an optional, per bridge port flag and feature to deliver
> multicast packets to any host on the according port via unicast
> individually. This is done by copying the packet per host and
> changing the multicast destination MAC to a unicast one accordingly.
How does this compare and/or relate to the multicast-to-unicast feature
we were going to add to the wifi stack, particularly mac80211? Do we
perhaps not need that feature at all, if bridging will have it?

I suppose that the feature there could apply also to locally generated
traffic when the AP interface isn't in a bridge, but I think I could
live with requiring the AP to be put into a bridge to achieve a similar
configuration?

Additionally, on an unrelated note, this seems to apply generically to
all kinds of frames, losing information by replacing the address.
Shouldn't it have similar limitations as the wifi stack feature has
then, like only applying to ARP, IPv4, IPv6 and not general protocols?

Also, it should probably come with the same caveat as we documented for
the wifi feature:

????Note that this may break certain expectations of the receiver,
????such as the ability to drop unicast IP packets received within
????multicast L2 frames, or the ability to not send ICMP destination
????unreachable messages for packets received in L2 multicast (which
????is required, but the receiver can't tell the difference if this
????new option is enabled.)


I'll hold off sending my tree in until we see that we really need both
features, or decide that we want the wifi feature *instead* of the
bridge feature.

johannes

On 2017-01-06 13:47, Johannes Berg wrote:
> On Mon, 2017-01-02 at 20:32 +0100, Linus L?ssing wrote:
>> Implements an optional, per bridge port flag and feature to deliver
>> multicast packets to any host on the according port via unicast
>> individually. This is done by copying the packet per host and
>> changing the multicast destination MAC to a unicast one accordingly.
> 
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
> 
> I suppose that the feature there could apply also to locally generated
> traffic when the AP interface isn't in a bridge, but I think I could
> live with requiring the AP to be put into a bridge to achieve a similar
> configuration?
> 
> Additionally, on an unrelated note, this seems to apply generically to
> all kinds of frames, losing information by replacing the address.
> Shouldn't it have similar limitations as the wifi stack feature has
> then, like only applying to ARP, IPv4, IPv6 and not general protocols?
> 
> Also, it should probably come with the same caveat as we documented for
> the wifi feature:
> 
>     Note that this may break certain expectations of the receiver,
>     such as the ability to drop unicast IP packets received within
>     multicast L2 frames, or the ability to not send ICMP destination
>     unreachable messages for packets received in L2 multicast (which
>     is required, but the receiver can't tell the difference if this
>     new option is enabled.)
> 
> 
> I'll hold off sending my tree in until we see that we really need both
> features, or decide that we want the wifi feature *instead* of the
> bridge feature.
The bridge layer can use IGMP snooping to ensure that the multicast
stream is only transmitted to clients that are actually a member of the
group. Can the mac80211 feature do the same?

- Felix

> The bridge layer can use IGMP snooping to ensure that the multicast
> stream is only transmitted to clients that are actually a member of
> the group. Can the mac80211 feature do the same?
No, it'll convert the packet for all clients that are behind that
netdev. But that's an argument for dropping the mac80211 feature, which
hasn't been merged upstream yet, no?

johannes

On Fri, Jan 06, 2017 at 01:47:52PM +0100, Johannes Berg
wrote:
> How does this compare and/or relate to the multicast-to-unicast feature
> we were going to add to the wifi stack, particularly mac80211? Do we
> perhaps not need that feature at all, if bridging will have it?
> 
> I suppose that the feature there could apply also to locally generated
> traffic when the AP interface isn't in a bridge, but I think I could
> live with requiring the AP to be put into a bridge to achieve a similar
> configuration?
> 
> Additionally, on an unrelated note, this seems to apply generically to
> all kinds of frames, losing information by replacing the address.
> Shouldn't it have similar limitations as the wifi stack feature has
> then, like only applying to ARP, IPv4, IPv6 and not general protocols?
(should all three be answered with Michael's and my reply to
Michael's mail, I think)
> 
> Also, it should probably come with the same caveat as we documented for
> the wifi feature:
> 
> ????Note that this may break certain expectations of the receiver,
> ????such as the ability to drop unicast IP packets received within
> ????multicast L2 frames, or the ability to not send ICMP destination
> ????unreachable messages for packets received in L2 multicast (which
> ????is required, but the receiver can't tell the difference if this
> ????new option is enabled.)
Actually, I do not quite understand that remark in the mac80211
multicast-to-unicast patch. IP should not care about the ethernet
header?