Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Ryan Whelan <rcwhelan@gmail.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Babel over wireguard
Date: Wed, 06 Dec 2017 14:11:58 +0100	[thread overview]
Message-ID: <87a7yw0zmp.fsf@toke.dk> (raw)
In-Reply-To: <CAM3m09T_GA3-AdFkZuEf4P5sG0=wNi4FN_79Da6cd4q6un+oDw@mail.gmail.com>

Ryan Whelan <rcwhelan@gmail.com> writes:

> Are there any routing protocol implementations that do not depend on
> multicast?

We are in the process of standardising Babel, and one of the things we
are adding is the ability to run entirely over unicast. So in the
future, Babel will be able to do this (and integration with Wireguard is
one of the things I want to achieve with this). But for now, no
implementation exists.

Other than that, maybe BGP? But you'd still need integration with
Wireguard if you don't want to just set AllowedIPs to ::/0

> In my setup, 2 hosts will be able to route to one another over 2
> different wg interfaces and I just need something to select whichever
> interface has the least latency. Anything like that exist? :D

You can do this with point-to-point wireguard links. I.e., as long as
the wireguard link only has two peers, you can set AllowedIPs to
0.0.0.0/0, ::/0 on both sides, assign manual link-local addresses
(anything in fe80::/64 will work, so you could just assign fe80::1/64 to
one side and fe80::2/64 to the other side; they don't need to be
globally unique either). Then you can run babeld on top, which will
instruct the kernel to send appropriate packets to the wireguard
interface, and wireguard will forward it to the other side.

It's not currently possible to run a routing daemon on a multi-peer
wireguard interface. The routing daemon would need to reconfigure
wireguard in the kernel when it adds routes. I am planning to add this
to Bird at some point, but have not gotten around to it yet...

-Toke

  reply	other threads:[~2017-12-06 13:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-06 12:07 Ryan Whelan
2017-12-06 12:33 ` Toke Høiland-Jørgensen
2017-12-06 12:40   ` Ryan Whelan
2017-12-06 13:11     ` Toke Høiland-Jørgensen [this message]
2017-12-06 13:22       ` Ryan Whelan
2017-12-06 13:37         ` Toke Høiland-Jørgensen
2017-12-06 15:12         ` Lucian Cristian

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=87a7yw0zmp.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=rcwhelan@gmail.com \
    --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).