AW: Interest in adding multicast support to Wireguard?

[Derrick Lyndon Pallas]

Thanks for the reply.

Since I can't control the peers (they're mostly just running the 
official Wireguard apps), the way I've got it implemented is that 
224.0.0.0/4 is explicitly in their lists of AllowedIPs. On the hub side, 
I took approach (1) for the proof of concept.

If I were to extend the implementation, my gut says that it'd be better 
to separate AllowedIPs and MulticastIPs logically, and to make the 
ranges opt-in and per-peer. However, I haven't tried implementing that 
yet so I don't know how hard/useful it would be.

~Derrick


On 9/21/20 4:17 AM, Florian Werner wrote:
> I would appreciate multicast support for Wireguard. My wish and use-case would be full support for in band dynamic address assignment, i.e. without any external protocol or other shared information except the public key.
>
> At least for the IPv6 case (with I only consider here, but IPv4 can be added too), link-local scope multicast (FF02::/64) and the unspecified address (::) are enough to bootstrap any address assignment and to enable learning of self-assigned addresses (e.g. FE80::/64) of peers and eventually dynamic assignment (and learning) of global unicast addresses. This could all be accomplished only by standard protocols (IPv6 Neighbor Discovery, SLAAC, DHCPv6). The only modification would be for Wireguard to (optionally) send all packages with a multicast destination address to all peers and for Wireguard to receive packages with a (all or only some) multicast destination address from any peer. (if someone wants a detailed explanation of this, just ask)
>
> There are multiple ways to implement multicast addresses:
> (1) always make FF00::/8 and 224.0.0.0/4 special: send it to all peers and receive it from all
> (2) like (1) but opt in for multicast per Wireguard interface
> (3) like (1) but opt in for multicast per peer
> (4) make FF00::/8 and 224.0.0.0/4 special, but only send/receive them if listed in AllowedIPs
> (5) like (4) but allow smaller subnets (e.g. FF02::/64)
> (6) make FF00::/8 and 224.0.0.0/4 special and allow for fine grained filtering for sending and receiving, i.e. AllowedIPs but separate between send and receive.
>
> Regards,
> Florian
>
>> I know this has come up a few times before, but if there was resolution,
>> I couldn't find it.
>>
>> I am trying to set up a hub-and-spoke network with many clients
>> connected to a single concentrator. One application I need to support
>> relies on mDNS. Because Wireguard does not allow overlapping ranges (for
>> understandable reasons), this works on point-to-point links with two
>> peers but not on hub-and-spoke or other multi-peer setups. This would be
>> possible if every peer had its own hub interface, but that seems like an
>> inelegant, error-prone workaround.
>>
>> Some have suggested running vxlan or another encapsulation method on top
>> of Wireguard, but that's not possible in this situation because I do not
>> control the software running on the peers. Typically, they'll just be
>> running the official Wireguard apps for MacOS or Windows.
>>
>> Hacking Wireguard to understand the multicast range and to
>> clone-and-forward this traffic to all peers does work. If there is wider
>> interest in that specific feature, I'm happy to work what I have into
>> something that could be upstreamed. Currently the range is global and
>> hard-coded, but I could imagine wanting fine-grained control over which
>> peers were interested in specific multicast addresses, e.g., for a
>> user-space daemon managing IGMP subscriptions. However, before I spent
>> time on any of the above, I wanted to gauge whether there was interest
>> and whether that kind of feature might be accepted at all.
>>
>> Thanks, ~Derrick
>>
>