encoding link ID in link-local addrs (Re: about violation of standards)

神明達哉 <jinmei@wide.ad.jp> Fri, 19 April 2019 16:25 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279EB1201B3 for <ipv6@ietfa.amsl.com>; Fri, 19 Apr 2019 09:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.668
X-Spam-Level:
X-Spam-Status: No, score=-0.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTRimPo-qRj4 for <ipv6@ietfa.amsl.com>; Fri, 19 Apr 2019 09:25:44 -0700 (PDT)
Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2164F12016B for <ipv6@ietf.org>; Fri, 19 Apr 2019 09:25:44 -0700 (PDT)
Received: by mail-wm1-f45.google.com with SMTP id z6so9289756wmi.0 for <ipv6@ietf.org>; Fri, 19 Apr 2019 09:25:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=koGu62LD9yyj2vmgEdpECOyhA9r7/B6lWWMXVsKJ8Nw=; b=SQdsC7uQRnMfKVN3pzQE1YmLZrWCYyXVIPGzDjqmZr7xWTt/5+nCCHNkeBeePeBHvB jJpSLaAE1Cn+drT5VzxyTRACWAEz2Ini3hWmk6K1fRyfVPUyNPZWz/f+13nZ0J9o3H+s zWgIvXDoinqXO29TGKAzT8zcdvAkPsffM8ftaoWCq+fjBOtR5YRUisS2/0tXrYOFs4zf ekKvZVobOLTciISBzYHhQcdnnW4w0CQePKDKvcSJeXOO9GBQT78BEG1wv01db/OPhEP5 TF35jPmjcheTK2gC8wXpolPMpdGhq9gdIj4L9jYi+fyBwNJFcDQFJxdM52ISoi42YPWX eWHg==
X-Gm-Message-State: APjAAAXpgmmkf865I/turwCWJTca5IKM3xZsQsXvLsVZxwv4EcGZE31q FrQRrIzU2YTIkp4Q5lwFImWAE7WUt83iT96tbKU=
X-Google-Smtp-Source: APXvYqxF3eEwFfWhdfiRsWT4gkqhrDKlzGwaTsG8I4Ua9jkW8XThKt+NYlhoqgjtXp0Ch/bRcO6NubQ/MVi34wFTLoc=
X-Received: by 2002:a7b:cb58:: with SMTP id v24mr3039959wmj.121.1555691142229; Fri, 19 Apr 2019 09:25:42 -0700 (PDT)
MIME-Version: 1.0
References: <bb7f7606-2adf-e669-8bcd-e41f17800782@gmail.com> <CAJE_bqd9frqX5-yeVPj8MYXpZ4737HqK1gmfD9cQV3A-Ea5HrQ@mail.gmail.com> <6bd5db47-408a-727e-5c13-f34a3465f986@si6networks.com> <CAJE_bqfTLqRbLp4fLu2ASZuZ+4G5c2G+RXkO92kXfLgPTqBnng@mail.gmail.com> <EEF00EA7-2AAF-403F-99AD-1D53ED18E8B3@cisco.com>
In-Reply-To: <EEF00EA7-2AAF-403F-99AD-1D53ED18E8B3@cisco.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Fri, 19 Apr 2019 09:25:31 -0700
Message-ID: <CAJE_bqe8OXPWRDvXEY66gZHiBgv37OV67YB27WoEtq_VmBqieQ@mail.gmail.com>
Subject: encoding link ID in link-local addrs (Re: about violation of standards)
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: IPv6 <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e9b3490586e4911a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/nRuLvdZptV2aR3TTzvh0WCKo7fQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2019 16:25:46 -0000

At Fri, 19 Apr 2019 07:00:01 +0000,
"Pascal Thubert (pthubert)" <pthubert@cisco.com> wrote:

> While I completely object with Alexandre’s argument I tend to agree with
the end goal.
>
> Some functions in the router are complex to implement because same value
for a link local address appears on multiple interfaces.

Yeah, I see that motivation.  The generic/usual answer of mine to that
kind of problem is to use the sockaddr_in6::sin6_scope_id (or anything
similar to it for a non-POSIX platform) and the extended textual
format for scoped addresses as described in RFC4007.  But I can
imagine there are cases where they are not enough and/or applicable.

So...

> It would be useful to be able to encode an abstract interface ID
somewhere in the /64. Legacy 00 would mean unspecified...

(As a co-author of RFC4007 I can't help correcting it to "link ID"
instead of "interface ID" but:-)... yes, I can imagine we might reach
some consensus of using some portion of the 128-bit space to encode
that information.  But, that will require a lot of considerations,
including

- whether the goal is really impossible to achieve with currently
  available tools
- especially if the first answer is something like "it can, but it's
  not convenient", then whether the goal really justifies to consume
  a particular space of the finite resource of address space
- whether it has to be inside the upper 64 bits (or in more general,
  inside the "subnet prefix" part).  If it has to be so, whether it
  has to be within the first 32 bits (if not, at least it doesn't
  conflict with the BSD implementation).
- if, like draft-petrescu-6man-ll-prefix-len suggests, the encoded ID
  is the same for all nodes in the link, how we assign those IDs and
  how we ensure their uniqueness, how each node knows the ID on
  generating addresses, etc.

When I said "I'm open to discussion", I meant I'm willing to discuss
these matters.  Of course, since there are so many open questions, I'd
expect it to take quite a long time, and I can't say at this point
whether I support the eventual proposal that the WG might come up
with, or whether we can really expect any WG-wide consensus.  I'm now
clarifying the intent, as it didn't seem to be clear enough.

--
JINMEI, Tatuya