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

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Apr 2021 10:52:47 -0400

[email-masked] wrote:
    > Title           : CBOR tags for IPv4 and IPv6 addresses and prefixes
    > Author          : Michael Richardson
    > Filename        : draft-ietf-cbor-network-addresses-04.txt
    > Pages           : 6
    > Date            : 2021-04-21

...

    > A diff from the previous version is available at:
    > https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-network-addresses-04

The Designated Expert had already assigned the tags for -03, which was
published March 25.
Again, Carsten sent a few small edits, which are included in -04.

I am CC'ing 6man here, because perhaps someone there will have an opinion.

I believe that the document is done.
I have running code.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: [email-masked]
Date: Fri, 23 Apr 2021 12:45:41 +0200

Do you want to say anthing about tag 261 or perhaps subsume tag 261 into this?

Why do you have "Trailing zero bytes MUST be omitted." as it seems the decoder would happily deal with trailing zeros?

Cheers,
Ole

> On 21 Apr 2021, at 16:52, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Apr 2021 18:22:40 -0400

> Do you want to say anthing about tag 261 or perhaps subsume tag 261

Hi, I wasn't happy with tag 260/261.
In addition to not distinguishing between v4 and v6 explicitely, tag 260 also
confused 6-byte ethernet into the definition, and did not accomodate 8-byte
ethernet.
Tag 261 (on prefixes), I did not understand, which is why I wrote the document.

    > Why do you have "Trailing zero bytes MUST be omitted." as it seems the
    > decoder would happily deal with trailing zeros?

Yes, well Postel rule definitely applies here.

For prefixes, a concern was expressed that irrelvant bits could be included
and could form some kind of intentional convert channel.  Worse, they could
be a non-intentional leak of private information (a la Heartbleed).
So, it might be good to be able to make sure that encoders were more conservative.

---

From: Ole Troan <[email-masked]>
Date: Sun, 25 Apr 2021 13:06:10 +0200

Thanks Michael,

Top posting. 
- for 261 I would at least include those arguments and make it clear when to use or the other
- so you don’t want to support the commonly used shortcut of specifying both and address and a prefix in one?
- in ip agnostic code I often find I just need an IP address instead of having to care if it’s 4 or 6. It would therefore be nice with a general IP address and ip prefix type too. 

Cheers 
Ole

> On 25 Apr 2021, at 12:40, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 25 Apr 2021 17:30:13 +0200

> - for 261 I would at least include those arguments and make it clear when to use or the other

Sounds good to me.

> - so you don’t want to support the commonly used shortcut of specifying both and address and a prefix in one?

That is a valid point.
But I think the data should indicate whether they are just a prefix or an address and a prefix.

> - in ip agnostic code I often find I just need an IP address instead of having to care if it’s 4 or 6. It would therefore be nice with a general IP address and ip prefix type too. 

If I understand this right, we already have that.  One type with two different tags…
(CBOR doesn’t have “types” [except for the “major types” on the representation level].  You are free to construct your own types in your implementation, e.g. construct a “Boolean” type from “true” and “false”.  In your case, the “IP address and prefix” type would include values with either tag 52 or 54.  We could define recommended CDDL types, like we did in Section 5 of RFC 8746...)

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Apr 2021 09:12:24 +1200

>> - in ip agnostic code I often find I just need an IP address instead of having to care if it’s 4 or 6. It would therefore be nice with a general IP address and ip prefix type too. 

This is very dependent on the context where you are using the address. Sometimes you need to be address-family independent and sometimes not. It can also be programming-language dependent. And it can be API dependent (who are you passing the address to?). So I think this will have to be handled by the parser of the decoded CBOR, not by the CBOR tagging.
 
> If I understand this right, we already have that.  One type with two different tags…

Yes, and how you cast it into a particular language's type(s) is not a CBOR issue.

