wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Roman Mamedov <rm@romanrm.net>
Cc: Reid Rankin <reidrankin@gmail.com>,
	ch@ntrv.dk, WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Standardized IPv6 ULA from PublicKey
Date: Mon, 29 Jun 2020 13:03:40 +0200	[thread overview]
Message-ID: <87r1tygmlv.fsf@toke.dk> (raw)
In-Reply-To: <20200629153118.4d72f447@natsu>

Roman Mamedov <rm@romanrm.net> writes:

> On Mon, 29 Jun 2020 12:22:49 +0200
> Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>> Reid Rankin <reidrankin@gmail.com> writes:
>> 
>> > Each IPv6 network device is *required* to have a link-local
>> > address by the RFC
>> 
>> Given this
>
> What you quoted is the shakiest statement of the entire proposal. Might be a
> cool idea and all, but I don't think RFCs say anything about "requiring" that
> for point-to-point L3 interfaces, where there's no functioning multicast or
> broadcast to begin with. And it doesn't seem nice that submitter is trying to
> skew facts in their favor like that.

Eh? This is specified pretty clearly in RFC4291, section 2.1:

2.1.  Addressing Model

   IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node.

   All interfaces are required to have at least one Link-Local unicast
   address (see Section 2.8 for additional required addresses).  A
   single interface may also have multiple IPv6 addresses of any type
   (unicast, anycast, and multicast) or scope.  Unicast addresses with a
   scope greater than link-scope are not needed for interfaces that are
   not used as the origin or destination of any IPv6 packets to or from
   non-neighbors.  This is sometimes convenient for point-to-point
   interfaces.  There is one exception to this addressing model:

      A unicast address or a set of unicast addresses may be assigned to
      multiple physical interfaces if the implementation treats the
      multiple physical interfaces as one interface when presenting it
      to the internet layer.  This is useful for load-sharing over
      multiple physical interfaces.

   Currently, IPv6 continues the IPv4 model in that a subnet prefix is
   associated with one link.  Multiple subnet prefixes may be assigned
   to the same link.


The fact that Wireguard doesn't assign one is often a source of
annoyance, and since there already is a unique identifier for each peer
on a link (the public key), I really don't see why wg shouldn't just
assign a LL identifier and be done with it. Sure, have a config knob to
turn it off if you're not using IPv6, but let's make this the default
and have wg devices 'just work' over IPv6 by default.

-Toke

  parent reply	other threads:[~2020-06-29 11:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 16:52 Standardized IPv6 ULA from PublicKey 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
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 [this message]
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=87r1tygmlv.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=ch@ntrv.dk \
    --cc=reidrankin@gmail.com \
    --cc=rm@romanrm.net \
    --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).