idnits 2.17.00 (12 Aug 2021) /tmp/idnits25904/draft-amsuess-core-resource-directory-extensions-05.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 21 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-core-resource-directory]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '... proxy) MUST come up with a "Proxy U...' RFC 2119 keyword, line 139: '... The Proxy URL SHOULD have no path c...' RFC 2119 keyword, line 144: '... The RD MAY mint several alternative...' RFC 2119 keyword, line 161: '...on terminates, the RD SHOULD treat the...' RFC 2119 keyword, line 163: '... exceeded) and MAY eventually remove...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 February 2021) is 446 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 == Outdated reference: A later version (-06) exists of draft-tiloca-core-groupcomm-proxy-02 == Outdated reference: A later version (-11) exists of draft-tiloca-core-oscore-discovery-07 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Amsüss 3 Internet-Draft 22 February 2021 4 Intended status: Experimental 5 Expires: 26 August 2021 7 CoRE Resource Directory Extensions 8 draft-amsuess-core-resource-directory-extensions-05 10 Abstract 12 A collection of extensions to the Resource Directory 13 [I-D.ietf-core-resource-directory] that can stand on their own, and 14 have no clear future in specification yet. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 26 August 2021. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Reverse Proxy requests . . . . . . . . . . . . . . . . . . . 3 51 2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.2. Registration . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2.1. Registration updates . . . . . . . . . . . . . . . . 4 54 2.2.2. Proxy behavior . . . . . . . . . . . . . . . . . . . 5 55 2.2.3. On-Demand proxying . . . . . . . . . . . . . . . . . 5 56 2.2.4. Multiple upstreams . . . . . . . . . . . . . . . . . 5 57 2.2.5. Examples . . . . . . . . . . . . . . . . . . . . . . 6 58 2.2.6. Notes on stability and maturity . . . . . . . . . . . 7 59 2.2.7. Security considerations . . . . . . . . . . . . . . . 7 60 3. Infinite lifetime . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4. Lookup across link relations . . . . . . . . . . . . . . . . 8 63 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Lifetime Age . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6. Zone identifier introspection . . . . . . . . . . . . . . . . 10 66 6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 7. Proxying multicast requests . . . . . . . . . . . . . . . . . 11 68 7.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 8. Opportunistic RD . . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Applications . . . . . . . . . . . . . . . . . . . . . . 15 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 9.2. Informative References . . . . . . . . . . . . . . . . . 16 74 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 17 75 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 This document pools some extensions to the Resource Directory 81 [I-D.ietf-core-resource-directory] that might be useful but have no 82 place in the original document. 84 They might become individual documents for IETF submission, simple 85 registrations in the RD Parameter Registry at IANA, or grow into a 86 shape where they can be submitted as a collection of tools. 88 At its current state, this draft is a collection of ideas. 90 [ This document is being developed at https://gitlab.com/chrysn/ 91 resource-directory-extensions (https://gitlab.com/chrysn/resource- 92 directory-extensions). ] 94 2. Reverse Proxy requests 96 When a registrant registers at a Resource Directory, it might not 97 have a suitable address it can use as a base address. Typical 98 reasons include being inside a NAT without control over port 99 forwarding, or only being able to open outgoing connections (as 100 program running inside a web browser utilizing CoAP over WebSocket 101 [RFC8323] might be). 103 [I-D.ietf-core-resource-directory] suggests (in the Cellular M2M use 104 case) that proxy access to such endpoints can be provided, it gives 105 no concrete mechanism to do that; this is such a mechanism. 107 This mechanism is intended to be a last-resort option to provide 108 connectivity. Where possible, direct connections are preferred. 109 Before registering for proxying, the registrant should attempt to 110 obtain a publicly available port, for example using PCP ([RFC6887]). 112 The same mechanism can also be employed by clients that want to 113 conceal their network address from its clients. 115 A deployed application where this is implicitly done is LwM2M 116 [citation missing]. Notable differences are that the protocol used 117 between the client and the proxying RD is not CoAP but application 118 specific, and that the RD (depending on some configuration) eagerly 119 populates its proxy caches by sending requests and starting 120 observations at registration time. 122 2.1. Discovery 124 An RD that provides proxying functionality advertises it by 125 announcing the additional resource type "TBD1" on its directory 126 resource. 128 2.2. Registration 130 A client passes the "proxy=yes" or "proxy=ondemand" query parameter 131 in addition to (but typically instead of) a "base" query parameter. 133 A server that receives a "proxy=yes" query parameter in a 134 registration (or receives "proxy=ondemand" and decides it needs to 135 proxy) MUST come up with a "Proxy URL" on which it accepts requests, 136 and which it uses as a Registration Base URI for lookups on the 137 present registration. 139 The Proxy URL SHOULD have no path component, as acting as a reverse 140 proxy in such a scenario means that any relative references in all 141 representations that are proxied must be recognized and possibly 142 rewritten. 144 The RD MAY mint several alternative Registration Base URIs using 145 different protocols to make the proxied content available; 146 [I-D.silverajan-core-coap-protocol-negotiation] can be used to 147 advertise them. 149 The registrant is not informed of the chosen public name by the RD. 151 This mechanism is applicable to all transports that can be used to 152 register. If proxying is active, the restrictions on when the base 153 parameter needs to be present ([I-D.ietf-core-resource-directory] 154 Registration template) are relaxed: The base parameter may also be 155 absent if the connection originates from an ephemeral port, as long 156 as the underlying protocol supports role reversal, and link-local 157 IPv6 addresses may be used without any concerns of expressibility. 159 If the client uses the role reversal rule relaxation, both it and the 160 server keep that connection open for as long as it wants to be 161 reachable. When the connection terminates, the RD SHOULD treat the 162 registration as having timed out (even if its lifetime has not been 163 exceeded) and MAY eventually remove the registration. It is yet to 164 be decided whether the RD's announced ability to do proxying should 165 imply that infinite lifetimes are necessarily supported for such 166 registrations; at least, it is RECOMMENDED. 168 2.2.1. Registration updates 170 The "proxy" query parameter can not be changed or repeated in a 171 registration update; RD servers MUST answer 4.00 Bad Request to any 172 registration update that has a "proxy" query parameter. 174 As always, registration updates can explicitly or implicitly update 175 the Registration Base URI. In proxied registrations, those changes 176 are not propagated to lookup, but do change the forwarding address of 177 the proxy. 179 For example, if a registration is established over TCP, an update can 180 come along in a new TCP connection. Starting then, proxied requests 181 are forwarded along that new connection. 183 2.2.2. Proxy behavior 185 The RD operates as a reverse-proxy as described in [RFC7252] 186 Section 5.7.3 at the announced Proxy URL(s), where it decides based 187 on the requested host and port to which registrant endpoint to 188 forward the request. 190 The address the incoming request are forwarded to is the base address 191 of the registration. If an explicit "base" paremter is given, the RD 192 will forward requests to that location. Otherwise, it forwards to 193 the registration's source address (which is the implied base 194 parameter). 196 When an implicit base is used, the requests forwarded by the RD to 197 the EP contain no Uri-Host option. EPs that want to run multiple 198 parallel registrations (especially gateway-like devices) can either 199 open up separate connections, or use an additional (to-be-specified) 200 mechanism to set the "virtual host name" for that registration in a 201 separate argument. 203 2.2.3. On-Demand proxying 205 If an endpoint is deployed in an unknown network, it might not know 206 whether it is behind a NAT that would require it to configure an 207 explicit base address, and ask the RD to assist by proxying if 208 necessary by registering with the "proxy=ondemand" query parameter. 210 A server receiving that SHOULD use a different IP address to try to 211 access the registrant's .well-known/core file using a GET request 212 under the Registration Base URI. If that succeeds, it may assume 213 that no NAT is present, and ignore the proxying request. Otherwise, 214 it configures proxying as if "proxy=yes" were requested. 216 Note that this is only a heuristic [ and not tested in deployments 217 yet ]. 219 2.2.4. Multiple upstreams 221 When a proxying RD is operating behind a router that has uplinks with 222 multiple provisioning domains (see [RFC7556]) or a similar setup, it 223 MAY mint multiple addresses that are reachable on the respective 224 provisioning domains. When possible, it is preferred to keep the 225 number of URIs handed out low (avoiding URI aliasing); this can be 226 achieved by announcing both the proxy's public addresses under the 227 same wildcard name. 229 If RDs are announced by the uplinks using RDAO, the proxy may use the 230 methods of [I-D.amsuess-core-rd-replication] to distribute its 231 registrations to all the announced upstream RDs. 233 In such setups, the router can forward the upstream RDs using the PvD 234 option ([RFC8801]) to PvD-aware hosts and only announce the local RD 235 to PvD-unaware ones (which then forwards their registrations). It 236 can be expected that PvD-aware endpoints are capable of registering 237 with multiple RDs simultaneously. 239 2.2.5. Examples 241 2.2.5.1. Registration through a firewall 243 Req from [2001:db8:42::9876]:5683: 244 POST coap://rd.example.net/rd?ep=node9876&proxy=ondemand 245 ;rt="example.x" 247 Req from other-address.rd.example.net: 248 GET coap://[2001:db8:42::9876]/.well-known/core 250 Request blocked by stateful firewall around [2001:db8:42::] 252 RD decides that proxying is necessary 254 Res: 2.04 Created 255 Location: /reg/abcd 257 Later, lookup of that registration might say: 259 Req: GET coap://rd.example.net/lookup/res?rt=example.x 261 Res: 2.05 Content 262 ;rt="example.x 264 A request to that resource will end up at an IP address of the RD, 265 which will forward it using its the IP and port on which the 266 registrant had registered as source port, thus reaching the 267 registrant through the stateful firewall. 269 2.2.5.2. Registration from a browser context 271 Req: POST coaps+ws://rd.example.net/rd?ep=node1234&proxy=yes 272 ;rt="core.s" 274 Res: 2.04 Created 275 Location: /reg/123 276 The gyroscope can now not only be looked up in the RD, but also be 277 reached: 279 Req: GET coap://rd.example.net/lookup/res?rt=core.s 281 Res: 2.05 Content 282 ;rt="core.s" 284 In this example, the RD has chosen to do port-based rather than host- 285 based virtual hosting and announces its literal IP address as that 286 allows clients to not send the lengthy Uri-Host option with all 287 requests. 289 2.2.6. Notes on stability and maturity 291 Using this with UDP can be quite fragile; the author only draws on 292 own experience that this can work across cell-phone NATs and does not 293 claim that this will work over generic firewalls. 295 [ It may make sense to have the example as TCP right away. ] 297 2.2.7. Security considerations 299 An RD MAY impose additional restrictions on which endpoints can 300 register for proxying, and thus respond 4.01 Unauthorized to request 301 that would pass had they not requested proxying. 303 Attackers could do third party registrations with an attacked 304 device's address as base URI, though the RD would probably not 305 amplify any attacks in that case. 307 The RD MUST NOT reveal the address at which it reaches the registrant 308 except for adaequately authenticated and authorized debugging 309 purposes, as that address could reveal sensitive location data the 310 registrant may wish to hide by using a proxy. 312 Usual caveats for proxies apply. 314 3. Infinite lifetime 316 An RD can indicate support for infinite lifetimes by adding the 317 resoruce type "TBD2" to its list of resource types. 319 A registrant that wishes to keep its registration alive indefinitely 320 can set the lifetime value as "lt=inf". 322 Registrations with infinite lifetimes never time out. Unlike regular 323 registrations, they are not "soft state"; the registrant can expect 324 the RD to persist the registrations across network changes, reboots, 325 softare updates and that like. 327 Typical use cases for infinite life times are: 329 * Commissioning tools (CTs) that do not return to the deployment 330 site, and thus can not refresh the soft state 332 * Proxy registrations whose lifetime is limited by a connection that 333 is kept alive 335 3.1. Example 337 Had the example of Section 2.2.5.2 discovered support for infinite 338 lifetimes during lookup like this: 340 Req: GET coaps+ws://rd.example.net/.well-known/coer?rt=core.rd* 342 Res: 2.05 Content 343 ;rt="core.rd TBD1 TBD2";ct=40 345 it could register like that: 347 Req: POST coaps+ws://rd.example.net/rd?ep=node1234&proxy=yes<=inf 348 ;rt="core.s" 350 Res: 2.04 Created 351 Location: /reg/123 353 and never need to update the registration for as long as the 354 websocket connection is open. 356 (When it gets terminated, it could try renewing the registration, but 357 needs to be prepared for the RD to already have removed the original 358 registration.) 360 4. Lookup across link relations 362 Resource lookup occasionally needs execute multiple queries to follow 363 links. 365 An RD server (or any other server that supports [RFC6690] compatible 366 lookup), can announce support for following links in resource lookups 367 by announcing support for the TBD3 interface type on its resource 368 lookup. 370 A client can the query that server to not only provide the matched 371 links, but also links that are reachable over relations given in 372 "follow" query parameters. 374 4.1. Example 376 Assume a node presents the following data in its <.well-known/core> 377 resource (and submitted the same to the RD): 379 ;if="core.s";rt="example.temperature", 380 ;rel="calibration-protocol";anchor="/temp", 381 ;rel="describedby";anchor="/temp", 382 ;if="core.s";rt="example.humidity", 383 ;rel="calibration-protocol";anchor="/hum", 385 A lookup client can, in one query, find the temperature sensor and 386 its relevant metadata: 388 Req: GET /rd-lookup/res?rt=example.temperature&follow=calibration-protocol&follow=describedby 390 ;if="core.s";rt="example.temperature";anchor="coap://node1", 391 ;rel="calibration-protocol";anchor="coap://node1/temp", 392 ;rel="describedby";anchor="coap://node1/temp", 394 [ There is a better example (https://github.com/ace-wg/ace-oauth/ 395 issues/120#issuecomment-407997786) in an earlier stage of 396 [I-D.tiloca-core-oscore-discovery] ] 398 Given the likelihood of a CoRAL based successor to [RFC6690], this 399 lookup variant might easily be superseeded by a CoRAL FETCH format; 400 it might look like this there: 402 Req: FETCH /reef-lookup 403 Content-Format: application/template-coral+cbor 404 Payload: 405 #using core = <...> 406 #using reef = <...> 407 reef:content ?x { 408 core:rt "example.temperature" 409 calibration-protocol ?y { 410 core:describedby ?z 411 } 412 } 414 Res: 2.01 Content 415 Content-Format: aplication/coral+cbor 416 Payload: 417 reef:content { 418 core:rt "example.temperature" 419 calibration-protocol { 420 core:describedby 421 } 422 } 424 5. Lifetime Age 426 This extension is described in [I-D.amsuess-core-rd-replication] 427 Section 5.2. 429 The "provenance" extension in Section 5.1 of the same document should 430 probably be expressed differently to avoid using non-target link 431 attributes. 433 6. Zone identifier introspection 435 The 'split-horizon' mechanism introduced in 436 [I-D.ietf-core-resource-directory] (-19) (that registrations with 437 link-local bases can only be read from the zone they registered on) 438 reduces the usability of the endpoint lookup interface for debugging 439 purposes. 441 To allow an administrator to read out the "show-zone-id" query 442 parameter for endpoint and resource lookup is introduced. 444 A Resource Directory that understands this parameter MUST NOT limit 445 lookup results to registrations from the lookup's zone, and MUST use 446 [RFC6874] zone identifiers to annotate which zone those registrations 447 are valid on. 449 The RD MUST limit such requests to authenticated and authorized 450 debugging requests, as registrants may rely on the RD to keep their 451 presence secret from other links. 453 6.1. Example 455 Req: GET /rd-lookup/ep?show-zone-id&et=printer 457 Res: 2.05 Content 458 ;base="coap://[2001:db8::1]";et=printer;ep="bigprinter", 459 ;base="coap://[fe80::99%wlan0]";et=printer;ep="localprinter-1234", 460 ;base="coap://[fe80::99%eth2]";et=printer;ep="localprinter-5678", 462 7. Proxying multicast requests 464 Multicast requests are hard to forward at a proxy: Even if a media 465 type is used in which multiple responses can be aggregated 466 transparently, the proxy can not reliably know when all responses 467 have come in. [RFC7390] Section 2.9 destribes the difficulties in 468 more detail. 470 Note that [I-D.tiloca-core-groupcomm-proxy] provides a mechanism that 471 _does_ allow the forwarding of multicast requests. It is yet to be 472 determined what the respective pros and cons are. Conversely, that 473 lookup mechanism may also serve as an alternative to resource lookup 474 on an RD. 476 A proxy MAY expose an interface compatible with the RD lookup 477 interface, which SHOULD be advertised by a link to it that indicates 478 the resource types core.rd-lookup-res and TBD4. 480 The proxy sends multicast requests to All CoAP Nodes ([RFC7252] 481 Section 12.8) requesting their .well-known/core files either eagerly 482 (ie. in regular intervals independent of queries) or on demand (in 483 which case it SHOULD limit the results by applying [RFC6690] query 484 filtering; if it has received multiple query parameters it should 485 forward the one it deems most likely to limit the results, as .well- 486 known/core only supports a single query parameter). 488 In comparison to classical RD operation, this RD behaves roughly as 489 if it had received a simple registration with a All CoAP Nodes 490 address as the source address, if such behavior were specified. The 491 individual registrations that result from this neither have an 492 explicit registration resource nor an explicit endpoint name; given 493 that the endpoint lookup interface is not present on such proxies, 494 neither can be queried. 496 Clients that would intend to do run a multicast discovery operation 497 behind the proxy can then instead query that resource lookup 498 interface. They SHOULD use observation on lookups, as an on-demand 499 implementation MAY return the first result before others have 500 arrived, or MAY even return an empty link set immediately. 502 7.1. Example 504 Req: GET coap+ws://gateway.example.com/.well-known/core?rt=TBD4 506 Res: 2.05 Content 507 ;rt="core.rd-lookup-res TBD4";ct=40 509 Req: GET coap+ws://gateway.example.com/discover?rt=core.s 510 Observe: 0 512 Res: 2.05 Content 513 Observe: 0 514 Content-Format: 40 515 (empty payload) 517 At the same time, the proxy sends out multicast requests on its 518 interfaces: 520 Req: GET coap://ff05::fd/.well-known/core?rt=core.s 522 Res (from [2001:db8::1]:5683): 2.05 Content 523 ;ct="0 112";rt="core.s" 525 Res (from [2001:db8::2]:5683): 2.05 Content 526 ;ct="0 112";rt="core.s" 528 upon receipt of which it sends out a notification to the websocket 529 client: 531 Res: 2.05 Content 532 Observe: 1 533 Content-Format: 40 534 ;ct="0 112";rt="core.s";anchor="coap://[2001:db8::1]", 535 ;ct="0 112";rt="core.s";anchro="coap://[2001:db8::2]" 537 8. Opportunistic RD 539 An application that wants to advertise its resources in Resource 540 Directory can find itself in a network that has no RD deployed. It 541 may be able to start an RD on its own to fill in that gap until an 542 explicitly configured one gets installed. 544 This bears the risk of having competing RDs on the same network, 545 where resources registered at one can not be discovered on the other. 546 To mitigate that, such Opportunistic Resource Directories should 547 follow those steps: 549 * The RD chooses its own Opportunistic Capability value. That 550 integer number is an estimate of number of target attributes it 551 expects to be able to store, where in absence of better estimates 552 one would assume that a registration contains 16 links, and each 553 links contains three target attributes each with an eight byte key 554 and a 16 byte value. 556 The Opportunistic Capability value is advertised as a TBD5-cap= 557 target attribute on the registration resource. 559 * The RD chooses its own Opportunistic Tie-Break value. That 560 integer number needs no other properties than being likely to be 561 different even for two instances of the same device being started; 562 numeric forms of MAC addresses or random numbers make good 563 candidates. 565 The Opportunistic Capability value is advertised as a TBD5-tie= 566 target attribute on the registration resource. 568 * The Opportunistic RD, before advertising its resources, performs 569 RD discovery itself, using at least all the discovery paths it may 570 become discoverable on itself. 572 * If the Opportunistic RD finds no other RD, or if the RD it finds 573 is less capable than itself, it can start advertising itself as a 574 Resource Directory. 576 An RD is called more capable than another if its TBD5-cap value is 577 greater than the other's, or if its TBD5-tie value is greater than 578 the other's if the former results in a tie. Absent or unparsable 579 attributes are considered greater than any present attribute. 581 In case an RD observes a tie even after evaluating the tie 582 breaker, it may change its Opportunistic Tie-Break value if that 583 was picked randomly, or reevaluate its life choices if it uses its 584 own MAC address. 586 * A running Opportunistic RD needs to perform discovery for other 587 RDs repeatedly. If it discovers a more capable RD, it stops 588 advertising its own resources. It should continue to serve lookup 589 requests, but refuse any new registration or registration updates 590 (which will trigger the registrant endpoints to look for a new 591 RD). 593 An inactive Opportunistic RD will be notified of the highter 594 capability RD's shutdown by the expiry of whatever it may be 595 started to advertise that was now advertised there; see below for 596 possible improvements. 598 * An RD that discovers an Opportunistic RD of lower capability may 599 speed up the transition process by (not mutually exclusive) two 600 ways 602 - It can register its own (registration) resource(s) into the 603 lower capability directory. That RD can take that as having 604 discovered a higher capability RD and stop advertising. 606 - It can expose resources and registrations of the lower 607 capability directory using the methods described in 608 [I-D.amsuess-core-rd-replication]. 610 * An Opportunistic RD that yields to a more capable RD may ease the 611 transition by attempting to register its active registrations at 612 the more capable RD, taking the role of a CT. The lifetimes 613 picked for those must not exceed the remaining lifetime of its 614 registrations, and it must not renew those registrations. 616 Future iterations of this document may want to cut down on the 617 possibilities listed above. 619 Some ideas are around for making the shutdown of a commissioned or 620 otherwise high-capability RD more graceful, but they still have some 621 problems 623 * Setting a commissioned or high-capability RD's Capability to zero 624 in preparation of the shutdown may create loops in any distributed 625 lookups. 627 * Asking the lower capability RD to register its registration 628 resource (even though not otherwise advertised) at the higher 629 capability RD still creates a situation where clients may find two 630 RDs running simultaneously, and we can't expect clients to make 631 any decisions based on TBD5 values. 633 * Asking the higher capability RD to register its registration 634 resource with the lower capability RD contradicts the current 635 recommendation for the passive Opportunistic RD to not accept 636 registrations / renewals. Also, the deployed RD may not know that 637 Opportunistic RDs are a thing. 639 * Advertising an almost-but-not-quite rt= value on passive 640 registration resources may be an option, but needs to be thought 641 through thoroughly. 643 Installations of Opportunistic RDs are at special risk of resource 644 exhaustion because they are not sized with their actual deployment in 645 mind, but rely on defaults set by the application that starts the RD. 646 Opportunistic RDs should only be started if the application's 647 administrator can be informed in a timely fashion when the RD's 648 resources are nearing exhaustion; guidance towards installing a more 649 capable RD on the network should be provided in that case. 651 8.1. Applications 653 * Group managers using [I-D.tiloca-core-oscore-discovery] can ship 654 its own low-priority Opportunistic RD to announce its join 655 resources. This provides benefits over announcing them on 656 multicast discovery if the network can efficiently route requests 657 to the All CoAP Resource Directories multicast address (so group 658 members get a response back from an early focused request to all 659 RDs rather than falling back to multicasting All CoAP Nodes for 660 "?rt=osc.j&..."), or if discovery of the group's multicast address 661 is used. 663 * Administrative tools that try to provide a broad overview of a 664 network's CoAP devices could offer to open an Opportunistic RD if 665 they find no active RD on the network (but should ask the user in 666 interactive scenarios). 668 That allows them to see devices that newly join the network 669 quickly (by observing their own or the found RD), rather than 670 relying periodic multicasts. 672 9. References 674 9.1. Normative References 676 [I-D.amsuess-core-rd-replication] 677 Amsuess, C., "Resource Directory Replication", Work in 678 Progress, Internet-Draft, draft-amsuess-core-rd- 679 replication-02, 11 March 2019, . 682 [I-D.ietf-core-resource-directory] 683 Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. 684 Stok, "CoRE Resource Directory", Work in Progress, 685 Internet-Draft, draft-ietf-core-resource-directory-26, 2 686 November 2020, . 689 [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing 690 IPv6 Zone Identifiers in Address Literals and Uniform 691 Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, 692 February 2013, . 694 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 695 Application Protocol (CoAP)", RFC 7252, 696 DOI 10.17487/RFC7252, June 2014, 697 . 699 9.2. Informative References 701 [I-D.silverajan-core-coap-protocol-negotiation] 702 Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", 703 Work in Progress, Internet-Draft, draft-silverajan-core- 704 coap-protocol-negotiation-09, 2 July 2018, 705 . 708 [I-D.tiloca-core-groupcomm-proxy] 709 Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group 710 Communication", Work in Progress, Internet-Draft, draft- 711 tiloca-core-groupcomm-proxy-02, 2 November 2020, 712 . 715 [I-D.tiloca-core-oscore-discovery] 716 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 717 Groups with the CoRE Resource Directory", Work in 718 Progress, Internet-Draft, draft-tiloca-core-oscore- 719 discovery-07, 2 November 2020, . 723 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 724 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 725 . 727 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 728 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 729 DOI 10.17487/RFC6887, April 2013, 730 . 732 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 733 the Constrained Application Protocol (CoAP)", RFC 7390, 734 DOI 10.17487/RFC7390, October 2014, 735 . 737 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 738 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 739 . 741 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 742 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 743 Application Protocol) over TCP, TLS, and WebSockets", 744 RFC 8323, DOI 10.17487/RFC8323, February 2018, 745 . 747 [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. 748 Shao, "Discovering Provisioning Domain Names and Data", 749 RFC 8801, DOI 10.17487/RFC8801, July 2020, 750 . 752 Appendix A. Change log 754 Since -04: 756 * Minor adjustments: 758 - Mention LwM2M and how it is already doing RD proxying. 760 - Tie proxying in with infinite lifetimes. 762 - Remove note on not being able to switch protocols: RDs that 763 support some future protocol negotiation can do that. 765 - Point out that there is no Uri-Host from the RD proxy to the 766 EP, but there could be. 768 - Infinite lifetimes: Take up CTs more explicitly from RD 769 discussion. 771 - Start exploring interactions with groupcomm-proxy. 773 Since -03: 775 * Added interaction with PvD (Provisioning Domains) 777 Since -02: 779 * Added abstract 781 * Added example of CoRAL FETCH to Lookup across link relations 782 section 784 Since -01: 786 * Added section on Opportunistic RDs 788 Since -00: 790 * Add multicast proxy usage pattern 792 * ondemand proxying: Probing queries must be sent from a different 793 address 795 * proxying: Point to RFC7252 to describe how the actual proxying 796 happens 798 * proxying: Describe this as a last-resort options and suggest 799 attempting PCP first 801 Appendix B. Acknowledgements 803 [ Reviews from: Jaime Jimenez ] 805 Author's Address 807 Christian Amsüss 808 Hollandstr. 12/4 809 1020 810 Austria 812 Phone: +43-664-9790639 813 Email: christian@amsuess.com