[RFC] Multicast and IPv6 Link Local Addresses

[RFC] Multicast and IPv6 Link Local Addresses

[Jason A. Donenfeld]

Hey list,

Various networking people have been poking and prodding about
supporting IPv6 Link Local addresses and about supporting special
multicast addresses. *I MAY VERY WELL NEVER CHOOSE TO IMPLEMENT THIS*
but in case I do, I wanted to start spec'ing out what this might look
like in order to think about it better. There are a lot of odd
concerns to take into account, so I doubt that the below will wind up
as a final solution.

For these two options below, I introduce them with corresponding
configuration nobs. Since I don't really like adding nobs, it's
entirely likely that on the small chance I do wind up implementing
this, it would be without the nobs and just always on.


== Multicast ==

# wg set wg0 multicast on

When multicast mode is turned on, packets sent to the special address
ranges 224.0.0.0/24 or fe02::/16 are sent to every peer on that
interface.


== IPv6 Link Local Addresses ==

# wg set wg0 llv6 on

This command fails and returns -ENOTUNIQ if two existing peers have
the same value of hash(pubkey). When this command succeeds:, the wg0
interface receives an automatically assigned IP address of
fe80::hash(interfacepubkey)/64. Every peer has
fe80::hash(peerpubkey)/128 implicitly added to their allowed-ips. When
adding a new peer, if hash(pubkey) is the same value of an existing
peer, the command fails and returns -ENOTUNIQ.


I'm open to thoughts and suggestions about the above ideas.

Thanks,
Jason

Re: [RFC] Multicast and IPv6 Link Local Addresses

[Jason A. Donenfeld]

Hey George,

On Fri, Apr 7, 2017 at 4:13 PM, George Walker <georgewalkeriv@gmail.com> wrote:
> I'm far from an IP muticast expert, but it would seem more consistent with
> the existing cryptokey routing paradigm if the packets addressed to the
> multicast range went to every peer on that interface which had the multicast
> address addressed among its "allowedIPs."  Then, the only difference between
> configuring multicast and unicast is how many peers may have the same
> allowedIP.

Thanks for this feedback. Indeed this is the initial design I had
thought about and discussed quite a bit. In the name of "simplicity" I
had been nudged back toward the easier special case semantics. I
suppose it's still up in the air.

== Peers Sharing Multiple AllowedIPs Entries ==
Pros:
- Highly configurable.
- More clear what's happening.
Cons:
- Right now there is a strict one-entry-one-peer enforcement, to
maintain the one to one. This has the nice property that if you try to
add the same allowed-ips to the same peer, by accident, the allowed-ip
simply _moves_. I rather like this behavior. Thus, there'd have to be
some explicit way of telling it, "yes I really do want this to be
duplicated, not moved". Perhaps a "multi:" prefix? I don't know, but
it's uglier UI stuff to grok.

== Special Cased Broadcast/Multicast Addresses ==
Pros:
- Simple on and off switch.
Cons:
- A bit too magical.
- Seems to break paradigm.

Hm.

Jason

Re: [RFC] Multicast and IPv6 Link Local Addresses

[Jason A. Donenfeld]

Hey George,

More excellent feedback, thanks. Be sure to CC the list next time though.

If I understand correctly, your suggestion is to not clutter
everything with a horrible "multi:" prefix, but instead allow
multicast addressees, which are well defined, to be added to multiple
peers, and only allow unicast addresses to be added to one peer at a
time keeping the current behavior. I find that a very nice UI
solution. Wonderful.

Jason

