From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A30B7C433E0 for ; Mon, 29 Jun 2020 11:39:08 +0000 (UTC) Received: from krantz.zx2c4.com (krantz.zx2c4.com [192.95.5.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0987723AA9 for ; Mon, 29 Jun 2020 11:39:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0987723AA9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=romanrm.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=wireguard-bounces@lists.zx2c4.com Received: by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 90167cb6; Mon, 29 Jun 2020 11:19:16 +0000 (UTC) Received: from rin.romanrm.net (rin.romanrm.net [51.158.148.128]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTPS id 500c66ae (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Mon, 29 Jun 2020 11:19:15 +0000 (UTC) Received: from natsu (unknown [IPv6:fd39::e99e:8f1b:cfc9:ccb8]) by rin.romanrm.net (Postfix) with SMTP id 3C4744A4; Mon, 29 Jun 2020 11:38:52 +0000 (UTC) Date: Mon, 29 Jun 2020 16:38:51 +0500 From: Roman Mamedov To: Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= Cc: Reid Rankin , ch@ntrv.dk, WireGuard mailing list Subject: Re: Standardized IPv6 ULA from PublicKey Message-ID: <20200629163851.41d6d755@natsu> In-Reply-To: <87r1tygmlv.fsf@toke.dk> References: <372AE79B-69E5-4B18-926C-E402FDFB2E95@lonnie.abelbeck.com> <20171205035352.01ffe1f5@vega.skynet.aixah.de> <20200624153706.3yngzzslepqh7q54@ws.flokli.de> <875zbai32e.fsf@toke.dk> <20200629153118.4d72f447@natsu> <87r1tygmlv.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.30rc1 Precedence: list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" On Mon, 29 Jun 2020 13:03:40 +0200 Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Eh? This is specified pretty clearly in RFC4291, section 2.1: It also says: ----- 2.5.6. Link-Local IPv6 Unicast Addresses Link-Local addresses are for use on a single link. Link-Local addresses have the following format: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ ----- So should we also follow the designated format for link-locals, or accept t= hat WG's case differs from what they had in mind in those sections. That the "interface" is a special one, with a "link" that doesn't function as other kinds of links do, that there's no "neighbour" per se to contact by an all-neighbour multicast for instance, no mechanism for the "all routers" multicast to work, etc (i.e. all of what the LLs were intended to support). To be clear I'm not against adding LLs, just that "the RFC says so" shouldn= 't be considered the main argument for that when it comes to WG. --=20 With respect, Roman