Subject: [Cbor] changes to draft-ietf-cbor-network-addresses-01.txt

From: Michael Richardson <[email-masked]>
Date: Sun, 07 Mar 2021 18:37:48 -0500

>        Title           : CBOR tags for IPv4 and IPv6 addresses and prefixes
>	Filename        : draft-ietf-cbor-network-addresses-01.txt
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-network-addresses-01

Brian E Carpenter <[email-masked]> wrote:
    bec> FYI, I am not tracking the CBOR list, but this caught my eye.

    bec> Since prefixes may be of any length and are not required to be
    bec> nibble-aligned, how is 2001:db8:1234::/47 encoded? Is it just this?

    bec>     TBD1([ 47, h'20010db81234'])

    bec> What is the specified behaviour if the byte string is too short or
    bec> too long?

The intention is that it is always zero-padded out to the needed prefix
length.

I have added sections in draft-ietf-cbor-network-addresses-01 which addresses
this as _Encoder Considerations_ and _Decoder Considerations_

I can't recall who asked about Covert Channels, but there are indeed an
opportunity.
In particular, with non-byte aligned prefixes (like 47 above), the 48th bit
(and bits 48 to 128) should be forced to zero.

Brian also laments:

> Reminder: in draft-ietf-anima-prefix-management-07 (RFC Editor queue), we
> have the CDDL below. Of course we could have used your tags if they had
> existed.

>     prefval /= pref6val
>     pref6val = [version6, length, ?prefix]
>     version6 = 6
>     length = 0..128             ; requested or offered prefix length
>     prefix = bytes .size 16     ; offered prefix in binary format

So, one byte for 4/6, vs two bytes for a 1+1 tag.
Unclear if "prefix" can be shortened though.

I just adjusted my code to omit trailing zeros, and to force bits to zero
when sending and receiving.
(Oh, I don't force trailing bits in a byte to zero when sending yet)

My C code is short, I could put it in an appendix if someone thought that was
useful, but I'm afraid it might cause more comments.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Mar 2021 08:53:00 +0100

I think prefixes and addresses are completely separate use cases.

There is rarely a point in suppressing trailing zeroes in an address.
We shouldn’t burden implementations to cater to this 0.4 % case (probably less in practice).

Prefixes are different, and they should indeed always be tail-cut.
(They are usually /64 or shorter, so there is a real win.)

We could imagine an alternate world where IIDs are carefully chosen so that actual addresses have as many trailing zeroes as possible.
But that’s not what happens today.  If we were to compress inner zero runs (as in “::”), we’d need to give the byte position where that happens (the length would be implied by the length of the remaining byte string).
I’m not proposing we cater to that.

Grüße, Carsten

(The /24 IPv4 example in the draft is wrong.)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Mar 2021 17:28:45 +1300

> (They are usually /64 or shorter, so there is a real win.)

True, but we didn't bother about that in draft-ietf-anima-prefix-management, because it isn't really aimed at constrained devices. It sends the prefix as bytes .size 16
(or bytes .size 4), which makes life easier.
 
> We could imagine an alternate world where IIDs are carefully chosen so that actual addresses have as many trailing zeroes as possible.

We could, but that contravenes the IPv6 privacy recommendations.

> I’m not proposing we cater to that.

No, you'd be better inventing a generic "compress zero bytes" mechanism and tag, but would you really want to go there?

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Mar 2021 09:44:33 -0500

> (probably less in practice).

okay.  I will take this constructive criticism and edit as you suggest.
When the byte-string is short, is it invalid then?

    > (The /24 IPv4 example in the draft is wrong.)

In that it has a non-zero value after the prefix length?
Yes, a copy&paste goof.

I have posted -02 just now.

https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-network-addresses-02

I guess I need to change the encoder and decoder considerations a bit more.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Mar 2021 15:50:07 +0100

> On 2021-03-09, at 15:44, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

Yes (for an address).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Mar 2021 11:09:25 -0500

> I guess I need to change the encoder and decoder considerations a bit

Actually, I don't think that there is much to say, as those sections actually
were specific to prefixes, not addresses.

I did ask in the decoder section:

~~~~
[0]
~~~~

or

~~~~
[0, null]
~~~~

Do we wish to tolerate either of these as equivalent to ::/0?

Erik Kline noticed that I had screwed up the example for ::/128.
It should be [128,h'']