[core] IPv6-related allocations and mechanism in CoRE's Resource Directory
"Christian M. Amsüss" <christian@amsuess.com> Tue, 03 November 2020 16:39 UTC
Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE0A3A0DBA; Tue, 3 Nov 2020 08:39:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmPxCToeUgGa; Tue, 3 Nov 2020 08:39:26 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507523A0DAC; Tue, 3 Nov 2020 08:39:25 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 11F3040013; Tue, 3 Nov 2020 17:39:24 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id E2EF0AB; Tue, 3 Nov 2020 17:39:22 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 4699D34; Tue, 3 Nov 2020 17:39:22 +0100 (CET)
Received: (nullmailer pid 43419 invoked by uid 1000); Tue, 03 Nov 2020 16:39:21 -0000
Date: Tue, 03 Nov 2020 17:39:21 +0100
From: "Christian M. Amsüss" <christian@amsuess.com>
To: ipv6@ietf.org, core@ietf.org
Message-ID: <20201103163921.GB4187010@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/9cDM5pbiSZCFslaos8NHlR2JWyw>
Subject: [core] IPv6-related allocations and mechanism in CoRE's Resource Directory
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2020 16:39:29 -0000
Hello 6man group, as CoRE group's work on the Resource Directory ("RD", draft-ietf-core-resource-directory, [1]) is hopefully drawing to a conclusion, it is long overdue to draw on the 6man group's expertise on the document's IPv6 related IANA registrations and other v6 related mechanisms. While reviews on the whole document are always appreciated, here are the points most likely worth your attention: (As a preface: The RD is a place where embedded web servers can deposit information about their resources; IPv6 interactions are primarily on the side of how an RD can be found in a network if not explicitly configured). * We introduce RDAO, the Resource Directory Address Option. It is transported in RAs, and generally very similar to RDNSS. Full text at [2] (yes we know 38 is already taken, IANA is trusted to pick the next free one at time of publication). * For more ad-hoc use, we ask that an "All CoRE Resource Directories" multicast address be assigned in the Variable Scope Multicast Addresses space at [3]. * The CoAP protocol has defined REST semantics for multicast requests and uses them with the above (or a locally configured) addresses. Unless extra steps are taken, the communication between the registering endpoint and the RD happens using the IP address the RD answers the multicast request from. The client address used in these later exchanges is communicated to other parties. Thus, it is desirable to guide the process towards the use of a routable address, even when the client originally sent the request to a link-local multicast address. To ease implementation, we recommend that the RD answer the multicast requests from a routable source address. The mechanism we suggest for picking that source address is expressed in terms of the RFC6724 address selection around [4]. Is that use within the intended applications of the source address selection mechanism, or (if it's a stretch but passes for creative merit) at least formally correct? * For the examples we want to use multicast addresses that are globally unique (as they may be used on nomadic devices) but still valid example addresses. Lacking precedent or guidance in RFC3849, a unicast-prefix based site-local example address was constructed as ff35:30:2001:db8:f1::8000:1. (The :f1: part is there because each section with internally consistent examples takes a /48 out of 2001:db8::/32). As should have been expected, both idnits and reviewers asked questions, but this still seems to be closest there is to globally unique example address. Is it constructed correctly, or is there a better example address for this purpose? Thanks for your attention Christian [1]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-26 [2]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-26#section-4.1.1 [3]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-26#section-9.5 [4]: https://tools.ietf.org/html/draft-ietf-core-resource-directory-26#page-17 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [core] IPv6-related allocations and mechanism in … Christian M. Amsüss