idnits 2.17.1 draft-ietf-core-groupcomm-09.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 29, 2013) is 3978 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: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-17 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-11 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-04 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group A. Rahman, Ed. 3 Internet-Draft InterDigital Communications, LLC 4 Intended status: Informational E.O. Dijk, Ed. 5 Expires: November 30, 2013 Philips Research 6 May 29, 2013 8 Group Communication for CoAP 9 draft-ietf-core-groupcomm-09 11 Abstract 13 CoAP is a RESTful transfer protocol for constrained devices and 14 constrained networks. It is anticipated that constrained devices 15 will often naturally operate in groups (e.g., in a building 16 automation scenario all lights in a given room may need to be 17 switched on/off as a group). This document provides guidance for how 18 the CoAP protocol should be used in a group communication context. 19 An approach for using CoAP on top of IP multicast is detailed. Also, 20 various use cases and corresponding protocol flows are provided to 21 illustrate important concepts. Finally, guidance is provided for 22 deployment in various network topologies. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 30, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Protocol Considerations . . . . . . . . . . . . . . . . . . . 4 63 3.1. IP Multicast Background . . . . . . . . . . . . . . . . . 4 64 3.2. Group Definition and Naming . . . . . . . . . . . . . . . 5 65 3.3. Port and URI Configuration . . . . . . . . . . . . . . . 6 66 3.4. Group Methods . . . . . . . . . . . . . . . . . . . . . . 7 67 3.5. Group Member Discovery . . . . . . . . . . . . . . . . . 7 68 3.6. Configuring Group Membership in Endpoints . . . . . . . . 7 69 3.7. Multicast Request Acceptance and Response Suppression . . 9 70 3.8. Congestion Control . . . . . . . . . . . . . . . . . . . 11 71 3.9. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 12 72 3.10. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 14 73 4. Use Cases and Corresponding Protocol Flows . . . . . . . . . 14 74 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 14 75 4.2. Network Configuration . . . . . . . . . . . . . . . . . . 14 76 4.3. Discovery of Resource Directory . . . . . . . . . . . . . 16 77 4.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 18 78 4.5. Lighting Control in MLD Enabled Network . . . . . . . . . 21 79 4.6. Commissioning the Network Based On Resource Directory . . 22 80 5. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 23 81 5.1. Target Network Topologies . . . . . . . . . . . . . . . . 23 82 5.2. Advertising Membership of Multicast Groups . . . . . . . 23 83 5.2.1. Using the MLD Listener Protocol . . . . . . . . . . . 23 84 5.2.2. Using the RPL Routing Protocol . . . . . . . . . . . 24 85 5.2.3. Using the MPL Forwarding Protocol . . . . . . . . . . 24 86 5.3. 6LoWPAN Specific Guidelines . . . . . . . . . . . . . . . 24 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 88 6.1. Security Configuration . . . . . . . . . . . . . . . . . 25 89 6.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 6.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 26 91 6.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 26 92 6.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 26 93 6.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 26 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 95 7.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 27 96 7.2. New 'coap-group+json' Internet Media Type . . . . . . . . 27 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 101 9.2. Informative References . . . . . . . . . . . . . . . . . 30 102 Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 30 103 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 31 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 106 1. Conventions and Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 [RFC2119]. 113 The above key words are used to establish a set of guidelines for 114 CoAP group communication. An implementation of CoAP group 115 communication MAY implement these guidelines; an implementation 116 claiming compliance to this document MUST implement the set of 117 guidelines. 119 This document assumes readers are familiar with the terms and 120 concepts that are used in [I-D.ietf-core-coap]. In addition, this 121 document defines the following terminology: 123 Group Communication 124 A source node sends a single message which is delivered to 125 multiple destination nodes, where all destinations are identified 126 to belong to a specific group. The source node itself may be part 127 of the group. The underlying mechanism for group communication is 128 assumed to be multicast based. The network involved may be a 129 constrained network such as a low-power, lossy network. 131 Multicast 132 Sending a message to multiple destination nodes with one network 133 invocation. There are various options to implement multicast 134 including layer 2 (Media Access Control) and layer 3 (IP) 135 mechanisms. 137 IP Multicast 138 A specific multicast solution based on the use of IP multicast 139 addresses as defined in "IANA Guidelines for IPv4 Multicast 140 Address Assignments" [RFC5771] and "IP Version 6 Addressing 141 Architecture" [RFC4291]. 143 Low power and Lossy Network (LLN) 144 A type of constrained IP network where devices are interconnected 145 by a variety of low-power and lossy links (such as IEEE 802.15.4, 146 Bluetooth Low Energy (BLE), Digital Enhanced Cordless 147 Telecommunication (DECT)) or lossy links (such as IEEE P1901.2 148 power-line communication). 150 2. Introduction 152 2.1. Background 154 Constrained Application Protocol (CoAP) is a Representational State 155 Transfer (REST) based approach for resource constrained devices 156 operating in an IP network [I-D.ietf-core-coap]. CoAP has many 157 similarities to HTTP [RFC2616] but also has some key differences. 158 Constrained devices can be large in number, but are often highly 159 correlated to each other (e.g., by type or location). For example, 160 all the light switches in a building may belong to one group and all 161 the thermostats may belong to another group. Groups may be pre- 162 configured before deployment or dynamically formed during operation. 163 If information needs to be sent to or received from a group of 164 devices, group communication mechanisms can improve efficiency and 165 latency of communication and reduce bandwidth requirements for a 166 given application. HTTP does not support any equivalent 167 functionality to CoAP group communication. 169 2.2. Scope 171 Group communication involves sending a CoAP Request as an IP 172 Multicast message and handling the potential multitude of (unicast) 173 CoAP Responses. The normative protocol aspects of running CoAP on 174 top of IP Multicast and processing the responses are given in 175 [I-D.ietf-core-coap]. The main contribution of this document lies in 176 providing additional guidance for key group communication features. 177 Among the topics covered are group definition, group resource 178 manipulation, and group configuration. Also, proxy operation and 179 minimizing congestion scenarios for group communication is discussed. 180 Finally, specific use case behavior and deployment guidelines are 181 outlined for CoAP group communication. 183 3. Protocol Considerations 185 3.1. IP Multicast Background 187 IP Multicast protocols have been evolving for decades, resulting in 188 proposed standards such as Protocol Independent Multicast - Sparse 189 Mode (PIM-SM) [RFC4601]. Yet, due to various technical and business 190 reasons, IP Multicast is not widely deployed on the general Internet. 191 However, IP Multicast is very popular in specific deployments such as 192 in enterprise networks (e.g., for video conferencing), smart home 193 networks (e.g., Universal Plug and Play (UPnP)) and carrier IPTV 194 deployments. The packet economy and minimal host complexity of IP 195 multicast make it attractive for group communication in constrained 196 environments. 198 To achieve IP multicast beyond a subnet, an IP multicast routing or 199 forwarding protocol needs to be active on IP routers. An example of 200 a routing protocol specifically for LLNs is the IPv6 Routing Protocol 201 for Low-Power and Lossy Networks (RPL) (Section 12 of [RFC6550]) and 202 an example of a forwarding protocol for LLNs is Multicast Protocol 203 for Low power and Lossy Networks (MPL) [I-D.ietf-roll-trickle-mcast]. 204 Finally, PIM-SM [RFC4601] is often used for multicast routing in un- 205 constrained networks. 207 IP multicast can also be run in a Link-Local (LL) scope. This means 208 that there is no routing involved and an IP multicast message is only 209 received over the link on which it was sent. 211 For a complete IP multicast solution, in addition to a routing/ 212 forwarding protocol, a so-called "listener" protocol is needed for 213 the devices to subscribe to groups (see Section 5.2). 215 3.2. Group Definition and Naming 217 A group is defined as a set of CoAP endpoints, where each endpoint is 218 configured to receive a multicast CoAP request that is sent to the 219 group's associated IP multicast address. An endpoint MAY be a member 220 of multiple groups. Group membership of an endpoint MAY dynamically 221 change over time. 223 For group communication, the Group URI will be the CoAP request URI. 224 A Group URI has the scheme 'coap' and includes in the authority part 225 either a group IP multicast address plus optional port number; or a 226 hostname (e.g., Group Fully Qualified Domain Name (FQDN)) plus 227 optional port number that can be resolved to the group IP multicast 228 address. Group URIs follow the CoAP URI syntax [I-D.ietf-core-coap]. 230 It is recommended, for sending nodes, to use the IP multicast address 231 literal as the default for the Group URI. If a Group FQDN is used, 232 it can be uniquely mapped to a site-local or global IP multicast 233 address via DNS resolution (if supported). Some examples of 234 hierarchical Group FQDN naming (and scoping) for a building control 235 application are shown below ([I-D.vanderstok-core-dna]): 237 URI authority Targeted group 238 --------------------------- ----------------------------------- 239 all.bldg6.example.com "all nodes in building 6" 240 all.west.bldg6.example.com "all nodes in west wing, building 6" 241 all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, 242 building 6" 243 all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, 244 west wing, building 6" 246 Similarly, if supported, reverse mapping (from IP multicast address 247 to Group FQDN) is possible using the reverse DNS resolution technique 248 ([I-D.vanderstok-core-dna]). 250 3.3. Port and URI Configuration 252 A CoAP group member listens for CoAP messages on the group's IP 253 multicast address, on a specified UDP port. The default UDP port is 254 the CoAP default port of 5683 but a non-default UDP port MAY be 255 specified for the group; in which case implementers MUST ensure that 256 all group members are configured to use this same port. 258 Multicast based group communication will not work if there diversity 259 in the authority port (i.e., a diversity of dynamic port addresses 260 across the group) or if the resources are located at different paths 261 on different endpoints. Therefore, some measures must be present to 262 ensure uniformity in port number and resource names/locations within 263 a group. All CoAP multicast requests MUST be sent using the port 264 number as follows: 266 1. A pre-configured port number, if available. The pre- 267 configuration mechanism MUST ensure that the same port number is 268 pre-configured across all endpoints in a group and across all 269 CoAP clients performing the group requests. 271 2. If the client is configured to use service discovery including 272 port discovery, it uses a port number obtained via a service 273 discovery lookup operation as a valid CoAP port for the targeted 274 CoAP multicast group. 276 3. Otherwise use the default CoAP UDP port (5683). 278 All CoAP multicast requests SHOULD operate on URI paths ("links") 279 only in one or more of the following ways: 281 1. Pre-configured URI paths, if available. The pre-configuration 282 mechanism SHOULD ensure that these URIs are pre-configured across 283 all CoAP servers in a group and all CoAP clients performing the 284 group requests. 286 2. If the client is configured to use default CoRE resource 287 discovery, it uses URI paths retrieved from a "/.well-known/core" 288 lookup on a group member. The URI paths the client will use MUST 289 be known to be available also in all other endpoints in the 290 group. The URI path configuration mechanism on servers MUST 291 ensure that these URIs (identified as being supported by the 292 group) are configured on all group endpoints. 294 3. If the client is configured to use another form of service 295 discovery, it uses URI paths from an equivalent service discovery 296 lookup which returns the resources supported by all group 297 members. 299 3.4. Group Methods 301 Group communication MUST be used for idempotent methods (i.e., CoAP 302 GET, PUT, and DELETE). Group communication MAY be used for non- 303 idempotent methods (i.e., CoAP POST) if the resource being POSTed is 304 designed to support the lossy nature of multicast. Note that not all 305 group members are guaranteed to receive the multicast request, and 306 the sender cannot readily find out which group members did not 307 receive it. 309 All CoAP messages that are sent via multicast MUST be Non- 310 Confirmable. A unicast response per server MAY be sent back to 311 answer the group communication request (e.g., response "2.05 Content" 312 to a group GET request) taking into account the congestion control 313 rules defined in Section 3.8. The unicast responses received may be 314 a mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not 315 Found) codes depending on the individual server processing result. 317 3.5. Group Member Discovery 319 CoAP defines a resource discovery capability [RFC6690], but does not 320 specify how to discover groups (e.g., find a group to join or send a 321 multicast message to) or how to discover members of a group (e.g., to 322 address selected group members by unicast). A simple ad-hoc method 323 to discover members of a CoAP group would be to send a multicast 324 "CoAP ping" [I-D.ietf-core-coap]. The collected responses to the 325 ping would then give an indication of the group members. 327 3.6. Configuring Group Membership in Endpoints 329 The group membership of a CoAP endpoint may be configured in one of 330 the following ways. First, the group membership may be pre- 331 configured before node deployment. Second, a node may be programmed 332 to discover (query) its group membership during operation using a 333 specific service discovery means. Third, it may be configured during 334 operation by another node (e.g., a commissioning device). 336 In the first case, the pre-configured group information may be either 337 directly a IP multicast address, or a hostname (FQDN) which is during 338 operation resolved to a IP multicast address by the endpoint using 339 DNS (if supported). 341 For the second case, a CoAP endpoint may look up its group membership 342 using techniques such as DNS-SD and Resource Directory 343 [I-D.shelby-core-resource-directory]. The latter is detailed more in 344 Section 4.6. 346 In the third case, typical in scenarios such as building control, a 347 commissioning tool determines to which group a sensor or actuator 348 node belongs, and writes this information to the node, which can 349 subsequently join the correct IP multicast group on its network 350 interface. The information written may again be a IP multicast 351 address or a hostname. 353 To achieve better interoperability between endpoints from different 354 manufacturers, an OPTIONAL RESTful interface for configuring CoAP 355 endpoints with relevant group information is described here. This 356 interface provides a solution for the third case mentioned above. To 357 access this interface a client MUST use unicast methods (GET/PUT/POST 358 /DELETE) only as it is a method of configuring group information in 359 individual endpoints. Using multicast operations in this situation 360 may lead to unexpected (possibly circular) behavior in the network. 362 CoAP endpoints implementing this optional mechanism MUST support the 363 group configuration Internet Media Type "application/coap-group+json" 364 (Section 7.2). A resource offering this representation can be 365 annotated for direct discovery [RFC6690] using the resource type (rt) 366 "core.gp" where "gp" is shorthand for "group" (Section 7.1). An 367 authorized controller uses this media type to query/manage group 368 membership of a CoAP endpoint as defined below. 370 The group configuration resource has a JSON-based content format (as 371 indicated by the media type). A (unicast) GET on a resource 372 accepting this format returns a JSON array of group objects, each 373 group object formatted as shown below: 375 Req: GET /gp 376 Res: 2.05 Content (Content-Format: application/coap-group+json) 377 [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", 378 "ip": "ff15::4200:f7fe:ed37:14ca" } 379 ] 381 where the OPTIONAL "n" key/value pair defines the Group name as FQDN 382 and the OPTIONAL "ip" key/value pair defines the associated IP 383 multicast address. If the IP multicast address is given, this takes 384 priority. The Group name is just informational in this case. If 385 only a Group name is given, the CoAP endpoint has to do DNS 386 resolution (if supported) to obtain the IP multicast address. 388 Note that each group object in the JSON array represents a single IP 389 multicast group for the endpoint. If there are multiple elements in 390 the array then the endpoint is a member of multiple IP multicast 391 groups. 393 A (unicast) POST with a group configuration media type as payload 394 instructs the CoAP endpoint to join the defined group(s). The 395 endpoint adds the specified IP multicast address(es) to its network 396 interface configuration. The endpoint also updates the resource by 397 adding the specified group object(s) to the existing ones: 399 Req: POST /gp (Content-Format: application/coap-group+json) 400 { "n": "floor1.west.bldg6.example.com", 401 "ip": "ff15::4200:f7fe:ed37:14cb" } 402 Res: 2.04 Changed 404 A (unicast) PUT with a group configuration media type as payload will 405 replace all current group memberships in the endpoint with the new 406 ones defined in the PUT request. A (unicast) DELETE with a group 407 configuration media type will delete all group memberships from the 408 endpoint. 410 After any change on a Group configuration resource, the endpoint MUST 411 effect registration/de-registration from the corresponding IP 412 multicast group(s) as soon as possible. Finally, any (unicast) 413 operation to change a CoAP endpoint group membership configuration 414 (i.e., PUT/POST/DELETE) SHOULD use DTLS-secured CoAP 415 [I-D.ietf-core-coap]. Thus only authorized controllers should be 416 allowed by an endpoint to configure its group membership. 418 3.7. Multicast Request Acceptance and Response Suppression 420 CoAP [I-D.ietf-core-coap] and CoRE Link Format [RFC6690] define 421 normative behaviors for: 423 1. Multicast request acceptance - in which cases a request is 424 accepted and executed, and when not. 426 2. Multicast response suppression - in which cases the response of 427 an executed request is returned to the requesting endpoint, and 428 when not. 430 This section first summarizes these normative behaviors and then 431 presents additional guidelines for response suppression. Also a 432 number of multicast example applications are given to illustrate the 433 overall approach. 435 To apply any rules for request and/or response suppression, a CoAP 436 server must be aware that an incoming request arrived via multicast 437 by making use of APIs such as IPV6_RECVPKTINFO [RFC3542]. 439 For multicast request acceptance, the behaviors are: 441 o A server SHOULD NOT accept a multicast request that cannot be 442 "authenticated" in some way (cryptographically or by some 443 multicast boundary limiting the potential sources) 444 [I-D.ietf-core-coap]. See Section 6.3 for examples of multicast 445 boundary limiting methods. 447 o A server SHOULD NOT accept a multicast discovery request with a 448 query string (as defined in CoRE Link Format [RFC6690]) if 449 filtering ([RFC6690]) is not supported by the server. 451 o A server SHOULD NOT accept a multicast request that acts on a 452 specific resource for which multicast support is not required. 453 (Note that for discovery resource "/.well-known/core" multicast 454 support is always required. Implementers are advised to disable 455 multicast support by default on any other resource, until 456 explicitly enabled by an application.) 458 o Otherwise accept the multicast request. 460 For multicast response suppression, the behaviors are: 462 o A server SHOULD NOT respond to a multicast discovery request if 463 the filter specified by the request's query string does not match. 465 o A server MAY choose not to respond to a multicast request, if 466 there's nothing useful to respond (e.g., error or empty response). 468 o If the server API cannot indicate that an incoming message was 469 multicast, then the server SHOULD NOT respond for incoming 470 messages for selected resources which are known (through 471 application knowledge) to be used for multicast requests. 473 o Otherwise respond to the multicast request. 475 The above response suppression behaviors are complemented by the 476 following guidelines. CoAP servers SHOULD implement configurable 477 response suppression, enabling at least the following per resource: 479 o Suppression of all 2.xx success responses; 481 o Suppression of all 4.xx client errors; 483 o Suppression of all 5.xx server errors; 485 o Suppression of all 2.05 responses with empty payload. 487 A number of group communication example applications are given below 488 to illustrate how to make use of response suppression: 490 o CoAP resource discovery: Suppress 2.05 responses with empty 491 payload and all 4.xx and 5.xx errors. 493 o Lighting control: Suppress all 2.xx responses after a lighting 494 change command. 496 o Update group configuration data using multicast PUT: No 497 suppression at all. The client uses collected responses to 498 identify which group members did not receive the new 499 configuration; then attempt using CoAP CON unicast to update those 500 group members. 502 o Multicast firmware update by sending blocks of data: Suppress all 503 2.xx and 5.xx responses. After having sent all multicast blocks, 504 the client checks each endpoint by unicast to identify which 505 blocks are still missing in each endpoint. 507 o Conditional reporting for a group (e.g., sensors) based on a URI 508 query: Suppress all 2.05 responses with empty payload (i.e., if a 509 query produces no matching results). 511 3.8. Congestion Control 513 Multicast CoAP requests may result in a multitude of replies from 514 different nodes, potentially causing congestion. Therefore both the 515 sending of multicast requests and sending unicast CoAP responses to 516 multicast requests should be conservatively controlled. 518 CoAP [I-D.ietf-core-coap] reduces multicast-specific congestion risks 519 through the following measures: 521 o A server MAY choose not to respond to a multicast request if 522 there's nothing useful to respond (e.g., error or empty response). 523 See Section 3.7 for more detailed guidelines on response 524 suppression. 526 o A server SHOULD limit the support for multicast requests to 527 specific resources where multicast operation is required. 529 o A multicast request MUST be Non-Confirmable. 531 o A response to a multicast request SHOULD be Non-Confirmable 532 (Section 5.2.3). 534 o A server does not respond immediately to a multicast request, but 535 SHOULD first wait for a time that is randomly picked within a 536 predetermined time interval called the Leisure. 538 o A server SHOULD NOT accept multicast requests that can not be 539 authenticated in some way. See Section 3.7 for more details on 540 request suppression and multicast source authentication. 542 Additional guidelines to reduce congestion risks are: 544 o A server in an LLN should only support multicast GET for resources 545 that are small, e.g., the payload of the response fits into a 546 single link-layer frame. 548 o A server can minimize the payload length in response to a 549 multicast GET on "/.well-known/core" by using hierarchy in 550 arranging link descriptions for the response. An example of this 551 is given in Section 5 of [RFC6690]. 553 o Alternatively a server can also minimize the payload length of a 554 response to a multicast GET (e.g., on "/.well-known/core") using 555 CoAP blockwise transfers [I-D.ietf-core-block], returning only a 556 first block of the link format description. 558 o A client should always aim to use IP multicast with link-local 559 scope if possible. If this is not possible, then site-local scope 560 IP multicast should be considered. If this is not possible, then 561 global scope IP multicast should be considered as a last resort 562 only. 564 3.9. Proxy Operation 565 CoAP [I-D.ietf-core-coap] allows a client to request a forward-proxy 566 to process its CoAP request. For this purpose the client either 567 specifies the request URI as a string in the Proxy-URI option, or it 568 specifies the Proxy-Scheme option with the URI constructed from the 569 usual Uri-* options. This approach works well for unicast requests. 570 However, there are certain issues and limitations of processing the 571 (unicast) responses to a group communication request made in this 572 manner through a proxy. Specifically, if a proxy would apply 573 aggregation of responses in such a case: 575 o Aggregation of (unicast) responses to a group communication 576 request in a proxy is difficult. This is because the proxy does 577 not know how many members there are in the group or how many group 578 members will actually respond. 580 o There is no default format defined in CoAP for aggregation of 581 multiple responses into a single response. 583 But if a proxy follows the specification for a CoAP Proxy 584 [I-D.ietf-core-coap], the proxy would simply forward all the 585 individual (unicast) responses to a group communication request to 586 the client (i.e., no aggregation). There are also issues with this 587 approach: 589 o The client may be confused as it may not have known that the 590 Proxy-URI contained a multicast target. That is, the client may 591 be expecting only one (unicast) response but instead receives 592 multiple (unicast) responses potentially leading to fault 593 conditions in the application. 595 o Each individual CoAP response will appear to originate (IP Source 596 address) from the CoAP Proxy, and not from the server that 597 produced the response. This makes it impossible for the client to 598 identify the server that produced each response. 600 Due to above issues, a guideline is defined here that a CoAP Proxy 601 SHOULD NOT support processing a multicast CoAP request but rather 602 return a 501 (Not Implemented) response in such case. The exception 603 case here (i.e., to process it) is allowed under following 604 conditions: 606 o The CoAP Proxy MUST be explicitly configured (whitelist) to allow 607 proxied multicast requests by specific client(s). 609 o The proxy SHOULD return individual (unicast) CoAP responses to the 610 client (i.e., not aggregated). The exception case here occurs 611 when a (future) standardized aggregation format is being used. 613 o It MUST be known to the person/entity doing the configuration of 614 the proxy, or verified in some way, that the client configured in 615 the whitelist supports receiving multiple responses to a proxied 616 unicast CoAP request. 618 3.10. Exceptions 620 Group communication using IP multicast offers improved network 621 efficiency and latency amongst other benefits. However, group 622 communication may not always be possible to implement in a given 623 network. The primary reason for this will be if IP multicast is not 624 (fully) supported in the network. For example, assume an LLN where 625 the MPL protocol is not supported, but the RPL protocol is used for 626 routing multicast packets. Also assume the RPL routers operate in 627 "Non-storing mode" [RFC6550]. Then there will be no IP multicast 628 routing in this network beyond link-local scope. This means that any 629 CoAP group communication above link-local scope will not be supported 630 in this network. 632 4. Use Cases and Corresponding Protocol Flows 634 4.1. Introduction 636 The use of CoAP group communication is shown in the context of the 637 following two use cases and corresponding protocol flows: 639 o Discovery of Resource Directory (RD, 640 [I-D.shelby-core-resource-directory]): discovering the local CoAP 641 RD which contains links (URIs) to resources stored on other CoAP 642 servers [RFC6690]. 644 o Lighting Control: synchronous operation of a group of 645 IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights). 647 4.2. Network Configuration 649 To illustrate the use cases we define two network configurations. 650 Both are based on the topology as shown in Figure 1. The two 651 configurations using this topology are: 653 1. Subnets are 6LoWPAN networks; the routers Rtr-1 and Rtr-2 are 654 6LoWPAN Border Routers (6LBRs, [RFC6775]). 656 2. Subnets are Ethernet links; the routers Rtr-1 and Rtr-2 are 657 multicast-capable Ethernet routers. 659 Both configurations are further specified by the following: 661 o A large room (Room-A) with three lights (Light-1, Light-2, 662 Light-3) controlled by a Light Switch. The devices are organized 663 into two subnets. In reality, there could be more lights (up to 664 several hundreds) but these are not shown for clarity. 666 o Light-1 and the Light Switch are connected to a router (Rtr-1). 668 o Light-2 and the Light-3 are connected to another router (Rtr-2). 670 o The routers are connected to an IPv6 network backbone which is 671 also multicast enabled. In the general case, this means the 672 network backbone and Rtr-1/Rtr-2 support a PIM based multicast 673 routing protocol, and Multicast Listener Discovery (MLD) for 674 forming groups. In a limited case, if the network backbone is one 675 link, then the routers only have to support MLD-snooping 676 (Appendix A) for the following use cases to work. 678 o A CoAP RD is connected to the network backbone. 680 o The DNS server is optional. If the server is there (connected to 681 the network backbone) then certain DNS based features are 682 available (e.g., DNS resolution of URI to IP multicast address). 683 If the DNS server is not there, then different manual provisioning 684 of the network is required (e.g., IP multicast addresses are hard- 685 coded into devices). 687 o A Controller (client) is connected to the backbone, which is able 688 to control various building functions including lighting. 690 Network 691 Backbone 692 ################################################ | 693 # ********************** Room-A # | 694 # ** Subnet-1 ** # | 695 # * ** # | 696 # * +----------+ * # | 697 # * | Light |-------+ * # | 698 # * | Switch | | * # | 699 # * +----------+ +---------+ * # | 700 # * | Rtr-1 |-----------------------------+ 701 # * +---------+ * # | 702 # * +----------+ | * # | 703 # * | Light-1 |--------+ * # | 704 # * +----------+ * # | 705 # * * # | 706 # ** ** # | 707 # ********************** # | 708 # # | 709 # ********************** # | 710 # ** Subnet-2 ** # | 711 # * ** # | 712 # * +----------+ * # | 713 # * | Light-2 |-------+ * # | 714 # * | | | * # | 715 # * +----------+ +---------+ * # | 716 # * | Rtr-2 |-----------------------------+ 717 # * +---------+ * # | 718 # * +----------+ | * # | 719 # * | Light-3 |--------+ * # | 720 # * +----------+ * # +------------+ | 721 # * * # | Controller |--+ 722 # ** ** # | Client | | 723 # ********************** # +------------+ | 724 ################################################ | 725 | 726 +------------+ | 727 | CoAP | | 728 | Resource |-----------------+ 729 | Directory | | 730 +------------+ | 731 +------------+ | 732 | DNS Server | | 733 | (Optional) |-----------------+ 734 +------------+ 736 Figure 1: Network Topology of a Large Room (Room-A) 738 4.3. Discovery of Resource Directory 740 The protocol flow for discovery of the CoAP RD for the given network 741 (of Figure 1) is shown in Figure 2: 743 o The fixture for Light-2 is installed and powered on for the first 744 time. 746 o Light-2 will then search for the local CoAP RD by sending out a 747 GET request (with the "/.well-known/core?rt=core.rd" request URI) 748 to the site-local "All CoAP Nodes" multicast address. 750 o This multicast message will then go to each node in subnet-2. 751 Rtr-2 will then forward into to the Network Backbone where it will 752 be received by the CoAP RD. All other nodes in subnet-2 will 753 ignore the multicast GET because it is qualified by the query 754 string "?rt=core.rd" (which indicates it should only be processed 755 by the endpoint if it is a RD). 757 o The CoAP RD will then send back a unicast response containing the 758 requested content. 760 o Note that the flow is shown only for Light-2 for clarity. Similar 761 flows will happen for Light-1, Light-3 and the Light Switch when 762 they are first powered on. 764 The CoAP RD may also be discovered by other means such as by assuming 765 a default location (e.g., on a 6LBR), using DHCP, anycast address, 766 etc. However, these approaches do not invoke CoAP group 767 communication so are not further discussed here. 769 For other discovery use cases such as discovering local CoAP servers, 770 services or resources group communication can be used in a similar 771 fashion as in the above use case. Both Link-Local (LL) and site- 772 local discovery are possible this way. 774 Light CoAP 775 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD 776 | | | | | | | 777 | | | | | | | 778 ********************************** | | | 779 * Light-2 is installed * | | | 780 * and powers on for first time * | | | 781 ********************************** | | | 782 | | | | | | | 783 | | | | | | | 784 | | COAP NON Mcast(GET | | 785 | | /.well-known/core?rt=core.rd) | | 786 | |--------->-------------------------------->| | 787 | | | | | |--------->| 788 | | | | | | | 789 | | | | | | | 790 | | COAP NON (2.05 Content | | 791 | | ;rt="core.rd";ins="Primary") |<---------| 792 | |<------------------------------------------| | 793 | | | | | | | 795 Figure 2: Resource Directory Discovery via Multicast Message 797 4.4. Lighting Control 799 The protocol flow for a building automation lighting control scenario 800 for the network (Figure 1) in 6LoWPAN configuration is shown in 801 sequence in Figure 3 for the case that the CoAP servers in each Light 802 are configured to not generate a CoAP response to lighting control 803 CoAP multicast requests. (See Section 3.7 for more details on 804 response suppression by a server.) 806 In addition, Figure 4 shows a protocol flow example for the case that 807 servers do respond to a lighting control multicast request with 808 (unicast) CoAP NON responses. There are two success responses and 809 one 5.00 error response. In this particular use case the Light 810 Switch does not check, based on the responses, that all Lights in the 811 group actually received the multicast request, because it is not 812 configured with an exhaustive list of IP addresses of all Lights 813 belonging to the group. However, based on received error responses 814 it could take additional action such as logging a fault or alerting 815 the user via its LCD display. 817 Reliability of CoAP multicast is not guaranteed. Therefore, one or 818 more lights in the group may not have received the CoAP control 819 request due to packet loss. In this use case there is no detection 820 nor correction of such situations: the application layer expects that 821 the multicast forwarding/routing will be of sufficient quality to 822 provide on average a very high probability of packet delivery to all 823 CoAP endpoints in a multicast group. An example protocol to 824 accomplish this is the MPL forwarding protocol for LLNs 825 [I-D.ietf-roll-trickle-mcast]. 827 We assume the following steps have already occurred before the 828 illustrated flows: 830 1. Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to 831 all devices. The CoAP network is formed. 833 2. Network configuration (application-independent): 6LBRs are 834 configured with multicast address blocks to filter out or to pass 835 through to/from the 6LoWPAN. 837 3. Commissioning phase (application-related): The IP multicast 838 address of the group (Room-A-Lights) has been configured in all 839 the Lights and in the Light Switch. 841 4. As an alternative to the previous step, when a DNS server is 842 available, the Light Switch and/or the Lights have been 843 configured with a group hostname which each nodes resolves to the 844 above IP multicast address of the group. 846 Note for the Commissioning phase: the switch's software supports 847 sending unicast, multicast or proxied unicast/multicast CoAP 848 requests, including processing of the multiple responses that may be 849 generated by a multicast CoAP request. 851 Light Network 852 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 853 | | | | | | | 854 | | | | | | | 855 | | *********************** | | 856 | | * User flips on * | | 857 | | * light switch to * | | 858 | | * turn on all the * | | 859 | | * lights in Room A * | | 860 | | *********************** | | 861 | | | | | | | 862 | | | | | | | 863 | | | COAP NON Mcast(PUT, | | 864 | | | Payload=lights ON) | | 865 |<-------------------------------+--------->| | | 866 ON | | | |-------------------->| 867 | | | | | |<---------| 868 | |<---------|<-------------------------------| | 869 | ON ON | | | | 870 ^ ^ ^ | | | | 871 *********************** | | | | 872 * Lights in Room-A * | | | | 873 * turn on (nearly * | | | | 874 * simultaneously) * | | | | 875 *********************** | | | | 876 | | | | | | | 878 Figure 3: Light Switch Sends Multicast Control Message 880 Light Network 881 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 882 | | | | | | | 883 | COAP NON (2.04 Changed) | | | | 884 |------------------------------->| | | | 885 | | | | | | | 886 | | | | | | | 887 | COAP NON (2.04 Changed) | | | 888 | |------------------------------------------>| | 889 | | | | | |--------->| 890 | | | | |<--------------------| 891 | | | |<---------| | | 892 | | | | | | | 893 | | COAP NON (5.00 Internal Server Error) | 894 | | |------------------------------->| | 895 | | | | | |--------->| 896 | | | | |<--------------------| 897 | | | |<---------| | | 898 | | | | | | | 900 Figure 4: Lights (Optionally) Respond to Multicast CoAP Request 902 Another, but similar, lighting control use case is shown in Figure 5. 903 In this case a controller connected to the Network Backbone sends a 904 CoAP multicast request to turn on all lights in Room-A. Every Light 905 sends back a CoAP response to the Controller after being turned on. 907 Network 908 Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller 909 | | | | | | | 910 | | | | | COAP NON Mcast(PUT, 911 | | | | | Payload=lights ON) 912 | | | | | |<-------| 913 | | | |<----------<---------| | 914 |<--------------------------------| | | | 915 ON | | | | | | 916 | |<----------<---------------------| | | 917 | ON ON | | | | 918 ^ ^ ^ | | | | 919 *********************** | | | | 920 * Lights in Room-A * | | | | 921 * turn on (nearly * | | | | 922 * simultaneously) * | | | | 923 *********************** | | | | 924 | | | | | | | 925 | | | | | | | 926 | COAP NON (2.04 Changed) | | | | 927 |-------------------------------->| | | | 928 | | | |-------------------->| | 929 | | COAP NON (2.04 Changed) | |------->| 930 | |-------------------------------->| | | 931 | | | | |--------->| | 932 | | | COAP NON (2.04 Changed) |------->| 933 | | |--------------------->| | | 934 | | | | |--------->| | 935 | | | | | |------->| 936 | | | | | | | 938 Figure 5: Controller On Backbone Sends Multicast Control Message 940 4.5. Lighting Control in MLD Enabled Network 942 The use case of previous section can also apply in networks where 943 nodes support the MLD protocol [RFC3810]. The Lights then take on 944 the role of MLDv2 listener and the routers (Rtr-1, Rtr-2) are MLDv2 945 Routers. In the Ethernet based network configuration, MLD may be 946 available on all involved network interfaces. Use of MLD in the 947 6LoWPAN based configuration is also possible, but requires MLD 948 support in all nodes in the 6LoWPAN which is usually not implemented 949 in many deployments. 951 The resulting protocol flow is shown in Figure 6. This flow is 952 executed after the commissioning phase, as soon as Lights are 953 configured with a group address to listen to. The (unicast) MLD 954 Reports may require periodic refresh activity as specified by the MLD 955 protocol. In the figure, LL denotes Link Local communication. 957 After the shown sequence of MLD Report messages has been executed, 958 both Rtr-1 and Rtr-2 are automatically configured to forward 959 multicast traffic destined to Room-A-Lights onto their connected 960 subnet. Hence, no manual Network Configuration of routers, as 961 previously indicated in Section 4.4, is needed anymore. 963 Light Network 964 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 965 | | | | | | | 966 | | | | | | | 967 | | | | | | | 968 | MLD Report: Join | | | | | 969 | Group (Room-A-Lights) | | | | 970 |---LL------------------------------------->| | | 971 | | | | |MLD Report: Join | 972 | | | | |Group (Room-A-Lights)| 973 | | | | |---LL---->----LL---->| 974 | | | | | | | 975 | | MLD Report: Join | | | | 976 | | Group (Room-A-Lights) | | | 977 | |---LL------------------------------------->| | 978 | | | | | | | 979 | | | MLD Report: Join | | | 980 | | | Group (Room-A-Lights) | | 981 | | |---LL-------------------------->| | 982 | | | | | | | 983 | | | | |MLD Report: Join | 984 | | | | |Group (Room-A-Lights)| 985 | | | | |<--LL-----+---LL---->| 986 | | | | | | | 987 | | | | | | | 989 Figure 6: Joining Lighting Groups Using MLD 991 4.6. Commissioning the Network Based On Resource Directory 993 This section outlines how devices in the lighting use case (both 994 Switches and Lights) can be commissioned, making use of Resource 995 Directory [I-D.shelby-core-resource-directory] and its group 996 configuration feature. 998 Once the Resource Directory (RD) is discovered, the Switches and 999 Lights need to be discovered and their groups need to be defined. 1000 For the commissioning of these devices, a commissioning tool can be 1001 used that defines the entries in the RD. The commissioning tool has 1002 the authority to change the contents of the RD and the nodes. DTLS 1003 based security is used by the commissioning tool to modify 1004 operational data in RD, Switches and Lights. 1006 In our particular use case, a group of three lights is defined with 1007 one multicast address and hostname 1008 "Room-A-Lights.floor1.west.bldg6.example.com". The commissioning 1009 device has a list of the three lights and the associated multicast 1010 address. For each light in the list the tool learns the IP address 1011 of the light and instructs the RD with 3 POST commands to store the 1012 end-points associated with the three lights as prescribed by RD. 1013 Finally the commissioning device defines the group in the RD to 1014 contain these three end-points. Also the commissioning tool writes 1015 the MC address in the Lights with, for example, the POST /gp command 1016 discussed in Section 3.6. 1018 The light switch can discover the group in RD and learn the MC 1019 address of the group. The light switch will use this address to send 1020 MC commands to the members of the group. When the message arrives 1021 the Lights should recognize the MC address and accept the message. 1023 5. Deployment Guidelines 1025 This section provides guidelines how an IP Multicast based solution 1026 for CoAP group communication can be deployed in various network 1027 configurations. 1029 5.1. Target Network Topologies 1031 CoAP group communication can be deployed in various network 1032 topologies. First, the target network may be a regular IP network, 1033 or a LLN such as a 6LoWPAN network, or consist of mixed constrained/ 1034 unconstrained network segments. Second, it may be a single subnet 1035 only or multi-subnet; e.g., multiple 6LoWPAN networks joined by a 1036 single backbone LAN. Third, a wireless network segment may have all 1037 nodes reachable in a single IP hop, or it may require multiple IP 1038 hops for some pairs of nodes to reach each other. 1040 Each topology may pose different requirements on the configuration of 1041 routers and protocol(s), in order to enable efficient CoAP group 1042 communication. 1044 5.2. Advertising Membership of Multicast Groups 1046 If a multicast routing/forwarding protocol is used in a network, 1047 server nodes that intend to receive CoAP multicast requests generally 1048 require a method to advertise the specific IP multicast address(es) 1049 they want to receive (i.e., a method to join specific IP multicast 1050 groups). This section identifies the ways in which this can be 1051 accomplished. 1053 5.2.1. Using the MLD Listener Protocol 1055 CoAP nodes that are IP hosts (i.e., not IP routers) are generally 1056 unaware of the specific multicast routing/forwarding protocol being 1057 used. When such a host needs to join a specific (CoAP) multicast 1058 group, it requires a way to signal to multicast routers which 1059 multicast traffic it wants to receive. For efficient multicast 1060 routing (i.e., avoid always flooding IP multicast packets), routers 1061 must know which hosts need to receive packets addressed to specific 1062 IP multicast destinations. 1064 The Multicast Listener Discovery (MLD) protocol [RFC3810] 1065 (Appendix A) is the standard IPv6 method to achieve this. [RFC6636] 1066 discusses tuning of MLD for mobile and wireless networks. These 1067 guidelines may be useful when implementing MLD in LLNs. 1069 Alternatively, to avoid the use of MLD in LLN deployments, either all 1070 nodes can be configured as multicast routers in an LLN, or a 1071 multicast forwarding/flooding protocol can be used that forwards any 1072 IP multicast packet to all forwarders (routers) in the subnet (LLN). 1074 5.2.2. Using the RPL Routing Protocol 1076 The RPL routing protocol [RFC6550] defines in Section 12 the 1077 advertisement of IP multicast destinations using DAO messages. This 1078 mechanism can be used by CoAP nodes (which are also RPL routers) to 1079 advertise IP multicast group membership to other RPL routers. Then, 1080 the RPL protocol can route multicast CoAP requests over multiple hops 1081 to the correct CoAP servers. 1083 This mechanism can be used as a means to convey IP multicast group 1084 membership information to an edge router (e.g., 6LBR), in case the 1085 edge router is also the root of the RPL DODAG. This could be useful 1086 in LLN segments where MLD is not available and the edge router needs 1087 to know what IP multicast traffic to pass through from the backbone 1088 network into the LLN subnet. 1090 5.2.3. Using the MPL Forwarding Protocol 1092 The MPL forwarding protocol [I-D.ietf-roll-trickle-mcast] can be used 1093 in a predefined network domain for propagation of IP multicast 1094 packets to all MPL routers, over multiple hops. MPL is designed to 1095 work in LLN deployments. Due to its property of propagating all 1096 (non-link-local) IP multicast packets to all MPL routers, there is in 1097 principle no need for CoAP server nodes to advertise IP multicast 1098 group membership assuming that any IP multicast source is also part 1099 of the MPL domain. 1101 5.3. 6LoWPAN Specific Guidelines 1103 To support multi-LoWPAN scenarios for CoAP group communication, it is 1104 recommended that a 6LoWPAN Border Router (6LBR) will act in an MLD 1105 Router role on the backbone link. If this is not possible then the 1106 6LBR should be configured to act as an MLD Multicast Address Listener 1107 and/or MLD Snooper (Appendix A) on the backbone link. 1109 To avoid that backbone IP multicast traffic needlessly congests 1110 6LoWPAN network segments, it is recommended that a filtering means is 1111 implemented to block IP multicast traffic from 6LoWPAN segments where 1112 none of the 6LoWPAN nodes listen to this traffic. Possible means 1113 are: 1115 o Filtering in 6LBRs based on information from the routing protocol. 1116 This allows a 6LBR to only forward multicast traffic onto the 1117 LoWPAN, for which it is known that there exists at least one 1118 listener on the LoWPAN. 1120 o Filtering in 6LBRs based on MLD reports. Similar as previous but 1121 based directly on MLD reports from 6LoWPAN nodes. This only works 1122 in a single-IP-hop 6LoWPAN network, such as a mesh-under routing 1123 network or a star topology network, because MLD relies on link- 1124 local communication. 1126 o Filtering in 6LBRs based on settings. Filtering tables with 1127 blacklists/whitelists can be configured in the 6LBR by system 1128 administration for all 6LBRs or configured on a per-6LBR basis. 1130 o Filtering in router(s) or firewalls that provide access to 1131 constrained network segments. For example, in an access router/ 1132 bridge that connects a regular intranet LAN to a building control 1133 IPv6 backbone. This backbone connects multiple 6LoWPAN segments, 1134 each segment connected via a 6LBR. 1136 6. Security Considerations 1138 This section describes the relevant security configuration for CoAP 1139 group communication using IP multicast. The threats to CoAP group 1140 communication are also identified and various approaches to mitigate 1141 these threats are summarized. 1143 6.1. Security Configuration 1145 As defined in [I-D.ietf-core-coap], CoAP group communication based on 1146 IP multicast must use the following security modes: 1148 o Group communication MUST operate in CoAP NoSec (No Security) mode. 1150 o Group communication MUST NOT use "coaps" scheme. That is, all 1151 group communication MUST use only "coap" scheme. 1153 6.2. Threats 1155 Essentially the above configuration means that there is no security 1156 at the CoAP layer for group communication. This is due to the fact 1157 that the current DTLS based approach for CoAP is exclusively unicast 1158 oriented and does not support group security features such as group 1159 key exchange and group authentication. As a direct consequence of 1160 this, CoAP group communication is vulnerable to all attacks mentioned 1161 in [I-D.ietf-core-coap] for IP multicast. 1163 6.3. Threat Mitigation 1165 [I-D.ietf-core-coap] identifies various threat mitigation techniques 1166 for CoAP IP multicast. In addition to those guidelines, it is 1167 recommended that for sensitive data or safety-critical control, a 1168 combination of appropriate link-layer security and administrative 1169 control of IP multicast boundaries should be used. Some examples are 1170 given below. 1172 6.3.1. WiFi Scenario 1174 In a home automation scenario (using WiFi), the WiFi encryption 1175 should be enabled to prevent rogue nodes from joining. Also, if MAC 1176 address filtering at the WiFi Access Point is supported that should 1177 also be enabled. The IP router should have the fire wall enabled to 1178 isolate the home network from the rest of the Internet. In addition, 1179 the domain of the IP multicast should be set to be either link-local 1180 scope or site-local scope. Finally, if possible, devices should be 1181 configured to accept only Source Specific Multicast (SSM) packets 1182 (see [RFC4607]) from within the trusted home network. For example, 1183 all lights in a particular room should only accept IP multicast 1184 traffic originating from the master light switch in that room. In 1185 this case, the Spoofed Source Address considerations of Section 7.4 1186 of [RFC4607] should be heeded. 1188 6.3.2. 6LoWPAN Scenario 1190 In a building automation scenario, a particular room may have a 1191 single 6LoWPAN topology with a single Edge Router (6LBR). Nodes on 1192 the subnet can use link-layer encryption to prevent rogue nodes from 1193 joining. The 6LBR can be configured so that it blocks any incoming 1194 IP multicast traffic. Another example topology could be a multi- 1195 subnet 6LoWPAN in a large conference room. In this case, the 1196 backbone can implement port authentication (IEEE 802.1X) to ensure 1197 only authorized devices can join the Ethernet backbone. The access 1198 router to this secured segment can also be configured to block 1199 incoming IP multicast traffic. 1201 6.3.3. Future Evolution 1203 In the future, to further mitigate the threats, the developing 1204 approach for DTLS-based IP multicast security for CoAP networks (see 1205 [I-D.keoh-tls-multicast-security]) or similar approaches should be 1206 considered once they mature. 1208 7. IANA Considerations 1209 7.1. New 'core.gp' Resource Type 1211 This memo registers a new resource type (rt) from the CoRE Parameters 1212 Registry called 'core.gp'. 1214 (Note to IANA/RFC Editor: This registration follows the process 1215 described in section 7.4 of [RFC6690]). 1217 Attribute Value: core.gp 1219 Description: Optional Group Configuration resource. This resource is 1220 used to query/manage the group membership of a CoAP server. 1222 Reference: See Section 3.6. 1224 7.2. New 'coap-group+json' Internet Media Type 1226 This memo registers a new Internet Media Type for CoAP group 1227 configuration resource called 'application/coap-group+json'. 1229 (Note to IANA/RFC Editor: This registration follows the guidance from 1230 [RFC6839], and [I-D.ietf-core-coap] section 12.3 (last paragraph)). 1232 Type name: application 1234 Subtype name: coap-group+json 1236 Required parameters: None 1238 Optional parameters: None 1240 Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32. 1242 JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON is 1243 written in UTF-8, JSON is 8bit compatible. When JSON is written in 1244 UTF-16 or UTF-32, the binary content-transfer-encoding must be used. 1246 If the client is aware that the server group configuration resource 1247 is 8bit encoded (which is most efficient for a constrained device), 1248 that encoding should be respected by the client (i.e., it should not 1249 try to replace it by a binary encoded group configuration resource). 1251 Security considerations: 1253 Denial of Service attacks could be performed by constantly setting 1254 the group configuration resource of a CoAP endpoint. This will cause 1255 the endpoint to register (or de-register) from the related IP 1256 multicast group. To prevent this it is mandatory that DTLS-secured 1257 CoAP communication be used for setting the group configuration 1258 resource. Thus only authorized clients will be allowed by a server 1259 to configure its group membership. 1261 Interoperability considerations: None 1263 Published specification: (This I-D when it becomes an RFC) 1265 Applications that use this media type: 1267 CoAP client and server implementations that wish to set/read the 1268 group configuration resource via 'application/coap-group+json' 1269 payload as described in Section 3.6. 1271 Additional Information: 1273 Magic number(s): None 1275 File extension(s): *.json 1277 Macintosh file type code(s): TEXT 1279 Intended usage: COMMON 1281 Restrictions on usage: None 1283 Author: CoRE WG 1285 Change controller: IETF 1287 8. Acknowledgements 1289 Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo 1290 Castellani, Bjoern Hoehrmann, Matthias Kovatsch, Guang Lu, Salvatore 1291 Loreto, Kerry Lynn, Dale Seed, Zach Shelby, Peter van der Stok, and 1292 Juan Carlos Zuniga for their helpful comments and discussions that 1293 have helped shape this document. 1295 9. References 1297 9.1. Normative References 1299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1300 Requirement Levels", BCP 14, RFC 2119, March 1997. 1302 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1303 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1304 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1306 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1307 "Advanced Sockets Application Program Interface (API) for 1308 IPv6", RFC 3542, May 2003. 1310 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1311 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1313 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1314 Architecture", RFC 4291, February 2006. 1316 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1317 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1318 Protocol Specification (Revised)", RFC 4601, August 2006. 1320 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1321 IP", RFC 4607, August 2006. 1323 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1324 "Transmission of IPv6 Packets over IEEE 802.15.4 1325 Networks", RFC 4944, September 2007. 1327 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1328 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1329 March 2010. 1331 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1332 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1333 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1334 Lossy Networks", RFC 6550, March 2012. 1336 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1337 the Internet Group Management Protocol (IGMP) and 1338 Multicast Listener Discovery (MLD) for Routers in Mobile 1339 and Wireless Networks", RFC 6636, May 2012. 1341 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1342 Format", RFC 6690, August 2012. 1344 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1345 "Neighbor Discovery Optimization for IPv6 over Low-Power 1346 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1347 November 2012. 1349 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type 1350 Structured Syntax Suffixes", RFC 6839, January 2013. 1352 [I-D.ietf-core-coap] 1353 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1354 Application Protocol (CoAP)", draft-ietf-core-coap-17 1355 (work in progress), May 2013. 1357 9.2. Informative References 1359 [I-D.ietf-core-block] 1360 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1361 draft-ietf-core-block-11 (work in progress), March 2013. 1363 [I-D.vanderstok-core-dna] 1364 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 1365 Naming, and Addressing", draft-vanderstok-core-dna-02 1366 (work in progress), July 2012. 1368 [I-D.ietf-roll-trickle-mcast] 1369 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1370 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 1371 mcast-04 (work in progress), February 2013. 1373 [I-D.keoh-tls-multicast-security] 1374 Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast 1375 Security for Low-Power and Lossy Networks (LLNs)", draft- 1376 keoh-tls-multicast-security-00 (work in progress), October 1377 2012. 1379 [I-D.shelby-core-resource-directory] 1380 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 1381 Directory", draft-shelby-core-resource-directory-05 (work 1382 in progress), February 2013. 1384 Appendix A. Multicast Listener Discovery (MLD) 1386 In order to extend the scope of IP multicast beyond link-local scope, 1387 an IP multicast routing or forwarding protocol has to be active in 1388 routers on an LLN. To achieve efficient multicast routing (i.e., 1389 avoid always flooding IP multicast packets), routers have to learn 1390 which hosts need to receive packets addressed to specific IP 1391 multicast destinations. 1393 The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its 1394 IPv4 pendant IGMP) is today the method of choice used by an (IP 1395 multicast enabled) router to discover the presence of multicast 1396 listeners on directly attached links, and to discover which multicast 1397 addresses are of interest to those listening nodes. MLD was 1398 specifically designed to cope with fairly dynamic situations in which 1399 multicast listeners may join and leave at any time. 1401 IGMP/MLD Snooping is a technique implemented in some corporate LAN 1402 routing/switching devices. An MLD snooping switch listens to MLD 1403 State Change Report messages from MLD listeners on attached links. 1404 Based on this, the switch learns on what LAN segments there is 1405 interest for what IP multicast traffic. If the switch receives at 1406 some point an IP multicast packet, it uses the stored information to 1407 decide onto which LAN segment(s) to send the packet. This improves 1408 network efficiency compared to the regular behavior of forwarding 1409 every incoming multicast packet onto all LAN segments. An MLD 1410 snooping switch may also send out MLD Query messages (which is 1411 normally done by a device in MLD Router role) if no MLD Router is 1412 present. 1414 [RFC6636] discusses optimal tuning of the parameters of MLD for 1415 routers for mobile and wireless networks. These guidelines may be 1416 useful when implementing MLD in LLNs. 1418 Appendix B. Change Log 1420 Changes from ietf-08 to ietf-09: 1422 o Cleaned up requirements language in general. Also, requirements 1423 language are now only used in section 3 (Protocol Considerations) 1424 and section 6 (Security Considerations). Requirements language 1425 has been removed from other sections to keep them to a minimum 1426 (#271). 1428 o Addressed final comment from Peter van der Stok to define what "IP 1429 stack" meant (#296). Following the lead of CoAP-17, we know refer 1430 instead to "APIs such as IPV6_RECVPKTINFO [RFC3542]". 1432 o Changed text in section 3.4 (Group Methods) to allow multicast 1433 POST under specific conditions and highlighting the risks with 1434 using it (#328). 1436 o Various editorial updates for improved readability. 1438 Changes from ietf-07 to ietf-08: 1440 o Updated text in section 3.6 (Configuring Group Membership in 1441 Endpoints) to make it more explicit that the Internet Media Type 1442 is used in the processing rules (#299). 1444 o Addressed various comments from Peter van der Stok (#296). 1446 o Various editorial updates for improved readability including 1447 defining all acronyms. 1449 Changes from ietf-06 to ietf-07: 1451 o Added an IANA request (in section 7.2) for a dedicated content- 1452 format (Internet Media type) for the group management JSON format 1453 called 'application/coap-group+json' (#299). 1455 o Clarified semantics (in section 3.6) of group management JSON 1456 format (#300). 1458 o Added details of IANA request (in section 7.1) for a new CORE 1459 Resource Type called 'core.gp'. 1461 o Clarified that DELETE method (in section 3.6) is also a valid 1462 group management operation. 1464 o Various editorial updates for improved readability. 1466 Changes from ietf-05 to ietf-06: 1468 o Added a new section on commissioning flow when using discovery 1469 services when end devices discover in which multicast group they 1470 are allocated (#295). 1472 o Added a new section on CoAP Proxy Operation (section 3.9) that 1473 outlines the potential issues and limitations of doing CoAP 1474 multicast requests via a CoAP Proxy (#274). 1476 o Added use case of multicasting controller on the backbone (#279). 1478 o Use cases were updated to show only a single CoAP RD (to replace 1479 the previous multiple RDs with one in each subnet). This is a 1480 more efficient deployment and also avoids RD specific issues such 1481 as synchronization of RD information between serves (#280). 1483 o Added text to section 3.6 (Configuring Group Membership in 1484 Endpoints) that clarified that any (unicast) operation to change 1485 an endpoint's group membership must use DTLS-secured CoAP. 1487 o Clarified relationship of this document to [I-D.ietf-core-coap] in 1488 section 2.2 (Scope). 1490 o Removed IPSec related requirement, as IPSec is not part of 1491 [I-D.ietf-core-coap] anymore. 1493 o Editorial reordering of subsections in section 3 to have a better 1494 flow of topics. Also renamed some of the (sub)sections to better 1495 reflect their content. Finally, moved the URI Configuration text 1496 to the same section as the Port Configuration section as it was a 1497 more natural grouping (now in section 3.3) . 1499 o Editorial rewording of section 3.7 (Multicast Request Acceptance 1500 and Response Suppression) to make the logic easier to comprehend 1501 (parse). 1503 o Various editorial updates for improved readability. 1505 Changes from ietf-04 to ietf-05: 1507 o Added a new section 3.9 (Exceptions) that highlights that IP 1508 multicast (and hence group communication) is not always available 1509 (#187). 1511 o Updated text on the use of [RFC2119] language (#271) in Section 1. 1513 o Included guidelines on when (not) to use CoAP responses to 1514 multicast requests and when (not) to accept multicast requests 1515 (#273). 1517 o Added guideline on use of core-block for minimizing response size 1518 (#275). 1520 o Restructured section 6 (Security Considerations) to more fully 1521 describe threats and threat mitigation (#277). 1523 o Clearly indicated that DNS resolution and reverse DNS lookup are 1524 optional. 1526 o Removed confusing text about a single group having multiple IP 1527 addresses. If multiple IP addresses are required then multiple 1528 groups (with the same members) should be created. 1530 o Removed repetitive text about the fact that group communication is 1531 not guaranteed. 1533 o Merged previous section 5.2 (Multicast Routing) into 3.1 (IP 1534 Multicast Routing Background) and added link to section 5.2 1535 (Advertising Membership of Multicast Groups). 1537 o Clarified text in section 3.8 (Congestion Control) regarding 1538 precedence of use of IP multicast domains (i.e. first try to use 1539 link-local scope, then site-local scope, and only use global IP 1540 multicast as a last resort). 1542 o Extended group resource manipulation guidelines with use of pre- 1543 configured ports/paths for the multicast group. 1545 o Consolidated all text relating to ports in a new section 3.3 (Port 1546 Configuration). 1548 o Clarified that all methods (GET/PUT/POST) for configuring group 1549 membership in endpoints should be unicast (and not multicast) in 1550 section 3.7 (Configuring Group Membership In Endpoints). 1552 o Various editorial updates for improved readability, including 1553 editorial comments by Peter van der Stok to WG list of December 1554 18th, 2012. 1556 Changes from ietf-03 to ietf-04: 1558 o Removed section 2.3 (Potential Solutions for Group Communication) 1559 as it is purely background information and moved section to draft- 1560 dijk-core-groupcomm-misc (#266). 1562 o Added reference to draft-keoh-tls-multicast-security to section 6 1563 (Security Considerations). 1565 o Removed Appendix B (CoAP-Observe Alternative to Group 1566 Communications) as it is as an alternative to IP Multicast that 1567 the WG has not adopted and moved section to draft-dijk-core- 1568 groupcomm-misc (#267). 1570 o Deleted section 8 (Conclusions) as it is redundant (#268). 1572 o Simplified light switch use case (#269) by splitting into basic 1573 operations and additional functions (#269). 1575 o Moved section 3.7 (CoAP Multicast and HTTP Unicast Interworking) 1576 to draft-dijk-core-groupcomm-misc (#270). 1578 o Moved section 3.3.1 (DNS-SD) and 3.3.2 (CoRE Resource Directory) 1579 to draft-dijk-core-groupcomm-misc as these sections essentially 1580 just repeated text from other drafts regarding DNS based features. 1581 Clarified remaining text in this draft relating to DNS based 1582 features to clearly indicate that these features are optional 1583 (#272). 1585 o Focus section 3.5 (Configuring Group Membership) on a single 1586 proposed solution. 1588 o Scope of section 5.3 (Use of MLD) widened to multicast destination 1589 advertisement methods in general. 1591 o Rewrote section 2.2 (Scope) for improved readability. 1593 o Moved use cases that are not addressed to draft-dijk-core- 1594 groupcomm-misc. 1596 o Various editorial updates for improved readability. 1598 Changes from ietf-02 to ietf-03: 1600 o Clarified that a group resource manipulation may return back a 1601 mixture of successful and unsuccessful responses (section 3.4 and 1602 Figure 6) (#251). 1604 o Clarified that security option for group communication must be 1605 NoSec mode (section 6) (#250). 1607 o Added mechanism for group membership configuration (#249). 1609 o Removed IANA request for multicast addresses (section 7) and 1610 replaced with a note indicating that the request is being made in 1611 [I-D.ietf-core-coap] (#248). 1613 o Made the definition of 'group' more specific to group of CoAP 1614 endpoints and included text on UDP port selection (#186). 1616 o Added explanatory text in section 3.4 regarding why not to use 1617 group communication for non-idempotent messages (i.e. CoAP POST) 1618 (#186). 1620 o Changed link-local RD discovery to site-local in RD discovery use 1621 case to make it more realistic. 1623 o Fixed lighting control use case CoAP proxying; now returns 1624 individual CoAP responses as in coap-12. 1626 o Replaced link format I-D with RFC6690 reference. 1628 o Various editorial updates for improved readability 1630 Changes from ietf-01 to ietf-02: 1632 o Rewrote congestion control section based on latest CoAP text 1633 including Leisure concept (#188) 1635 o Updated the CoAP/HTTP interworking section and example use case 1636 with more details and use of MLD for multicast group joining 1638 o Key use cases added (#185) 1639 o References to [I-D.vanderstok-core-dna] and draft-castellani-core- 1640 advanced-http-mapping added 1642 o Moved background sections on "MLD" and "CoAP-Observe" to 1643 Appendices 1645 o Removed requirements section (and moved it to draft-dijk-core- 1646 groupcomm-misc) 1648 o Added details for IANA request for group communication multicast 1649 addresses 1651 o Clarified text to distinguish between "link local" and general 1652 multicast cases 1654 o Moved lengthy background section 5 to draft-dijk-core-groupcomm- 1655 misc and replaced with a summary 1657 o Various editorial updates for improved readability 1659 o Change log added 1661 Changes from ietf-00 to ietf-01: 1663 o Moved CoAP-observe solution section to section 2 1665 o Editorial changes 1667 o Moved security requirements into requirements section 1669 o Changed multicast POST to PUT in example use case 1671 o Added CoAP responses in example use case 1673 Changes from rahman-07 to ietf-00: 1675 o Editorial changes 1677 o Use cases section added 1679 o CoRE Resource Directory section added 1681 o Removed section 3.3.5. IP Multicast Transmission Methods 1683 o Removed section 3.4 Overlay Multicast 1685 o Removed section 3.5 CoAP Application Layer Group Management 1686 o Clarified section 4.3.1.3 RPL Routers with Non-RPL Hosts case 1688 o References added and some normative/informative status changes 1690 Authors' Addresses 1692 Akbar Rahman (editor) 1693 InterDigital Communications, LLC 1695 Email: Akbar.Rahman@InterDigital.com 1697 Esko Dijk (editor) 1698 Philips Research 1700 Email: esko.dijk@philips.com