idnits 2.17.1 draft-ietf-core-groupcomm-07.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 07, 2013) is 4007 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 ---------------------------------------------------------------------------- == Unused Reference: 'RFC2616' is defined on line 1283, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-16 == 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: 4 errors (**), 0 flaws (~~), 6 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 08, 2013 Philips Research 6 May 07, 2013 8 Group Communication for CoAP 9 draft-ietf-core-groupcomm-07 11 Abstract 13 CoAP is a RESTful transfer protocol for constrained devices and 14 networks. It is anticipated that constrained devices will often 15 naturally operate in groups (e.g. in a building automation scenario 16 all lights in a given room may need to be switched on/off as a 17 group). This document provides guidance for how the CoAP protocol 18 should be used in a group communication context. An approach for 19 using CoAP on top of IP multicast is detailed for both constrained 20 and un-constrained networks. Also, various use cases and 21 corresponding protocol flows are provided to illustrate important 22 concepts. Finally, guidance is provided for deployment in various 23 network topologies. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 08, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Protocol Considerations . . . . . . . . . . . . . . . . . . . 4 64 3.1. IP Multicast Background . . . . . . . . . . . . . . . . . 4 65 3.2. Group Definition and Naming . . . . . . . . . . . . . . . 5 66 3.3. Port and URI Configuration . . . . . . . . . . . . . . . 6 67 3.4. Group Methods . . . . . . . . . . . . . . . . . . . . . . 7 68 3.5. Group Member Discovery . . . . . . . . . . . . . . . . . 7 69 3.6. Configuring Group Membership In Endpoints . . . . . . . . 7 70 3.7. Multicast Request Acceptance and Response Suppression . . 9 71 3.8. Congestion Control . . . . . . . . . . . . . . . . . . . 11 72 3.9. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 12 73 3.10. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 13 74 4. Use Cases and Corresponding Protocol Flows . . . . . . . . . 14 75 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 14 76 4.2. Network Configuration . . . . . . . . . . . . . . . . . . 14 77 4.3. Discovery of Resource Directory . . . . . . . . . . . . . 16 78 4.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 18 79 4.5. Lighting Control in MLD Enabled Network . . . . . . . . . 21 80 4.6. Commissioning the Network Based On Resource Directory . . 22 81 5. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 23 82 5.1. Target Network Topologies . . . . . . . . . . . . . . . . 23 83 5.2. Advertising Membership of Multicast Groups . . . . . . . 23 84 5.2.1. Using the Multicast Listener Discovery (MLD) Protocol 24 85 5.2.2. Using the RPL Routing Protocol . . . . . . . . . . . 24 86 5.2.3. Using the MPL Forwarding Protocol . . . . . . . . . . 24 87 5.3. 6LoWPAN-Specific Guidelines . . . . . . . . . . . . . . . 25 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 89 6.1. Security Configuration . . . . . . . . . . . . . . . . . 26 90 6.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 6.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 26 92 6.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 26 93 6.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 26 94 6.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 27 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 7.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 27 97 7.2. New 'coap-group+json' Internet Media Type . . . . . . . . 27 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 101 9.2. Informative References . . . . . . . . . . . . . . . . . 30 102 Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 30 103 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 31 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 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 These key words are used to establish a set of best practices 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. 118 This document assumes readers are familiar with the terms and 119 concepts that are used in [I-D.ietf-core-coap]. In addition, this 120 document defines the following terminology: 122 Group Communication 123 A source node sends a single message which is delivered to 124 multiple destination nodes, where all destinations are identified 125 to belong to a specific group. The source node itself may be part 126 of the group. The underlying mechanism for group communication is 127 assumed to be multicast based. The network involved may be a 128 constrained network such as a low-power, lossy network. 130 Multicast 131 Sending a message to multiple destination nodes with one network 132 invocation. There are various options to implement multicast 133 including layer 2 (Media Access Control) and layer 3 (IP) 134 mechanisms. 136 IP Multicast 137 A specific multicast solution based on the use of IP multicast 138 addresses as defined in "IANA Guidelines for IPv4 Multicast 139 Address Assignments" [RFC5771] and "IP Version 6 Addressing 140 Architecture" [RFC4291]. 142 Low power and Lossy Network (LLN) 143 A type of constrained IP network where devices are interconnected 144 by a variety of low-power and lossy links (such as IEEE 802.15.4, 145 Bluetooth LE, DECT, DECT ULE) or lossy links (such as IEEE P1901.2 146 power-line communication). 148 2. Introduction 150 2.1. Background 152 The Constrained Application Protocol (CoAP) is an application 153 protocol (analogous to HTTP) for resource constrained devices 154 operating in an IP network [I-D.ietf-core-coap]. Constrained devices 155 can be large in number, but are often highly correlated to each other 156 (e.g. by type or location). For example, all the light switches in 157 a building may belong to one group and all the thermostats may belong 158 to another group. Groups may be pre-configured before deployment or 159 dynamically formed during operation. If information needs to be sent 160 to or received from a group of devices, group communication 161 mechanisms can improve efficiency and latency of communication and 162 reduce bandwidth requirements for a given application. HTTP does not 163 support any equivalent functionality to CoAP group communication. 165 2.2. Scope 167 Group communication involves sending a CoAP Request as an IP 168 Multicast message and handling the potential multitude of (unicast) 169 CoAP Responses. The normative protocol aspects of running CoAP on 170 top of IP Multicast and processing the responses are given in 171 [I-D.ietf-core-coap]. The main contribution of this document lies in 172 providing additional guidance for key group communication features. 173 Among the topics covered are group definition, group resource 174 manipulation, and group configuration. Also, proxy operation and 175 minimizing congestion scenarios for group communication is discussed. 176 Finally, specific use case behavior and deployment guidelines are 177 outlined for CoAP group communication. 179 3. Protocol Considerations 181 3.1. IP Multicast Background 183 IP Multicast protocols have been evolving for decades, resulting in 184 proposed standards such as Protocol Independent Multicast - Sparse 185 Mode (PIM-SM) [RFC4601]. Yet, due to various technical and business 186 reasons, IP Multicast is not widely deployed on the general Internet. 187 However, IP Multicast is very popular in specific deployments such as 188 in enterprise networks (e.g. for video conferencing), smart home 189 networks (e.g. UPnP) and carrier IPTV deployments. The packet 190 economy and minimal host complexity of IP multicast make it 191 attractive for group communication in constrained environments. 193 To achieve IP multicast beyond a subnet, an IP multicast routing or 194 forwarding protocol needs to be active on IP routers. An examples of 195 a routing protocol specifically for LLNs is RPL (Section 12 of 196 [RFC6550]) and an example of a forwarding protocol for LLNs is MPL 197 [I-D.ietf-roll-trickle-mcast]. PIM-SM [RFC4601] is often used for 198 multicast routing in un-constrained networks. 200 IP multicast can also be run in a Link-Local (LL) scope. This means 201 that there is no routing involved and an IP multicast message is only 202 received over the link on which it was sent. 204 For a complete IP multicast solution, in addition to a routing/ 205 forwarding protocol, a so-called "listener" protocol is needed for 206 the devices to subscribe to groups (see Section 5.2). 208 3.2. Group Definition and Naming 210 A group is defined as a set of CoAP endpoints, where each endpoint is 211 configured to receive a multicast CoAP request that is sent to the 212 group's associated IP multicast address. An endpoint MAY be a member 213 of multiple groups. Group membership of an endpoint MAY dynamically 214 change over time. 216 For group communication, the Group URI will be the CoAP request URI. 217 A Group URI has the scheme 'coap' and includes in the authority part 218 either a group IP multicast address plus optional port number or a 219 hostname plus optional port number that can be resolved to the group 220 IP multicast address (e.g., a Group Name or Group FQDN). Group URIs 221 follow the CoAP URI syntax [I-D.ietf-core-coap]. It is recommended 222 for sending nodes to use the IP multicast address literal in the 223 authority for the Group URI as the default. 225 If a Group FQDN is used, it can be uniquely mapped to a site-local or 226 global IP multicast address via DNS resolution (if supported). Some 227 examples of hierarchical Group FQDN naming (and scoping) for a 228 building control application are shown below 229 ([I-D.vanderstok-core-dna]): 231 URI authority Targeted group 232 all.bldg6.example.com "all nodes in building 6" 233 all.west.bldg6.example.com "all nodes in west wing, building 6" 234 all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, 235 building 6" 236 all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, 237 west wing, building 6" 239 Similarly, if supported, reverse mapping (from IP multicast address 240 to Group FQDN) is possible using the reverse DNS resolution technique 241 ([I-D.vanderstok-core-dna]). 243 3.3. Port and URI Configuration 245 A CoAP group member listens for CoAP messages on the group's IP 246 multicast address, on a specified UDP port. Note that the default 247 UDP port is the CoAP default port 5683 but a non-default UDP port MAY 248 be specified for the group; in which case implementers MUST ensure 249 that all group members are configured to use this same port. 251 Multicast based group communication will not work if there diversity 252 in the authority port (i.e. a diversity of dynamic port addresses 253 across the group) or if the resources are located at different paths 254 on different endpoints. Therefore, some measures must be present to 255 ensure uniformity in port number and resource names/locations within 256 a group. All CoAP multicast requests MUST be sent using the port 257 number as follows: 259 1. A pre-configured port number, if available. The pre- 260 configuration mechanism MUST ensure that the same port number is 261 pre-configured across all endpoints in a group and across all 262 CoAP clients performing the group requests. 264 2. If the client is configured to use service discovery including 265 port discovery, it uses a port number obtained via a service 266 discovery lookup operation as a valid CoAP port for the targeted 267 CoAP multicast group. 269 3. Otherwise use the default CoAP UDP port. 271 All CoAP multicast requests SHOULD operate on URI paths ("links") as 272 follows: 274 1. Pre-configured URI paths, if available. The pre-configuration 275 mechanism MUST ensure that these URIs are pre-configured across 276 all CoAP servers in a group and all CoAP clients performing the 277 group requests. 279 2. If the client is configured to use default CoRE resource 280 discovery, it uses URI paths retrieved from a "/.well-known/core" 281 lookup on a group member. The URI paths the client will use MUST 282 be known to be available also in all other endpoints in the 283 group. The URI path configuration mechanism on servers MUST 284 ensure that these URIs (identified as being supported by the 285 group) are configured on all group endpoints. 287 3. If the client is configured to use another form of service 288 discovery, it uses URI paths from an equivalent service discovery 289 lookup which returns the resources supported by all group 290 members. 292 3.4. Group Methods 294 Group communication SHALL only be used for idempotent methods (i.e. 295 CoAP GET, PUT, and DELETE). The CoAP messages that are sent via 296 multicast SHALL be Non-Confirmable. 298 A unicast response per server MAY be sent back to answer the group 299 request (e.g. response "2.05 Content" to a group GET request) taking 300 into account the congestion control rules defined in Section 3.8. 301 The unicast responses received may be a mixture of success (e.g. 302 2.05 Content) and failure (e.g. 4.04 Not Found) codes depending on 303 the individual server processing result. 305 Group communication SHALL NOT be used for non-idempotent methods 306 (i.e. CoAP POST). This is because not all group members are 307 guaranteed to receive the multicast request, and the sender cannot 308 readily find out which group members did not receive it. 310 3.5. Group Member Discovery 312 CoAP defines a resource discovery capability [RFC6690], but does not 313 specify how to discover groups (e.g. find a group to join or send a 314 multicast message to) or how to discover members of a group (e.g. to 315 address selected group members by unicast). A simple ad-hoc method 316 to discover members of a CoAP group would be to send a multicast 317 "CoAP ping" [I-D.ietf-core-coap]. The collected responses to the 318 ping would then give an indication of the group members. 320 3.6. Configuring Group Membership In Endpoints 322 The group membership of a CoAP endpoint may be configured in one of 323 the following ways. First, the group membership may be pre- 324 configured before node deployment. Second, a node may be programmed 325 to discover (query) its group membership during operation using a 326 specific service discovery means. Third, it may be configured during 327 operation by another node (e.g. a commissioning device). 329 In the first case, the pre-configured group information may be either 330 directly a IP multicast address, or a hostname which is during 331 operation resolved to a IP multicast address by the endpoint using 332 DNS. 334 For the second case, a CoAP endpoint may look up its group membership 335 using techniques such as DNS-SD and Resource Directory 336 [I-D.shelby-core-resource-directory]. The latter is detailed more in 337 section Section 4.6. 339 In the third case, typical in scenarios such as building control, a 340 commissioning tool determines to which group a sensor or actuator 341 node belongs, and writes this information to the node, which can 342 subsequently join the correct IP multicast group on its network 343 interface. The information written may again be a IP multicast 344 address or a hostname. 346 To achieve better interoperability between endpoints from different 347 manufacturers, an OPTIONAL default RESTful interface for configuring 348 CoAP endpoints with relevant group information is described here. 349 This interface provides a solution for the third case mentioned 350 above. To access this interface a client MUST use unicast methods 351 (GET/PUT/POST/DELETE) only as it is a method of configuring group 352 information in individual endpoints. Using multicast operations in 353 this situation may lead to unexpected (possibly circular) behavior in 354 the network. 356 CoAP endpoints implementing this optional mechanism MUST support at 357 least one discoverable "Group Configuration" resource of resource 358 type (rt) [RFC6690] "core.gp" where "gp" is shorthand for "group". 359 This resource is used by an authorized controller to query/manage 360 group membership of a CoAP server. 362 The resource of type "core.gp" has a JSON content format. A 363 (unicast) GET on this resource returns a JSON array of group objects, 364 each group object formatted as shown below: 366 Req: GET /gp 367 Res: 2.05 Content (Content-Format: application/coap-group+json) 368 [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", 369 "ip": "ff15::4200:f7fe:ed37:14ca" } 370 ] 372 where the OPTIONAL "n" key/value pair defines the Group name as FQDN 373 and the OPTIONAL "ip" key/value pair defines the associated IP 374 multicast address. If the IP multicast address is given, this takes 375 priority. The Group name is just informational in this case. If 376 only a Group name is given, the CoAP endpoint has to do DNS 377 resolution (if supported) to obtain the IP multicast address. 379 Note that each group object in the JSON array represents a single IP 380 multicast group for the endpoint. If there are multiple elements in 381 the array then the endpoint is a member of multiple IP multicast 382 groups. 384 A CoAP endpoint can be added to another group by a (unicast) POST on 385 the resource with a single JSON group object, which updates the 386 existing resource by adding the group object to the existing ones: 388 Req: POST /gp (Content-Format: application/coap-group+json) 389 { "n": "floor1.west.bldg6.example.com", 390 "ip": "ff15::4200:f7fe:ed37:14cb" } 391 Res: 2.04 Changed 393 A (unicast) PUT with as payload an array of JSON group objects will 394 replace all current group memberships with the new ones as defined in 395 the payload. After a change effected on the "core.gp" type resource, 396 the endpoint MUST effect registration/de-registration from 397 corresponding IP multicast groups as soon as possible. A (unicast) 398 DELETE will delete all group memberships, and the endpoint MUST 399 effect de-registration from corresponding IP multicast groups as soon 400 as possible. 402 Any (unicast) operation to change a CoAP endpoint group membership 403 configuration (i.e. PUT/POST/DELETE) MUST use DTLS-secured CoAP 404 [I-D.ietf-core-coap]. Thus only authorized clients will be allowed 405 by a server to configure the server's (endpoint) group membership. 407 3.7. Multicast Request Acceptance and Response Suppression 409 CoAP [I-D.ietf-core-coap] and CoRE Link Format [RFC6690] define 410 normative behaviors for: 412 1. Multicast request acceptance - in which cases a request is 413 accepted and executed, and when not. 415 2. Multicast response suppression - in which cases the response of 416 an executed request is returned to the requesting endpoint, and 417 when not. 419 This section first summarizes these normative behaviors and then 420 presents additional guidelines for response suppression. Also a 421 number of multicast example applications are given to illustrate the 422 overall approach. 424 To apply any rules for request and/or response suppression, the IP 425 stack interface of a CoAP server must be able to indicate for an 426 incoming request that the destination address of the request was 427 multicast. 429 For multicast request acceptance, the behaviors are: 431 o A server SHOULD NOT accept a multicast request that cannot be 432 "authenticated" in some way (cryptographically or by some 433 multicast boundary limiting the potential sources) 434 [I-D.ietf-core-coap]. See Section 6.3 for examples of multicast 435 boundary limiting methods. 437 o A server SHOULD NOT accept a multicast discovery request with a 438 query string (as defined in CoRE Link Format [RFC6690]) if 439 filtering ([RFC6690]) is not supported by the server. 441 o A server SHOULD NOT accept a multicast request that acts on a 442 specific resource for which multicast support is not required. 443 (Note that for discovery resource "/.well-known/core" multicast 444 support is always required. Implementers are advised to disable 445 multicast support by default on any other resource, until 446 explicitly enabled by an application.) 448 o Otherwise accept the multicast request. 450 For multicast response suppression, the behaviors are: 452 o A server SHOULD NOT respond to a multicast discovery request if 453 the filter specified by the request's query string does not match. 455 o A server MAY choose not to respond to a multicast request, if 456 there's nothing useful to respond (e.g. error or empty response). 458 o If the IP stack interface cannot indicate that an incoming message 459 was multicast, then the server SHOULD NOT respond for incoming 460 messages for selected resources which are known (through 461 application knowledge) to be used for multicast requests. 463 o Otherwise respond to the multicast request. 465 The above response suppression behaviors are complemented by the 466 following guidelines. CoAP servers should implement configurable 467 response suppression, enabling at least the following per resource: 469 o Suppression of all 2.xx success responses; 471 o Suppression of all 4.xx client errors; 473 o Suppression of all 5.xx server errors; 475 o Suppression of all 2.05 responses with empty payload. 477 A number of group communication example applications are described 478 below illustrating how to make use of response suppression: 480 o CoAP resource discovery: Suppress 2.05 responses with empty 481 payload and all 4.xx and 5.xx errors. 483 o Lighting control: Suppress all 2.xx responses after a lighting 484 change command. 486 o Update group configuration data using multicast PUT: No 487 suppression at all. Use collected responses to identify which 488 group members did not receive the new configuration; then attempt 489 using CoAP CON unicast to update those group members. 491 o Multicast firmware update by sending blocks of data: Suppress all 492 2.xx and 5.xx responses. After having sent all multicast blocks, 493 the client checks each endpoint by unicast to identify which 494 blocks are still missing in each endpoint. 496 o Conditional reporting for a group (e.g. sensors) based on a URI 497 query: Suppress all 2.05 responses with empty payload (i.e. if a 498 query produces no matching results). 500 3.8. Congestion Control 502 Multicast CoAP requests may result in a multitude of replies from 503 different nodes, potentially causing congestion. Therefore both the 504 sending of multicast requests and sending unicast CoAP responses to 505 multicast requests should be conservatively controlled. 507 CoAP [I-D.ietf-core-coap] reduces multicast-specific congestion risks 508 through the following measures: 510 o A server MAY choose not to respond to a multicast request if 511 there's nothing useful to respond (e.g. error or empty response). 512 See Section 3.7 for more detailed guidelines on response 513 suppression. 515 o A server SHOULD limit the support for multicast requests to 516 specific resources where multicast operation is required. 518 o A multicast request MUST be Non-Confirmable. 520 o A response to a multicast request SHOULD be Non-Confirmable 521 (Section 5.2.3). 523 o A server does not respond immediately to a multicast request, but 524 SHOULD first wait for a time that is randomly picked within a 525 predetermined time interval called the Leisure. 527 o A server SHOULD NOT accept multicast requests that can not be 528 authenticated in some way. See Section 3.7 for more details on 529 request suppression and multicast source authentication. 531 Additional guidelines to reduce congestion risks are: 533 o A server in an LLN should only support multicast GET for resources 534 that are small, e.g. the payload of the response fits into a 535 single link-layer frame. 537 o A server can minimize the payload length in response to a 538 multicast GET on "/.well-known/core" by using hierarchy in 539 arranging link descriptions for the response. An example of this 540 is given in Section 5 of [RFC6690]. 542 o Alternatively a server can also minimize the payload length of a 543 response to a multicast GET (e.g. on "/.well-known/core") using 544 CoAP blockwise transfers [I-D.ietf-core-block], returning only a 545 first block of the link format description. 547 o A client should always aim to use IP multicast with link-local 548 scope if possible. If this is not possible, then site-local scope 549 IP multicast should be considered. If this is not possible, then 550 global scope IP multicast should be considered as a last resort 551 only. 553 3.9. Proxy Operation 555 CoAP [I-D.ietf-core-coap] allows a client to request a forward-proxy 556 to process its CoAP request. For this purpose the client either 557 specifies the request URI as a string in the Proxy-URI option, or it 558 specifies the Proxy-Scheme option with the URI constructed from the 559 usual Uri-* options. This approach works well for unicast requests. 560 However, there are certain issues and limitations of processing the 561 (unicast) responses to a group communication request made in this 562 manner through a proxy. Specifically, if a proxy would apply 563 aggregation of responses in such a case: 565 o Aggregation of (unicast) responses to a group communication 566 request in a proxy is difficult. This is because the proxy does 567 not know how many members there are in the group or how many group 568 members will actually respond. 570 o There is no default format defined in CoAP for aggregation of 571 multiple responses into a single response. 573 But if a proxy would follow the specification for a CoAP Proxy 574 [I-D.ietf-core-coap], the proxy would simply forward all the 575 individual (unicast) responses to a group communication request to 576 the client (i.e. no aggregation), there are also issues: 578 o The client may be confused as it may not have known that the 579 Proxy-URI contained a multicast target. That is, the client may 580 be expecting only one (unicast) response but instead receives 581 multiple (unicast) responses potentially leading to fault 582 conditions in the application or CoAP stack. 584 o Each individual CoAP response will appear to originate (IP Source 585 address) from the CoAP Proxy, and not from the server that 586 produced the response. This makes it impossible for the client to 587 identify the server that produced each response. 589 Due to above issues, a guideline is defined here that a CoAP Proxy 590 SHOULD NOT support processing a multicast CoAP request but rather 591 return a 501 (Not Implemented) response in such case. The exception 592 case here (i.e. to process it) is allowed under following 593 conditions: 595 o The CoAP Proxy MUST be explicitly configured (whitelist) to allow 596 proxied multicast requests by specific client(s). 598 o The proxy SHOULD return individual (unicast) CoAP responses to the 599 client, i.e. not aggregated. (This condition MAY be removed once 600 an aggregation format is standardized.) 602 o It MUST be known to the person/entity doing the configuration of 603 the proxy, or verified in some way, that the client configured in 604 the whitelist supports receiving multiple responses to a proxied 605 unicast CoAP request. 607 3.10. Exceptions 608 Group communication using IP multicast offers improved network 609 efficiency and latency amongst other benefits. However, group 610 communication may not always be possible to implement in a given 611 network. The primary reason for this will be if IP multicast is not 612 supported in the network. For example, in a LLN, if the RPL protocol 613 is used for routing multicast packets and RPL routers operate in 614 "Non-storing mode" [RFC6550] there will be no IP multicast routing in 615 that network beyond link-local scope. This means that any CoAP group 616 communication above link-local scope will not be supported in that 617 network. 619 4. Use Cases and Corresponding Protocol Flows 621 4.1. Introduction 623 The use of CoAP group communication is shown in the context of the 624 following two use cases and corresponding protocol flows: 626 o Discovery of Resource Directory (RD, 627 [I-D.shelby-core-resource-directory]): discovering the local CoAP 628 RD which contains links (URIs) to resources stored on other CoAP 629 servers [RFC6690]. 631 o Lighting Control: synchronous operation of a group of 632 IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights). 634 4.2. Network Configuration 636 To illustrate the use cases we define two network configurations. 637 Both are based on the topology as shown in Figure 1. The two 638 configurations using this topology are: 640 1. Subnets are 6LoWPAN networks; the routers Rtr-1 and Rtr-2 are 641 6LoWPAN Border Routers (6LBRs, [RFC6775]). 643 2. Subnets are Ethernet links; the routers Rtr-1 and Rtr-2 are 644 multicast-capable Ethernet routers. 646 Both configurations are further specified by the following: 648 o A large room (Room-A) with three lights (Light-1, Light-2, 649 Light-3) controlled by a Light Switch. The devices are organized 650 into two subnets. In reality, there could be more lights (up to 651 several hundreds) but these are not shown for clarity. 653 o Light-1 and the Light Switch are connected to a router (Rtr-1). 655 o Light-2 and the Light-3 are connected to another router (Rtr-2). 657 o The routers are connected to an IPv6 network backbone which is 658 also multicast enabled. In the general case, this means the 659 network backbone and Rtr-1/Rtr-2 support a PIM based multicast 660 routing protocol, and MLD for forming groups. In a limited case, 661 if the network backbone is one link, then the routers only have to 662 support MLD-snooping (Appendix A) for the following use cases to 663 work. 665 o A CoAP RD is connected to the network backbone. 667 o The DNS server is optional. If the server is there (connected to 668 the network backbone) then certain DNS based features are 669 available (e.g. DNS resolution of URI to IP multicast address). 670 If the DNS server is not there, then different manual provisioning 671 of the network is required (e.g. IP multicast addresses are hard- 672 coded into devices). 674 o A Controller (client) is connected to the backbone, which is able 675 to control various building functions including lighting. 677 Network 678 Backbone 679 ################################################ | 680 # ********************** Room-A # | 681 # ** Subnet-1 ** # | 682 # * ** # | 683 # * +----------+ * # | 684 # * | Light |-------+ * # | 685 # * | Switch | | * # | 686 # * +----------+ +---------+ * # | 687 # * | Rtr-1 |-----------------------------+ 688 # * +---------+ * # | 689 # * +----------+ | * # | 690 # * | Light-1 |--------+ * # | 691 # * +----------+ * # | 692 # * * # | 693 # ** ** # | 694 # ********************** # | 695 # # | 696 # ********************** # | 697 # ** Subnet-2 ** # | 698 # * ** # | 699 # * +----------+ * # | 700 # * | Light-2 |-------+ * # | 701 # * | | | * # | 702 # * +----------+ +---------+ * # | 703 # * | Rtr-2 |-----------------------------+ 704 # * +---------+ * # | 705 # * +----------+ | * # | 706 # * | Light-3 |--------+ * # | 707 # * +----------+ * # +------------+ | 708 # * * # | Controller |--+ 709 # ** ** # | Client | | 710 # ********************** # +------------+ | 711 ################################################ | 712 | 713 +------------+ | 714 | CoAP | | 715 | Resource |-----------------+ 716 | Directory | | 717 +------------+ | 718 +------------+ | 719 | DNS Server | | 720 | (Optional) |-----------------+ 721 +------------+ 723 Figure 1: Network Topology of a Large Room (Room-A) 725 4.3. Discovery of Resource Directory 727 The protocol flow for discovery of the CoAP RD for the given network 728 (of Figure 1) is shown in Figure 2: 730 o The fixture for Light-2 is installed and powered on for the first 731 time. 733 o Light-2 will then search for the local CoAP RD by sending out a 734 GET request (with the "/.well-known/core?rt=core.rd" request URI) 735 to the site-local "All CoAP Nodes" multicast address. 737 o This multicast message will then go to each node in subnet-2. 738 Rtr-2 will then forward into to the Network Backbone where it will 739 be received by the CoAP RD. All other nodes in subnet-2 will 740 ignore the multicast GET because it is qualified by the query 741 string "?rt=core.rd" (which indicates it should only be processed 742 by the endpoint if it is a RD). 744 o The CoAP RD will then send back a unicast response containing the 745 requested content. 747 o Note that the flow is shown only for Light-2 for clarity. Similar 748 flows will happen for Light-1, Light-3 and the Light Switch when 749 they are first powered on. 751 The CoAP RD may also be discovered by other means such as by assuming 752 a default location (e.g. on a 6LBR), using DHCP, anycast address, 753 etc. However, these approaches do not invoke CoAP group 754 communication so are not further discussed here. 756 For other discovery use cases such as discovering local CoAP servers, 757 services or resources group communication can be used in a similar 758 fashion as in the above use case. Both Link-Local (LL) and site- 759 local discovery are possible this way. 761 Light CoAP 762 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD 763 | | | | | | | 764 | | | | | | | 765 ********************************** | | | 766 * Light-2 is installed * | | | 767 * and powers on for first time * | | | 768 ********************************** | | | 769 | | | | | | | 770 | | | | | | | 771 | | COAP NON Mcast(GET | | 772 | | /.well-known/core?rt=core.rd) | | 773 | |--------->-------------------------------->| | 774 | | | | | |--------->| 775 | | | | | | | 776 | | | | | | | 777 | | COAP NON (2.05 Content | | 778 | | ;rt="core.rd";ins="Primary") |<---------| 779 | |<------------------------------------------| | 780 | | | | | | | 782 Figure 2: Resource Directory Discovery via Multicast Message 784 4.4. Lighting Control 786 The protocol flow for a building automation lighting control scenario 787 for the network (Figure 1) in 6LoWPAN configuration is shown in 788 sequence in Figure 3 for the case that the CoAP servers in each Light 789 are configured to not generate a CoAP response to lighting control 790 CoAP multicast requests. (See section Section 3.7 for more details 791 on response suppression by a server.) 793 In addition, Figure 4 shows a protocol flow example for the case that 794 servers do respond to a lighting control multicast request with 795 (unicast) CoAP NON responses. There are two success responses and 796 one 5.00 error response. In this particular use case the Light 797 Switch does not check, based on the responses, that all Lights in the 798 group actually received the multicast request, because it is not 799 configured with an exhaustive list of IP addresses of all Lights 800 belonging to the group. However, based on received error responses 801 it could take additional action such as logging a fault or alerting 802 the user via its LCD display. 804 Reliability of CoAP multicast is not guaranteed. Therefore, one or 805 more lights in the group may not have received the CoAP control 806 request due to packet loss. In this use case there is no detection 807 nor correction of such situations: the application layer expects that 808 the multicast forwarding/routing will be of sufficient quality to 809 provide on average a very high probability of packet delivery to all 810 CoAP endpoints in a multicast group. An example protocol to 811 accomplish this is the MPL forwarding protocol for LLNs 812 [I-D.ietf-roll-trickle-mcast]. 814 We assume the following steps have already occurred before the 815 illustrated flows: 817 1. Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to 818 all devices. The CoAP network is formed. 820 2. Network configuration (application-independent): 6LBRs are 821 configured with multicast address blocks to filter out or to pass 822 through to/from the 6LoWPAN. 824 3. Commissioning phase (application-related): The IP multicast 825 address of the group (Room-A-Lights) has been configured in all 826 the Lights and in the Light Switch. 828 4. As an alternative to the previous step, when a DNS server is 829 available, the Light Switch and/or the Lights have been 830 configured with a group hostname which each nodes resolves to the 831 above IP multicast address of the group. 833 Note for the Commissioning phase: the switch's software supports 834 sending unicast, multicast or proxied unicast/multicast CoAP 835 requests, including processing of the multiple responses that may be 836 generated by a multicast CoAP request. 838 Light Network 839 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 840 | | | | | | | 841 | | | | | | | 842 | | *********************** | | 843 | | * User flips on * | | 844 | | * light switch to * | | 845 | | * turn on all the * | | 846 | | * lights in Room A * | | 847 | | *********************** | | 848 | | | | | | | 849 | | | | | | | 850 | | | COAP NON Mcast(PUT, | | 851 | | | Payload=lights ON) | | 852 |<-------------------------------+--------->| | | 853 ON | | | |-------------------->| 854 | | | | | |<---------| 855 | |<---------|<-------------------------------| | 856 | ON ON | | | | 857 ^ ^ ^ | | | | 858 *********************** | | | | 859 * Lights in Room-A * | | | | 860 * turn on (nearly * | | | | 861 * simultaneously) * | | | | 862 *********************** | | | | 863 | | | | | | | 865 Figure 3: Light Switch Sends Multicast Control Message 867 Light Network 868 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 869 | | | | | | | 870 | COAP NON (2.04 Changed) | | | | 871 |------------------------------->| | | | 872 | | | | | | | 873 | | | | | | | 874 | COAP NON (2.04 Changed) | | | 875 | |------------------------------------------>| | 876 | | | | | |--------->| 877 | | | | |<--------------------| 878 | | | |<---------| | | 879 | | | | | | | 880 | | COAP NON (5.00 Internal Server Error) | 881 | | |------------------------------->| | 882 | | | | | |--------->| 883 | | | | |<--------------------| 884 | | | |<---------| | | 885 | | | | | | | 887 Figure 4: Lights (Optionally) Respond to Multicast CoAP Request 889 Another, but similar, lighting control use case is shown in Figure 5. 890 In this case a controller connected to the Network Backbone sends a 891 CoAP multicast request to turn on all lights in Room-A. Every Light 892 sends back a CoAP response to the Controller after being turned on. 894 Network 895 Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller 896 | | | | | | | 897 | | | | | COAP NON Mcast(PUT, 898 | | | | | Payload=lights ON) 899 | | | | | |<-------| 900 | | | |<----------<---------| | 901 |<--------------------------------| | | | 902 ON | | | | | | 903 | |<----------<---------------------| | | 904 | ON ON | | | | 905 ^ ^ ^ | | | | 906 *********************** | | | | 907 * Lights in Room-A * | | | | 908 * turn on (nearly * | | | | 909 * simultaneously) * | | | | 910 *********************** | | | | 911 | | | | | | | 912 | | | | | | | 913 | COAP NON (2.04 Changed) | | | | 914 |-------------------------------->| | | | 915 | | | |-------------------->| | 916 | | COAP NON (2.04 Changed) | |------->| 917 | |-------------------------------->| | | 918 | | | | |--------->| | 919 | | | COAP NON (2.04 Changed) |------->| 920 | | |--------------------->| | | 921 | | | | |--------->| | 922 | | | | | |------->| 923 | | | | | | | 925 Figure 5: Controller On Backbone Sends Multicast Control Message 927 4.5. Lighting Control in MLD Enabled Network 929 The use case of previous section can also apply in networks where 930 nodes support the MLD protocol [RFC3810]. The Lights then take on 931 the role of MLDv2 listener and the routers (Rtr-1, Rtr-2) are MLDv2 932 Routers. In the Ethernet based network configuration, MLD may be 933 available on all involved network interfaces. Use of MLD in the 934 6LoWPAN based configuration is also possible, but requires MLD 935 support in all nodes in the 6LoWPAN which is usually not implemented 936 in many deployments. 938 The resulting protocol flow is shown in Figure 6. This flow is 939 executed after the commissioning phase, as soon as Lights are 940 configured with a group address to listen to. The (unicast) MLD 941 Reports may require periodic refresh activity as specified by the MLD 942 protocol. In the figure, LL denotes Link Local communication. 944 After the shown sequence of MLD Report messages has been executed, 945 both Rtr-1 and Rtr-2 are automatically configured to forward 946 multicast traffic destined to Room-A-Lights onto their connected 947 subnet. Hence, no manual Network Configuration of routers, as 948 previously indicated in Section 4.4, is needed anymore. 950 Light Network 951 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 952 | | | | | | | 953 | | | | | | | 954 | | | | | | | 955 | MLD Report: Join | | | | | 956 | Group (Room-A-Lights) | | | | 957 |---LL------------------------------------->| | | 958 | | | | |MLD Report: Join | 959 | | | | |Group (Room-A-Lights)| 960 | | | | |---LL---->----LL---->| 961 | | | | | | | 962 | | MLD Report: Join | | | | 963 | | Group (Room-A-Lights) | | | 964 | |---LL------------------------------------->| | 965 | | | | | | | 966 | | | MLD Report: Join | | | 967 | | | Group (Room-A-Lights) | | 968 | | |---LL-------------------------->| | 969 | | | | | | | 970 | | | | |MLD Report: Join | 971 | | | | |Group (Room-A-Lights)| 972 | | | | |<--LL-----+---LL---->| 973 | | | | | | | 974 | | | | | | | 976 Figure 6: Joining Lighting Groups Using MLD 978 4.6. Commissioning the Network Based On Resource Directory 980 This section outlines how devices in the lighting use case (both 981 Switches and Lights) can be commissioned, making use of Resource 982 Directory [I-D.shelby-core-resource-directory] and its group 983 configuration feature. 985 Once the Resource Directory (RD) is discovered, the Switches and 986 Lights need to be discovered and their groups need to be defined. 987 For the commissioning of these devices, a commissioning tool can be 988 used that defines the entries in the RD. The commissioning tool has 989 the authority to change the contents of the RD and the nodes. DTLS 990 based security is used by the commissioning tool to modify 991 operational data in RD, Switches and Lights. 993 In our particular use case, a group of three lights is defined with 994 one multicast address and hostname 995 Room-A-Lights.floor1.west.bldg6.example.com. The commissioning 996 device has a list of the three lights and the associated multicast 997 address. For each light in the list the tool learns the IP address 998 of the light and instructs the RD with 3 POST commands to store the 999 end-points associated with the three lights as prescribed by RD. 1000 Finally the commissioning device defines the group in the RD to 1001 contain these three end-points. Also the commissioning tool writes 1002 the MC address in the Lights with e.g. the POST /gp command 1003 discussed in Section 3.6. 1005 The light switch can discover the group in RD and learn the MC 1006 address of the group. The light switch will use this address to send 1007 MC commands to the members of the group. When the message arrives 1008 the Lights should recognize the MC address and accept the message. 1010 5. Deployment Guidelines 1012 This section provides guidelines how an IP Multicast based solution 1013 for CoAP group communication can be deployed in various network 1014 configurations. 1016 5.1. Target Network Topologies 1018 CoAP group communication can be deployed in various network 1019 topologies. First, the target network may be a regular IP network, 1020 or a LLN such as a 6LoWPAN network, or consist of mixed constrained/ 1021 unconstrained network segments. Second, it may be a single subnet 1022 only or multi-subnet; e.g. multiple 6LoWPAN networks joined by a 1023 single backbone LAN. Third, a wireless network segment may have all 1024 nodes reachable in a single IP hop, or it may require multiple IP 1025 hops for some pairs of nodes to reach each other. 1027 Each topology may pose different requirements on the configuration of 1028 routers and protocol(s), in order to enable efficient CoAP group 1029 communication. 1031 5.2. Advertising Membership of Multicast Groups 1032 If a multicast routing/forwarding protocol is used in a network, 1033 server nodes that intend to receive CoAP multicast requests generally 1034 require a method to advertise the specific IP multicast address(es) 1035 they want to receive, i.e. a method to join specific IP multicast 1036 groups. This section identifies the ways in which this can be 1037 accomplished. 1039 5.2.1. Using the Multicast Listener Discovery (MLD) Protocol 1041 CoAP nodes that are IP hosts (i.e. not IP routers) are generally 1042 unaware of the specific multicast routing/forwarding protocol being 1043 used. When such a host needs to join a specific (CoAP) multicast 1044 group, it usually requires a way to signal to multicast routers which 1045 multicast traffic it wants to receive. For efficient multicast 1046 routing (i.e. avoid always flooding IP multicast packets), routers 1047 must know which hosts need to receive packets addressed to specific 1048 IP multicast destinations. 1050 The Multicast Listener Discovery (MLD) protocol ([RFC3810], 1051 Appendix A) is the standard IPv6 method to achieve this. [RFC6636] 1052 discusses tuning of MLD for mobile and wireless networks. These 1053 guidelines may be useful when implementing MLD in LLNs. 1055 Alternatively, to avoid the use of MLD in LLN deployments, either all 1056 nodes can be configured as multicast routers in an LLN, or a 1057 multicast forwarding/flooding protocol can be used that forwards any 1058 IP multicast packet to all forwarders (routers) in the subnet (LLN). 1060 5.2.2. Using the RPL Routing Protocol 1062 The RPL routing protocol [RFC6550] defines in Section 12 the 1063 advertisement of IP multicast destinations using DAO messages. This 1064 mechanism can be used by CoAP nodes (which are also RPL routers) to 1065 advertise IP multicast group membership to other RPL routers. Then, 1066 the RPL protocol can route multicast CoAP requests over multiple hops 1067 to the correct CoAP servers. 1069 This mechanism can be used as a means to convey IP multicast group 1070 membership information to an edge router (e.g. 6LBR), in case the 1071 edge router is also the root of the RPL DODAG. This could be useful 1072 in LLN segments where MLD is not available and the edge router needs 1073 to know what IP multicast traffic to pass through from the backbone 1074 network into the LLN subnet. 1076 5.2.3. Using the MPL Forwarding Protocol 1078 The MPL forwarding protocol [I-D.ietf-roll-trickle-mcast] can be used 1079 in a predefined network domain for propagation of IP multicast 1080 packets to all MPL routers, over multiple hops. MPL is designed to 1081 work in LLN deployments. Due to its property of propagating all 1082 (non-link-local) IP multicast packets to all MPL routers, there is in 1083 principle no need for CoAP server nodes to advertise IP multicast 1084 group membership assuming that any IP multicast source is also part 1085 of the MPL domain. 1087 5.3. 6LoWPAN-Specific Guidelines 1089 To support multi-LoWPAN scenarios for CoAP group communication, it is 1090 RECOMMENDED that a 6LoWPAN Border Router (6LBR) will act in an MLD 1091 Router role on the backbone link. If this is not possible then the 1092 6LBR SHOULD be configured to act as an MLD Multicast Address Listener 1093 and/or MLD Snooper (Appendix A) on the backbone link. 1095 To avoid that backbone IP multicast traffic needlessly congests 1096 6LoWPAN network segments, it is RECOMMENDED that a filtering means is 1097 implemented to block IP multicast traffic from 6LoWPAN segments where 1098 none of the 6LoWPAN nodes listen to this traffic. Possible means 1099 are: 1101 o Filtering in 6LBRs based on information from the routing protocol. 1102 This allows a 6LBR to only forward multicast traffic onto the 1103 LoWPAN, for which it is known that there exists at least one 1104 listener on the LoWPAN. 1106 o Filtering in 6LBRs based on MLD reports. Similar as previous but 1107 based directly on MLD reports from 6LoWPAN nodes. This only works 1108 in a single-IP-hop 6LoWPAN network, such as a mesh-under routing 1109 network or a star topology network, because MLD relies on link- 1110 local communication. 1112 o Filtering in 6LBRs based on settings. Filtering tables with 1113 blacklists/whitelists can be configured in the 6LBR by system 1114 administration for all 6LBRs or configured on a per-6LBR basis. 1116 o Filtering in router(s) or firewalls that provide access to 1117 constrained network segments. For example, in an access router/ 1118 bridge that connects a regular intranet LAN to a building control 1119 IPv6 backbone. This backbone connects multiple 6LoWPAN segments, 1120 each segment connected via a 6LBR. 1122 6. Security Considerations 1124 This section describes the relevant security configuration for CoAP 1125 group communication using IP multicast. The threats to CoAP group 1126 communication are also identified and various approaches to mitigate 1127 these threats are summarized. 1129 6.1. Security Configuration 1131 As defined in [I-D.ietf-core-coap], CoAP group communication based on 1132 IP multicast must use the following security modes: 1134 o Group communication MUST operate in CoAP NoSec (No Security) mode. 1136 o Group communication MUST NOT use "coaps" scheme. That is, all 1137 group communication MUST use only "coap" scheme. 1139 6.2. Threats 1141 Essentially the above configuration means that there is no security 1142 at the CoAP layer for group communication. This is due to the fact 1143 that the current DTLS based approach for CoAP is exclusively unicast 1144 oriented and does not support group security features such as group 1145 key exchange and group authentication. As a direct consequence of 1146 this, CoAP group communication is vulnerable to all attacks mentioned 1147 in [I-D.ietf-core-coap] for IP multicast. 1149 6.3. Threat Mitigation 1151 [I-D.ietf-core-coap] identifies various threat mitigation techniques 1152 for CoAP IP multicast. In addition to those guidelines, it is 1153 recommended that for sensitive data or safety-critical control, a 1154 combination of appropriate link-layer security and administrative 1155 control of IP multicast boundaries should be used. Some examples are 1156 given below. 1158 6.3.1. WiFi Scenario 1160 In a home automation scenario (using WiFi), the WiFi encryption 1161 should be enabled to prevent rogue nodes from joining. Also, if MAC 1162 address filtering at the WiFi Access Point is supported that should 1163 also be enabled. The IP router should have the fire wall enabled to 1164 isolate the home network from the rest of the Internet. In addition, 1165 the domain of the IP multicast should be set to be either link-local 1166 scope or site-local scope. Finally, if possible, devices should be 1167 configured to accept only Source Specific Multicast (SSM) packets 1168 (see [RFC4607]) from within the trusted home network. For example, 1169 all lights in a particular room should only accept IP multicast 1170 traffic originating from the master light switch in that room. In 1171 this case, the Spoofed Source Address considerations of Section 7.4 1172 of [RFC4607] should be heeded. 1174 6.3.2. 6LoWPAN Scenario 1175 In a building automation scenario, a particular room may have a 1176 single 6LoWPAN topology with a single Edge Router (6LBR). Nodes on 1177 the subnet can use link-layer encryption to prevent rogue nodes from 1178 joining. The 6LBR can be configured so that it blocks any incoming 1179 IP multicast traffic. Another example topology could be a multi- 1180 subnet 6LoWPAN in a large conference room. In this case, the 1181 backbone can implement port authentication (IEEE 802.1X) to ensure 1182 only authorized devices can join the Ethernet backbone. The access 1183 router to this secured segment can also be configured to block 1184 incoming IP multicast traffic. 1186 6.3.3. Future Evolution 1188 In the future, to further mitigate the threats, the developing 1189 approach for DTLS-based IP multicast security for CoAP networks (see 1190 [I-D.keoh-tls-multicast-security]) or similar approaches should be 1191 considered once they mature. 1193 7. IANA Considerations 1195 7.1. New 'core.gp' Resource Type 1197 This memo registers a new resource type (rt) from the CoRE Parameters 1198 Registry called 'core.gp' as per the process described in section 7.4 1199 of [RFC6690]. 1201 Attribute Value: core.gp 1203 Description: Optional Group Configuration resource. This resource is 1204 used to query/manage the group membership of a CoAP server. 1206 Reference: See Section 3.6. 1208 7.2. New 'coap-group+json' Internet Media Type 1210 This memo registers a new Internet Media Type for CoAP group 1211 configuration resource called 'application/coap-group+json' (as per 1212 [RFC4288]) . This registration also follows the specific guidance 1213 from section 12.3 (last paragraph) of [I-D.ietf-core-coap]. 1215 Type name: application 1217 Subtype name: coap-group+json 1219 Required parameters: None 1221 Optional parameters: None 1222 Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32. 1224 JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON is 1225 written in UTF-8, JSON is 8bit compatible. When JSON is written in 1226 UTF-16 or UTF-32, the binary content-transfer-encoding must be used. 1228 If the client is aware that the server group configuration resource 1229 is 8bit encoded (which is most efficient for a constrained device), 1230 that encoding should be respected by the client (i.e. it should not 1231 try to replace it by a binary encoded group configuration resource). 1233 Security considerations: 1235 Denial of Service attacks could be performed by constantly setting 1236 the group configuration resource of a CoAP endpoint. This will cause 1237 the endpoint to register (or de-register) from the related IP 1238 multicast group. To prevent this it is mandatory that DTLS-secured 1239 CoAP communication be used for setting the group configuration 1240 resource. Thus only authorized clients will be allowed by a server 1241 to configure its group membership. 1243 Interoperability considerations: None 1245 Published specification: (This I-D when it becomes an RFC) 1247 Applications that use this media type: 1249 CoAP client and server implementations that wish to set/read the 1250 group configuration resource via 'application/coap-group+json' 1251 payload as described in Section 3.6. 1253 Additional Information: 1255 Magic number(s): None 1257 File extension(s): *.json 1259 Macintosh file type code(s): TEXT 1261 Intended usage: COMMON 1263 Restrictions on usage: None 1265 Author: CoRE WG 1267 Change controller: IETF 1269 8. Acknowledgements 1271 Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo 1272 Castellani, Guang Lu, Salvatore Loreto, Kerry Lynn, Dale Seed, Zach 1273 Shelby, Peter van der Stok, and Juan Carlos Zuniga for their helpful 1274 comments and discussions that have helped shape this document. 1276 9. References 1278 9.1. Normative References 1280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1281 Requirement Levels", BCP 14, RFC 2119, March 1997. 1283 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1284 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1285 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1287 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1288 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1290 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1291 Registration Procedures", RFC 4288, December 2005. 1293 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1294 Architecture", RFC 4291, February 2006. 1296 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1297 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1298 Protocol Specification (Revised)", RFC 4601, August 2006. 1300 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1301 IP", RFC 4607, August 2006. 1303 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1304 "Transmission of IPv6 Packets over IEEE 802.15.4 1305 Networks", RFC 4944, September 2007. 1307 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1308 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1309 March 2010. 1311 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1312 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1313 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1314 Lossy Networks", RFC 6550, March 2012. 1316 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1317 the Internet Group Management Protocol (IGMP) and 1318 Multicast Listener Discovery (MLD) for Routers in Mobile 1319 and Wireless Networks", RFC 6636, May 2012. 1321 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1322 Format", RFC 6690, August 2012. 1324 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1325 "Neighbor Discovery Optimization for IPv6 over Low-Power 1326 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1327 November 2012. 1329 [I-D.ietf-core-coap] 1330 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1331 Application Protocol (CoAP)", draft-ietf-core-coap-16 1332 (work in progress), May 2013. 1334 9.2. Informative References 1336 [I-D.ietf-core-block] 1337 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1338 draft-ietf-core-block-11 (work in progress), March 2013. 1340 [I-D.vanderstok-core-dna] 1341 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 1342 Naming, and Addressing", draft-vanderstok-core-dna-02 1343 (work in progress), July 2012. 1345 [I-D.ietf-roll-trickle-mcast] 1346 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1347 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 1348 mcast-04 (work in progress), February 2013. 1350 [I-D.keoh-tls-multicast-security] 1351 Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast 1352 Security for Low-Power and Lossy Networks (LLNs)", draft- 1353 keoh-tls-multicast-security-00 (work in progress), October 1354 2012. 1356 [I-D.shelby-core-resource-directory] 1357 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 1358 Directory", draft-shelby-core-resource-directory-05 (work 1359 in progress), February 2013. 1361 Appendix A. Multicast Listener Discovery (MLD) 1362 In order to extend the scope of IP multicast beyond link-local scope, 1363 an IP multicast routing or forwarding protocol has to be active in 1364 routers on an LLN. To achieve efficient multicast routing (i.e. 1365 avoid always flooding IP multicast packets), routers have to learn 1366 which hosts need to receive packets addressed to specific IP 1367 multicast destinations. 1369 The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its 1370 IPv4 pendant IGMP) is today the method of choice used by an (IP 1371 multicast enabled) router to discover the presence of multicast 1372 listeners on directly attached links, and to discover which multicast 1373 addresses are of interest to those listening nodes. MLD was 1374 specifically designed to cope with fairly dynamic situations in which 1375 multicast listeners may join and leave at any time. 1377 IGMP/MLD Snooping is a technique implemented in some corporate LAN 1378 routing/switching devices. An MLD snooping switch listens to MLD 1379 State Change Report messages from MLD listeners on attached links. 1380 Based on this, the switch learns on what LAN segments there is 1381 interest for what IP multicast traffic. If the switch receives at 1382 some point an IP multicast packet, it uses the stored information to 1383 decide onto which LAN segment(s) to send the packet. This improves 1384 network efficiency compared to the regular behavior of forwarding 1385 every incoming multicast packet onto all LAN segments. An MLD 1386 snooping switch may also send out MLD Query messages (which is 1387 normally done by a device in MLD Router role) if no MLD Router is 1388 present. 1390 [RFC6636] discusses optimal tuning of the parameters of MLD for 1391 routers for mobile and wireless networks. These guidelines may be 1392 useful when implementing MLD in LLNs. 1394 Appendix B. Change Log 1396 Changes from ietf-06 to ietf-07: 1398 o Added an IANA request (in section 7.2) for a dedicated content- 1399 format (Internet Media type) for the group management JSON format 1400 called 'application/coap-group+json' (#299). 1402 o Clarified semantics (in section 3.6) of group management JSON 1403 format (#300). 1405 o Added details of IANA request (in section 7.1) for a new CORE 1406 Resource Type called 'core.gp'. 1408 o Clarified that DELETE method (in section 3.6) is also a valid 1409 group management operation. 1411 o Various editorial updates for improved readability. 1413 Changes from ietf-05 to ietf-06: 1415 o Added a new section on commissioning flow when using discovery 1416 services when end devices discover in which multicast group they 1417 are allocated (#295). 1419 o Added a new section on CoAP Proxy Operation (section 3.9) that 1420 outlines the potential issues and limitations of doing CoAP 1421 multicast requests via a CoAP Proxy (#274). 1423 o Added use case of multicasting controller on the backbone (#279). 1425 o Use cases were updated to show only a single CoAP RD (to replace 1426 the previous multiple RDs with one in each subnet). This is a 1427 more efficient deployment and also avoids RD specific issues such 1428 as synchronization of RD information between serves (#280). 1430 o Added text to section 3.6 (Configuring Group Membership in 1431 Endpoints) that clarified that any (unicast) operation to change 1432 an endpoint's group membership must use DTLS-secured CoAP. 1434 o Clarified relationship of this document to [I-D.ietf-core-coap] in 1435 section 2.2 (Scope). 1437 o Removed IPSec related requirement, as IPSec is not part of 1438 [I-D.ietf-core-coap] anymore. 1440 o Editorial reordering of subsections in section 3 to have a better 1441 flow of topics. Also renamed some of the (sub)sections to better 1442 reflect their content. Finally, moved the URI Configuration text 1443 to the same section as the Port Configuration section as it was a 1444 more natural grouping (now in section 3.3) . 1446 o Editorial rewording of section 3.7 (Multicast Request Acceptance 1447 and Response Suppression) to make the logic easier to comprehend 1448 (parse). 1450 o Various editorial updates for improved readability. 1452 Changes from ietf-04 to ietf-05: 1454 o Added a new section 3.9 (Exceptions) that highlights that IP 1455 multicast (and hence group communication) is not always available 1456 (#187). 1458 o Updated text on the use of [RFC2119] language (#271) in Section 1. 1460 o Included guidelines on when (not) to use CoAP responses to 1461 multicast requests and when (not) to accept multicast requests 1462 (#273). 1464 o Added guideline on use of core-block for minimizing response size 1465 (#275). 1467 o Restructured section 6 (Security Considerations) to more fully 1468 describe threats and threat mitigation (#277). 1470 o Clearly indicated that DNS resolution and reverse DNS lookup are 1471 optional. 1473 o Removed confusing text about a single group having multiple IP 1474 addresses. If multiple IP addresses are required then multiple 1475 groups (with the same members) should be created. 1477 o Removed repetitive text about the fact that group communication is 1478 not guaranteed. 1480 o Merged previous section 5.2 (Multicast Routing) into 3.1 (IP 1481 Multicast Routing Background) and added link to section 5.2 1482 (Advertising Membership of Multicast Groups). 1484 o Clarified text in section 3.8 (Congestion Control) regarding 1485 precedence of use of IP multicast domains (i.e. first try to use 1486 link-local scope, then site-local scope, and only use global IP 1487 multicast as a last resort). 1489 o Extended group resource manipulation guidelines with use of pre- 1490 configured ports/paths for the multicast group. 1492 o Consolidated all text relating to ports in a new section 3.3 (Port 1493 Configuration). 1495 o Clarified that all methods (GET/PUT/POST) for configuring group 1496 membership in endpoints should be unicast (and not multicast) in 1497 section 3.7 (Configuring Group Membership In Endpoints). 1499 o Various editorial updates for improved readability, including 1500 editorial comments by Peter van der Stok to WG list of December 1501 18th, 2012. 1503 Changes from ietf-03 to ietf-04: 1505 o Removed section 2.3 (Potential Solutions for Group Communication) 1506 as it is purely background information and moved section to draft- 1507 dijk-core-groupcomm-misc (#266). 1509 o Added reference to draft-keoh-tls-multicast-security to section 6 1510 (Security Considerations). 1512 o Removed Appendix B (CoAP-Observe Alternative to Group 1513 Communications) as it is as an alternative to IP Multicast that 1514 the WG has not adopted and moved section to draft-dijk-core- 1515 groupcomm-misc (#267). 1517 o Deleted section 8 (Conclusions) as it is redundant (#268). 1519 o Simplified light switch use case (#269) by splitting into basic 1520 operations and additional functions (#269). 1522 o Moved section 3.7 (CoAP Multicast and HTTP Unicast Interworking) 1523 to draft-dijk-core-groupcomm-misc (#270). 1525 o Moved section 3.3.1 (DNS-SD) and 3.3.2 (CoRE Resource Directory) 1526 to draft-dijk-core-groupcomm-misc as these sections essentially 1527 just repeated text from other drafts regarding DNS based features. 1528 Clarified remaining text in this draft relating to DNS based 1529 features to clearly indicate that these features are optional 1530 (#272). 1532 o Focus section 3.5 (Configuring Group Membership) on a single 1533 proposed solution. 1535 o Scope of section 5.3 (Use of MLD) widened to multicast destination 1536 advertisement methods in general. 1538 o Rewrote section 2.2 (Scope) for improved readability. 1540 o Moved use cases that are not addressed to draft-dijk-core- 1541 groupcomm-misc. 1543 o Various editorial updates for improved readability. 1545 Changes from ietf-02 to ietf-03: 1547 o Clarified that a group resource manipulation may return back a 1548 mixture of successful and unsuccessful responses (section 3.4 and 1549 Figure 6) (#251). 1551 o Clarified that security option for group communication must be 1552 NoSec mode (section 6) (#250). 1554 o Added mechanism for group membership configuration (#249). 1556 o Removed IANA request for multicast addresses (section 7) and 1557 replaced with a note indicating that the request is being made in 1558 [I-D.ietf-core-coap] (#248). 1560 o Made the definition of 'group' more specific to group of CoAP 1561 endpoints and included text on UDP port selection (#186). 1563 o Added explanatory text in section 3.4 regarding why not to use 1564 group communication for non-idempotent messages (i.e. CoAP POST) 1565 (#186). 1567 o Changed link-local RD discovery to site-local in RD discovery use 1568 case to make it more realistic. 1570 o Fixed lighting control use case CoAP proxying; now returns 1571 individual CoAP responses as in coap-12. 1573 o Replaced link format I-D with RFC6690 reference. 1575 o Various editorial updates for improved readability 1577 Changes from ietf-01 to ietf-02: 1579 o Rewrote congestion control section based on latest CoAP text 1580 including Leisure concept (#188) 1582 o Updated the CoAP/HTTP interworking section and example use case 1583 with more details and use of MLD for multicast group joining 1585 o Key use cases added (#185) 1587 o References to [I-D.vanderstok-core-dna] and draft-castellani-core- 1588 advanced-http-mapping added 1590 o Moved background sections on "MLD" and "CoAP-Observe" to 1591 Appendices 1593 o Removed requirements section (and moved it to draft-dijk-core- 1594 groupcomm-misc) 1596 o Added details for IANA request for group communication multicast 1597 addresses 1599 o Clarified text to distinguish between "link local" and general 1600 multicast cases 1602 o Moved lengthy background section 5 to draft-dijk-core-groupcomm- 1603 misc and replaced with a summary 1605 o Various editorial updates for improved readability 1607 o Change log added 1609 Changes from ietf-00 to ietf-01: 1611 o Moved CoAP-observe solution section to section 2 1613 o Editorial changes 1615 o Moved security requirements into requirements section 1617 o Changed multicast POST to PUT in example use case 1619 o Added CoAP responses in example use case 1621 Changes from rahman-07 to ietf-00: 1623 o Editorial changes 1625 o Use cases section added 1627 o CoRE Resource Directory section added 1629 o Removed section 3.3.5. IP Multicast Transmission Methods 1631 o Removed section 3.4 Overlay Multicast 1633 o Removed section 3.5 CoAP Application Layer Group Management 1635 o Clarified section 4.3.1.3 RPL Routers with Non-RPL Hosts case 1637 o References added and some normative/informative status changes 1639 Authors' Addresses 1641 Akbar Rahman (editor) 1642 InterDigital Communications, LLC 1644 Email: Akbar.Rahman@InterDigital.com 1646 Esko Dijk (editor) 1647 Philips Research 1649 Email: esko.dijk@philips.com