On Fri, Apr 7, 2017 at 6:02 PM, George Walker <georgewalkeriv@gmail.com> wrote:
> Cons:
> - A bit too magical.
> - Seems to break paradigm.
>
>
> Another is scalability --the computational and network overhead associated
> with making every peer irrevocably a member of every multicast group.
> Sending all multicast messages to all peers eliminates much of the benefit
> of having more than one multicast address.  That could mean a lot of
> unnecessary handshakes!  I can imagine applications for which this behavior
> would make (accidental or malicious) DoS very easy.
>
> If you only have a lab-scale deployment and generous bandwidth, of course
> receive-side filtering is fine.  But Wireguard's performance and general
> utility would suggest that some will want big far-flung networks that may
> well have need for lots of multicast groups (e.g. industrial IoT), while not
> being able to afford to broadcast everything to everyone.
>
> Thus, there'd have to be
> some explicit way of telling it, "yes I really do want this to be
> duplicated, not moved". Perhaps a "multi:" prefix?
>
>
> I respectfully disagree concerning the necessity to add special, ugly,
> inconsistent UI for the multicast-as-multicast (instead of
> multicast-as-broadcast) approach.  Multicast address ranges are well-known,
> specified in RFCs.  That they behave a little bit differently from unicast
> addresses is expected behavior.  Most of us ignore them and don't use those
> ranges most or all of the time, which works fine.  Thus Multicast support
> (e.g. in routers) doesn't generally interfere with the actual vs. expected
> behavior of the unicast traffic most people use most of the time.
>
> Anyone who is diddling with networking at this level already knows how to
> avoid multicast IPs when they intend unicast (whether they know they do or
> not).
>
> It doesn't seem problematic for a layer 3 VPN to treat adding a unicast
> address when such an address is already an allowedIP as different from
> adding a multicast address (moving in the first case, adding in the second).
> It sounds to me like doing the right (intuitive) thing in each case.

Re: [RFC] Multicast and IPv6 Link Local Addresses

[Dan Lüdtke]

Hi everyone,

I am very excited that we have this discussion, as I am one of those =
IPv6-first/IPv6-only guys who like poking the topic.
I try to keep it short:

- Scalability: I agree with what George said. Broadcast does not scale =
nicely, and IPv6 multicast is intended to help scaling things by =
reaching exactly the node that need to get a copy of a particular =
packet. Downgrading IPv6 multicast to broadcast hurts scalability and I =
for one, would rather not see multicast in WireGuard if it does not =
scale. I am afraid it would be counterproductive to the goal of having a =
widely accepted and used protocol.

- Multicast is not the everyday use case, so if multicast requires an =
extra knob or an extra option, that would be fine I guess. I am in favor =
of intentionally enabling multicast. I am still wrapping my head around =
static vs. dynamic (read: magic) configuration of multicast addresses =
and groups. Will let you know once I end up with something worth =
sharing. In the meantime, I think "solicited node multicast =
addresses/groups" are the one thing that comes with the least amount of =
trouble. Especially if IPv6 LL addressing is also there.

- IPv6 link-local addressing: For me it is a perfect example for "the =
right amount of magic". It would make (at least my) life so much easier. =
Filling the neighbor cache would require WireGuard to provide (simulated =
or real) solicited node multicast addresses routing, right? Or is it =
feasible to fill the neighbor cache based on the peer configuration? The =
last thing sounds wrong to me.

So much for my first thoughts.

Cheers,

Dan=

Re: [RFC] Multicast and IPv6 Link Local Addresses

[Toke Høiland-Jørgensen]

"Jason A. Donenfeld" <Jason@zx2c4.com> writes:

> Hey George,
>
> More excellent feedback, thanks. Be sure to CC the list next time though.
>
> If I understand correctly, your suggestion is to not clutter
> everything with a horrible "multi:" prefix, but instead allow
> multicast addressees, which are well defined, to be added to multiple
> peers, and only allow unicast addresses to be added to one peer at a
> time keeping the current behavior. I find that a very nice UI
> solution. Wonderful.

I'd be fine with this, as long as it's on the subnet level (which I
believe is the case, just making sure). I.e., if I want behaviour
corresponding to full link-local multicast, I can just add fe02::/16 to
every peer in my config and be done with it.

-Toke

Re: [RFC] Multicast and IPv6 Link Local Addresses

[George Walker]

