[Cbor] Supporting IPv6 Link-Local with scope (was Re: Éric Vyncke's Discuss on draft-ietf-cbor-network-addresses-09: (with DISCUSS and COMMENT))

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 05 October 2021 18:55 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3765E3A0874; Tue, 5 Oct 2021 11:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 dHwMghw1-358; Tue, 5 Oct 2021 11:55:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27E93A0872; Tue, 5 Oct 2021 11:55:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EF43A180B8; Tue, 5 Oct 2021 15:03:31 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kimBCpDi_QuR; Tue, 5 Oct 2021 15:03:24 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 03F1C18038; Tue, 5 Oct 2021 15:03:24 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2855058B; Tue, 5 Oct 2021 14:55:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: =?utf-8?q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
cc: The IESG <iesg@ietf.org>, d3e3e3@gmail.com, draft-ietf-cbor-network-addresses@ietf.org, barryleiba@computer.org, cbor-chairs@ietf.org, cbor@ietf.org
In-Reply-To: <163344085669.17315.998599560097016034@ietfa.amsl.com>
References: <163344085669.17315.998599560097016034@ietfa.amsl.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 05 Oct 2021 14:55:18 -0400
Message-ID: <24367.1633460118@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/RXuMr_dNigMjBH3_-TGQoauJiE4>
Subject: [Cbor] Supporting IPv6 Link-Local with scope (was Re: Éric Vyncke's Discuss on draft-ietf-cbor-network-addresses-09: (with DISCUSS and COMMENT))
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2021 18:55:36 -0000

Captured as issue:
   https://github.com/cbor-wg/cbor-network-address/issues/12

Éric Vyncke via Datatracker <noreply@ietf.org> wrote:
    > == DISCUSS ==

    > Generic comment how are link-local address (LLA) with scope encoded ? I would
    > expect CBOR to work also on LLA only networks... At the bare minimum, please
    > state that link-local addresses cannot be encoded with their scope, hence, they
    > cannot represent an interface.

    > -- Section 3.1.3 --
    > How can 2 valid link-local addresses (fe80::1%eth0, fe80::1%eth1) can be
    > represented in order to identity two interfaces ?

There are three kinds of things encoded:
      a) addresses.
      b) prefixes
      c) interface definitions

For (b) and (c), we could easily entertain (and did we discuss this in the
thread that was CC'ed to 6man?) adding a third element to the array to store
the interface ID.
For (a), I'm not sure what we can do to add the interface ID, but see below.

That's kinda the easy part.
The hard part is deciding how to encode the scope.
The simplest is as an integer, being the ifindex.

CBOR makes that easy and efficient, and many systems don't have more than 24
interfaces.  However, on systems where interfaces come/go a lot, the ifindex
often increments anyway.  Using the ifindex is probably clearer on most any
system than a string which can change, but it does change from one boot to
another.
While the ifindex is system specific and has no outside meaning, the purposes
where I imagine this being used would be in some system specific container.
(My use case, which drove me to do this, actually probably needed scope-id)

One way to do (a) could be to append to the IPv6 string.
Another way would be not to bother, to always use the interface definition
when a IPv6-LL is needed.  Whether the length is 0, 128, or the actual
interface prefix (probably 64) is something we could specify.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide