Re: [Cbor] I-D Action: draft-richardson-cbor-network-addresses-01.txt

[Michael Richardson <[e-mail]>]

Carsten Bormann <[e-mail]> wrote:
    >> Carsten Bormann <[e-mail]> wrote:
    >>> Nice and sweet (although I liked the sequence in -00 of describing
    >>> current IP before legacy 32-bit IP better).
    >>
    >> I put current IP (v6) first, and v4 second.
    >> I don't think that changed.

    > It did, but in the right direction…
    > Sorry, misread the diff.
    >>> There needs to be some text about padding in the prefix byte strings.
    >>> (Ultimately, a prefix is a bit string, which we decided NOT to have as
    >>> a basic type in RFC 7049; that would be two bytes shorter if we want
    >>> that.)
    >>
    >> You mean, if I have 2001:db8:1234::/33  ?  That I need to emit 7 bits of
    >> zeroes, ideally, and/or that the recipient needs to force those bits to 0.

    > Leaving these bits open as a side channel would actually give you
    > something to write about in the Security considerations?

Yes, that's a good point as to why they MUST be zero.
I tend to think about what a receiver SHOULD do when it gets bad data.

    > The padding bits should be sender MUST be zero, receiver MUST check.
    > And it probably would be useful to define the preferred encoding to not
    > have more padding than needed.

Agreed.

    >>> I think it would be useful to have some discussion about the
    >>> pre-existing tags in this space, but that could be done separately
    >>> (such as in the notable-tags document, for which I need to find time to
    >>> update it…).
    >>
    >> An appendix that describes previous work maybe?

    > Works for me.

    > How useful is it going to be to be able to drop trailing zero bytes?

If you have a lot of /48s to describe, then it would be a win.
My notation does not let you apply the single tag a group.

Maybe:
    TBD1([[ 48, h'20010db81234'],...])

should be valid too.

    > My intuition is that this creates busywork for the receiver and almost
    > never can be used anyway.

I disagree.  The receiver has an empty (zeroed) sockaddr6 on in6_addr.
The receiver just memcpy's the number of bytes received.
Somewhere along there, a check for non-multiple of 8 is applied to zero the
trailing bits.

    > Oh, and the other thing that is missing is a format for transport
    > addresses (i.e., add a port).

So we'd wind up needing a protocol, scope and port.
I'd say that a "sockaddr" TAG is appropriate here, with the v4/v6-ness
established by these tags.  Or maybe not. ANIMA GRASP has all that stuff.

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