[-- Attachment #1: Type: text/plain, Size: 3046 bytes --]

> If I understand correctly

You do.

> I find that a very nice UI
> solution. Wonderful.

Thanks!  Thinking about it definitely got me excited about what I could do with a secure multicast-capable network overlay...

Sent from my iPhone

> On Apr 7, 2017, at 4:42 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> 
> Hey George,
> 
> More excellent feedback, thanks. Be sure to CC the list next time though.
> 
> If I understand correctly, your suggestion is to not clutter
> everything with a horrible "multi:" prefix, but instead allow
> multicast addressees, which are well defined, to be added to multiple
> peers, and only allow unicast addresses to be added to one peer at a
> time keeping the current behavior. I find that a very nice UI
> solution. Wonderful.
> 
> Jason
> 
>> On Fri, Apr 7, 2017 at 6:02 PM, George Walker <georgewalkeriv@gmail.com> wrote:
>> Cons:
>> - A bit too magical.
>> - Seems to break paradigm.
>> 
>> 
>> Another is scalability --the computational and network overhead associated
>> with making every peer irrevocably a member of every multicast group.
>> Sending all multicast messages to all peers eliminates much of the benefit
>> of having more than one multicast address.  That could mean a lot of
>> unnecessary handshakes!  I can imagine applications for which this behavior
>> would make (accidental or malicious) DoS very easy.
>> 
>> If you only have a lab-scale deployment and generous bandwidth, of course
>> receive-side filtering is fine.  But Wireguard's performance and general
>> utility would suggest that some will want big far-flung networks that may
>> well have need for lots of multicast groups (e.g. industrial IoT), while not
>> being able to afford to broadcast everything to everyone.
>> 
>> Thus, there'd have to be
>> some explicit way of telling it, "yes I really do want this to be
>> duplicated, not moved". Perhaps a "multi:" prefix?
>> 
>> 
>> I respectfully disagree concerning the necessity to add special, ugly,
>> inconsistent UI for the multicast-as-multicast (instead of
>> multicast-as-broadcast) approach.  Multicast address ranges are well-known,
>> specified in RFCs.  That they behave a little bit differently from unicast
>> addresses is expected behavior.  Most of us ignore them and don't use those
>> ranges most or all of the time, which works fine.  Thus Multicast support
>> (e.g. in routers) doesn't generally interfere with the actual vs. expected
>> behavior of the unicast traffic most people use most of the time.
>> 
>> Anyone who is diddling with networking at this level already knows how to
>> avoid multicast IPs when they intend unicast (whether they know they do or
>> not).
>> 
>> It doesn't seem problematic for a layer 3 VPN to treat adding a unicast
>> address when such an address is already an allowedIP as different from
>> adding a multicast address (moving in the first case, adding in the second).
>> It sounds to me like doing the right (intuitive) thing in each case.

[-- Attachment #2: Type: text/html, Size: 5938 bytes --]

Re: [RFC] Multicast and IPv6 Link Local Addresses

[Juliusz Chroboczek]

> - Scalability: I agree with what George said. Broadcast does not scale
>   nicely, and IPv6 multicast is intended to help scaling things by
>   reaching exactly the node that need to get a copy of a particular
>   packet.

Not necessarily.  IPv6 link-local multicast replaces IPv4 link-local
broadcast.  Implementing link-local multicast as broadcast, while
suboptimal, is good enough to get IPv6 to work.

> - Multicast is not the everyday use case,

That's IPv4 thinking.  In IPv6, multicast is a basic, compulsory part of
the protocol.  A number of very basic IPv6 protocols fail to work if
link-local multicast is not functional.

See the IPv6 over NMBA (MARS, not LANE) specification for the kind of
horrors that are required to work around link layers that don't support
multicast.

> - IPv6 link-local addressing: For me it is a perfect example for "the
>   right amount of magic". It would make (at least my) life so much
>   easier. Filling the neighbor cache would require WireGuard to provide
>   (simulated or real) solicited node multicast addresses routing, right?

Yes, IPv6 neighbour discovery is one of those protocols that rely on
link-local multicast.

-- Juliusz

Re: [RFC] Multicast and IPv6 Link Local Addresses

[Juliusz Chroboczek]

>> - IPv6 link-local addressing: For me it is a perfect example for "the
>> right amount of magic". It would make (at least my) life so much
>> easier. Filling the neighbor cache would require WireGuard to provide
>> (simulated or real) solicited node multicast addresses routing, right?

> Yes, IPv6 neighbour discovery is one of those protocols that rely on
> link-local multicast.

I just realised this contradicts my mail dated 7 April to Jason.  ND is
not strictly necessary here, since there are no link-layer addresses.

-- Juliusz

Re: [RFC] Multicast and IPv6 Link Local Addresses

[Baptiste Jonglez]

[-- Attachment #1: Type: text/plain, Size: 3177 bytes --]

Hi Jason,

On Fri, Apr 07, 2017 at 04:02:49PM +0200, Jason A. Donenfeld wrote:
> Various networking people have been poking and prodding about
> supporting IPv6 Link Local addresses and about supporting special
> multicast addresses. *I MAY VERY WELL NEVER CHOOSE TO IMPLEMENT THIS*
> but in case I do, I wanted to start spec'ing out what this might look
> like in order to think about it better. There are a lot of odd
> concerns to take into account, so I doubt that the below will wind up
> as a final solution.

This is good news!  I can't wait to see Babel running on a wireguard
interface with several peers, or even what OSPF would look like on such a
network.

That being said, for the purpose of a routing protocol like Babel, I think
it still makes more sense to use only *point-to-point* wireguard links.
Link-local and multicast communication solves the problem of discovering
remote routing daemon, but the AllowedIPs list is still static, which does
not make sense for a routing protocol.  With point-to-point links, you can
bypass this limitation by simply setting AllowedIPs to ::/0.  Of course,
once we have dynamic AllowedIPs, this will change :)

Regarding the current consensus about link-local and multicast:

1) link-local:

> This command fails and returns -ENOTUNIQ if two existing peers have
> the same value of hash(pubkey). When this command succeeds:, the wg0
> interface receives an automatically assigned IP address of
> fe80::hash(interfacepubkey)/64. Every peer has
> fe80::hash(peerpubkey)/128 implicitly added to their allowed-ips. When
> adding a new peer, if hash(pubkey) is the same value of an existing
> peer, the command fails and returns -ENOTUNIQ.

This looks like a very good idea, and I think it should be enabled by
default.  What would be the cost of doing this, except for the risk of
collision?  If I'm not mistaken, you would have a high chance of collision
starting with around 2**32 peers (see [1]).

2) multicast:

