[core] IPv6-related allocations and mechanism in CoRE's Resource Directory

["Christian M. Amsüss" <[e-mail]>]

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