> (CBOR doesn’t have “types” [except for the “major types” on the representation level].  You are free to construct your own types in your implementation, e.g. construct a “Boolean” type from “true”…

Sure. But in GRASP we ended up with 
  ipv4-address = bytes .size 4
  ipv6-address = bytes .size 16
which wouldn't suit every case. 

Regards
    Brian

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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 25 Apr 2021 20:06:19 -0400

> - for 261 I would at least include those arguments and make it clear

I'm not sure it's fair to criticise 261.

    > both and address and a prefix in one?

I don't understand your suggestion.
    X - address
[n,X] - prefix

    > - in ip agnostic code I often find I just need an IP address instead of
    > having to care if it’s 4 or 6. It would therefore be nice with a
    > general IP address and ip prefix type too.

So, I think that I've done this.

When you find that you need a v4 or a v6 in your schema, you would just write
"IPaddress", and then let the tag tell your decoder whether it was v4 or v6.

I used this CDDL in my use case:

IPaddress = #6.260(v6addr) / #6.261(v4addr)
IPsubnet  = #6.260([prefixlen, v6addr])
          / #6.261([prefixlen, v4addr])
prefixlen = uint
v6addr    = bytes .size 16
v4addr    = bytes .size 4

---

From: Michael Richardson <[email-masked]>
Date: Sun, 25 Apr 2021 20:47:20 -0400

> Sounds good to me.

What I'm hearing is that you'd like me to write something like below.
  https://github.com/cbor-wg/cbor-network-address/commit/c7962ed01ef0f63773cca70c97be54edc481bb78

# Introduction

{{RFC8949}} defines a number of CBOR Tags for common items.

Tag 260 and tag 261 was later defined through IANA.
These tags cover addresses (260), and prefixes (261).
Tag 260 distinguishes between IPv4, IPv6 and Ethernet through the length of the byte string only.
Tag 261 was not documented well enough to be used.

The author wanted an explicit indication of IPv4 or IPv6, and the possibility to omit trailing zeroes.

This document provides a format for IPv6 and IPv4 addresses and prefixes.
Prefixes may omit trailing zeroes in the address.
Due to the complexity of testing the value of omitting trailing zeros for addresses was considered non-essential and support for that was removed in this specification.

This document does not deal with 6 or 8-byte ethernet addressees.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Apr 2021 07:15:17 +0200

> I don't understand your suggestion.

Back in IPv4-land, we often said something like

“Configure the interface to 192.168.3.5/24”

Which is a short-cut for

“Configure the interface to address 192.168.3.5, prefix 192.168.3.0/24”

Since address/prefix is structurally similar to a prefix (but uses a full 32-bit address), it could be expressed by adding a third case

>    A - address
> [n,P] - prefix
> [A,n] - address/prefix

Where A is a 4-byte byte-string, P is a 0-to-4-byte byte string, and n is an unsigned integer 0 to 32.

This construct is less common in IPv6-land, because n is usually 64, so sending the address suffices, but there are exceptions to that here, too.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 26 Apr 2021 07:18:37 +0200

> The author wanted an explicit indication of IPv4 or IPv6, and the possibility to omit trailing zeroes.

s/The author wanted/The present specification achieves/ or some such.

> Due to the complexity of testing the value of omitting trailing zeros for addresses was considered non-essential and support for that was removed in this specification.

Need a comma after “testing”.
s/removed/not provided/

> This document does not deal with 6 or 8-byte ethernet addressees.

MAC addresses, more generally.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Apr 2021 14:23:05 -0400

Carsten Bormann <[email-masked]> wrote:
    >>> both and address and a prefix in one?
    >>

    > “Configure the interface to 192.168.3.5/24”

Ah, oh yes.
Ole is this what you had in mind?

    > Since address/prefix is structurally similar to a prefix (but uses a
    > full 32-bit address), it could be expressed by adding a third case

    <1> A - address
    <2> [n,P] - prefix
    <3> [A,n] - address/prefix

<3> is forced because case <2> demands that the trailing bits are zero, and
are ideally omitted.  If we didn't insist on that, then we could do it all
with one case.

I find the need for a third case a bit inelegant, but I can live with it.

---

From: [email-masked]
Date: Tue, 27 Apr 2021 12:57:29 +0200

Michael,

> Ole is this what you had in mind?

Yes. Although I think it equally applies to IPv6. An implementation should not and can not assume 64.

> I find the need for a third case a bit inelegant, but I can live with it.

It has it's pros and cons.
Configuring the on-link prefix and configuring the address are two separate things indeed.
It is a short-cut.

If you choose not to support it, it might be worth having a little blurb stating how configured an address and connected prefix would look like.

Best regards,
Ole

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 27 Apr 2021 13:06:30 +0200

> I find the need for a third case a bit inelegant, but I can live with it.

The purpose of the tag is to indicate the semantics, and I agree with Ole that prefix ≠ interface configuration (address + prefix).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Apr 2021 11:40:15 -0400

> The purpose of the tag is to indicate the semantics, and I agree with
    > Ole that prefix ≠ interface configuration (address + prefix).

I am open to whatever consensus the CBOR WG comes to about including this third case in the document.
I don't have this need myself.

While I think that this third case *could* be added at a later time,  it
seems silly to omit it if there is interest now.

If there was another syntactic way to distinguish address+"netmask" from
prefix, rather than two orderings of the array, I'd be more keen.

One way is to say that it's all prefixes, but that bits beyond the
prefix-length MAY be set.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Apr 2021 21:36:35 +0200

Le 26/04/2021 à 07:15, Carsten Bormann a écrit :
> This construct is less common in IPv6-land, because n is usually 64,

well, no, but I think it was said.

> so sending the address suffices, but there are exceptions to that here, too.

YEs, there are exceptions.  There is a VSLAAC I-D (V for Variable 
length) and open source linux kernel implementation which configures an 
IP address out of a prefix of any length, not only 64.  Manually it is 
also possible.  OpenBSD also has such code.

Alex