* Re: [RFC] Multicast and IPv6 Link Local Addresses
2017-04-07 14:02 [RFC] Multicast and IPv6 Link Local Addresses Jason A. Donenfeld
@ 2017-04-07 14:31 ` Jason A. Donenfeld
[not found] ` <03B23E99-75C4-4598-AC0A-3C65F346675F@gmail.com>
2017-04-08 9:39 ` Dan Lüdtke
2017-04-17 14:11 ` Baptiste Jonglez
2 siblings, 1 reply; 10+ messages in thread
From: Jason A. Donenfeld @ 2017-04-07 14:31 UTC (permalink / raw)
To: WireGuard mailing list
Cc: Toke Høiland-Jørgensen, Dave Täht, Juliusz Chroboczek
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Multicast and IPv6 Link Local Addresses
2017-04-07 14:02 [RFC] Multicast and IPv6 Link Local Addresses Jason A. Donenfeld
2017-04-07 14:31 ` Jason A. Donenfeld
@ 2017-04-08 9:39 ` Dan Lüdtke
2017-04-08 17:15 ` Juliusz Chroboczek
2017-04-17 14:11 ` Baptiste Jonglez
2 siblings, 1 reply; 10+ messages in thread
From: Dan Lüdtke @ 2017-04-08 9:39 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Juliusz Chroboczek, Toke Høiland-Jørgensen,
Dave Täht, WireGuard mailing list
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=
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Multicast and IPv6 Link Local Addresses
2017-04-08 9:39 ` Dan Lüdtke
@ 2017-04-08 17:15 ` Juliusz Chroboczek
2017-04-08 19:05 ` Juliusz Chroboczek
0 siblings, 1 reply; 10+ messages in thread
From: Juliusz Chroboczek @ 2017-04-08 17:15 UTC (permalink / raw)
To: Dan Lüdtke
Cc: Toke Høiland-Jørgensen, Dave Täht, WireGuard mailing list
> - 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Multicast and IPv6 Link Local Addresses
2017-04-08 17:15 ` Juliusz Chroboczek
@ 2017-04-08 19:05 ` Juliusz Chroboczek
0 siblings, 0 replies; 10+ messages in thread
From: Juliusz Chroboczek @ 2017-04-08 19:05 UTC (permalink / raw)
To: Dan Lüdtke
Cc: Toke Høiland-Jørgensen, Dave Täht, WireGuard mailing list
>> - 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Multicast and IPv6 Link Local Addresses
2017-04-07 14:02 [RFC] Multicast and IPv6 Link Local Addresses Jason A. Donenfeld
2017-04-07 14:31 ` Jason A. Donenfeld
2017-04-08 9:39 ` Dan Lüdtke
@ 2017-04-17 14:11 ` Baptiste Jonglez
2017-04-17 16:55 ` Toke Høiland-Jørgensen
2 siblings, 1 reply; 10+ messages in thread
From: Baptiste Jonglez @ 2017-04-17 14:11 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Juliusz Chroboczek, Toke Høiland-Jørgensen,
WireGuard mailing list
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC] Multicast and IPv6 Link Local Addresses
2017-04-17 14:11 ` Baptiste Jonglez
@ 2017-04-17 16:55 ` Toke Høiland-Jørgensen
0 siblings, 0 replies; 10+ messages in thread
From: Toke Høiland-Jørgensen @ 2017-04-17 16:55 UTC (permalink / raw)
To: Baptiste Jonglez; +Cc: Juliusz Chroboczek, WireGuard mailing list
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
^ permalink raw reply [flat|nested] 10+ messages in thread