idnits 2.17.1 draft-ietf-core-groupcomm-06.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 (April 12, 2013) is 4025 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 1202, 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 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-14 == 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 (~~), 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: October 14, 2013 Philips Research 6 April 12, 2013 8 Group Communication for CoAP 9 draft-ietf-core-groupcomm-06 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 October 14, 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 Routing 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 . . . . . . . . . 13 75 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 13 76 4.2. Network Configuration . . . . . . . . . . . . . . . . . . 14 77 4.3. Discovery of Resource Directory . . . . . . . . . . . . . 16 78 4.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 17 79 4.5. Lighting Control in MLD Enabled Network . . . . . . . . . 20 80 4.6. Commissioning the Network Based On Resource Directory . . 21 81 5. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 22 82 5.1. Target Network Topologies . . . . . . . . . . . . . . . . 22 83 5.2. Advertising Membership of Multicast Groups . . . . . . . 22 84 5.2.1. Using the Multicast Listener Discovery (MLD) Protocol 23 85 5.2.2. Using the RPL Routing Protocol . . . . . . . . . . . 23 86 5.2.3. Using the MPL Forwarding Protocol . . . . . . . . . . 23 87 5.3. 6LoWPAN-Specific Guidelines . . . . . . . . . . . . . . . 24 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 89 6.1. Security Configuration . . . . . . . . . . . . . . . . . 24 90 6.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 6.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 25 92 6.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 25 93 6.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 25 94 6.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 26 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 99 9.2. Informative References . . . . . . . . . . . . . . . . . 27 100 Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 28 101 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 28 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 104 1. Conventions and Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in 109 [RFC2119]. 111 These key words are used to establish a set of best practices for 112 CoAP group communication. An implementation of CoAP group 113 communication MAY implement these guidelines; an implementation 114 claiming compliance to this document MUST implement the set. 116 This document assumes readers are familiar with the terms and 117 concepts that are used in [I-D.ietf-core-coap]. In addition, this 118 document defines the following terminology: 120 Group Communication 121 A source node sends a single message which is delivered to 122 multiple destination nodes, where all destinations are identified 123 to belong to a specific group. The source node itself may be part 124 of the group. The underlying mechanism for group communication is 125 assumed to be multicast based. The network involved may be a 126 constrained network such as a low-power, lossy network. 128 Multicast 129 Sending a message to multiple destination nodes with one network 130 invocation. There are various options to implement multicast 131 including layer 2 (Media Access Control) and layer 3 (IP) 132 mechanisms. 134 IP Multicast 135 A specific multicast solution based on the use of IP multicast 136 addresses as defined in "IANA Guidelines for IPv4 Multicast 137 Address Assignments" [RFC5771] and "IP Version 6 Addressing 138 Architecture" [RFC4291]. 140 Low power and Lossy Network (LLN) 141 A type of constrained IP network where devices are interconnected 142 by a variety of low-power and lossy links (such as IEEE 802.15.4, 143 Bluetooth LE, DECT, DECT ULE) or lossy links (such as IEEE P1901.2 144 power-line communication). 146 2. Introduction 148 2.1. Background 150 The Constrained Application Protocol (CoAP) is an application 151 protocol (analogous to HTTP) for resource constrained devices 152 operating in an IP network [I-D.ietf-core-coap]. Constrained devices 153 can be large in number, but are often highly correlated to each other 154 (e.g. by type or location). For example, all the light switches in 155 a building may belong to one group and all the thermostats may belong 156 to another group. Groups may be pre-configured before deployment or 157 dynamically formed during operation. If information needs to be sent 158 to or received from a group of devices, group communication 159 mechanisms can improve efficiency and latency of communication and 160 reduce bandwidth requirements for a given application. HTTP does not 161 support any equivalent functionality to CoAP group communication. 163 2.2. Scope 165 Group communication involves sending a CoAP Request as an IP 166 Multicast message and handling the potential multitude of (unicast) 167 CoAP Responses. The normative protocol aspects of running CoAP on 168 top of IP Multicast and processing the responses are given in 169 [I-D.ietf-core-coap]. The main contribution of this document lies in 170 providing additional guidance for key group communication features. 171 Among the topics covered are group definition, group resource 172 manipulation, and group configuration. Also, proxy operation and 173 minimizing congestion scenarios for group communication is discussed. 174 Finally, specific use case behavior and deployment guidelines are 175 outlined for CoAP group communication. 177 3. Protocol Considerations 179 3.1. IP Multicast Routing Background 181 IP Multicast routing protocols have been evolving for decades, 182 resulting in proposed standards such as Protocol Independent 183 Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various 184 technical and marketing reasons, IP Multicast routing is not widely 185 deployed on the general Internet. However, IP Multicast is very 186 popular in specific deployments such as in enterprise networks (e.g. 187 for video conferencing), smart home networks (e.g. UPnP) and carrier 188 IPTV deployments. The packet economy and minimal host complexity of 189 IP multicast make it attractive for group communication in 190 constrained environments. 192 To achieve IP multicast beyond a subnet, an IP multicast routing or 193 forwarding protocol needs to be active on IP routers. An examples of 194 a routing protocol specifically for LLNs is RPL (Section 12 of 195 [RFC6550]) and an example of a forwarding protocol for LLNs is MPL 196 [I-D.ietf-roll-trickle-mcast]. PIM-SM [RFC4601] is often used for 197 multicast routing in un-constrained networks. 199 IP multicast can also be run in a Link-Local (LL) scope. This means 200 that there is no routing involved and an IP multicast message is only 201 received over the link on which it was sent. 203 For a complete IP multicast solution, in addition to a routing/ 204 forwarding protocol, a so-called "listener" protocol is needed for 205 the devices to subscribe to groups (see Section 5.2). 207 3.2. Group Definition and Naming 209 A group is defined as a set of CoAP endpoints, where each endpoint is 210 configured to receive a multicast CoAP request that is sent to the 211 group's associated IP multicast address. An endpoint MAY be a member 212 of multiple groups. Group membership of an endpoint MAY dynamically 213 change over time. 215 For group communication, the Group URI will be the CoAP request URI. 216 A Group URI has the scheme 'coap' and includes in the authority part 217 either a group IP multicast address plus optional port number or a 218 hostname plus optional port number that can be resolved to the group 219 IP multicast address (e.g., a Group Name or Group FQDN). Group URIs 220 follow the CoAP URI syntax [I-D.ietf-core-coap]. It is recommended 221 for sending nodes to use the IP multicast address literal in the 222 authority for the Group URI as the default. 224 If a Group FQDN is used, it can be uniquely mapped to a site-local or 225 global multicast IP address via DNS resolution (if supported). Some 226 examples of hierarchical Group FQDN naming (and scoping) for a 227 building control application are shown below 228 ([I-D.vanderstok-core-dna]): 230 URI authority Targeted group 231 all.bldg6.example.com "all nodes in building 6" 232 all.west.bldg6.example.com "all nodes in west wing, building 6" 233 all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, 234 building 6" 235 all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, 236 west wing, building 6" 238 Similarly, if supported, reverse mapping (from IP multicast address 239 to Group FQDN) is possible using the reverse DNS resolution technique 240 ([I-D.vanderstok-core-dna]). 242 3.3. Port and URI Configuration 244 A CoAP group member listens for CoAP messages on the group's IP 245 multicast address, on a specified UDP port. Note that the default 246 UDP port is the CoAP default port 5683 but a non-default UDP port MAY 247 be specified for the group; in which case implementers MUST ensure 248 that all group members are configured to use this same port. 250 Multicast based group communication will not work if there diversity 251 in the authority port (i.e. a diversity of dynamic port addresses 252 across the group) or if the resources are located at different paths 253 on different endpoints. Therefore, some measures must be present to 254 ensure uniformity in port number and resource names/locations within 255 a group. All CoAP multicast requests MUST be sent using the port 256 number as follows: 258 1. A pre-configured port number, if available. The pre- 259 configuration mechanism MUST ensure that the same port number is 260 pre-configured across all endpoints in a group and across all 261 CoAP clients performing the group requests. 263 2. If the client is configured to use service discovery including 264 port discovery, it uses a port number obtained via a service 265 discovery lookup operation as a valid CoAP port for the targeted 266 CoAP multicast group. 268 3. Otherwise use the default CoAP UDP port. 270 All CoAP multicast requests SHOULD operate on URI paths ("links") as 271 follows: 273 1. Pre-configured URI paths, if available. The pre-configuration 274 mechanism MUST ensure that these URIs are pre-configured across 275 all CoAP servers in a group and all CoAP clients performing the 276 group requests. 278 2. If the client is configured to use default CoRE resource 279 discovery, it uses URI paths retrieved from a "/.well-known/core" 280 lookup on a group member. The URI paths the client will use MUST 281 be known to be available also in all other endpoints in the 282 group. The URI path configuration mechanism on servers MUST 283 ensure that these URIs (identified as being supported by the 284 group) are configured on all group endpoints. 286 3. If the client is configured to use another form of service 287 discovery, it uses URI paths from an equivalent service discovery 288 lookup which returns the resources supported by all group 289 members. 291 3.4. Group Methods 293 Group communication SHALL only be used for idempotent methods (i.e. 294 CoAP GET, PUT, and DELETE). The CoAP messages that are sent via 295 multicast SHALL be Non-Confirmable. 297 A unicast response per server MAY be sent back to answer the group 298 request (e.g. response "2.05 Content" to a group GET request) taking 299 into account the congestion control rules defined in Section 3.8. 300 The unicast responses received may be a mixture of success (e.g. 301 2.05 Content) and failure (e.g. 4.04 Not Found) codes depending on 302 the individual server processing result. 304 Group communication SHALL NOT be used for non-idempotent methods 305 (i.e. CoAP POST). This is because not all group members are 306 guaranteed to receive the multicast request, and the sender cannot 307 readily find out which group members did not receive it. 309 3.5. Group Member Discovery 311 CoAP defines a resource discovery capability [RFC6690], but does not 312 specify how to discover groups (e.g. find a group to join or send a 313 multicast message to) or how to discover members of a group (e.g. to 314 address selected group members by unicast). A simple ad-hoc method 315 to discover members of a CoAP group would be to send a multicast 316 "CoAP ping" [I-D.ietf-core-coap]. The collected responses to the 317 ping would then give an indication of the group members. 319 3.6. Configuring Group Membership In Endpoints 321 The group membership of a CoAP server may be determined in one or 322 more of the following ways. First, the group membership may be pre- 323 configured before node deployment. Second, it may be configured 324 during operation by another node e.g. a commissioning device. 325 Third, a node may be programmed to discover (query) its group 326 membership during operation using a specific service discovery means. 328 In the first case, the pre-configured group may be a multicast IP 329 address or a hostname which is during operation resolved to a 330 multicast IP address by the endpoint using DNS. 332 In the second case, typical in e.g. building control, a 333 commissioning tool determines to which groups a sensor or actuator 334 node belongs, and writes this information to the node, which can 335 subsequently join the correct IP multicast group on its network 336 interface. The information written may again be a multicast IP 337 address or a hostname. 339 For the third case, specific methods to use for a CoAP server to look 340 up its group membership(s) may be DNS-SD and Resource Directory 341 [I-D.shelby-core-resource-directory]. The latter is detailed more in 342 section Section 4.6. 344 To achieve better interoperability between nodes/endpoints from 345 different manufacturers, an OPTIONAL default RESTful interface for 346 configuring CoAP endpoints with relevant group information is 347 specified here. This interface thus provides a solution for the 348 second case mentioned above. To access this interface a client MUST 349 use unicast methods (GET/PUT/POST) only as it is a method of 350 configuring group information in individual endpoints. Using 351 multicast operations in this situation may lead to unexpected 352 (possibly circular) behavior in the network. 354 CoAP endpoints implementing this optional mechanism MUST support at 355 least one discoverable "Group Configuration" resource of resource 356 type (rt) [RFC6690] "core.gp" where "gp" is shorthand for "group". 357 This resource is used by an authorized endpoint to manage group 358 membership of the CoAP endpoint. 360 The resource of type "core.gp" has a JSON content format. A 361 (unicast) GET on this resource returns a JSON array of group objects, 362 each group object formatted as shown below: 364 Req: GET /gp 365 Res: 2.05 Content (Content-Format: application/json) 366 [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", 367 "ip": "ff15::4200:f7fe:ed37:14ca" } 368 ] 370 where the OPTIONAL "n" key/value pair defines the Group name as FQDN 371 and the OPTIONAL "ip" key/value pair defines the associated multicast 372 IP address. A CoAP endpoint can be added to another group by a 373 (unicast) POST on the resource with a single JSON group object, which 374 updates the existing resource by adding the group object to the 375 existing ones: 377 Req: POST /gp (Content-Format: application/json) 378 { "n": "floor1.west.bldg6.example.com", 379 "ip": "ff15::4200:f7fe:ed37:14cb" } 380 Res: 2.04 Changed 382 A (unicast) PUT with as payload an array of JSON group objects will 383 replace all current group memberships with the new ones as defined in 384 the payload. After a change effected on the "core.gp" type resource, 385 the endpoint MUST effect registration/deregistration from 386 corresponding IP multicast groups as soon as possible. 388 Any (unicast) operation (i.e. PUT/POST) to change a CoAP endpoint 389 group membership configuration MUST use DTLS-secured CoAP 390 [I-D.ietf-core-coap]. Thus only authorized clients will be allowed 391 by a server to configure the server's (endpoint) group membership. 393 3.7. Multicast Request Acceptance and Response Suppression 395 CoAP [I-D.ietf-core-coap] and CoRE Link Format [RFC6690] define 396 normative behaviors for: 398 1. Multicast request acceptance - in which cases a request is 399 accepted and executed, and when not. 401 2. Multicast response suppression - in which cases the response of 402 an executed request is returned to the requesting endpoint, and 403 when not. 405 This section first summarizes these normative behaviors and then 406 presents additional guidelines for response suppression. Also a 407 number of multicast example applications are given to illustrate the 408 overall approach. 410 To apply any rules for request and/or response suppression, the IP 411 stack interface of a CoAP server must be able to indicate for an 412 incoming request that the destination address of the request was 413 multicast. 415 For multicast request acceptance, the behaviors are: 417 o A server SHOULD NOT accept a multicast request that cannot be 418 "authenticated" in some way (cryptographically or by some 419 multicast boundary limiting the potential sources) 420 [I-D.ietf-core-coap]. See Section 6.3 for examples of multicast 421 boundary limiting methods. 423 o A server SHOULD NOT accept a multicast discovery request with a 424 query string (as defined in CoRE Link Format [RFC6690]) if 425 filtering ([RFC6690]) is not supported by the server. 427 o A server SHOULD NOT accept a multicast request that acts on a 428 specific resource for which multicast support is not required. 429 (Note that for discovery resource "/.well-known/core" multicast 430 support is always required. Implementers are advised to disable 431 multicast support by default on any other resource, until 432 explicitly enabled by an application.) 434 o Otherwise accept the multicast request. 436 For multicast response suppression, the behaviors are: 438 o A server SHOULD NOT respond to a multicast discovery request if 439 the filter specified by the request's query string does not match. 441 o A server MAY choose not to respond to a multicast request, if 442 there's nothing useful to respond (e.g. error or empty response). 444 o If the IP stack interface cannot indicate that an incoming message 445 was multicast, then the server SHOULD NOT respond for incoming 446 messages for selected resources which are known (through 447 application knowledge) to be used for multicast requests. 449 o Otherwise respond to the multicast request. 451 The above response suppression behaviors are complemented by the 452 following guidelines. CoAP servers should implement configurable 453 response suppression, enabling at least the following per resource: 455 o Suppression of all 2.xx success responses; 457 o Suppression of all 4.xx client errors; 459 o Suppression of all 5.xx server errors; 461 o Suppression of all 2.05 responses with empty payload. 463 A number of group communication example applications are described 464 below illustrating how to make use of response suppression: 466 o CoAP resource discovery: Suppress 2.05 responses with empty 467 payload and all 4.xx and 5.xx errors. 469 o Lighting control: Suppress all 2.xx responses after a lighting 470 change command. 472 o Update group configuration data using multicast PUT: No 473 suppression at all. Use collected responses to identify which 474 group members did not receive the new configuration; then attempt 475 using CoAP CON unicast to update those group members. 477 o Multicast firmware update by sending blocks of data: Suppress all 478 2.xx and 5.xx responses. After having sent all multicast blocks, 479 the client checks each endpoint by unicast to identify which 480 blocks are still missing in each endpoint. 482 o Conditional reporting for a group (e.g. sensors) based on a URI 483 query: Suppress all 2.05 responses with empty payload (i.e. if a 484 query produces no matching results). 486 3.8. Congestion Control 488 Multicast CoAP requests may result in a multitude of replies from 489 different nodes, potentially causing congestion. Therefore both the 490 sending of multicast requests and sending unicast CoAP responses to 491 multicast requests should be conservatively controlled. 493 CoAP [I-D.ietf-core-coap] reduces multicast-specific congestion risks 494 through the following measures: 496 o A server MAY choose not to respond to a multicast request if 497 there's nothing useful to respond (e.g. error or empty response). 498 See Section 3.7 for more detailed guidelines on response 499 suppression. 501 o A server SHOULD limit the support for multicast requests to 502 specific resources where multicast operation is required. 504 o A multicast request MUST be Non-Confirmable. 506 o A response to a multicast request SHOULD be Non-Confirmable 507 (Section 5.2.3). 509 o A server does not respond immediately to a multicast request, but 510 SHOULD first wait for a time that is randomly picked within a 511 predetermined time interval called the Leisure. 513 o A server SHOULD NOT accept multicast requests that can not be 514 authenticated in some way. See Section 3.7 for more details on 515 request suppression and multicast source authentication. 517 Additional guidelines to reduce congestion risks are: 519 o A server in an LLN should only support multicast GET for resources 520 that are small, e.g. the payload of the response fits into a 521 single link-layer frame. 523 o A server can minimize the payload length in response to a 524 multicast GET on "/.well-known/core" by using hierarchy in 525 arranging link descriptions for the response. An example of this 526 is given in Section 5 of [RFC6690]. 528 o Alternatively a server can also minimize the payload length of a 529 response to a multicast GET (e.g. on "/.well-known/core") using 530 CoAP blockwise transfers [I-D.ietf-core-block], returning only a 531 first block of the link format description. 533 o A client should always aim to use IP multicast with link-local 534 scope if possible. If this is not possible, then site-local scope 535 IP multicast should be considered. If this is not possible, then 536 global scope IP multicast should be considered as a last resort 537 only. 539 3.9. Proxy Operation 541 CoAP [I-D.ietf-core-coap] allows a client to request a forward-proxy 542 to process its CoAP request. For this purpose the client either 543 specifies the request URI as a string in the Proxy-URI option, or it 544 specifies the Proxy-Scheme option with the URI constructed from the 545 usual Uri-* options. This approach works well for unicast requests. 546 However, there are certain issues and limitations of processing the 547 (unicast) responses to a group communication request made in this 548 manner through a proxy. Specifically, if a proxy would apply 549 aggregation of responses in such a case: 551 o Aggregation of (unicast) responses to a group communication 552 request in a proxy is difficult. This is because the proxy does 553 not know how many members there are in the group or how many group 554 members will actually respond. 556 o There is no default format defined in CoAP for aggregation of 557 multiple responses into a single response. 559 But if a proxy would follow the specification for a CoAP Proxy 560 [I-D.ietf-core-coap], the proxy would simply forward all the 561 individual (unicast) responses to a group communication request to 562 the client (i.e. no aggregation), there are also issues: 564 o The client may be confused as it may not have known that the 565 Proxy-URI contained a multicast target. That is, the client may 566 be expecting only one (unicast) response but instead receives 567 multiple (unicast) responses potentially leading to fault 568 conditions in the application or CoAP stack. 570 o Each individual CoAP response will appear to originate (IP Source 571 address) from the CoAP Proxy, and not from the server that 572 produced the response. This makes it impossible for the client to 573 identify the server that produced each response. 575 Due to above issues, a guideline is defined here that a CoAP Proxy 576 SHOULD NOT support processing a multicast CoAP request but rather 577 return a 501 (Not Implemented) response in such case. The exception 578 case here (i.e. to process it) is allowed under following 579 conditions: 581 o The CoAP Proxy MUST be explicitly configured (whitelist) to allow 582 proxied multicast requests by specific client(s). 584 o The proxy SHOULD return individual (unicast) CoAP responses to the 585 client, i.e. not aggregated. (This condition MAY be removed once 586 an aggregation format is standardized.) 588 o It MUST be known to the person/entity doing the configuration of 589 the proxy, or verified in some way, that the client configured in 590 the whitelist supports receiving multiple responses to a proxied 591 unicast CoAP request. 593 3.10. Exceptions 595 Group communication using IP multicast offers improved network 596 efficiency and latency amongst other benefits. However, group 597 communication may not always be possible to implement in a given 598 network. The primary reason for this will be if IP multicast is not 599 supported in the network. For example, in a LLN, if the RPL protocol 600 is used for routing multicast packets and RPL routers operate in 601 "Non-storing mode" [RFC6550] there will be no IP multicast routing in 602 that network beyond link-local scope. This means that any CoAP group 603 communication above link-local scope will not be supported in that 604 network. 606 4. Use Cases and Corresponding Protocol Flows 608 4.1. Introduction 610 The use of CoAP group communication is shown in the context of the 611 following two use cases and corresponding protocol flows: 613 o Discovery of Resource Directory (RD, 614 [I-D.shelby-core-resource-directory]): discovering the local CoAP 615 RD which contains links (URIs) to resources stored on other CoAP 616 servers [RFC6690]. 618 o Lighting Control: synchronous operation of a group of 619 IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights). 621 4.2. Network Configuration 623 To illustrate the use cases we define two network configurations. 624 Both are based on the topology as shown in Figure 1. The two 625 configurations using this topology are: 627 1. Subnets are 6LoWPAN networks; the routers Rtr-1 and Rtr-2 are 628 6LoWPAN Border Routers (6LBRs, [RFC6775]). 630 2. Subnets are Ethernet links; the routers Rtr-1 and Rtr-2 are 631 multicast-capable Ethernet routers. 633 Both configurations are further specified by the following: 635 o A large room (Room-A) with three lights (Light-1, Light-2, 636 Light-3) controlled by a Light Switch. The devices are organized 637 into two subnets. In reality, there could be more lights (up to 638 several hundreds) but these are not shown for clarity. 640 o Light-1 and the Light Switch are connected to a router (Rtr-1). 642 o Light-2 and the Light-3 are connected to another router (Rtr-2). 644 o The routers are connected to an IPv6 network backbone which is 645 also multicast enabled. In the general case, this means the 646 network backbone and Rtr-1/Rtr-2 support a PIM based multicast 647 routing protocol, and MLD for forming groups. In a limited case, 648 if the network backbone is one link, then the routers only have to 649 support MLD-snooping (Appendix A) for the following use cases to 650 work. 652 o A CoAP RD is connected to the network backbone. 654 o The DNS server is optional. If the server is there (connected to 655 the network backbone) then certain DNS based features are 656 available (e.g. DNS resolution of URI to IP multicast address). 657 If the DNS server is not there, then different manual provisioning 658 of the network is required (e.g. IP multicast addresses are hard- 659 coded into devices). 661 o A Controller (client) is connected to the backbone, which is able 662 to control various building functions including lighting. 664 Network 665 Backbone 666 ################################################ | 667 # ********************** Room-A # | 668 # ** Subnet-1 ** # | 669 # * ** # | 670 # * +----------+ * # | 671 # * | Light |-------+ * # | 672 # * | Switch | | * # | 673 # * +----------+ +---------+ * # | 674 # * | Rtr-1 |-----------------------------+ 675 # * +---------+ * # | 676 # * +----------+ | * # | 677 # * | Light-1 |--------+ * # | 678 # * +----------+ * # | 679 # * * # | 680 # ** ** # | 681 # ********************** # | 682 # # | 683 # ********************** # | 684 # ** Subnet-2 ** # | 685 # * ** # | 686 # * +----------+ * # | 687 # * | Light-2 |-------+ * # | 688 # * | | | * # | 689 # * +----------+ +---------+ * # | 690 # * | Rtr-2 |-----------------------------+ 691 # * +---------+ * # | 692 # * +----------+ | * # | 693 # * | Light-3 |--------+ * # | 694 # * +----------+ * # +------------+ | 695 # * * # | Controller |--+ 696 # ** ** # | Client | | 697 # ********************** # +------------+ | 698 ################################################ | 699 | 700 +------------+ | 701 | CoAP | | 702 | Resource |-----------------+ 703 | Directory | | 704 +------------+ | 705 +------------+ | 706 | DNS Server | | 707 | (Optional) |-----------------+ 708 +------------+ 710 Figure 1: Network Topology of a Large Room (Room-A) 712 4.3. Discovery of Resource Directory 714 The protocol flow for discovery of the CoAP RD for the given network 715 (of Figure 1) is shown in Figure 2: 717 o The fixture for Light-2 is installed and powered on for the first 718 time. 720 o Light-2 will then search for the local CoAP RD by sending out a 721 GET request (with the "/.well-known/core?rt=core.rd" request URI) 722 to the site-local "All CoAP Nodes" multicast address. 724 o This multicast message will then go to each node in subnet-2. 725 Rtr-2 will then forward into to the Network Backbone where it will 726 be received by the CoAP RD. All other nodes in subnet-2 will 727 ignore the multicast GET because it is qualified by the query 728 string "?rt=core.rd" (which indicates it should only be processed 729 by the endpoint if it is a RD). 731 o The CoAP RD will then send back a unicast response containing the 732 requested content. 734 o Note that the flow is shown only for Light-2 for clarity. Similar 735 flows will happen for Light-1, Light-3 and the Light Switch when 736 they are first powered on. 738 The CoAP RD may also be discovered by other means such as by assuming 739 a default location (e.g. on a 6LBR), using DHCP, anycast address, 740 etc. However, these approaches do not invoke CoAP group 741 communication so are not further discussed here. 743 For other discovery use cases such as discovering local CoAP servers, 744 services or resources group communication can be used in a similar 745 fashion as in the above use case. Both Link-Local (LL) and site- 746 local discovery are possible this way. 748 Light CoAP 749 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD 750 | | | | | | | 751 | | | | | | | 752 ********************************** | | | 753 * Light-2 is installed * | | | 754 * and powers on for first time * | | | 755 ********************************** | | | 756 | | | | | | | 757 | | | | | | | 758 | | COAP NON Mcast(GET | | 759 | | /.well-known/core?rt=core.rd) | | 760 | |--------->-------------------------------->| | 761 | | | | | |--------->| 762 | | | | | | | 763 | | | | | | | 764 | | COAP NON (2.05 Content | | 765 | | ;rt="core.rd";ins="Primary") |<---------| 766 | |<------------------------------------------| | 767 | | | | | | | 769 Figure 2: Resource Directory Discovery via Multicast Message 771 4.4. Lighting Control 773 The protocol flow for a building automation lighting control scenario 774 for the network (Figure 1) in 6LoWPAN configuration is shown in 775 sequence in Figure 3 for the case that the CoAP servers in each Light 776 are configured to not generate a CoAP response to lighting control 777 CoAP multicast requests. (See section Section 3.7 for more details 778 on response suppression by a server.) 780 In addition, Figure 4 shows a protocol flow example for the case that 781 servers do respond to a lighting control multicast request with 782 (unicast) CoAP NON responses. There are two success responses and 783 one 5.00 error response. In this particular use case the Light 784 Switch does not check, based on the responses, that all Lights in the 785 group actually received the multicast request, because it is not 786 configured with an exhaustive list of IP addresses of all Lights 787 belonging to the group. However, based on received error responses 788 it could take additional action such as logging a fault or alerting 789 the user via its LCD display. 791 Reliability of CoAP multicast is not guaranteed. Therefore, one or 792 more lights in the group may not have received the CoAP control 793 request due to packet loss. In this use case there is no detection 794 nor correction of such situations: the application layer expects that 795 the multicast forwarding/routing will be of sufficient quality to 796 provide on average a very high probability of packet delivery to all 797 CoAP endpoints in a multicast group. An example protocol to 798 accomplish this is the MPL forwarding protocol for LLNs 799 [I-D.ietf-roll-trickle-mcast]. 801 We assume the following steps have already occurred before the 802 illustrated flows: 804 1. Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to 805 all devices. The CoAP network is formed. 807 2. Network configuration (application-independent): 6LBRs are 808 configured with multicast address blocks to filter out or to pass 809 through to/from the 6LoWPAN. 811 3. Commissioning phase (application-related): The IP multicast 812 address of the group (Room-A-Lights) has been configured in all 813 the Lights and in the Light Switch. 815 4. As an alternative to the previous step, when a DNS server is 816 available, the Light Switch and/or the Lights have been 817 configured with a group hostname which each nodes resolves to the 818 above IP multicast address of the group. 820 Note for the Commissioning phase: the switch's software supports 821 sending unicast, multicast or proxied unicast/multicast CoAP 822 requests, including processing of the multiple responses that may be 823 generated by a multicast CoAP request. 825 Light Network 826 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 827 | | | | | | | 828 | | | | | | | 829 | | *********************** | | 830 | | * User flips on * | | 831 | | * light switch to * | | 832 | | * turn on all the * | | 833 | | * lights in Room A * | | 834 | | *********************** | | 835 | | | | | | | 836 | | | | | | | 837 | | | COAP NON Mcast(PUT, | | 838 | | | Payload=lights ON) | | 839 |<-------------------------------+--------->| | | 840 ON | | | |-------------------->| 841 | | | | | |<---------| 842 | |<---------|<-------------------------------| | 843 | ON ON | | | | 844 ^ ^ ^ | | | | 845 *********************** | | | | 846 * Lights in Room-A * | | | | 847 * turn on (nearly * | | | | 848 * simultaneously) * | | | | 849 *********************** | | | | 850 | | | | | | | 851 Figure 3: Light Switch Sends Multicast Control Message 853 Light Network 854 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 855 | | | | | | | 856 | COAP NON (2.04 Changed) | | | | 857 |------------------------------->| | | | 858 | | | | | | | 859 | | | | | | | 860 | COAP NON (2.04 Changed) | | | 861 | |------------------------------------------>| | 862 | | | | | |--------->| 863 | | | | |<--------------------| 864 | | | |<---------| | | 865 | | | | | | | 866 | | COAP NON (5.00 Internal Server Error) | 867 | | |------------------------------->| | 868 | | | | | |--------->| 869 | | | | |<--------------------| 870 | | | |<---------| | | 871 | | | | | | | 873 Figure 4: Lights (Optionally) Respond to Multicast CoAP Request 875 Another, but similar, lighting control use case is shown in Figure 5. 876 In this case a controller connected to the Network Backbone sends a 877 CoAP multicast request to turn on all lights in Room-A. Every Light 878 sends back a CoAP response to the Controller after being turned on. 880 Network 881 Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller 882 | | | | | | | 883 | | | | | COAP NON Mcast(PUT, 884 | | | | | Payload=lights ON) 885 | | | | | |<-------| 886 | | | |<----------<---------| | 887 |<--------------------------------| | | | 888 ON | | | | | | 889 | |<----------<---------------------| | | 890 | ON ON | | | | 891 ^ ^ ^ | | | | 892 *********************** | | | | 893 * Lights in Room-A * | | | | 894 * turn on (nearly * | | | | 895 * simultaneously) * | | | | 896 *********************** | | | | 897 | | | | | | | 898 | | | | | | | 899 | COAP NON (2.04 Changed) | | | | 900 |-------------------------------->| | | | 901 | | | |-------------------->| | 902 | | COAP NON (2.04 Changed) | |------->| 903 | |-------------------------------->| | | 904 | | | | |--------->| | 905 | | | COAP NON (2.04 Changed) |------->| 906 | | |--------------------->| | | 907 | | | | |--------->| | 908 | | | | | |------->| 909 | | | | | | | 911 Figure 5: Controller On Backbone Sends Multicast Control Message 913 4.5. Lighting Control in MLD Enabled Network 915 The use case of previous section can also apply in networks where 916 nodes support the MLD protocol [RFC3810]. The Lights then take on 917 the role of MLDv2 listener and the routers (Rtr-1, Rtr-2) are MLDv2 918 Routers. In the Ethernet based network configuration, MLD may be 919 available on all involved network interfaces. Use of MLD in the 920 6LoWPAN based configuration is also possible, but requires MLD 921 support in all nodes in the 6LoWPAN which is usually not implemented 922 in many deployments. 924 The resulting protocol flow is shown in Figure 6. This flow is 925 executed after the commissioning phase, as soon as Lights are 926 configured with a group address to listen to. The (unicast) MLD 927 Reports may require periodic refresh activity as specified by the MLD 928 protocol. In the figure, LL denotes Link Local communication. 930 After the shown sequence of MLD Report messages has been executed, 931 both Rtr-1 and Rtr-2 are automatically configured to forward 932 multicast traffic destined to Room-A-Lights onto their connected 933 subnet. Hence, no manual Network Configuration of routers, as 934 previously indicated in Section 4.4, is needed anymore. 936 Light Network 937 Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone 938 | | | | | | | 939 | | | | | | | 940 | | | | | | | 941 | MLD Report: Join | | | | | 942 | Group (Room-A-Lights) | | | | 943 |---LL------------------------------------->| | | 944 | | | | |MLD Report: Join | 945 | | | | |Group (Room-A-Lights)| 946 | | | | |---LL---->----LL---->| 947 | | | | | | | 948 | | MLD Report: Join | | | | 949 | | Group (Room-A-Lights) | | | 950 | |---LL------------------------------------->| | 951 | | | | | | | 952 | | | MLD Report: Join | | | 953 | | | Group (Room-A-Lights) | | 954 | | |---LL-------------------------->| | 955 | | | | | | | 956 | | | | |MLD Report: Join | 957 | | | | |Group (Room-A-Lights)| 958 | | | | |<--LL-----+---LL---->| 959 | | | | | | | 960 | | | | | | | 962 Figure 6: Joining Lighting Groups Using MLD 964 4.6. Commissioning the Network Based On Resource Directory 966 This section outlines how devices in the lighting use case (both 967 Switches and Lights) can be commissioned, making use of Resource 968 Directory [I-D.shelby-core-resource-directory] and its group 969 configuration feature. 971 Once the Resource Directory (RD) is discovered, the Switches and 972 Lights need to be discovered and their groups need to be defined. 973 For the commissioning of these devices, a commissioning tool can be 974 used that defines the entries in the RD. The commissioning tool has 975 the authority to change the contents of the RD and the nodes. DTLS 976 based security is used by the commissioning tool to modify 977 operational data in RD, Switches and Lights. 979 In our particular use case, a group of three lights is defined with 980 one multicast address and hostname 981 Room-A-Lights.floor1.west.bldg6.example.com. The commissioning 982 device has a list of the three lights and the associated multicast 983 address. For each light in the list the tool learns the IP address 984 of the light and instructs the RD with 3 POST commands to store the 985 end-points associated with the three lights as prescribed by RD. 986 Finally the commissioning device defines the group in the RD to 987 contain these three end-points. Also the commissioning tool writes 988 the MC address in the Lights with e.g. the POST /gp command 989 discussed in Section 3.6. 991 The light switch can discover the group in RD and learn the MC 992 address of the group. The light switch will use this address to send 993 MC commands to the members of the group. When the message arrives 994 the Lights should recognize the MC address and accept the message. 996 5. Deployment Guidelines 998 This section provides guidelines how an IP Multicast based solution 999 for CoAP group communication can be deployed in various network 1000 configurations. 1002 5.1. Target Network Topologies 1004 CoAP group communication can be deployed in various network 1005 topologies. First, the target network may be a regular IP network, 1006 or a LLN such as a 6LoWPAN network, or consist of mixed constrained/ 1007 unconstrained network segments. Second, it may be a single subnet 1008 only or multi-subnet; e.g. multiple 6LoWPAN networks joined by a 1009 single backbone LAN. Third, a wireless network segment may have all 1010 nodes reachable in a single IP hop, or it may require multiple IP 1011 hops for some pairs of nodes to reach each other. 1013 Each topology may pose different requirements on the configuration of 1014 routers and protocol(s), in order to enable efficient CoAP group 1015 communication. 1017 5.2. Advertising Membership of Multicast Groups 1019 If a multicast routing/forwarding protocol is used in a network, 1020 server nodes that intend to receive CoAP multicast requests generally 1021 require a method to advertise the specific IP multicast address(es) 1022 they want to receive, i.e. a method to join specific IP multicast 1023 groups. This section identifies the ways in which this can be 1024 accomplished. 1026 5.2.1. Using the Multicast Listener Discovery (MLD) Protocol 1028 CoAP nodes that are IP hosts (i.e. not IP routers) are generally 1029 unaware of the specific multicast routing/forwarding protocol being 1030 used. When such a host needs to join a specific (CoAP) multicast 1031 group, it usually requires a way to signal to multicast routers which 1032 multicast traffic it wants to receive. For efficient multicast 1033 routing (i.e. avoid always flooding multicast IP packets), routers 1034 must know which hosts need to receive packets addressed to specific 1035 IP multicast destinations. 1037 The Multicast Listener Discovery (MLD) protocol ([RFC3810], 1038 Appendix A) is the standard IPv6 method to achieve this. [RFC6636] 1039 discusses tuning of MLD for mobile and wireless networks. These 1040 guidelines may be useful when implementing MLD in LLNs. 1042 Alternatively, to avoid the use of MLD in LLN deployments, either all 1043 nodes can be configured as multicast routers in an LLN, or a 1044 multicast forwarding/flooding protocol can be used that forwards any 1045 IP multicast packet to all forwarders (routers) in the subnet (LLN). 1047 5.2.2. Using the RPL Routing Protocol 1049 The RPL routing protocol [RFC6550] defines in Section 12 the 1050 advertisement of IP multicast destinations using DAO messages. This 1051 mechanism can be used by CoAP nodes (which are also RPL routers) to 1052 advertise IP multicast group membership to other RPL routers. Then, 1053 the RPL protocol can route multicast CoAP requests over multiple hops 1054 to the correct CoAP servers. 1056 This mechanism can be used as a means to convey IP multicast group 1057 membership information to an edge router (e.g. 6LBR), in case the 1058 edge router is also the root of the RPL DODAG. This could be useful 1059 in LLN segments where MLD is not available and the edge router needs 1060 to know what IP multicast traffic to pass through from the backbone 1061 network into the LLN subnet. 1063 5.2.3. Using the MPL Forwarding Protocol 1065 The MPL forwarding protocol [I-D.ietf-roll-trickle-mcast] can be used 1066 in a predefined network domain for propagation of IP multicast 1067 packets to all MPL routers, over multiple hops. MPL is designed to 1068 work in LLN deployments. Due to its property of propagating all 1069 (non-link-local) IP multicast packets to all MPL routers, there is in 1070 principle no need for CoAP server nodes to advertise IP multicast 1071 group membership assuming that any IP multicast source is also part 1072 of the MPL domain. 1074 5.3. 6LoWPAN-Specific Guidelines 1076 To support multi-LoWPAN scenarios for CoAP group communication, it is 1077 RECOMMENDED that a 6LoWPAN Border Router (6LBR) will act in an MLD 1078 Router role on the backbone link. If this is not possible then the 1079 6LBR SHOULD be configured to act as an MLD Multicast Address Listener 1080 and/or MLD Snooper (Appendix A) on the backbone link. 1082 To avoid that backbone IP multicast traffic needlessly congests 1083 6LoWPAN network segments, it is RECOMMENDED that a filtering means is 1084 implemented to block IP multicast traffic from 6LoWPAN segments where 1085 none of the 6LoWPAN nodes listen to this traffic. Possible means 1086 are: 1088 o Filtering in 6LBRs based on information from the routing protocol. 1089 This allows a 6LBR to only forward multicast traffic onto the 1090 LoWPAN, for which it is known that there exists at least one 1091 listener on the LoWPAN. 1093 o Filtering in 6LBRs based on MLD reports. Similar as previous but 1094 based directly on MLD reports from 6LoWPAN nodes. This only works 1095 in a single-IP-hop 6LoWPAN network, such as a mesh-under routing 1096 network or a star topology network, because MLD relies on link- 1097 local communication. 1099 o Filtering in 6LBRs based on settings. Filtering tables with 1100 blacklists/whitelists can be configured in the 6LBR by system 1101 administration for all 6LBRs or configured on a per-6LBR basis. 1103 o Filtering in router(s) or firewalls that provide access to 1104 constrained network segments. For example, in an access router/ 1105 bridge that connects a regular intranet LAN to a building control 1106 IPv6 backbone. This backbone connects multiple 6LoWPAN segments, 1107 each segment connected via a 6LBR. 1109 6. Security Considerations 1111 This section describes the relevant security configuration for CoAP 1112 group communication using IP multicast. The threats to CoAP group 1113 communication are also identified and various approaches to mitigate 1114 these threats are summarized. 1116 6.1. Security Configuration 1118 As defined in [I-D.ietf-core-coap], CoAP group communication based on 1119 IP multicast must use the following security modes: 1121 o Group communication MUST operate in CoAP NoSec (No Security) mode. 1123 o Group communication MUST NOT use "coaps" scheme. That is, all 1124 group communication MUST use only "coap" scheme. 1126 6.2. Threats 1128 Essentially the above configuration means that there is no security 1129 at the CoAP layer for group communication. This is due to the fact 1130 that the current DTLS based approach for CoAP is exclusively unicast 1131 oriented and does not support group security features such as group 1132 key exchange and group authentication. As a direct consequence of 1133 this, CoAP group communication is vulnerable to all attacks mentioned 1134 in [I-D.ietf-core-coap] for IP multicast. 1136 6.3. Threat Mitigation 1138 [I-D.ietf-core-coap] identifies various threat mitigation techniques 1139 for CoAP IP multicast. In addition to those guidelines, it is 1140 recommended that for sensitive data or safety-critical control, a 1141 combination of appropriate link-layer security and administrative 1142 control of IP multicast boundaries should be used. Some examples are 1143 given below. 1145 6.3.1. WiFi Scenario 1147 In a home automation scenario (using WiFi), the WiFi encryption 1148 should be enabled to prevent rogue nodes from joining. Also, if MAC 1149 address filtering at the WiFi Access Point is supported that should 1150 also be enabled. The IP router should have the fire wall enabled to 1151 isolate the home network from the rest of the Internet. In addition, 1152 the domain of the IP multicast should be set to be either link-local 1153 scope or site-local scope. Finally, if possible, devices should be 1154 configured to accept only Source Specific Multicast (SSM) packets 1155 (see [RFC4607]) from within the trusted home network. For example, 1156 all lights in a particular room should only accept IP multicast 1157 traffic originating from the master light switch in that room. In 1158 this case, the Spoofed Source Address considerations of Section 7.4 1159 of [RFC4607] should be heeded. 1161 6.3.2. 6LoWPAN Scenario 1163 In a building automation scenario, a particular room may have a 1164 single 6LoWPAN topology with a single Edge Router (6LBR). Nodes on 1165 the subnet can use link-layer encryption to prevent rogue nodes from 1166 joining. The 6LBR can be configured so that it blocks any incoming 1167 IP multicast traffic. Another example topology could be a multi- 1168 subnet 6LoWPAN in a large conference room. In this case, the 1169 backbone can implement port authentication (IEEE 802.1X) to ensure 1170 only authorized devices can join the Ethernet backbone. The access 1171 router to this secured segment can also be configured to block 1172 incoming IP multicast traffic. 1174 6.3.3. Future Evolution 1176 In the future, to further mitigate the threats, the developing 1177 approach for DTLS-based IP multicast security for CoAP networks (see 1178 [I-D.keoh-tls-multicast-security]) or similar approaches should be 1179 considered once they mature. 1181 7. IANA Considerations 1183 tbd: allocation of "core.gp" resource type in relevant registry. 1185 (Note to RFC Editor: The required multicast address request to IANA 1186 is made in [I-D.ietf-core-coap]). 1188 8. Acknowledgements 1190 Thanks to Peter Bigot, Carsten Bormann, Anders Brandt, Angelo 1191 Castellani, Guang Lu, Salvatore Loreto, Kerry Lynn, Dale Seed, Zach 1192 Shelby, Peter van der Stok, and Juan Carlos Zuniga for their helpful 1193 comments and discussions that have helped shape this document. 1195 9. References 1197 9.1. Normative References 1199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1200 Requirement Levels", BCP 14, RFC 2119, March 1997. 1202 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1203 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1204 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1206 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1207 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1209 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1210 Architecture", RFC 4291, February 2006. 1212 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1213 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1214 Protocol Specification (Revised)", RFC 4601, August 2006. 1216 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1217 IP", RFC 4607, August 2006. 1219 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1220 "Transmission of IPv6 Packets over IEEE 802.15.4 1221 Networks", RFC 4944, September 2007. 1223 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1224 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1225 March 2010. 1227 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1228 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1229 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1230 Lossy Networks", RFC 6550, March 2012. 1232 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1233 the Internet Group Management Protocol (IGMP) and 1234 Multicast Listener Discovery (MLD) for Routers in Mobile 1235 and Wireless Networks", RFC 6636, May 2012. 1237 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1238 Format", RFC 6690, August 2012. 1240 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1241 "Neighbor Discovery Optimization for IPv6 over Low-Power 1242 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1243 November 2012. 1245 [I-D.ietf-core-coap] 1246 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1247 Application Protocol (CoAP)", draft-ietf-core-coap-14 1248 (work in progress), March 2013. 1250 9.2. Informative References 1252 [I-D.ietf-core-block] 1253 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1254 draft-ietf-core-block-11 (work in progress), March 2013. 1256 [I-D.vanderstok-core-dna] 1257 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 1258 Naming, and Addressing", draft-vanderstok-core-dna-02 1259 (work in progress), July 2012. 1261 [I-D.ietf-roll-trickle-mcast] 1262 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1263 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 1264 mcast-04 (work in progress), February 2013. 1266 [I-D.keoh-tls-multicast-security] 1267 Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast 1268 Security for Low-Power and Lossy Networks (LLNs)", draft- 1269 keoh-tls-multicast-security-00 (work in progress), October 1270 2012. 1272 [I-D.shelby-core-resource-directory] 1273 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 1274 Directory", draft-shelby-core-resource-directory-05 (work 1275 in progress), February 2013. 1277 Appendix A. Multicast Listener Discovery (MLD) 1279 In order to extend the scope of IP multicast beyond link-local scope, 1280 an IP multicast routing or forwarding protocol has to be active in 1281 routers on an LLN. To achieve efficient multicast routing (i.e. 1282 avoid always flooding multicast IP packets), routers have to learn 1283 which hosts need to receive packets addressed to specific IP 1284 multicast destinations. 1286 The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its 1287 IPv4 pendant IGMP) is today the method of choice used by an (IP 1288 multicast enabled) router to discover the presence of multicast 1289 listeners on directly attached links, and to discover which multicast 1290 addresses are of interest to those listening nodes. MLD was 1291 specifically designed to cope with fairly dynamic situations in which 1292 multicast listeners may join and leave at any time. 1294 IGMP/MLD Snooping is a technique implemented in some corporate LAN 1295 routing/switching devices. An MLD snooping switch listens to MLD 1296 State Change Report messages from MLD listeners on attached links. 1297 Based on this, the switch learns on what LAN segments there is 1298 interest for what IP multicast traffic. If the switch receives at 1299 some point an IP multicast packet, it uses the stored information to 1300 decide onto which LAN segment(s) to send the packet. This improves 1301 network efficiency compared to the regular behavior of forwarding 1302 every incoming multicast packet onto all LAN segments. An MLD 1303 snooping switch may also send out MLD Query messages (which is 1304 normally done by a device in MLD Router role) if no MLD Router is 1305 present. 1307 [RFC6636] discusses optimal tuning of the parameters of MLD for 1308 routers for mobile and wireless networks. These guidelines may be 1309 useful when implementing MLD in LLNs. 1311 Appendix B. Change Log 1313 Changes from ietf-05 to ietf-06: 1315 o Added a new section on commissioning flow when using discovery 1316 services when end devices discover in which multicast group they 1317 are allocated (#295). 1319 o Added a new section on CoAP Proxy Operation (section 3.9) that 1320 outlines the potential issues and limitations of doing CoAP 1321 multicast requests via a CoAP Proxy (#274). 1323 o Added use case of multicasting controller on the backbone (#279). 1325 o Use cases were updated to show only a single CoAP RD (to replace 1326 the previous multiple RDs with one in each subnet). This is a 1327 more efficient deployment and also avoids RD specific issues such 1328 as synchronization of RD information between serves (#280). 1330 o Added text to section 3.6 (Configuring Group Membership in 1331 Endpoints) that clarified that any (unicast) operation to change 1332 an endpoint's group membership must use DTLS-secured CoAP. 1334 o Clarified relationship of this document to [I-D.ietf-core-coap] in 1335 section 2.2 (Scope). 1337 o Removed IPSec related requirement, as IPSec is not part of 1338 [I-D.ietf-core-coap] anymore. 1340 o Editorial reordering of subsections in section 3 to have a better 1341 flow of topics. Also renamed some of the (sub)sections to better 1342 reflect their content. Finally, moved the URI Configuration text 1343 to the same section as the Port Configuration section as it was a 1344 more natural grouping (now in section 3.3) . 1346 o Editorial rewording of section 3.7 (Multicast Request Acceptance 1347 and Response Suppression) to make the logic easier to comprehend 1348 (parse). 1350 o Various editorial updates for improved readability. 1352 Changes from ietf-04 to ietf-05: 1354 o Added a new section 3.9 (Exceptions) that highlights that IP 1355 multicast (and hence group communication) is not always available 1356 (#187). 1358 o Updated text on the use of [RFC2119] language (#271) in Section 1. 1360 o Included guidelines on when (not) to use CoAP responses to 1361 multicast requests and when (not) to accept multicast requests 1362 (#273). 1364 o Added guideline on use of core-block for minimizing response size 1365 (#275). 1367 o Restructured section 6 (Security Considerations) to more fully 1368 describe threats and threat mitigation (#277). 1370 o Clearly indicated that DNS resolution and reverse DNS lookup are 1371 optional. 1373 o Removed confusing text about a single group having multiple IP 1374 addresses. If multiple IP addresses are required then multiple 1375 groups (with the same members) should be created. 1377 o Removed repetitive text about the fact that group communication is 1378 not guaranteed. 1380 o Merged previous section 5.2 (Multicast Routing) into 3.1 (IP 1381 Multicast Routing Background) and added link to section 5.2 1382 (Advertising Membership of Multicast Groups). 1384 o Clarified text in section 3.8 (Congestion Control) regarding 1385 precedence of use of IP multicast domains (i.e. first try to use 1386 link-local scope, then site-local scope, and only use global IP 1387 multicast as a last resort). 1389 o Extended group resource manipulation guidelines with use of pre- 1390 configured ports/paths for the multicast group. 1392 o Consolidated all text relating to ports in a new section 3.3 (Port 1393 Configuration). 1395 o Clarified that all methods (GET/PUT/POST) for configuring group 1396 membership in endpoints should be unicast (and not multicast) in 1397 section 3.7 (Configuring Group Membership In Endpoints). 1399 o Various editorial updates for improved readability, including 1400 editorial comments by Peter van der Stok to WG list of December 1401 18th, 2012. 1403 Changes from ietf-03 to ietf-04: 1405 o Removed section 2.3 (Potential Solutions for Group Communication) 1406 as it is purely background information and moved section to draft- 1407 dijk-core-groupcomm-misc (#266). 1409 o Added reference to draft-keoh-tls-multicast-security to section 6 1410 (Security Considerations). 1412 o Removed Appendix B (CoAP-Observe Alternative to Group 1413 Communications) as it is as an alternative to IP Multicast that 1414 the WG has not adopted and moved section to draft-dijk-core- 1415 groupcomm-misc (#267). 1417 o Deleted section 8 (Conclusions) as it is redundant (#268). 1419 o Simplified light switch use case (#269) by splitting into basic 1420 operations and additional functions (#269). 1422 o Moved section 3.7 (CoAP Multicast and HTTP Unicast Interworking) 1423 to draft-dijk-core-groupcomm-misc (#270). 1425 o Moved section 3.3.1 (DNS-SD) and 3.3.2 (CoRE Resource Directory) 1426 to draft-dijk-core-groupcomm-misc as these sections essentially 1427 just repeated text from other drafts regarding DNS based features. 1428 Clarified remaining text in this draft relating to DNS based 1429 features to clearly indicate that these features are optional 1430 (#272). 1432 o Focus section 3.5 (Configuring Group Membership) on a single 1433 proposed solution. 1435 o Scope of section 5.3 (Use of MLD) widened to multicast destination 1436 advertisement methods in general. 1438 o Rewrote section 2.2 (Scope) for improved readability. 1440 o Moved use cases that are not addressed to draft-dijk-core- 1441 groupcomm-misc. 1443 o Various editorial updates for improved readability. 1445 Changes from ietf-02 to ietf-03: 1447 o Clarified that a group resource manipulation may return back a 1448 mixture of successful and unsuccessful responses (section 3.4 and 1449 Figure 6) (#251). 1451 o Clarified that security option for group communication must be 1452 NoSec mode (section 6) (#250). 1454 o Added mechanism for group membership configuration (#249). 1456 o Removed IANA request for multicast addresses (section 7) and 1457 replaced with a note indicating that the request is being made in 1458 [I-D.ietf-core-coap] (#248). 1460 o Made the definition of 'group' more specific to group of CoAP 1461 endpoints and included text on UDP port selection (#186). 1463 o Added explanatory text in section 3.4 regarding why not to use 1464 group communication for non-idempotent messages (i.e. CoAP POST) 1465 (#186). 1467 o Changed link-local RD discovery to site-local in RD discovery use 1468 case to make it more realistic. 1470 o Fixed lighting control use case CoAP proxying; now returns 1471 individual CoAP responses as in coap-12. 1473 o Replaced link format I-D with RFC6690 reference. 1475 o Various editorial updates for improved readability 1477 Changes from ietf-01 to ietf-02: 1479 o Rewrote congestion control section based on latest CoAP text 1480 including Leisure concept (#188) 1482 o Updated the CoAP/HTTP interworking section and example use case 1483 with more details and use of MLD for multicast group joining 1485 o Key use cases added (#185) 1487 o References to [I-D.vanderstok-core-dna] and draft-castellani-core- 1488 advanced-http-mapping added 1490 o Moved background sections on "MLD" and "CoAP-Observe" to 1491 Appendices 1493 o Removed requirements section (and moved it to draft-dijk-core- 1494 groupcomm-misc) 1496 o Added details for IANA request for group communication multicast 1497 addresses 1499 o Clarified text to distinguish between "link local" and general 1500 multicast cases 1502 o Moved lengthy background section 5 to draft-dijk-core-groupcomm- 1503 misc and replaced with a summary 1505 o Various editorial updates for improved readability 1507 o Change log added 1508 Changes from ietf-00 to ietf-01: 1510 o Moved CoAP-observe solution section to section 2 1512 o Editorial changes 1514 o Moved security requirements into requirements section 1516 o Changed multicast POST to PUT in example use case 1518 o Added CoAP responses in example use case 1520 Changes from rahman-07 to ietf-00: 1522 o Editorial changes 1524 o Use cases section added 1526 o CoRE Resource Directory section added 1528 o Removed section 3.3.5. IP Multicast Transmission Methods 1530 o Removed section 3.4 Overlay Multicast 1532 o Removed section 3.5 CoAP Application Layer Group Management 1534 o Clarified section 4.3.1.3 RPL Routers with Non-RPL Hosts case 1536 o References added and some normative/informative status changes 1538 Authors' Addresses 1540 Akbar Rahman (editor) 1541 InterDigital Communications, LLC 1543 Email: Akbar.Rahman@InterDigital.com 1545 Esko Dijk (editor) 1546 Philips Research 1548 Email: esko.dijk@philips.com