Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Dan Lüdtke" <mail@danrl.com>
To: nicolas prochazka <prochazka.nicolas@gmail.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: [wireguard-devel] About ip management
Date: Mon, 20 Feb 2017 13:48:54 +0100	[thread overview]
Message-ID: <11EB84FE-DEE6-4E3A-BEB2-FFCE80BA0524@danrl.com> (raw)
In-Reply-To: <CADdae-jNLBGrjwKjfibBtwKennPDESaBe0_hE3vbu5=x_BTmFw@mail.gmail.com>

Hi Nicolas,


> On 17 Feb 2017, at 15:03, nicolas prochazka =
<prochazka.nicolas@gmail.com> wrote:
> I hope not to have misunderstood ip management with wireguard,=20
> in a "server mode operation" , as many peers -> one peer ( server ) ,
> private ip configuration must be coherent.

There is no need for private (assuming you mean RFC1918) addresses, but =
of course it works with private IPs as well as with public IP addresses.


> In fact, as server / client example in contrib, server must delivery =
ip to clients, there's no way for client to know good private_ip .

Unless it is configured statically, which is what I suggest doing. There =
is plenty of IP space to use. Think of ULA or subprefixes of you GU(s). =
A single /64 should be sufficient to address all your clients uniquely =
per "server wg interface". The situation for legacy IP is also not that =
bad. RFC1918 space is huge, and there is also RFC6598 to pick from. Why =
don't just roll out IP configurations the same way you roll out =
WireGuard configuration? It's just a line more in the config when you =
use wg-quick.


> We cannot use dhcp, layer 3 , so ...=20

That's true for legacy IP. It does not hold true for state-of-the-art =
IP.


> we need to implement a pool ip manager , is it correct ?

I do not really know what you are referring to when you write "pool ip =
manager", but if you want to distribute IP configuration data inside the =
wg tunnel, you would need to configure static addresses to bootstrap =
that from. This might change in the future, as Jason said to be working =
in OOB features. IP management would then take place in user space =
mostly/entirely.

Hope that helps!

Cheers,

Dan=

  reply	other threads:[~2017-02-20 12:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-17 14:03 nicolas prochazka
2017-02-20 12:48 ` Dan Lüdtke [this message]
2017-02-21  7:41   ` nicolas prochazka

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=11EB84FE-DEE6-4E3A-BEB2-FFCE80BA0524@danrl.com \
    --to=mail@danrl.com \
    --cc=prochazka.nicolas@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).