I agree that George's solution (no implicit multicast AllowedIPs, and
AllowedIPs in a multicast range have a "cloning" semantic instead of the
usual "moving" semantic) is clean.

There is just the minor issue of subnets that encompass both unicast and
multicast addresses, the simplest one being ::/0.  Such subnets could be
automatically split by wireguard, or just have the "moving" semantic of
unicast subnets.  With this last option, a user would have to explicitly
add a subnet which is *within* a multicast prefix to trigger the "cloning"
semantic.

Another idea could be to add ff02::1/128 (the all-nodes multicast address)
by default to every peer.  This would allow to nicely discover the
link-local address and RTT of neighbouring peers by simply running:

  $ ping -6 -L -I wg0 ff02::1
  PING ff02::1(ff02::1) from fe80::XXX%wg0 wg0: 56 data bytes
  64 bytes from fe80::YYY%wg0: icmp_seq=1 ttl=64 time=0.459 ms
  64 bytes from fe80::ZZZ%wg0: icmp_seq=1 ttl=64 time=0.692 ms (DUP!)

However, it would be another special case in Wireguard, and some people
might want to disable this behaviour if it's enabled by default.

Baptiste

[1] https://en.wikipedia.org/wiki/Birthday_problem#Probability_table

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC] Multicast and IPv6 Link Local Addresses

[Toke Høiland-Jørgensen]

Baptiste Jonglez <baptiste@bitsofnetworks.org> writes:

> Hi Jason,
>
> On Fri, Apr 07, 2017 at 04:02:49PM +0200, Jason A. Donenfeld wrote:
>> Various networking people have been poking and prodding about
>> supporting IPv6 Link Local addresses and about supporting special
>> multicast addresses. *I MAY VERY WELL NEVER CHOOSE TO IMPLEMENT THIS*
>> but in case I do, I wanted to start spec'ing out what this might look
>> like in order to think about it better. There are a lot of odd
>> concerns to take into account, so I doubt that the below will wind up
>> as a final solution.
>
> This is good news!  I can't wait to see Babel running on a wireguard
> interface with several peers, or even what OSPF would look like on such a
> network.
>
> That being said, for the purpose of a routing protocol like Babel, I think
> it still makes more sense to use only *point-to-point* wireguard links.
> Link-local and multicast communication solves the problem of discovering
> remote routing daemon, but the AllowedIPs list is still static, which does
> not make sense for a routing protocol.  With point-to-point links, you can
> bypass this limitation by simply setting AllowedIPs to ::/0.  Of course,
> once we have dynamic AllowedIPs, this will change :)

Yeah, for the use case I'm envisioning, I would teach the routing daemon
to update wireguard's route tables...

> There is just the minor issue of subnets that encompass both unicast and
> multicast addresses, the simplest one being ::/0.  Such subnets could be
> automatically split by wireguard, or just have the "moving" semantic of
> unicast subnets.  With this last option, a user would have to explicitly
> add a subnet which is *within* a multicast prefix to trigger the "cloning"
> semantic.

I agree that the least confusing would be to only treat prefixes
entirely contained in the known multicast prefixes as having "cloning"
semantics.

-Toke