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

Michael Richardson <> Sun, 07 February 2021 08:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 971473AFACF for <>; Sun, 7 Feb 2021 00:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WnL4NnU2OGqq for <>; Sun, 7 Feb 2021 00:50:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CB7B3AFACD for <>; Sun, 7 Feb 2021 00:50:02 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A2C2389A9; Sun, 7 Feb 2021 03:53:05 -0500 (EST)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id 8ITtrgGIpSj4; Sun, 7 Feb 2021 03:53:04 -0500 (EST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 48C95389A7; Sun, 7 Feb 2021 03:53:04 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 49837C65; Sun, 7 Feb 2021 03:49:58 -0500 (EST)
From: Michael Richardson <>
To: Carsten Bormann <>
In-Reply-To: <>
References: <> <> <9223.1612672667@localhost> <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sun, 07 Feb 2021 03:49:58 -0500
Message-ID: <7924.1612687798@localhost>
Archived-At: <>
Subject: Re: [Cbor] I-D Action: draft-richardson-cbor-network-addresses-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Feb 2021 08:50:06 -0000

Carsten Bormann <> wrote:
    >> Carsten Bormann <> 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.


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

    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 <>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide