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

tom petch <ietfc@btconnect.com> Mon, 26 July 2021 11:49 UTC

Return-Path: <ietfc@btconnect.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 A61783A0D42; Mon, 26 Jul 2021 04:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.658
X-Spam-Level:
X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 g8ptk4mcMnok; Mon, 26 Jul 2021 04:49:22 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80107.outbound.protection.outlook.com [40.107.8.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AAD3A0D86; Mon, 26 Jul 2021 04:49:21 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X3slV2a1fxC4HAHQxThn4RBX9/iwd0pfiPIguYiWotTSGx93YGW+YkBq/vZH9eDyrzZwrQ/CNC5ksvyyivXE04QQEseGjzK4Jg3A/rjIr0FwwAK9SIdL1yyM1NhC4jy6IsyrYqO8R8z/3pzV86by+kJ2cSz9CGEpE30X1ILJ2/sIKRJe7C/2UB5UkewQ4PvtttJUy77+tq3ZJF98MSwpJHwP0da4HqABouTvzcQB7PDoqBpbvGc9MXWOu2nm7LUmvmXua0nojk17XSqDXbyqADekgPay/+U9MNQIoYYJLvVSHD9XeGgAL3IhZUrMfE6nZL6tdPxZB3Y+OQoAu4GP2g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hq/Wk5AfyrsXqQm0uWP2a/pVKH20LP3aTwJBbx2cfvA=; b=cadQJJ58NA3EFOEIOy7XGjM3TJDjg6+pQywy407Cy2iRxb8Vt98psprkIM6Zwu3UsNIAXZR3kRiQL009ylfJ9o5fV5AlW932kMx5a2aV5bOKWaYLhBX/e24iBIAhLbYnRxMBdMWZnMeAWt3XbpBBaUklY/VhFhu2KZJMHdUcceNPcIk5opoDJkzFSsQZ3hIEfl28TWE9h6A+BlQ/t5zDVQW9Ba4JoW/LrqIglo0iUERS15B+h/ISLQ8n4AUVmib5xTGibA8I22xbyFrhwIwI0T0fEAB+tCZO+zv/oxlhNDCQjdRBFTS4GOTRkJG64WoQrFDeYNOWQAdhRkU1N3+F1Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hq/Wk5AfyrsXqQm0uWP2a/pVKH20LP3aTwJBbx2cfvA=; b=XMcy1vFeWx52tmBokIb81SdleIOLkWE/uUBSynMOqcABhaKRRw0Ri51zdicZiw42oTa6/wSBKCb2xK5gsV9ptTA9dDQ+6M0VD9wpIAY2ycSpeMJ9LFp6/JVXNblJ1DQdW+YZPHYpRSF7DAH3qL/w/mqNJ2Cy8dNwQpRjPW99oDo=
Received: from VI1PR07MB6256.eurprd07.prod.outlook.com (2603:10a6:800:133::7) by VI1PR07MB3102.eurprd07.prod.outlook.com (2603:10a6:802:1f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.15; Mon, 26 Jul 2021 11:49:18 +0000
Received: from VI1PR07MB6256.eurprd07.prod.outlook.com ([fe80::f964:3eed:2d44:a3c0]) by VI1PR07MB6256.eurprd07.prod.outlook.com ([fe80::f964:3eed:2d44:a3c0%9]) with mapi id 15.20.4373.015; Mon, 26 Jul 2021 11:49:18 +0000
From: tom petch <ietfc@btconnect.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Erik Kline <ek.ietf@gmail.com>, "cbor@ietf.org" <cbor@ietf.org>
CC: 6MAN <6man@ietf.org>
Thread-Topic: changes in draft-ietf-cbor-network-addresses-05.txt
Thread-Index: AQHXdxLY9sV77huO5U6gtDJkMWbdUatSzBcAgAARfICAAlTdAA==
Date: Mon, 26 Jul 2021 11:49:18 +0000
Message-ID: <VI1PR07MB6256E2C9CC9565FF2F080B5DA0E89@VI1PR07MB6256.eurprd07.prod.outlook.com>
References: <162608928922.11086.12172415971165753394@ietfa.amsl.com> <29067.1626090045@localhost> <CAMGpriUnfMjhk7teAN-A0j5SCK=BpyJEDC+NOCJtHzmF1BFeow@mail.gmail.com>, <aa9884b5-fd58-60cb-fa1d-b2d76f5a09a1@gmail.com>
In-Reply-To: <aa9884b5-fd58-60cb-fa1d-b2d76f5a09a1@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 41e740b6-a8af-4bf4-6d4d-08d9502b66d6
x-ms-traffictypediagnostic: VI1PR07MB3102:
x-microsoft-antispam-prvs: <VI1PR07MB310230D4ADE72FFE16B856ACA0E89@VI1PR07MB3102.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: mDLSXyIEiQmjB8RTPS8Sj9XK0BDvmiitkzPLi5tKP0BZkU93DayksReDOj5sgKRrg0lXytPpkkAk3Nd1qCVB84WmJHFl8EnYxX9SB9smW8Jpnb1C3wZ/JB+RjaM3K/5lRRI4rmgu2S3qW/FT8KiCwDCGUr5kKsa+qMBPIKRnJ3wx707m98dk0oEUvTyrBqJOqcyM8netiyzmcLT30gdE02OcvaxYdriqOOi3rLsdfBgZOhEHXLVM4WqVJzt9/r18jIoYH9L+HgySuL04cozoVV9qwjX4/E79qL2K84momlvLvHxSJztOVmvfeYQxMLsOZsIHkrc7Tbr4pwNqtlzgl+5AoHRcwEe4AMwlF8ef4wjdWyHtylT43tauLxaZQB+mPxIqV8NbxTLu83wOJ27ckFnEp8kFFh/FFJmzlS/FbKpWQ3dxYBljxzeJEmYP7Hqm8a9sF/WG140pZ3QpIpixEpMACJE7cqnomFuwB3/DHZJLmb2VaF9l62yw+WcpJlVVAahGW2CsI6rHaau7G6VM5yoDbS5nnZS+VZy7+Nb5OXrv0QSK/WJCsPqxdSsmPjz2otTnzLrU1qj4Q53K83IsAu4TL+MaOuuiXfARskKrpjoCE7zdRuU9K0JaIs+GaalRXpfjRHqVPVbFXBDbxcy7DKWe5vzpgaSS1rtKK0mgGB1FZqQ+saMgci701xoYH6AukTkOt3XUhugQ3uuliVrkYUrvvWwXbfBIvlvKe/TO38jNnmiWaWqnojVVYeZthe/03dczHKdOY3PiaHfbULuKUxWMcpPlzw6iGQoq9sVZDcLSEqep76vqAs2euXgOcPSuuLkbTRFp2Sub75nqA9ll/lJt2bR27dMriDrhQWaQ1Xg=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6256.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(6019001)(136003)(366004)(376002)(39860400002)(346002)(396003)(269900001)(83380400001)(122000001)(316002)(8676002)(55016002)(52536014)(8936002)(110136005)(33656002)(2906002)(66574015)(5660300002)(38100700002)(9686003)(86362001)(186003)(478600001)(91956017)(4326008)(71200400001)(66946007)(966005)(64756008)(53546011)(6506007)(66446008)(26005)(66476007)(76116006)(7696005)(66556008)(38070700004)(16193025007); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?IksYiyVHYt/xgD3o+6dPtsypObdi1+N8eGTW0zSNEWZOD3xMxDs09LFXaR?= =?iso-8859-1?Q?S8jKY+Y8UbN5l7M92H0GT3qijlzont3EN9tkG8vuJOjwVR/jQsf+FnaBFM?= =?iso-8859-1?Q?da23R0WHJCoCXl9hwh2oP+rSQrT/JSbyiBS5iRILC3KC1JIf4B1YwMHcm5?= =?iso-8859-1?Q?85dAtj9EA+znSTNiTZ95k0UZKo3/N445JuyfbPIXeu/l6P7VE317bS8Jyy?= =?iso-8859-1?Q?YXFhOwK+goeBbGQdqPwuVojn0YXZqco2ldM8ImJe7CpMTBif/Yadpo2SoY?= =?iso-8859-1?Q?25Xcm+a+6OvnbiJ02SEXbuK0NAvzj2bMdBgCRwINXUng5y/t/rWGFHAjVv?= =?iso-8859-1?Q?kTb/VSTSd7hMyVdQsc4hMQq/qKgzYgt+qB4rR57p8xsD2lAQNq/nA/KrNz?= =?iso-8859-1?Q?mK5mjY9u9DXOsm9JNfLxSwhMW/OIRskZho7yVyQwMuldex3Q4Wy+qlGQIn?= =?iso-8859-1?Q?ODpJTkD7fUtg8f/sJVIbTHezigpGtIszl5sZsFGfTeTdd3ZOVYuvw9RpXP?= =?iso-8859-1?Q?eHVxH98y3k5yfAe149t5xJ01P9BR7MjSlEkkjZvXRbRXsze0rcOyZjhmrM?= =?iso-8859-1?Q?VvNPV66EhBGci5ruVneqnGqLjeoFIKE76OXj908OUi6ZKwQkdTGC1EbPiM?= =?iso-8859-1?Q?48K2CiCcWFirDKj2JFfvQ6N+ElAYwL+b1Ig9vZljsyrllxq9YVQ+UjRZYO?= =?iso-8859-1?Q?Y4GAhQjfHzDbBRy3j6rFtD/GCVsz4EOLZl+/XEIjqkCSxYoebf3ZzB3Ced?= =?iso-8859-1?Q?9xBzFMDwMeF5aqVfkDiaJrcpNGiIeXnSDFyNV7Ef2GtV3EKoLF5VIcPEZJ?= =?iso-8859-1?Q?YBZ1TOVxSQHg7Ije4/dpA09YSBFOPS9cuxbclCHu2qkVNTD8ZJbyyuR9LK?= =?iso-8859-1?Q?xclYPmw8zhysPNk3RH2UrJBMphY5nStIPcAtXxPJ4uOOn4ffoJ2/pGBmNK?= =?iso-8859-1?Q?t2kbz212aCouFahapXv6OKbxepIZ5I2RKTMeQ1/OctfROd7YN2dsttokwq?= =?iso-8859-1?Q?FjQR2JBshARugEEILq8nS2kR2Xbr5cb/wNZ4z558VEAmqae1wyiw+3fBVl?= =?iso-8859-1?Q?rHbHqvHtUfTcBWQUKQPTglDup7zOEpur3T27nrmTFi/LMc7alllrhZXAnG?= =?iso-8859-1?Q?fpHxlXoKHHyeczkmN9kc0Vs+U0UNzh/b9jBtDNa1rBCX2N4bbyRiayDjkL?= =?iso-8859-1?Q?0ZGy6uaIZ0yNOWT7MUwn4E3nX0RVyULTR7kdPJHLSXdH40C0iHQM4RfJk+?= =?iso-8859-1?Q?7/XCw+P6iv4KR1pSBJCjHGDsjciHuQxW/OUZoM+BlLbsixmheWyPJb6YU0?= =?iso-8859-1?Q?gFdUATcUKuESme0+TmNwSX2EXLhBTETPVUjmNEne4znSBF4=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6256.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 41e740b6-a8af-4bf4-6d4d-08d9502b66d6
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2021 11:49:18.7665 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2EyNjN54rbEimnEC0/AX2e+d7TmTBnjKPVHGjs3TZ6UOKp2WStPz9FgIKLyYLZ3e0KN58f5TPbezbf1NqqWfIA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3102
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/mjhUAumNvfQqiqEUVsf2K1WaDm8>
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: Mon, 26 Jul 2021 11:49:28 -0000

From: ipv6 <ipv6-bounces@ietf.org> on behalf of Brian E Carpenter <brian.e.carpenter@gmail.com>
Sent: 25 July 2021 00:44

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

<tp>
Brian

As I may have said before, the YANG Types RFC6991 provides types for IPv4 and IPv6 addresses both with a zone index.  It also provides no-zone types with a suffix 'no-zone' on the type name.  I see evidence that most authors of YANG modules do not realise that a reference to 'ip-address' per se is a reference to the format that includes the zone and so have specified that format in many if not most cases.  Thus it seems likely that many of the addresses on the wire are in the zone format, even if the zone is rarely present.  With hindsight, it might have been better to have specified 'ip-address' and 'ip-address-zone' rather than ip-address' and io-address-no-zone'.

Tom Petch

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------