[Cbor] changes in draft-ietf-cbor-network-addresses-05.txt

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 12 July 2021 11:40 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C61B93A0DE1; Mon, 12 Jul 2021 04:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6BiaMbBhP4Ga; Mon, 12 Jul 2021 04:40:52 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B6B3A0DE0; Mon, 12 Jul 2021 04:40:52 -0700 (PDT)
Received: from localhost (localhost []) by tuna.sandelman.ca (Postfix) with ESMTP id CFE1838A3A; Mon, 12 Jul 2021 07:43:39 -0400 (EDT)
Received: from tuna.sandelman.ca ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id z0rfaZ4POirk; Mon, 12 Jul 2021 07:43:35 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 70E7338A15; Mon, 12 Jul 2021 07:43:35 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5DF03EA; Mon, 12 Jul 2021 07:40:45 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: cbor@ietf.org
cc: 6man@ietf.org
Reply-To: cbor@ietf.org
In-Reply-To: <162608928922.11086.12172415971165753394@ietfa.amsl.com>
References: <162608928922.11086.12172415971165753394@ietfa.amsl.com>
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: Mon, 12 Jul 2021 07:40:45 -0400
Message-ID: <29067.1626090045@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/1JnELQp07aR8lZuvqlAGcYKuYVU>
Subject: [Cbor] changes in draft-ietf-cbor-network-addresses-05.txt
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2021 11:40:58 -0000

internet-drafts@ietf.org 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/

    > 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

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
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.     ".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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide