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

Carsten Bormann <> Tue, 05 October 2021 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11C9C3A0912; Tue, 5 Oct 2021 14:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ztSod8kX5Nwr; Tue, 5 Oct 2021 14:42:10 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E5263A09EC; Tue, 5 Oct 2021 14:42:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4HP9yy6nP9z2xfN; Tue, 5 Oct 2021 23:42:02 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Tue, 5 Oct 2021 23:42:02 +0200
Cc: Michael Richardson <>, The IESG <>, "" <>, "" <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <24367.1633460118@localhost> <>
To: "Eric Vyncke (evyncke)" <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Cbor] =?utf-8?q?Supporting_IPv6_Link-Local_with_scope_=28was_Re?= =?utf-8?q?=3A__=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-cbor-network-ad?= =?utf-8?q?dresses-09=3A_=28with_DISCUSS_and_COMMENT=29=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Oct 2021 21:42:16 -0000

On 5. Oct 2021, at 23:14, Eric Vyncke (evyncke) <> wrote:
> Michael
> The problem is indeed solvable.

I think the perception we arrived at when we did explore solving it was that the ifindex/ifname issue was too much in flux to commit to either.
YANG ietf-inet-types can simply ignore that problem because YANG is all textual anyway:


(N is numbers, L is letters, so 03Å and 17 and FARP and 𝔈𝔗ℌ0 are all great zone identifiers — you don’t even get to know whether 17 is an ifname or an ifindex).

> My own take would be not to use ifIndex (for the reasons you just explained) also it could be confusing with another encoding as both (length & ifindex) are uint...

That is more of a secondary concern then — we’d first like to get the information model level data types right.

> As I wrote in my ballot, an alternative (not so nice though) would be to clearly state that the encoding is not applicable to LLA + scope

Tags are cheap enough.
52 and 54 are the CBOR “no-zone” equivalents then, and we can always define tags for potentially zoned addresses once the ifindex/ifname issue converges.

(I do not have a *strong* opinion that this is the right decision, but I think the reasons we arrived where we are, do make sense.)

Grüße, Carsten

> -éric
> On 05/10/2021, 20:55, "Michael Richardson" <> wrote:
>    Captured as issue:
>    Éric Vyncke via Datatracker <> 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 <>   . o O ( IPv6 IøT consulting )
>               Sandelman Software Works Inc, Ottawa and Worldwide