From: Baptiste Jonglez <baptiste@bitsofnetworks.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "Juliusz Chroboczek" <jch@irif.fr>,
"Toke Høiland-Jørgensen" <toke@toke.dk>,
"WireGuard mailing list" <wireguard@lists.zx2c4.com>
Subject: Re: [RFC] Multicast and IPv6 Link Local Addresses
Date: Mon, 17 Apr 2017 16:11:07 +0200 [thread overview]
Message-ID: <20170417141107.GA10609@tuxmachine.polynome.dn42> (raw)
In-Reply-To: <CAHmME9poZPFbYhitnK8UvDB-32hLRcTFc4vAwaUPwGEz0wY+Yg@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2017-04-17 14:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 14:02 Jason A. Donenfeld
2017-04-07 14:31 ` Jason A. Donenfeld
[not found] ` <03B23E99-75C4-4598-AC0A-3C65F346675F@gmail.com>
2017-04-07 20:42 ` Jason A. Donenfeld
2017-04-08 12:43 ` Toke Høiland-Jørgensen
2017-04-08 15:44 ` George Walker
2017-04-08 9:39 ` Dan Lüdtke
2017-04-08 17:15 ` Juliusz Chroboczek
2017-04-08 19:05 ` Juliusz Chroboczek
2017-04-17 14:11 ` Baptiste Jonglez [this message]
2017-04-17 16:55 ` Toke Høiland-Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170417141107.GA10609@tuxmachine.polynome.dn42 \
--to=baptiste@bitsofnetworks.org \
--cc=Jason@zx2c4.com \
--cc=jch@irif.fr \
--cc=toke@toke.dk \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).