Subject: [Cbor] I-D Action: draft-ietf-cbor-network-addresses-05.txt

From: [email-masked]
Date: Mon, 12 Jul 2021 04:28:09 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF.

        Title           : CBOR tags for IPv4 and IPv6 addresses and prefixes
        Authors         : Michael Richardson
                          Carsten Bormann
	Filename        : 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.

   RFC-EDITOR-please remove: This work is tracked at https://github.com/
   cbor-wg/cbor-network-address

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Jul 2021 07:40:45 -0400

[email-masked] wrote:
    > 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.

    > 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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jul 2021 08:36:40 +1200

Would it be useful to formally deprecate tags 260 and 261?

Regards
   Brian Carpenter

On 12-Jul-21 23:28, [email-masked] wrote:
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Jul 2021 21:11:30 -0400

> Would it be useful to formally deprecate tags 260 and 261?

I am ambilivent here: I don't care.

Whomwever out there is using them can continue using them.
Since 52 ('4') and 54 ('6') show up earlier in the table, I think that most
people will find them.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Jul 2021 09:43:25 +0200

> Would it be useful to formally deprecate tags 260 and 261?

We don’t have a process for that.

Other IETF registries are more actively curated, with “recommended” columns and some such.

The intention of the “Notable Tags” document was indeed to contain such guidance, but separate from the registry.
(Now I still have to find time to flesh that out some more…)

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jul 2021 09:50:25 +1200

> We don’t have a process for that.

A standards track document could label a tag as NOT RECOMMENDED and request IANA to add a column. But of course doing that requiires consensus, and shouldn't apply to the FCFS range.

> The intention of the “Notable Tags” document was indeed 
to contain such guidance, but separate from the registry.
> (Now I still have to find time to flesh that out some more…)

Indeed, it's real work (but if done now, it can prevent a historic mess like we have with port numbers).

Regards
    Brian

---

From: Erik Kline <[email-masked]>
Date: Sat, 24 Jul 2021 15:42:02 -0700

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 <[email-masked]>
wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

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:
>

---

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:

> 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: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Jul 2021 11:44:37 +1200

There's an "interesting" issue there, especially for IPv6, which is that the interface ID (or "zone index", per RFC4007) has no meaning outside the host. So it really shouldn't need to be sent on the wire in normal circumstances. 

(The conversation around RFC6874bis is slightly relevant.)

Regards
   Brian Carpenter

