Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Florian Klink <flokli@flokli.de>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Luis Ressel <aranea@aixah.de>,
	WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Standardized IPv6 ULA from PublicKey
Date: Wed, 24 Jun 2020 17:37:06 +0200	[thread overview]
Message-ID: <20200624153706.3yngzzslepqh7q54@ws.flokli.de> (raw)
In-Reply-To: <CAHmME9ouUNV4pc7qwr4bO-5bEecFc1U64PF13ExgmYnH9q45tw@mail.gmail.com>

Hey,

>> Has anyone thought about a standardized WireGuard IPv6 ULA generated
>> from the PublicKey ?
>
>This was indeed already discussed, albeit not for ULAs, but link-local
>addresses (fe80::/64). IIRC, Jason rejected it citing the KISS
>principle -- and I fully agree with that. Adding a hundred small
>features useful for certain corner cases is a sure way to transform
>wireguard into a behemoth of ipsec/openvpn dimensions. :)
>
>https://lists.zx2c4.com/pipermail/wireguard/2017-April/001177.html

Was this really a rejection?

I'd like to join the "poking and prodding about supporting IPv6 Link
Local addresses".

Deriving a IPv6 link-local address from the pubkey and adding it to the
interface should be a no-brainer and sane default, and already fix Babel
Routing (and most other issues) for "point-to-point tunnels"
(only one peer, both sides set AllowedIPs=::/0).

Quoting the proposal from the linked email:
> # 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.

Of course, generating these addresses could be implemented into
downstream tooling, but I'd rather see this defined in wireguard itself.
Then we'd not have multiple implementations possibly using different
hashes.

A standardized hashing, adding fe80::hash(interfacepubkey)/64 and
AllowedIPs=fe80::hash(peerpubkey)/128 for each peer would also allow
bring instant IPv6 connectivity between peers - which I find quite
appealing.

I'd propose handling the multicast replication ideas as well as the
ULA address generation as a followup, or the business of higher-level
tooling.

Regards,
Florian

  reply	other threads:[~2020-06-24 15:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 16:52 Lonnie Abelbeck
2017-12-04 17:14 ` Aaron Jones
2017-12-05  2:53 ` Luis Ressel
2017-12-05  3:31   ` Jason A. Donenfeld
2020-06-24 15:37     ` Florian Klink [this message]
2020-06-24 17:08       ` Chriztoffer Hansen
2020-06-24 17:30         ` JuniorJPDJ
2020-06-27 21:43         ` Reid Rankin
2020-06-28 10:15           ` Arti Zirk
2020-06-28 15:19             ` Derrick Lyndon Pallas
2020-06-29 10:22           ` Toke Høiland-Jørgensen
2020-06-29 10:31             ` Roman Mamedov
2020-06-29 10:52               ` Justin Kilpatrick
2020-06-29 11:03               ` Toke Høiland-Jørgensen
2020-06-29 11:38                 ` Roman Mamedov
2020-06-29 12:15                   ` Toke Høiland-Jørgensen
2020-06-29 17:01                     ` Arti Zirk
2020-06-29 18:01                       ` Jason A. Donenfeld
2020-06-29 19:58                         ` Reid Rankin
2020-06-30  1:24                           ` Jason A. Donenfeld
2020-06-30  8:01                             ` Reid Rankin
2020-06-29 18:49                     ` Luiz Angelo Daros de Luca

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=20200624153706.3yngzzslepqh7q54@ws.flokli.de \
    --to=flokli@flokli.de \
    --cc=Jason@zx2c4.com \
    --cc=aranea@aixah.de \
    --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).