I looked at this a while back. As far as I could tell, there's nothing fundamental about the protocol or the security model that prevents it from happening; conceptually, it's as simple as overlapping AllowedIP ranges. This is easy for incoming traffic, but outgoing traffic is more difficult; each outgoing packet would need to be duplicated and encrypted separately for each target peer. What's more, each of these duplicate unicast packets would have to be queued separately because each peer may be in a different handshake state.
None of this makes multicast over WireGuard impossible, however, just difficult to fit into the existing implementation. I've toyed with the idea of a one-interface-per-peer setup with bridging or some fancy netfilter stuff to handle duplication and dispatch between them, but it seems like it would be a PITA so I've never taken it farther. As far as "special" multicast ranges, heck no. One of the fundamental assurances of WG is that you'll only ever receive packets from a peer which have a source address listed in that peer's AllowedIPs. If you want to put ff00::/8 and 224.0.0.0/4 in a peer's AllowedIPs, by all means, but I'm strongly against WG itself having any special notion of what a "multicast address" is or any special handling -- or sneaky emergent properties -- for them. DHCPv6, for example, requires only ff02::1:2; if that's what you want, I probably wouldn't whitelist a whole /8 to get it. YMMV, of course, but that should be the user's choice and responsibility. Another reason not to treat certain address ranges specially is that there's more use cases for what would effectively be a "link-layer" multicast than there are for IP multicast. You could have something like port mirroring going on; say you've got a gateway with ::/0 as well as an IDS with the same range. Both could receive the same traffic, which could be useful in some applications. Obviously, you'd need to realize the security implications -- both client-side (sending copies of all your traffic) and IDS-side (trusting that you'll really be sent copies of all the traffic) -- but flexibility is good, and I can imagine some usecases (especially embedded systems) where that would be a desirable property. (Sure beats sending the traffic in the clear and having the IDS -- and whoever's hacked your switch -- get it that way.) --Reid On Mon, Sep 21, 2020 at 7:27 AM Jason A. Donenfeld <[email protected]> wrote: > > We've discussed this extensively and repeatedly. I made a few > proposals a few years ago that we discussed. It doesn't fit into > WireGuard's strong binding model. > > Jason
