Re: changes in draft-ietf-cbor-network-addresses-05.txt

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?

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

Curious,
-ek

On Mon, Jul 12, 2021 at 4:41 AM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> internet-drafts@ietf.org 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>