Subject: [core] Interface names (Re: [Cbor] changes in draft-ietf-cbor-network-addresses-05.txt)

From: Carsten Bormann <[email-masked]>
Date: Sun, 25 Jul 2021 01:13:01 +0200

> On 2021-07-25, at 00:42, Erik Kline <[email-masked]> wrote:
> 
> Michael,
> 
> Thanks for the update.
> 
> Was there any interest in figuring out a representation for link-local addresses (e.g. 169.254.x.y, fe80::zed, ff02::pqr, ...) that included either an interface name or index as part of a structured unit?  Perhaps some generic {address_info, interface_info} pairing that could be used the same way?

Interesting.  We just discussed this in the design team for draft-ietf-core-href, which is maybe the more likely case where an IP address is paired with an interface name.  This can be added, but we didn’t quite see such a strong use case.  Interface names are local, so it doesn’t make a lot of sense to carry them around between systems, which is where CBOR is mostly used these days.

> Obviously, it's possible to pair what you've described here together with extra interface information separately on an ad hoc basis.

Yes, but somehow, this question has come up often enough now that I’ll add a design to draft-ietf-core-href-06.  We can always delete that feature again later.

Grüße, Carsten

> 
> Curious,
> -ek
> 
> On Mon, Jul 12, 2021 at 4:41 AM Michael Richardson <[email-masked]> wrote:
> 
> [email-masked] wrote:
>     >         Title : CBOR tags for IPv4 and IPv6 addresses and prefixes
>     > Authors : Michael Richardson Carsten Bormann
>     > draft-ietf-cbor-network-addresses-05.txt Pages : 8 Date : 2021-07-12
> 
>     > Abstract: This document describes two CBOR Tags to be used with IPv4
>     > and IPv6 addresses and prefixes.
> 
>     > The IETF datatracker status page for this draft is:
>     > https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/
> 
>     > There is also an HTML version available at:
>     > https://www.ietf.org/archive/id/draft-ietf-cbor-network-addresses-05.html
> 
>     > A diff from the previous version is available at:
>     > https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-network-addresses-05
> 
> The major differences since -04 is that we now have three forms:
> 
> 1) IPv4 or IPv6 address.
> 2) IPv4-prefix/len or IPv6-prefix/len
> new: 3) IPv4-addr/len or IPv6-addr/len
> 
> The difference between (2) and (3) is that (2) is just the prefix, and the
> bits to the right MUST be zero, and MAY be omitted. (A bit win for IPv6/32 or
> Ipv6/48s..).
> In the case of (3), this is more of an interface definition, like:
>    2001:db8::1234/64  the "::1234" is to the right of the /64.
>    192.0.1.4/24     ".4" is to the right of the /24, and is the interface definition.
> 
> Cases (2) and (3) are distinguished by order of data vs prefix.
> (2) is:   [64, h'20010db8']
> (3) is:   [h'20010db8_00000000_00000000_00001234', 64]
> We can do this in CBOR, because it is self-describing.
> Note that (2) is much shorter than (3), because trailing zeroes are omitted.
> (3) is always 18 or 19 bytes long. (1 byte for CBOR array prefix)
> 
> Prefix longer than 24 require two bytes to encode the integer.
> (I guess we could have made the prefixlen be length-24, and then up to /48
> would fit into a single byte integer.  We could also have made the negative
> integers represent multiples of -4 perhaps)
> 
> I don't personally have a use case today for (3), but there were not many
> objections to including it.
> 
> --
> Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Erik Kline <[email-masked]>
Date: Sat, 24 Jul 2021 16:36:24 -0700

Ah, your point about interchange between systems seems important.
Following YAGNI
<https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it>, maybe
this is not necessary until there's a use case for something within a node
(some CBOR-encoded communication among processes on the same box, perhaps).

If it keeps coming up though, maybe it's just worth a sentence to say why
it's left for some other time/document (confession: I haven't read -05).

Thanks though!

On Sat, Jul 24, 2021 at 4:13 PM Carsten Bormann <[email-masked]> wrote:

> > Was there any interest in figuring out a representation for link-local
> addresses (e.g. 169.254.x.y, fe80::zed, ff02::pqr, ...) that included
> either an interface name or index as part of a structured unit?  Perhaps
> some generic {address_info, interface_info} pairing that could be used the
> same way?
>
> Interesting.  We just discussed this in the design team for
> draft-ietf-core-href, which is maybe the more likely case where an IP
> address is paired with an interface name.  This can be added, but we didn’t
> quite see such a strong use case.  Interface names are local, so it doesn’t
> make a lot of sense to carry them around between systems, which is where
> CBOR is mostly used these days.
>
> > Obviously, it's possible to pair what you've described here together
> with extra interface information separately on an ad hoc basis.
>
> Yes, but somehow, this question has come up often enough now that I’ll add
> a design to draft-ietf-core-href-06.  We can always delete that feature
> again later.
>
> Grüße, Carsten
>
>
> >
> > Curious,
> > -ek
> >

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 27 Jul 2021 11:55:05 +0200

Hello Carsten, groups,

> Interface names are local, so it doesn’t make a lot of sense to carry
> them around between systems, which is where CBOR is mostly used these
> days.

two applications come to mind:

* RD introspection[1] uses zone identifiers in what may be described as
  debug output: Usually an RD won't show you a resource on a fe80::
  address not on your link, but as an administrator you may need the
  birds-eye view.

* Many network devices offer a remote way to run a ping; when the
  process is started via CBOR, it'd be useful to give an interface
  identifier.

I'm not particularly advocating that we add zone identifiers to the new
tags (as I can use URIs or even work around completely in the former,
and don't have a pressing need for the latter) -- but with those
examples, a statement like "we don't specify interface identifiers
because they shouldn't be serialized anyway" would be overreaching.

BR
c

[1]: https://www.ietf.org/archive/id/draft-amsuess-core-resource-directory-extensions-05.html#name-zone-identifier-introspecti

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jul 2021 08:01:41 +1200

>   address not on your link, but as an administrator you may need the

Yes, that is an operational use case, as also considered in RFC6874(bis)
 
>   process is started via CBOR, it'd be useful to give an interface

How does host A know the Zone IDs (interface names) used on
host B?

(Answer: only if B has previously told A. So the use case is quite
complex.)
 
> because they shouldn't be serialized anyway" would be overreaching.

They shouldn't be on the wire except in rather special use cases.

    Brian