Draft: draft-ietf-core-resource-directory

Commentary: ... as promised for yesterday ( oops ) 
 ad " what is sub " : it 's DNS - SD 's syntax for subtypes ( RFC6763 Section 7.1 ) . Might also be ( " Subtype strings are not required to begin with an underscore , though they often do " ) . 
 Looks good to me . 
 There are several ways specified for finding a host serving an RD : static ( unicast or anycast , addresses or DNS ? could contain full RD path ( as in LWM2 M ) ? ) various neighbor discovery derived  the border router ( ABRO ) " other ND options that happen to point to servers ( such as RDNSS ) " might - be - defined DHCPv6 options multicast ( all - coap - nodes + .well - known / core ; serves the path by design ) There is an open issue to describe how this can be used with DNS - SD ( ) , and it came up 2017 - 04 - 07 that discovery via mDNS by those mechanisms might be possible but is not advisable . Can we give a set of discovery options that should be supported by all general - purpose clients and servers to avoid fragmentation where one vendor 's clients expect an  while the other vendor 's server relies on clients doing a multicast ? Can we say anything about which options are recommended to use , and which are rather to be viewed as shortcuts in extremely constrained cases ? Using RDNSS would be a candidate for such a statement . Maybe those cases are better described as " explicitly configured to use whichever RDNSS is announced " , so this is something that 's better than static configuration but still not to be expected from a generic client . 
 The new section 4 introduced in takes care of this .
Paragraph (version A):
Several mechanisms can be employed for discovering the RD, including
assuming a default location (e.g. on an Edge Router in a LoWPAN),
assigning an anycast address to the RD, using DHCP, or discovering
the RD using .well-known/core and hyperlinks as specified in CoRE
Link Format RFC6690.  Endpoints that want to contact a Resource
Directory (RD) can obtain candidate IP addresses of RD servers
dependent on the operational conditions.  It is assumed that the
nodes looking for a Resource Directory are connected to a Border
Router (6LBR).  Given the various existing network installation
procedures, the 6LBR is either connected or disconnected from the
Internet and its services like DHCP and DNS.  Two conditions are
separately considered: (1) Internet services present, and (2) no
Internet services present.
Paragraph (version A):
Sending a Multicast to [ff02::1]/.well-known/core with
?rt=core.rd*. The receiving RDs will answer the query.
Paragraph (version A):
The Authoritative Border Router Option (ABRO) present in the
Router Advertisements (RA), contains the address of the border
router.
Paragraph (version A):
Assuming that an RD is located at the 6LBR.  Confirmation can be
obtained by sending a Unicast to [6LBR]/.well-known/core with
?rt=core.rd*. Address of 6LBR is obtained from ABRO.
Paragraph (version A):
The installation manager can decide to preconfigure an ANYCAST
address with as destination the interface of the RDs.  Clients
send a discovery message to the predefined RD anycast address.
Each target network environment in which some of these
preconfigured nodes are to be brought up is then configured with a
route for this anycast address that leads to an appropriate RD.
Paragraph (version A):
Instead of using an ANYCAST address, a multicast address can be
preconfigured.  All RD directory servers need to configure one of
their interfaces with this multicast address.
Paragraph (version A):
After installation of mDNS on all nodes, mDNS can be queried for
the IP-address of RD.
Paragraph (version A):
Using a DNSSD query to return the Resource Records (RR) describing
the service with name rd._sub._coap._udp, preferably within the
domain of the querying nodes.
Paragraph (version A):
Using DHCPv6 with options to be defined.
Paragraph (version A):
Assisting the 9 techniques above, requires manual intervention or may
be done automatically.
Paragraph (version A):
IP address of RD is present in each node.
Paragraph (version A):
ANYCAST address or Multicast address of RD is present in each node
[see 5,6].
Paragraph (version A):
6LBR receives IP address of RD for distribution via RDAO [see 4].
Paragraph (version A):
RD address is configured in DHCP [see 9].
Paragraph (version A):
DNS is configured with Resource Record specifying address of RD
service [see 8].
Paragraph (version A):
Multicasting to all nodes to return IP address [see 1].
Paragraph (version A):
Querying mDNS to receive IP address [see 7].
Paragraph (version A):
6LBR contains RD service [see 2, 3].
Paragraph (version A):
As some of these RD addresses are just (more or less educated)
guesses, endpoints MUST make use of any error messages to very
strictly rate-limit requests to candidate IP addresses that don't
work out.  For example, an ICMP Destination Unreachable message (and,
in particular, the port unreachable code for this message) may
indicate the lack of a CoAP server on the candidate host, or a CoAP
error response code such as 4.05 "Method Not Allowed" may indicate
unwillingness of a CoAP server to act as a directory server.
Paragraph (version B):
A device coming up may want to find one or more resource directories
to make itself known with.
Paragraph (version B):
It may be configured with a DNS name for the RD and a resource-
record type to look up under this name; it can find a DNS server
to perform the lookup using the usual mechanisms for finding DNS
servers.
Paragraph (version B):
For cases where the device is not specifically configured with a way
to find a resource directory, the network may want to provide a
suitable default.
Paragraph (version B):
If the address configuration of the network is performed via
SLAAC, this is provided by the RDAO option rdao.
Paragraph (version B):
If the address configuration of the network is performed via DHCP,
this could be provided via a DHCP option (no such option is
defined at the time of writing).
Paragraph (version B):
Finally, if neither the device nor the network offer any specific
configuration, the device may want to employ heuristics to find a
suitable resource directory.
Paragraph (version B):
In a 6LoWPAN, just assume the Edge Router (6LBR) can act as a
resource directory (using the ABRO option to find that RFC6775).
Confirmation can be obtained by sending a Unicast to
coap://[6LBR]/.well-known/core?rt=core.rd*`.
Paragraph (version B):
In a network that supports multicast well, discovering the RD
using a multicast query for /.well-known/core as specified in CoRE
Link Format RFC6690: Sending a Multicast GET to
"coap://[ff02::1]/.well-known/core?rt=core.rd*".  RDs within the
multicast scope will answer the query.
Paragraph (version B):
As some of the RD addresses obtained by the methods listed here are
just (more or less educated) guesses, endpoints MUST make use of any
error messages to very strictly rate-limit requests to candidate IP
addresses that don't work out.  For example, an ICMP Destination
Unreachable message (and, in particular, the port unreachable code
for this message) may indicate the lack of a CoAP server on the
candidate host, or a CoAP error response code such as 4.05 "Method
Not Allowed" may indicate unwillingness of a CoAP server to act as a
directory server.
Paragraph (version B):
Changed the lookup interface to accept endpoint and Domain as
query string parameters to control the scope of a lookup.