All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arti Zirk <arti.zirk@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>,
	"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 20:01:51 +0300	[thread overview]
Message-ID: <910f09eb8b67bef5cc55114fe1b0bd6297ea2ec4.camel@gmail.com> (raw)
In-Reply-To: <87lfk6gjax.fsf@toke.dk>

On E, 2020-06-29 at 14:15 +0200, Toke Høiland-Jørgensen wrote:
> In general I'd say that deviating from the RFC needs a good reason.
> Expanding the number of bits we can use for the identifier may be a
> good reason to expand the LL interface ID width (although I'm not
> actually too worried about collisions even if we only use 64 bits).

Few more counter arguments against expanding identifier length:

1. There is a rejected errata 4406 that wants to do this
https://www.rfc-editor.org/errata/eid4406

2. FreeBSD and probably other *BSD/macOS use those unused 56 bits to
store the link scope_id. And support nonstandard fe80:1::30/64 notation
instead of fe80::30%1/64 to specify the scope.
https://stackoverflow.com/a/5891805/2303328
https://github.com/freebsd/freebsd/blob/76f9308e3e2b80e95630efcdd994f3c133806bf4/share/doc/IPv6/IMPLEMENTATION#L427
https://github.com/freebsd/freebsd/blob/e9a39e0c3c22543812afd4de74d1d0ad6782100b/sys/netinet6/scope6.c#L363


  reply	other threads:[~2020-06-29 17:02 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
2020-06-29 11:38                 ` Roman Mamedov
2020-06-29 12:15                   ` Toke Høiland-Jørgensen
2020-06-29 17:01                     ` Arti Zirk [this message]
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=910f09eb8b67bef5cc55114fe1b0bd6297ea2ec4.camel@gmail.com \
    --to=arti.zirk@gmail.com \
    --cc=ch@ntrv.dk \
    --cc=reidrankin@gmail.com \
    --cc=rm@romanrm.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.