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

[Erik Kline <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> > On 2021-07-25, at 00:42, Erik Kline <[e-mail]> 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 <
> [e-mail]> wrote:
> >
> > [e-mail] 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 <[e-mail]>   . o O ( IPv6 IøT
> consulting )
> >            Sandelman Software Works Inc, Ottawa and Worldwide
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > _______________________________________________
> > CBOR mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/cbor
>
>