On 25-Jul-21 10:42, Erik Kline wrote:
> On Mon, Jul 12, 2021 at 4:41 AM Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     [email-masked] <mailto:[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/ <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 <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 <https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-network-addresses-05>
> 
>        192.0.1.4/24 <http://192.0.1.4/24>     ".4" is to the right of the /24, and is the interface definition.
> 
>     Michael Richardson <[email-masked] <mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
>     [email-masked] <mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 25 Jul 2021 03:37:10 +0200

> 169.254.x.y,

Hmm.
RFC 6874 only defines Zone Identifiers for IPv6.
Should we support IPv4 here as well?

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Jul 2021 21:37:30 -0400

> some generic {address_info, interface_info} pairing that could be used the

We will name the third form "Interface Format" or "Inteface Definition Format"

I think that the concern about the scope could only apply to that format,
or to the Address format.
Hmm. Well, the more I think about it, the more I think it applies to Address only.

I imagine we might find a way to do this differently.
Best I think think about is abusing maps in some way here.
     { 'eth0' => h'fe800db81234DEEDBEEFCAFEFACEFEED' }

    > extra interface information separately on an ad hoc basis.

I'd like to avoid inventing syntax before we need it.
So, let's talk about how you might use this?

I heard a talk about Extended ICMP Echo from Ron Bonica this week, and I can
see how it might have used it, but that ship has sailed.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Jul 2021 14:16:29 +1200

> So, let's talk about how you might use this?

Indeed. I can more easily imagine how core-href might need
it, because the use cases for http might conceivably apply
there. But I don't see it here.

It would be an easy extension, just add a field to the array,
so could we just leave it for later?

fwiw, in a constrained environment, I think you'd always want
to use the interface number (a small integer) rather than
the interface name (which can be a lot longer than "eth0";
"enxb827ebc170a4" is a real example from my Raspberry Pi).

   Brian

---

From: tom petch <[email-masked]>
Date: Mon, 26 Jul 2021 11:49:18 +0000

From: ipv6 <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Sent: 25 July 2021 00:44

<tp>
Brian

As I may have said before, the YANG Types RFC6991 provides types for IPv4 and IPv6 addresses both with a zone index.  It also provides no-zone types with a suffix 'no-zone' on the type name.  I see evidence that most authors of YANG modules do not realise that a reference to 'ip-address' per se is a reference to the format that includes the zone and so have specified that format in many if not most cases.  Thus it seems likely that many of the addresses on the wire are in the zone format, even if the zone is rarely present.  With hindsight, it might have been better to have specified 'ip-address' and 'ip-address-zone' rather than ip-address' and io-address-no-zone'.

Tom Petch

Regards
   Brian Carpenter

On 25-Jul-21 10:42, Erik Kline wrote:
>         > https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/ <https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/>
>
>         > https://www.ietf.org/archive/id/draft-ietf-cbor-network-addresses-05.html <https://www.ietf.org/archive/id/draft-ietf-cbor-network-addresses-05.html>
>
>         > https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-network-addresses-05 <https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-network-addresses-05>
>

---

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

---

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

> As I may have said before, the YANG Types RFC6991 provides types for IPv4 and IPv6 addresses both with a zone index.  It also provides no-zone types with a suffix 'no-zone' on the type name.  I see…

Makes sense. The reply I just sent to Christian Amsüss probably applies to YANG too. Sending a zone index to another host is rarely meaningful or useful.

   Brian

>> 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?

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 27 Jul 2021 23:07:06 +0200

> Makes sense. The reply I just sent to Christian Amsüss probably applies to YANG too. Sending a zone index to another host is rarely meaningful or useful.

YANG was designed for network management purposes and there are quite
some use cases where communicating the zone index is somewhat essential:

- If you want to debug a problem, you likely need to know to which
  link a link-local address belongs.
- If you want to generate statistics for protocols using link-local
  addresses, you likely need to know to which links the link-local
  addresses belongs.
- If you want to configure a service to use a certain link-local
  address on a certain link, you may have to include the proper zone
  index.
- If an IP address is used to index lists, things can fall apart if
  you end up with duplicate link-local addresses on different links.

Whether we should have picked different names for the types may be
debatable but at the end it is the YANG module author's responsibility
to pick the appropriate types.

In other words, network management applications often need to be aware
of zone indexes in order to do the right thing. This is different from
end user applications (that usually have no topological awareness).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jul 2021 10:00:23 +1200

Jürgen,

We are not disagreeing. These are exactly the sort of use cases that also
motivate RFC6874 and RFC6874bis. 

But I have a question. In the management plane, do you think that the
zone index (an integer) is the item of interest, or a zone identifier
(a string)? The description at
https://datatracker.ietf.org/doc/html/rfc6991#page-20
only says that the numerical format is "canonical".

Regards
   Brian

On 28-Jul-21 09:07, Jürgen Schönwälder wrote:
>>> As I may have said before, the YANG Types RFC6991 provides types for IPv4 and IPv6 addresses both with a zone index.  It also provides no-zone 
types with a suffix 'no-zone' on the type name.  I see evidence that most 
authors of YANG modules do not realise that a reference to 'ip-address' per se is a reference to the format that includes the zone and so have specified that format in many if not most cases.  Thus it seems likely that many of the addresses on the wire are in the zone format, even if the zone is rarely present.  With hindsight, it might have been better to have specified 'ip-address' and 'ip-address-zone' rather than ip-address' and io-address-no-zone'.

---

From: tom petch <[email-masked]>
Date: Fri, 30 Jul 2021 09:22:52 +0000

From: Brian E Carpenter <[email-masked]>
Sent: 27 July 2021 23:00

Jürgen,

<tp>

I am not Juergen but ..
The few zones that I have seen have been alphanumeric and not numeric so making the numeric form canonical has always puzzled me.

I agree with Juergen that for Problem or  Performance, then zone is helpful.  My concern was more about Configuration.  Thus draft-ietf-opsawg-l3sm-l3nm, currently in IETF LC, configures DHCPv6 customer-addresses as ipv6-address, ie with zone, while the protocol specification, RFC8415, has 128 bit fields for addresses i.e. no zone.  This implies that all YANG servers must accept addresses in the zone format and strip the zone before using them.  I do not know if that is what YANG servers do in practice.

Tom Petch

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Jul 2021 09:48:46 +1200

> The few zones that I have seen have been alphanumeric and not numeric so making the numeric form canonical has always puzzled me.

You should widen your horizons and look at Windows. The index is more fundamental than the identifier, exactly as RFC4007 says. Portable code needs to dig out the index (an integer).

It normally doesn't matter since the zone is meaningless outside the host; it only matters in the management plane. You need to be very clear then 
whether you are transmitting the name or the number. Making the number canonical is more portable across operating systems.

    Brian

> 
> I agree with Juergen that for Problem or  Performance, then zone is helpful.  My concern was more about Configuration.  Thus draft-ietf-opsawg-l3sm-l3nm, currently in IETF LC, configures DHCPv6 customer-addresses as ipv6-address, ie with zone, while the protocol specification, RFC8415, has 
128 bit fields for addresses i.e. no zone.  This implies that all YANG servers must accept addresses in the zone format and strip the zone before using them.  I do not know if that is what YANG servers do in practice.
>>>> As I may have said before, the YANG Types RFC6991 provides types for 
IPv4 and IPv6 addresses both with a zone index.  It also provides no-zone
> authors of YANG modules do not realise that a reference to 'ip-address' 
per se is a reference to the format that includes the zone and so have specified that format in many if not most cases.  Thus it seems likely that 
many of the addresses on the wire are in the zone format, even if the zone is rarely present.  With hindsight, it might have been better to have specified 'ip-address' and 'ip-address-zone' rather than ip-address' and io-address-no-zone'.