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: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 []) 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 []) 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, 3 Nov 2020 17:39:21 +0100
From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= <christian@amsuess.com>
To: ipv6@ietf.org, core@ietf.org
Subject: IPv6-related allocations and mechanism in CoRE's Resource Directory
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/ipv6/xY0AqPvbja45gxgW02GU3oWPTwc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-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

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

* 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

  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

[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