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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 24 July 2021 23:44 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D273A003B; Sat, 24 Jul 2021 16:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.856
X-Spam-Level:
X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_s-8OIPf_jr; Sat, 24 Jul 2021 16:44:43 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349473A0033; Sat, 24 Jul 2021 16:44:43 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id k4-20020a17090a5144b02901731c776526so14373224pjm.4; Sat, 24 Jul 2021 16:44:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Vb8ujwhDONi+gQGSTBcYOPMeYzRTiNUfb3P3S/oPMso=; b=RVnSahNaJ4rL9bM5hVFMm/rU5xfOM+Fo9X9sdL8tVO38PzMOp+gKp0mfYMaGT05mvp WMr5tzGmExpTHbxS2wFkH6XfVa94L7hHF1kuu9kj2soLqgG+mHwDpuEBjHgPW2uzgXox t6nJy9XXNqtkT8OFP0ijPDql6NQfBktNJSt4rOsiOW3JaGjoLk7DwHH34oZgR42xmd8C sv+UjCGXfJOulddDsu2BwTimKd8L6/3Eqs41UPsq6dmBxtfR3QvKKuiDbJ1YDgSKfAmR cbPO5C+qim8liBImo7tbzQCu1HiUtA182GPOutfVUxLvESvx+VU3gEfVrYTspQr17ulU IWaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Vb8ujwhDONi+gQGSTBcYOPMeYzRTiNUfb3P3S/oPMso=; b=IKuE32rXZz8fwhe3hpayjGTwG/sGf2k+1iNsTYbKbkIoyVIM3fDF6r6YKPNx9fl4yt LtNpMejNO85cU6D2x4RLEc06CxcQ40QFHFYI9of+wdvP7cJSqpcnxzccFhBPOMsjjgGM e5WF2RGMHb8QWZRYs+X1v+t7BhzUhn5Olqv+EKdAE7G4LSVYWRvyGrvHZNMkk+T8N83u 4jZc0o1eymkqX76USg/itu6ipxKJZivsjWsw4Aok/H0O34qIh4UXQWxc57qXM4L80H7R mxYMxDUJwnAI6C9wdSo8BD9aJzcxHVVMepM6p7CynbkQAYKVhZIY2pt2zhwGOiaj2iN7 3uUg==
X-Gm-Message-State: AOAM530rrAAFgRHk4cjwxQSuM21IzwalFzi8qJpizLzCKw1tXwcqiMS4 WAaWjtnlaZsHWo5MXt2/qO1LcVb6ucpR6A==
X-Google-Smtp-Source: ABdhPJz8MW4Msc0rNv2nDGW0RXP+UHDWPvDYz40ULs+SyxyfmwDKn4Fm6qSIKpPVg+HOnt5R85M8Fg==
X-Received: by 2002:a63:f904:: with SMTP id h4mr11599286pgi.238.1627170281087; Sat, 24 Jul 2021 16:44:41 -0700 (PDT)
Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id gd20sm32366119pjb.33.2021.07.24.16.44.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jul 2021 16:44:40 -0700 (PDT)
To: Erik Kline <ek.ietf@gmail.com>, cbor@ietf.org
Cc: 6MAN <6man@ietf.org>
References: <162608928922.11086.12172415971165753394@ietfa.amsl.com> <29067.1626090045@localhost> <CAMGpriUnfMjhk7teAN-A0j5SCK=BpyJEDC+NOCJtHzmF1BFeow@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <aa9884b5-fd58-60cb-fa1d-b2d76f5a09a1@gmail.com>
Date: Sun, 25 Jul 2021 11:44:37 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <CAMGpriUnfMjhk7teAN-A0j5SCK=BpyJEDC+NOCJtHzmF1BFeow@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/hWwYdJTcDut_rdNkmuDEBjGGbic>
Subject: Re: [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: Sat, 24 Jul 2021 23:44:49 -0000

There's an "interesting" issue there, especially for IPv6, which is that the interface ID (or "zone index", per RFC4007) has no meaning outside the host. So it really shouldn't need to be sent on the wire in normal circumstances. 

(The conversation around RFC6874bis is slightly relevant.)

Regards
   Brian Carpenter

On 25-Jul-21 10:42, Erik Kline wrote:
> Michael,
> 
> Thanks for the update.
> 
> Was there any interest in figuring out a representation for link-local addresses (e.g. 169.254.x.y, fe80::zed, ff02::pqr, ...) that included either an interface name or index as part of a structured unit?  Perhaps some generic {address_info, interface_info} pairing that could be used the same way?
> 
> Obviously, it's possible to pair what you've described here together with extra interface information separately on an ad hoc basis.
> 
> Curious,
> -ek
> 
> On Mon, Jul 12, 2021 at 4:41 AM Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>> wrote:
> 
> 
>     internet-drafts@ietf.org <mailto: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/ <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 <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 <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
>     Ipv6/48s..).
>     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.
>        192.0.1.4/24 <http://192.0.1.4/24>     ".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 <mailto:mcr%2BIETF@sandelman.ca>>   . o O ( IPv6 IøT consulting )
>                Sandelman Software Works Inc, Ottawa and Worldwide
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 
<https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>