idnits 2.17.1 draft-dijk-core-groupcomm-misc-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2014) is 3580 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-06) exists of draft-castellani-core-advanced-http-mapping-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-14 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-18 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-13 == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-09 == Outdated reference: A later version (-08) exists of draft-keoh-dice-multicast-security-07 == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-02 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group E. Dijk, Ed. 3 Internet-Draft Philips Research 4 Intended status: Informational A. Rahman, Ed. 5 Expires: December 11, 2014 InterDigital Communications, LLC 6 June 9, 2014 8 Miscellaneous CoAP Group Communication Topics 9 draft-dijk-core-groupcomm-misc-06 11 Abstract 13 This document contains miscellaneous text around the topic of group 14 communication for the Constrained Application Protocol (CoAP). The 15 intent of this document is to keep track of useful ideas while the 16 main CoRE WG Group Communication draft goes through the RFC 17 publication process. These ideas may be then be used as input to 18 future standardization in the CoRE or other related WGs. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 11, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Potential Solutions for Group Communication . . . . . . . . . 3 56 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. General Requirements . . . . . . . . . . . . . . . . . . 5 60 4.3. Security Requirements . . . . . . . . . . . . . . . . . . 6 61 5. Group Communication Solutions . . . . . . . . . . . . . . . . 8 62 5.1. IP Multicast Transmission Methods . . . . . . . . . . . . 8 63 5.1.1. Serial unicast . . . . . . . . . . . . . . . . . . . 8 64 5.1.2. Unreliable IP Multicast . . . . . . . . . . . . . . . 8 65 5.1.3. Reliable IP Multicast . . . . . . . . . . . . . . . . 8 66 5.2. Overlay Multicast . . . . . . . . . . . . . . . . . . . . 9 67 5.3. CoAP Application Layer Group Management . . . . . . . . . 10 68 6. DNS-SD Based Group Resource Manipulation . . . . . . . . . . 13 69 7. Group Discovery and Member Discovery . . . . . . . . . . . . 13 70 7.1. DNS-SD . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7.2. CoRE Resource Directory . . . . . . . . . . . . . . . . . 14 72 8. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 14 73 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8.2. Implementation in Target Network Topologies . . . . . . . 15 75 8.2.1. Single LLN Topology . . . . . . . . . . . . . . . . . 15 76 8.2.2. Single LLN with Backbone Topology . . . . . . . . . . 17 77 8.2.3. Multiple LLNs with Backbone Topology . . . . . . . . 19 78 8.2.4. LLN(s) with Multiple 6LBRs . . . . . . . . . . . . . 19 79 8.2.5. Conclusions . . . . . . . . . . . . . . . . . . . . . 19 80 8.3. Implementation Considerations . . . . . . . . . . . . . . 20 81 8.3.1. MLD Implementation on LLNs and MLD alternatives . . . 20 82 8.3.2. 6LBR Implementation . . . . . . . . . . . . . . . . . 21 83 8.3.3. Backbone IP Multicast Infrastructure . . . . . . . . 21 84 9. Miscellaneous Topics . . . . . . . . . . . . . . . . . . . . 22 85 9.1. CoAP Multicast and HTTP Unicast Interworking . . . . . . 22 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 88 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 91 13.2. Informative References . . . . . . . . . . . . . . . . . 26 92 Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 28 93 Appendix B. CoAP-Observe Alternative to Group Communication . . 29 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 96 1. Introduction 98 This document contains miscellaneous text around the topic of group 99 communication for the Constrained Application Protocol, CoAP 100 [I-D.ietf-core-coap]. The first part of the document contains, for 101 reference, text that was removed from the Group Communication for 102 CoAP [I-D.ietf-core-groupcomm] draft and its predecessor 103 [I-D.rahman-core-groupcomm]. The second part of the document 104 contains text and/or functionality that may be considered for input 105 to future standardization in the CoRE or other related WGs. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. Potential Solutions for Group Communication 113 The classic concept of group communications is that of a single 114 source distributing content to multiple destination recipients that 115 are all part of a group. Before content can be distributed, there is 116 a separate process to form the group. The source may be either a 117 member or non-member of the group. 119 Group communication solutions have evolved from "bottom" to "top", 120 i.e., from layer 2 (Media Access Control broadcast/multicast) and 121 layer 3 (IP multicast) to application layer group communication, also 122 referred to as application layer multicast. A study published in 123 2005 [Lao05] identified new solutions in the "middle" (referred to as 124 overlay multicast) that utilize an infrastructure based on proxies. 126 Each of these classes of solutions may be compared [Lao05] using 127 metrics such as link stress and level of host complexity 128 [Banerjee01]. The results show for a realistic internet topology 129 that IP Multicast is the most resource-efficient, with the downside 130 being that it requires the most effort to deploy in the 131 infrastructure. IP Multicast is the solution adopted by this draft 132 for CoAP group communication. 134 3. Use Cases 136 CoAP group communication can be applied in the context of the 137 following use cases: 139 o Discovery of Resource Directory: discovering the local CoRE RD 140 which contains links (URIs) to resources stored on other servers 141 [RFC6690]. 143 o Lighting Control: synchronous operation of a group of 144 IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights). 146 o Parameter Update: updating parameters/settings simultaneously in a 147 large group of devices in a building/campus control 148 ([I-D.vanderstok-core-bc]) application. 150 o Firmware Update: efficiently updating firmware simultaneously in a 151 large group of devices in a building/campus control 152 ([I-D.vanderstok-core-bc]) application. Here, the use of CoAP 153 group communication could be realized via a multicast extension of 154 CoAP blockwise transfer [I-D.ietf-core-block]. This use case and 155 use of multicast is especially valuable if there are time 156 constraints related to the software update for large groups of 157 devices. 159 o Group Status Report: requesting status information or event 160 reports from a group of devices in a building/campus control 161 application. In this use case, conditional reporting is required: 162 only device that have events to report (as indicated by the 163 request query) respond, others remain silent. This use case 164 requires reliable CoAP group communication, which is currently not 165 in CoRE WG scope. 167 4. Requirements 169 Requirements that a CoAP group communication solution should fulfill 170 can be found in existing documents ([RFC5867], 171 [I-D.ietf-6lowpan-routing-requirements], [I-D.vanderstok-core-bc], 172 and [I-D.shelby-core-coap-req]). Below, a set of high-level 173 requirements is listed that a group communication solution should 174 ideally fulfill. In practice, all these requirements can never be 175 satisfied at once in an LLN context. Furthermore, different use 176 cases will have different needs i.e. an elaboration of a subset of 177 below requirements. 179 4.1. Background 181 The requirements for CoAP are documented in 182 [I-D.shelby-core-coap-req]. In this draft, we focus and expand 183 discussions on the requirements pertaining to CoAP "group 184 communication" and "multicast" support as stated in 185 [I-D.shelby-core-coap-req]: 187 REQ 9: CoAP will support a non-reliable IP multicast message to be 188 sent to a group of Devices to manipulate a resource on all the 189 Devices simultaneously. The use of multicast to query and 190 advertise descriptions must be supported, along with the support 191 of unicast responses. 193 Currently, the CoAP protocol [I-D.ietf-core-coap] supports unreliable 194 IP multicast using UDP. It defines the unreliable multicast 195 operation as follows in Section 4.5: 197 "CoAP supports sending messages to multicast destination 198 addresses. Such multicast messages MUST be Non-Confirmable. Some 199 mechanisms for avoiding congestion from multicast requests are 200 being considered in [I-D.eggert-core-congestion-control]." 202 Additional requirements were introduced in [I-D.vanderstok-core-bc] 203 driven by quality of experience issues in commercial lighting; the 204 need for large numbers of devices to respond with near simultaneity 205 to a command (multicast PUT), and for that command to be received 206 reliably (reliable multicast). 208 4.2. General Requirements 210 A CoAP group communication solution should (ideally) meet the 211 following general requirements: 213 GEN-REQ 1: Optional Reliability: the application can select 214 between unreliable group communication and reliable 215 group communication. 217 GEN-REQ 2: Efficiency: delivers messages more efficiently than a 218 "serial unicast" solution. Provides a balance between 219 group data traffic and control overhead. 221 GEN-REQ 3: Low latency: deliver a message as quickly as possible. 223 GEN-REQ 4: Synchrony: allows near-simultaneous modification of a 224 resource on all devices in a target group, providing a 225 perceived effect of synchrony or simultaneity. For 226 example a specified time span D such that a message is 227 delivered to all destinations in a time interval 228 [t,t+D]. 230 GEN-REQ 5: Ordering: message ordering may be required for reliable 231 group communication use cases. 233 GEN-REQ 6: Security: see Section 4.3 for security requirements for 234 group communication. 236 GEN-REQ 7: Flexibility: support for one or many source(s), both 237 dense and sparse networks, for high or low listener 238 density, small or large number of groups, and multi- 239 group membership. 241 GEN-REQ 8: Robust group management: functionality to join groups, 242 leave groups, view group membership, and persistent 243 group membership in failure or sleeping node 244 situations. 246 GEN-REQ 9: Network layer independence: a solution is independent 247 from specific unicast and/or IP multicast routing 248 protocols. 250 GEN-REQ 10: Minimal specification overhead: a group communication 251 solution should preferably re-use existing/established 252 (IETF) protocols that are suitable for LLN deployments, 253 instead of defining new protocols from scratch. 255 GEN-REQ 11: Minimal implementation overhead: e.g. a solution allows 256 to re-use existing (software) components that are 257 already present on constrained nodes such as (typical) 258 6LoWPAN/CoAP nodes. 260 GEN-REQ 12: Mixed backbone/LLN topology support: a solution should 261 work within a single LLN, and in combined LLN/backbone 262 network topologies, including multi-LLN topologies. 263 Both the senders and receivers of CoAP group messages 264 may be attached to different network links or be part 265 of different LLNs, possibly with routers or switches in 266 between group members. In addition, different routing 267 protocols may operate on the LLN and backbone networks. 268 Preferably a solution also works with existing, common 269 backbone IP infrastructure (e.g. switches or routers). 271 GEN-REQ 13: CoAP Proxying support: a CoAP proxy can handle 272 distribution of a message to a group on behalf of a 273 (constrained) CoAP client. 275 GEN-REQ 14: Suitable for operation on LLNs with constrained nodes. 277 4.3. Security Requirements 279 Security for group communications at the IP level has been studied 280 extensively in the IETF MSEC (Multicast Security) WG, and to a lesser 281 extent in the IRTF SAMRG (Scalable Adaptive Multicast Research 282 Group). In particular, [RFC3740], [RFC5374] and [RFC4046] are very 283 instructive. A set of requirements for securing group communications 284 in CoAP were derived from a study of these previous investigations as 285 well as understanding of CoAP specific needs. These are listed 286 below. 288 A CoAP group communication solution should (ideally) meet the 289 following security requirements: 291 SEC-REQ 1: Group communications data encryption: Important CoAP 292 group communications shall be encrypted (using a group 293 key) to preserve confidentiality. It shall also be 294 possible to send CoAP group communications in the clear 295 (i.e. unencrypted) for low value data. 297 SEC-REQ 2: Group communications source data authentication: 298 Important CoAP group communications shall be 299 authenticated by verifying the source of the data (i.e. 300 that it was generated by a given and trusted group 301 member). It shall also be possible to send 302 unauthenticated CoAP group communications for low value 303 data. 305 SEC-REQ 3: Group communications limited data authentication: Less 306 important CoAP group communications shall be 307 authenticated by simply verifying that it originated 308 from one of the group members (i.e. without explicitly 309 identifying the source node). This is a weaker 310 requirement (but simpler to implement) than REQ2. It 311 shall also be possible to send unauthenticated CoAP 312 group communications for low value data. 314 SEC-REQ 4: Group key management: There shall be a secure mechanism 315 to manage the cryptographic keys (e.g. generation and 316 distribution) belonging to the group; the state (e.g. 317 current membership) associated with the keys; and other 318 security parameters. 320 SEC-REQ 5: Use of Multicast IPSec: The CoAP protocol 321 [I-D.ietf-core-coap] allows IPSec to be used as one 322 option to secure CoAP. If IPSec is used as a way to 323 security CoAP communications, then multicast IPSec 324 [RFC5374] should be used for securing CoAP group 325 communications. 327 SEC-REQ 6: Independence from underlying routing security: CoAP 328 group communication security shall not be tied to the 329 security of underlying routing and distribution 330 protocols such as PIM [RFC4601] and RPL [RFC6550]. 331 Insecure or inappropriate routing (including IP 332 multicast routing) may cause loss of data to CoAP but 333 will not affect the authenticity or secrecy of CoAP 334 group communications. 336 SEC-REQ 7: Interaction with HTTPS: The security scheme for CoAP 337 group communications shall account for the fact that it 338 may need to interact with HTTPS (Hypertext Transfer 339 Protocol Secure) when a transaction involves a node in 340 the general Internet (non-constrained network) 341 communicating via a HTTP-CoAP proxy. 343 5. Group Communication Solutions 345 This section includes the text that describes the solutions of IP 346 multicast, overlay multicast, and application layer group 347 communication which were removed from [I-D.rahman-core-groupcomm] 348 version 07 when the text was transferred to 349 [I-D.ietf-core-groupcomm]. 351 5.1. IP Multicast Transmission Methods 353 5.1.1. Serial unicast 355 Even in systems that generally support IP Multicast, there may be 356 certain data links (or transports) that don't support IP multicast. 357 For those links a serial unicast alternative must be provided. This 358 implies that it should be possible to enumerate the members of a 359 group, in order to determine the correct unicast destinations. 361 5.1.2. Unreliable IP Multicast 363 The CoRE WG charter specified support for non-reliable IP multicast. 364 In the current CoAP protocol design [I-D.ietf-core-coap], unreliable 365 multicast is realized by the source sending Non-Confirmable messages 366 to a multicast IP address. IP Multicast (using UDP) in itself is 367 unreliable, unless specific reliability features are added to it. 369 5.1.3. Reliable IP Multicast 371 [TBD: This is a difficult problem. Need to investigate the benefits 372 of repeating MGET and MPUT requests (saturation) to get "Pretty Good 373 Reliability". Use the same MID or a new MID for repeated requests? 374 Carsten suggests the use of bloom filters to suppress duplicate 375 responses. 377 One could argue that non-idempotent operations (POST) cannot be 378 supported without a *truly* reliable multicast protocol. However, is 379 this the case? If a multicast POST request is sent repeatedly with 380 the same Message ID (MID), then CoAP nodes that already received it 381 once will ignore duplicates. Sending with Message ID is supported in 382 CoAP for Non-Confirmable messages (thus including multicast messages) 383 as per [I-D.ietf-core-coap] section 4.2. ] 385 Reliable multicast supports guaranteed delivery of messages to a 386 group of nodes. The following specifies the requirements as was 387 proposed originally in version 01 of [I-D.vanderstok-core-bc]: 389 o Validity - If sender sends a message, m, to a group, g, of 390 destinations, a path exists between sender and destinations, and 391 the sender and destinations are correct, all destinations in g 392 eventually receive m. 394 o Integrity - destination receives m at most once from sender and 395 only if sender sent m to a group including destination. 397 o Agreement - If a correct destination of g receives m, then all 398 correct destinations of g receive m. 400 o Timeliness - For real-time control of devices, there is a known 401 constant D such that if m is sent at time t, no correct 402 destination receives m after t+D. 404 There are various approaches to achieve reliability, such as 406 o Destination node sends response: a destination sends a CoAP 407 Response upon multicast Request reception (it SHOULD be a Non- 408 Confirmable response). The source node may retry a request to 409 destination nodes that did not respond in time with a CoAP 410 response. 412 o Route redundancy 414 o Source node transmits multiple times (destinations do not respond) 416 5.2. Overlay Multicast 418 An alternative group communication solution (to IP Multicast) is an 419 "overlay multicast" approach. We define an overlay multicast as one 420 that utilizes an infrastructure based on proxies (rather than an IP 421 router based IP multicast backbone) to deliver IP multicast packets 422 to end devices. MLD ([RFC3810]) has been selected as the basis for 423 multicast support by the ROLL working group for the RPL routing 424 protocol. Therefore, it is proposed that "IGMP/MLD Proxying" 425 [RFC4605] be used as a basis for an overlay multicast solution for 426 CoAP. 428 Specifically, a CoAP proxy [I-D.ietf-core-coap] may also contain an 429 MLD Proxy function. All CoAP devices that want to join a given IP 430 multicast group would then send an MLD Join to the CoAP (MLD) proxy. 431 Thereafter, the CoAP (MLD) proxy would be responsible for delivering 432 any IP multicast message to the subscribed CoAP devices. This will 433 require modifications to the existing [RFC4605] functionality. 435 Note that the CoAP (MLD) proxy may or may not be connected to an 436 external IP multicast enabled backbone. The key function for the 437 CoAP (MLD) proxy is to distribute CoAP generated multicast packets 438 even in the absence of router support for multicast. 440 5.3. CoAP Application Layer Group Management 442 Another alternative solution (to IP Multicast and Overlay Multicast) 443 is to define CoAP application level group management primitives. 444 Thus, CoAP can support group management features without need for any 445 underlying IP multicast support. 447 Interestingly, such group management primitives could also be offered 448 even if there is underlying IP multicast support. This is useful 449 because IP multicast inherently does not support the concept of a 450 group with managed members, while a managed group may be required for 451 some applications. 453 The following group management primitives are in general useful: 455 o discover groups; 457 o query group properties (e.g. related resource descriptions); 459 o create a group; 461 o remove a group; 463 o add a group member; 465 o remove a group member; 467 o enumerate group members; 469 o security and access control primitives. 471 In this proposal a (at least one) CoAP Proxy node is responsible for 472 group membership management. A constrained node can specify which 473 group it intends to join (or leave) using a CoAP request to the 474 appropriate CoAP Proxy. To Join, the group name will be included in 475 optional request header fields (explained below). These header 476 fields will be included in a PUT request to the Proxy. The Proxy-URI 477 is set to the Group Management URI of the Proxy (found previously 478 through the "/.well-known/" resource discovery mechanism). Note that 479 in this solution also CoAP Proxies may exist in a network that are 480 not capable of CoAP group operations. 482 Group names may be defined as arbitrary strings with a predefined 483 maximum length (e.g. 268 characters or the maximum string length in a 484 CoAP Option), or as URIs. 486 [ TBD: how can a client send a request to a group? Does it only need 487 to know the group name (string or URI) or also an IP multicast 488 address? One way is to send a CoAP request to the CoAP Proxy with a 489 group URI directly in the Proxy-URI field. This avoids having to 490 know anything related to IP multicast addresses. ] 492 This solution in principle supports both unreliable and reliable 493 group communication. A client would indicate unreliable 494 communication by sending a CoAP Non-Confirmable request to the CoAP 495 Proxy, or reliable communication by sending a CoAP Confirmable 496 request. 498 It is proposed that CoAP supports two Header Options for group "Join" 499 and "Leave". These Options are Elective so they should be assigned 500 an even number. Assuming the Type for "join" is x (value TBD), the 501 Header Options are illustrated by the table in Figure 1: 503 +------+-----+---------------+--------------+--------+--------------+ 504 | Type | C/E | Name | Data type | Length | Default | 505 |------+-----+---------------+--------------+--------+--------------+ 506 | | | | | | | 507 | x | E | Group Join | String | 1-270 | "" | 508 | | | | | B | | 509 | x+2 | E | Group Leave | String | 1-270 | "" | 510 | | | | | B | | 511 +------+-----|---------------+--------------+--------+--------------+ 513 Figure 1: CoAP Header Options for Group Management 515 Figure 2 illustrates how a node can join or leave a group using the 516 Header Options in a CoAP message: 518 0 1 2 3 519 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 |Ver| T | OC | Code | Message ID | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | delta |length | Join Group A (ID or URI) 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | 0 |length | Join Group B (ID or URI) 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | 2 |length | Leave Group C (ID or URI) 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 2: CoAP Message for Group Management 532 Header Fields for the above example: 534 Ver: 2-bit unsigned integer for CoAP Version. Set to 1 by 535 implementation as defined by the CoAP specification. 537 T: 2-bit unsigned integer for CoAP Transaction Type. Either '0' 538 Confirmation or '1' Non-Confirmable can be used for group "join" or 539 "leave" request. 541 OC: 4-bit unsigned integer for Option Count. For this example, the 542 value should be "3" since there are three option fields. 544 Code: 8-bit unsigned integer to indicate the Method in a Request or a 545 Response Code in a Response message. Any Code can be used so the 546 group management can be piggy-backed in either Request or Response 547 message. 549 Message ID: 16-bit value assigned by the source to uniquely identify 550 a pair of Request and Response. 552 CoAP defines a delta encoding for header options. The first delta is 553 the "Type" for group join in this specific example. If the type for 554 group join is x as illustrated in Figure 2, delta will be x. In the 555 second header option, it is also a group join so the delta is 0. The 556 third header option is a group leave so the delta is 2. 558 An alternative solution to using Header Options (explained above) is 559 to use designated parameters in the query part of the URI in the 560 Proxy-URI field of a POST (TBD: or PUT?) request to a Proxy's group 561 management service resource advertised by DNS-SD. For example, to 562 join group1 and leave group2: 564 coap://proxy1.bld2.example.com/groupmgt?j=group1&l=group2 566 6. DNS-SD Based Group Resource Manipulation 568 Ideally, all nodes in a given group (defined by its multicast IP 569 address) must receive the same request with high probability. This 570 will not be the case if there is diversity in the authority port 571 (i.e. a diversity of dynamic port addresses across the group) or if 572 the targeted resource is located at different paths on different 573 nodes. Extending the definition of group membership to include port 574 and path discovery is not desirable. 576 Therefore, some measures must be present to ensure uniformity in port 577 number and resource name/location within a group. 579 A first solution in this respect is to couple groups to service 580 descriptions in DNS (using DNS-SD as in [I-D.vanderstok-core-bc]). A 581 service description for a multicast group may have a TXT record in 582 DNS defining a schema X (e.g. "schema=DALI"), which defines by 583 service standard X (e.g. "DALI") which resources a node supporting X 584 MUST have. Therefore a multicast source can safely refer to all 585 resources with corresponding operations as prescribed by standard X. 586 For port numbers (which can be found using DNS-SD also) the same 587 holds. Alternatively, only the default CoAP port may be used in all 588 CoAP multicast requests. 590 7. Group Discovery and Member Discovery 592 CoAP defines a resource discovery capability, but does not yet 593 specify how to discover groups (e.g. find a group to join or send a 594 multicast message to) or to discover members of a group (e.g. to 595 address selected group members by unicast). These topics are 596 elaborated in more detail in [I-D.vanderstok-core-dna] including 597 examples for using DNS-SD and CoRE Resource Directory. 599 7.1. DNS-SD 601 DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a 602 conventional way to configure DNS PTR, SRV, and TXT records to enable 603 enumeration of services, such as services offered by CoAP nodes, or 604 enumeration of all CoAP nodes, within specified subdomains. A 605 service is specified by a name of the form 606 .., where the service type for CoAP 607 nodes is _coap._udp and the domain is a DNS domain name that 608 identifies a group as in the examples above. For each CoAP end-point 609 in a group, a PTR record with the name _coap._udp and/or a PTR record 610 with the name _coap._udp. is defined and it points to an SRV 611 record having the .. name. 613 All CoAP nodes in a given subdomain may be enumerated by sending a 614 query for PTR records named _coap._udp to the authoritative DNS 615 server for that zone. A list of SRV records is returned. Each SRV 616 record contains the port and host name (AAAA record) of a CoAP node. 617 The IP address of the node is obtained by resolving the host name. 618 DNS-SD also specifies an optional TXT record, having the same name as 619 the SRV record, which can contain "key=value" attributes. This can 620 be used to store information about the device, e.g. schema=DALI, 621 type=switch, group=lighting.bldg6, etc. 623 Another feature of DNS-SD is the ability to specify service sub-types 624 using PTR records. For example, one could represent all the CoAP 625 groups in a subdomain by PTR records with the name 626 _group._sub._coap._udp or alternatively 627 _group._sub._coap._udp.. 629 7.2. CoRE Resource Directory 631 CoRE Resource Directory [I-D.shelby-core-resource-directory] defines 632 the concept of a Resource Directory (RD) server where CoAP servers 633 can register their resources offered and CoAP clients can discover 634 these resources by querying the RD server. RD syntax can be mapped 635 to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping], 636 such that the above approach can be reused for group discovery and 637 group member discovery. 639 Specifically, the Domain (d) parameter can be set to the group URI by 640 an end-point registering to the RD. If an end-point wants to join 641 multiple groups, it has to repeat the registration process for each 642 group it wants to join. 644 8. Deployment Guidelines 646 8.1. Overview 648 We recommend to use IP multicast as the base solution for CoAP Group 649 Communication, provided that the use case and network characteristics 650 allow this. It has the advantage that it re-uses the IP multicast 651 suite of protocols and can operate even if group members are 652 distributed over both constrained and un-constrained network 653 segments. Still, this approach may require specifying or 654 implementing additional IP Multicast functionality in an LLN, in a 655 backbone network, or in both - this will be evaluated in more detail 656 in this section. 658 8.2. Implementation in Target Network Topologies 660 This section looks in more detail how an IP Multicast based solution 661 can be deployed onto the various network topologies that we consider 662 important for group communication use cases. Note that the chosen 663 solution of IP Multicast for CoAP group communication works mostly 664 independently from the underlying network topology and its specific 665 IP multicast implementation. 667 Starting from the simplest case of a single LLN topology, we move to 668 more complex topologies involving a backbone network or multiple 669 LLNs. With "backbone" we refer here typically to a corporate LAN or 670 VLAN, which constitutes a single broadcast domain by design. It 671 could also be an in-home network. A multi-link backbone is also 672 possible, if there is proper IP multicast routing or forwarding 673 configured between these links. (The term 6LoWPAN Border Router or 674 "6LBR" is used here for a border router, though our evaluation is not 675 necessarily restricted to 6LoWPAN networks.) 677 8.2.1. Single LLN Topology 679 The simplest topology is a single LLN, where all the IP multicast 680 source(s) and destinations are constrained nodes within this same 681 LLN. Possible implementations of IP multicast routing and group 682 administration for this topology are listed below. 684 8.2.1.1. Mesh-Under Multicast Routing 686 The LLN may be set up in either a mesh-under or a route-over 687 configuration. In the former case, the mesh routing protocol should 688 take care of routing IP multicast messages throughout the LLN. 690 Because conceptually all nodes in the LLN are attached to a single 691 link, there is in principle no need for nodes to announce their 692 interest in multicast IP addresses via MLD (see Appendix A). A 693 multicast message to a specific IP destination, which is delivered to 694 all 6LoWPAN nodes by the mesh routing algorithm, is accepted by the 695 IP network layer of that node only if it is listening on that 696 specific multicast IP address and port. 698 8.2.1.2. RPL Multicast Routing 700 The RPL routing protocol for LLNs provides support for routing to 701 multicast IP destinations (Section 12 of [RFC6550]). Like regular 702 unicast destinations, multicast destinations are advertised by nodes 703 using RPL DAO messages. This functionality requires "Storing mode 704 with multicast support" (Mode Of Operation, MOP is 3) in the RPL 705 network. 707 Once all RPL routing tables in the network are populated, any RPL 708 node can send packets to an IP multicast destination. The RPL 709 protocol performs distribution of multicast packet both upward 710 towards the DODAG root and downwards into the DODAG. 712 The text in Section 12 of the RPL specification clearly implies that 713 IP multicast packets are distributed using link-layer unicast 714 transmissions, looking at the use of the word "copied" in this 715 section. Specifically in 6LoWPAN networks, this behavior conflicts 716 with the requirement that IP multicast packets MUST be carried as 717 link-layer 802.15.4 broadcast frames [RFC4944]. 719 Assuming that link-layer unicast is indeed meant, this approach seems 720 efficient only in a balanced, sparse tree network topology, or in 721 situations where the fraction of nodes listening to a specific 722 multicast IP address is low, or in duty cycled LLNs where link-layer 723 broadcast is a very expensive operation. 725 8.2.1.3. RPL Routers with Non-RPL Hosts 727 Now we consider the case that hosts exist in a RPL network that are 728 not RPL-aware themselves, but rely on RPL routers for their IP 729 connectivity beyond link-local scope. Note that the current RPL 730 specification [RFC6550] leaves this case for future specification 731 (see Section 16.4). Non-RPL hosts cannot advertise their IP 732 multicast groups of interest via RPL DAO messages as defined above. 733 Therefore in that case MLD could be used for such advertisements 734 (State Change Report messages), with all or a subset of RPL routers 735 acting in the role of MLD Routers as defined in [RFC3810]. However, 736 as the MLD protocol is not designed specifically for LLNs it may be a 737 burden for the constrained RPL router nodes to run the full MLD 738 protocol. Alternatives are therefore proposed in Section 8.3.1. 740 8.2.1.4. Trickle Multicast Forwarding 742 Trickle Multicast Forwarding [I-D.ietf-roll-trickle-mcast] is an IP 743 multicast routing protocol suitable for LLNs, that uses the Trickle 744 algorithm as a basis. It is a simple protocol in the sense that no 745 topology maintenance is required. It can deal especially well with 746 situations where the node density is a-priori unknown. 748 Nodes from anywhere in the LLN can be the multicast source, and nodes 749 anywhere in the LLN can be multicast destinations. 751 Using Trickle Multicast Forwarding it is not required for IP 752 multicast destinations (listeners) to announce their interest in a 753 specific multicast IP address, e.g. by means of MLD. Instead, all 754 multicast IP packets regardless of IP destination address are stored 755 and forwarded by all routers. Because forwarding is always done by 756 multicast, both hosts and routers will be able to receive all 757 multicast IP packets. Routers that receive multicast packets they 758 are not interested in, will only buffer these for a limited time 759 until retransmission can be stopped as specified by the protocol. 760 Hosts that receive multicast packets they are not interested in, will 761 discard multicast packets that are not of interest. Above properties 762 seem to make Trickle especially efficient for cases where the 763 multicast listener density is high and the number of distinct 764 multicast groups relatively low. 766 8.2.1.5. Other Route-Over Methods 768 Other known IP multicast routing methods may be used, for example 769 flooding or other to be defined methods suitable for LLNs. An 770 important design consideration here is whether multicast listeners 771 need to advertise their interest in specific multicast addresses, or 772 not. If they do, MLD is a possible option but also protocol-specific 773 means (as in RPL) is an option. See Section 8.3.1 for more efficient 774 substitutes for MLD targeted towards a LLN context. 776 8.2.2. Single LLN with Backbone Topology 778 A LLN may be connected via a Border Router (e.g. 6LBR) to a backbone 779 network, on which IP multicast listeners and/or sources may be 780 present. This section analyzes cases in which IP multicast traffic 781 needs to flow from/to the backbone, to/from the LLN. 783 8.2.2.1. Mesh-Under Multicast Routing 785 Because in a mesh routing network conceptually all nodes in the LLN 786 are attached to a single link, a multicast IP packet originating in 787 the LLN is typically delivered by the mesh routing algorithm to the 788 6LBR as well, although there is no guaranteed delivery. The 6LBR may 789 be configured to accept all IP multicast traffic from the LLN and 790 then may forward such packets onto its backbone link. Alternatively, 791 the 6LBR may act in an MLD Router or MLD Snooper role on its backbone 792 link and decide whether to forward a multicast packet or not based on 793 information learned from previous MLD Reports received on its 794 backbone link. 796 Conversely, multicast packets originating on the backbone network 797 will reach the 6LBR if either the backbone is a single link (LAN/ 798 VLAN) or IPv6 multicast routing is enabled on the backbone. Then, 799 the 6LBR could simply forward all IP multicast traffic from the 800 backbone onto the LLN. However, in practice this situation may lead 801 to overload of the LLN caused by unnecessary multicast traffic. 802 Therefore the 6LBR SHOULD only forward traffic that one or more nodes 803 in the LLN have expressed interest in, effectively filtering inbound 804 LLN multicast traffic. 806 To realize this "filter", nodes on the LLN may use MLD to announce 807 their interest in specific multicast IP addresses to the 6LBR. One 808 option is for the 6LBR to act in an MLD Router role on its LLN 809 interface. However, this may be too much of a "burden" for 810 constrained nodes. Light-weight alternatives for MLD are discussed 811 in Section 8.3.1. 813 8.2.2.2. RPL Multicast Routing 815 For RPL routing within the 6LoWPAN, we first consider the case of an 816 IP multicast source on the backbone network with one or more IP 817 multicast listeners on the RPL LLN. Typically, the 6LBR would be the 818 root of a DODAG so that the 6LBR can easily forward the IP multicast 819 packet received on its backbone interface to the right RPL nodes in 820 the LLN down along this DODAG (based on previously DAO-advertized 821 destinations). 823 Second, a multicast source may be in the RPL LLN and listeners may be 824 both on the LLN and on the backbone. For this case RPL defines that 825 the multicast packet will propagate both up and down the DODAG, 826 eventually reaching the DODAG root (typically a 6LBR) from which the 827 packet can be routed onto the backbone in a manner specified in the 828 previous section. 830 8.2.2.3. RPL Routers with Non-RPL Hosts 832 For the case that a RPL LLN contains non-RPL hosts, the solutions 833 from the previous section can be used if in addition RPL routers 834 implement MLD or "MLD like" functionality similar to as described in 835 Section 8.2.1.3. 837 8.2.2.4. Trickle Multicast Forwarding 839 First, we consider the case of an IP multicast source node on the LLN 840 (where all 6LRs support Trickle Multicast Forwarding) and IP 841 multicast listeners that may be on the LLN and on the backbone. As 842 Trickle will eventually deliver multicast packets also to a 6LBR, 843 which acts as a Trickle Multicast router as well, the 6LBR can then 844 forward onto the backbone in the ways described earlier in 845 Section 8.2.2.1. 847 Second, for the case of an IP multicast source on the backbone and 848 multicast listeners on both backbone and/or LLN, the 6LBR needs to 849 forward multicast traffic from the backbone onto the LLN. Here, the 850 aforementioned problem (Section 8.2.2.1) of potentially overloading 851 the LLN with unwanted backbone IP multicast traffic appears again. 853 A possible solution to this is (again) to let multicast listeners 854 advertise their interest using MLD as described in Section 8.2.2.1 or 855 to use an MLD alternative suitable for LLNs as described in 856 Section 8.3.1. However, following this approach requires possibly an 857 extension to Trickle Multicast Forwarding: the protocol should ensure 858 that MLD-advertised information is somehow communicated to the 6LBR, 859 possibly over multiple hops. MLD itself supports link-local 860 communication only. 862 8.2.2.5. Other Route-Over Methods 864 For other multicast routing methods used on the LLN, there are 865 similar considerations to the ones in sections above: the strong need 866 to filter IP multicast traffic coming into the LLN, the need for 867 reporting multicast listener interest (e.g. with MLD or a to-be- 868 defined MLD alternative) by constrained (6LoWPAN) nodes, and the need 869 for LLN-internal routing as identified in the previous section such 870 that the MLD communicated information can reach the 6LBR to be used 871 there in multicast traffic filtering decisions. 873 8.2.3. Multiple LLNs with Backbone Topology 875 Now the case of a single backbone network with two or more LLNs 876 attached to it via 6LBRs is considered. For this case all the 877 considerations and solutions of the previous section can be applied. 879 For the specific case that a source on a backbone network has to send 880 to a very large number of destination located on many LLNs, the use 881 of IGMP/MLD Proxying [RFC4605] with a leaf IGMP/MLD Proxy located in 882 each 6LBR may be useful. This method only is defined for a tree 883 topology backbone network with the IP multicast source at the root of 884 the tree. 886 8.2.4. LLN(s) with Multiple 6LBRs 888 [ TBD: an LLN with multiple 6LBRs may require some additional 889 consideration. Any need to synchronize mutually on multicast 890 listener information? ] 892 8.2.5. Conclusions 894 For all network topologies that were evaluated, CoAP group 895 communication can be in principle supported with IP Multicast, making 896 use of existing protocols. For the case of Trickle Multicast 897 Forwarding, it appears that an addition to the protocol is required 898 such that information about multicast listeners can be distributed 899 towards the 6LBR. Opportunities were identified for an "MLD-like" or 900 "MLD-lightweight" protocol specifically suitable for LLNs, which 901 should inter-work with regular MLD on the backbone network. Such MLD 902 variants are further analyzed in Section 8.3.1. 904 8.3. Implementation Considerations 906 In this section various implementation aspects are considered such as 907 required protocol implementations, additional functionality of the 908 6LBR and backbone network equipment. 910 8.3.1. MLD Implementation on LLNs and MLD alternatives 912 In previous sections, it was mentioned that the MLDv2 protocol 913 [RFC3810] may be too costly for use in a LLN. MLD relies on periodic 914 link-local multicast operations to maintain state. Also it is 915 optimized to fairly dynamic situations where multicast listeners may 916 come and go over time. Such dynamic situations are less frequently 917 found in typical LLN use cases such as building control, where 918 multicast group membership can remain constant over longer periods of 919 time (e.g. months) after commissioning. 921 Hence, a viable strategy is to implement a subset of MLD 922 functionality in 6LoWPAN nodes which is just enough for the required 923 functionality. A first option is that 6LoWPAN Routers, like MLD 924 Snoopers, passively listen to MLD State Change Report messages and 925 handle the learned ("snooped") IP multicast destinations in the way 926 defined by the multicast routing protocol they are running (e.g. for 927 RPL, Routers advertise these destinations using DAO messages). 929 A second option is to use MLD as-is but adapt the recommended 930 parameter values such that operation on a LLN becomes more efficient. 931 [RFC6636] could be a guideline in this case. 933 A third option is to standardize a new protocol, taking a subset of 934 MLD functionality into a "MLD for 6LoWPAN" protocol to support 935 constrained nodes optimally. 937 A fourth option is now presented, which seems attractive in that it 938 minimizes standardization, implementation and network communication 939 overhead all at the same time. This option is to specify a new 940 Multicast Listener Option (MLO) as an addition to the 6LoWPAN-ND 941 [RFC6775] protocol communication that is anyway ongoing between a 942 6LoWPAN host and router(s). This MLO is preferably designed to be 943 maximally similar to the Address Registration Option (ARO), which 944 minimizes the need for additional program code on constrained nodes. 945 With an MLO, instead of registering a hosts's unicast IP address as 946 with ARO, a host "registers" its interest in a multicast IPv6 947 address. Unlike the ARO, multiple MLO can be used in the same ND 948 packet. A registration period is also defined in the MLO just like 949 in the ARO. MLO allows a host to persistently register as a listener 950 to IP multicast traffic and to avoid the overhead of periodic 951 multicast communication which is required for the regular MLD 952 protocol. 954 [ TBD: consider what aspects are needed/not needed for CoAP/LLN 955 applications. Will MLDv1 suffice? What to do with options like 956 'source specific' and include/exclude. Source-specific can also be 957 dealt with at the destination host by filtering? Do we need limits 958 on number of records per packet? Do we need a higher MLD reliability 959 setting - see the parameters in the MLD RFC ] 961 8.3.2. 6LBR Implementation 963 To support mixed backbone/LLN scenarios in CoAP group communication, 964 it is RECOMMENDED that a 6LowPAN Border Router (6LBR) will act in an 965 MLD Router role on the backbone link. If this is not possible then 966 the 6LBR SHOULD be configured to act as an MLD Multicast Address 967 Listener and/or MLD Snooper on the backbone link. 969 8.3.3. Backbone IP Multicast Infrastructure 971 For corporate/professional applications, most routing and switching 972 equipment that is currently on the market is IPv6 capable. For that 973 reason backbone infrastructure operating IPv4 only is considered out 974 of scope in this document, at least for the backbone network 975 segment(s) where IP multicast destinations are present. What is 976 still in scope is for example an IPv4-only HTTP client that wants to 977 send a group communication message via a HTTP-CoAP proxy as 978 considered in [I-D.castellani-core-advanced-http-mapping]. 980 The availability of, and requirements for, IP multicast support may 981 depend on the specific installation use case. For example, the 982 following cases may be relevant for new IP based building control 983 installations: 985 1. System deployed on existing IP (Ethernet/WiFi/...) 986 infrastructure, shared with existing IP devices (PCs) 988 2. Newly designed and deployed IP (Ethernet/WiFi/...) 989 infrastructure, to be shared with other IP devices (PCs) 991 3. Newly designed and deployed IP (Ethernet/WiFi/...) 992 infrastructure, exclusively used for building control. 994 Besides physical separation the building control backbone can be 995 separated from regular (PC) infrastructure by using a different VLAN. 996 A typical corporate installation will have many LAN switches and/or 997 routing switches, which pass through IP multicast traffic but on the 998 other hand do not support acting in the Router role of MLD/IGMP. 999 Perhaps for case 2) and 3) above it is acceptable to add a MLD/IGMP 1000 capable router somewhere in the network, while for case 1) this may 1001 not be the case. 1003 [TBD: consider the influence of WiFi based backbone networks. What 1004 if 6LBRs are at the same time also WiFi routers? What if 6LBRs have 1005 an Ethernet connection to legacy WiFI routers? Check if equivalent 1006 with Ethernet backbone.] 1008 9. Miscellaneous Topics 1010 This section collects miscellaneous text, topics or proposals related 1011 to CoAP group communication which do not directly fit into any of the 1012 preceding sections. 1014 9.1. CoAP Multicast and HTTP Unicast Interworking 1016 CoAP supports operation over UDP multicast, while HTTP does not. For 1017 use cases where it is required that CoAP group communication is 1018 initiated from an HTTP end-point, it would be advantageous if the 1019 HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group 1020 communication based on IP multicast. One possible way of operation 1021 of such HTTP-CoAP Proxy is illustrated in Figure 3. Note that this 1022 topic is covered in more detail in 1023 [I-D.castellani-core-advanced-http-mapping]. 1025 CoAP Mcast CoAP Mcast HTTP-CoAP HTTP 1026 Node 1 Rtr1 Node 2 Rtr2 Proxy Node 3 1027 | | | | | | 1028 |MLD REQUEST | | | | 1029 |(Join Group X) | | | | 1030 |--LL-->| | | | | 1031 | | |MLD REQUEST | | 1032 | | |(Join Group X) | | 1033 | | |--LL-->| | | 1034 | | | | | HTTP REQUEST | 1035 | | | | | (URI to | 1036 | | | | | unicast addr) | 1037 | | | | |< -----------------| 1038 | | | | | | 1039 | | | Resolve HTTP Request-Line URI | 1040 | | | to Group X multicast address | 1041 | | | | | | 1042 | CoAP REQUEST (to multicast addr)| | 1043 |< ------<---------<-------<------| | 1044 | | | | | | 1045 | | | | 1046 | (optional) CoAP RESPONSE(s) | | 1047 | |-------------->| | 1048 |-----------------|-------------->| Aggregated | 1049 | | | HTTP RESPONSE | 1050 | | |------------------>| 1051 | | | | 1053 Figure 3: CoAP Multicast and HTTP Unicast Interworking 1055 Note that Figure 3 illustrates the case of IP multicast as the 1056 underlying group communications mechanism. MLD denotes the Multicast 1057 Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a 1058 Link-Local multicast. 1060 A key point in Figure 3 is that the incoming HTTP Request (from node 1061 3) will carry a Host request-header field that resolves in the 1062 general Internet to the proxy node. At the proxy node, this hostname 1063 and/or the Request-Line URI will then possibly be mapped (as detailed 1064 in [I-D.castellani-core-advanced-http-mapping]) and again resolved 1065 (with the CoAP scheme) to an IP multicast address. This may be 1066 accomplished, for example, by using DNS or DNS-SD (Section 7). The 1067 proxy node will then IP multicast the CoAP Request (corresponding to 1068 the received HTTP Request) via multicast routers to the appropriate 1069 nodes (i.e. nodes 1 and 2). 1071 In terms of the HTTP Response, Figure 3 illustrates that it will be 1072 generated by the proxy node based on aggregated responses of the CoAP 1073 nodes and sent back to the client in the general Internet that sent 1074 the HTTP Request (i.e. node 1). In 1075 [I-D.castellani-core-advanced-http-mapping] the HTTP Response that 1076 the Proxy may use to aggregate multiple CoAP responses is described 1077 in more detail. So in terms of overall operation, the CoAP proxy can 1078 be considered to be a "non-transparent" proxy according to [RFC2616]. 1079 Specifically, [RFC2616] states that a "non-transparent proxy is a 1080 proxy that modifies the request or response in order to provide some 1081 added service to the user agent, such as group annotation services, 1082 media type transformation, protocol reduction or anonymity 1083 filtering." 1085 An alternative to the above is using a Forward Proxy. In this case, 1086 the CoAP request URI is carried in the HTTP Request-Line (as defined 1087 in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the 1088 IP address of the Proxy. 1090 10. Acknowledgements 1092 Thanks to all CoRE WG members who participated in the IETF 82 1093 discussions, which was the trigger to initiate this document. 1095 11. IANA Considerations 1097 This memo includes no request to IANA. 1099 12. Security Considerations 1101 The basic security aspects of group communication for CoAP are 1102 discussed in [I-D.ietf-core-groupcomm]. The DICE I-D 1103 [I-D.keoh-dice-multicast-security] takes as input many of the 1104 security requirements listed in Section 4.3 for proposing added DTLS 1105 protection for CoAP group communication. 1107 Some additional considerations for group communication security can 1108 be found in [RFC7258] which warns of the dangers of pervasive 1109 monitoring. CoAP group communication solutions built on IP multicast 1110 should pay particular heed to these dangers. This is because IP 1111 multicast is easier to intercept (e.g. and to secretly record) 1112 compared to unicast traffic. Also, CoAP traffic is meant for the 1113 Internet of Things. This means that CoAP traffic is often used for 1114 the control and monitoring of critical infrastructure (e.g. lights, 1115 alarms, etc.) 1117 For example, an attacker may want to record all the CoAP traffic 1118 going over the smart grid (electrical utility) of a country and try 1119 to determine critical control nodes. CoAP multicast traffic is 1120 inherently more vulnerable (compared to a unicast packet) as the same 1121 packet will be replicated over many links so there is a much higher 1122 probability of it getting captured by a pervasive monitoring system. 1123 Even if all the CoAP multicast traffic is protected via DTLS 1124 ([I-D.keoh-dice-multicast-security]), an attacker may attempt to 1125 capture the traffic and perform an off-line attack. Though of course 1126 having the multicast traffic protected is always desirable as it 1127 significantly raises the cost to an attacker (e.g. to break the 1128 encryption) versus unprotected multicast traffic. 1130 13. References 1132 13.1. Normative References 1134 [I-D.ietf-core-coap] 1135 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1136 Application Protocol (CoAP)", draft-ietf-core-coap-18 1137 (work in progress), June 2013. 1139 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1140 Requirement Levels", BCP 14, RFC 2119, March 1997. 1142 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1143 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1144 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1146 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 1147 Architecture", RFC 3740, March 2004. 1149 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1150 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1152 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 1153 "Multicast Security (MSEC) Group Key Management 1154 Architecture", RFC 4046, April 2005. 1156 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1157 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1158 Protocol Specification (Revised)", RFC 4601, August 2006. 1160 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1161 "Internet Group Management Protocol (IGMP) / Multicast 1162 Listener Discovery (MLD)-Based Multicast Forwarding 1163 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1165 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1166 "Transmission of IPv6 Packets over IEEE 802.15.4 1167 Networks", RFC 4944, September 2007. 1169 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 1170 Extensions to the Security Architecture for the Internet 1171 Protocol", RFC 5374, November 2008. 1173 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1174 "Building Automation Routing Requirements in Low-Power and 1175 Lossy Networks", RFC 5867, June 2010. 1177 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1178 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1179 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1180 Lossy Networks", RFC 6550, March 2012. 1182 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1183 the Internet Group Management Protocol (IGMP) and 1184 Multicast Listener Discovery (MLD) for Routers in Mobile 1185 and Wireless Networks", RFC 6636, May 2012. 1187 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1188 Format", RFC 6690, August 2012. 1190 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1191 "Neighbor Discovery Optimization for IPv6 over Low-Power 1192 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1193 November 2012. 1195 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1196 Attack", BCP 188, RFC 7258, May 2014. 1198 13.2. Informative References 1200 [Banerjee01] 1201 Banerjee, B. and B. Bhattacharjee, "A Comparative Study of 1202 Application Layer Multicast Protocols", 2001, 1203 . 1206 [I-D.castellani-core-advanced-http-mapping] 1207 Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1208 E. Dijk, "Guidelines for HTTP-CoAP Mapping 1209 Implementations", draft-castellani-core-advanced-http- 1210 mapping-03 (work in progress), December 2013. 1212 [I-D.cheshire-dnsext-dns-sd] 1213 Cheshire, S. and M. Krochmal, "DNS-Based Service 1214 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 1215 progress), December 2011. 1217 [I-D.eggert-core-congestion-control] 1218 Eggert, L., "Congestion Control for the Constrained 1219 Application Protocol (CoAP)", draft-eggert-core- 1220 congestion-control-01 (work in progress), January 2011. 1222 [I-D.ietf-6lowpan-routing-requirements] 1223 Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 1224 Statement and Requirements for 6LoWPAN Routing", draft- 1225 ietf-6lowpan-routing-requirements-10 (work in progress), 1226 November 2011. 1228 [I-D.ietf-core-block] 1229 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1230 draft-ietf-core-block-14 (work in progress), October 2013. 1232 [I-D.ietf-core-groupcomm] 1233 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1234 draft-ietf-core-groupcomm-18 (work in progress), December 1235 2013. 1237 [I-D.ietf-core-observe] 1238 Hartke, K., "Observing Resources in CoAP", draft-ietf- 1239 core-observe-13 (work in progress), April 2014. 1241 [I-D.ietf-roll-trickle-mcast] 1242 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 1243 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 1244 mcast-09 (work in progress), April 2014. 1246 [I-D.keoh-dice-multicast-security] 1247 Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. 1248 Rahman, "DTLS-based Multicast Security in Constrained 1249 Environments", draft-keoh-dice-multicast-security-07 (work 1250 in progress), May 2014. 1252 [I-D.lynn-core-discovery-mapping] 1253 Lynn, K. and Z. Shelby, "CoRE Link-Format to DNS-Based 1254 Service Discovery Mapping", draft-lynn-core-discovery- 1255 mapping-02 (work in progress), October 2012. 1257 [I-D.rahman-core-groupcomm] 1258 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1259 draft-rahman-core-groupcomm-07 (work in progress), October 1260 2011. 1262 [I-D.shelby-core-coap-req] 1263 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 1264 Kelsey, "CoAP Requirements and Features", draft-shelby- 1265 core-coap-req-02 (work in progress), October 2010. 1267 [I-D.shelby-core-resource-directory] 1268 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 1269 Directory", draft-shelby-core-resource-directory-05 (work 1270 in progress), February 2013. 1272 [I-D.vanderstok-core-bc] 1273 Stok, P. and K. Lynn, "CoAP Utilization for Building 1274 Control", draft-vanderstok-core-bc-05 (work in progress), 1275 October 2011. 1277 [I-D.vanderstok-core-dna] 1278 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 1279 Naming, and Addressing", draft-vanderstok-core-dna-02 1280 (work in progress), July 2012. 1282 [Lao05] Lao, L., Cui, J., Gerla, M., and D. Maggiorini, "A 1283 Comparative Study of Multicast Protocols: Top, Bottom, or 1284 In the Middle?", 2005, 1285 . 1288 Appendix A. Multicast Listener Discovery (MLD) 1290 In order to extend the scope of IP multicast beyond link-local scope, 1291 an IP multicast routing protocol has to be active in routers on an 1292 LLN. To achieve efficient multicast routing (i.e. avoid always 1293 flooding multicast IP packets), routers have to learn which hosts 1294 need to receive packets addressed to specific IP multicast 1295 destinations. 1297 The Multicast Listener Discovery (MLD) protocol [RFC3810] (or its 1298 IPv4 pendant IGMP) is today the method of choice used by an (IP 1299 multicast enabled) router to discover the presence of multicast 1300 listeners on directly attached links, and to discover which multicast 1301 addresses are of interest to those listening nodes. MLD was 1302 specifically designed to cope with fairly dynamic situations in which 1303 multicast listeners may join and leave at any time. 1305 IGMP/MLD Snooping is a technique implemented in some corporate LAN 1306 routing/switching devices. An MLD snooping switch listens to MLD 1307 State Change Report messages from MLD listeners on attached links. 1308 Based on this, the switch learns on what LAN segments there is 1309 interest for what IP multicast traffic. If the switch receives at 1310 some point an IP multicast packet, it uses the stored information to 1311 decide onto which LAN segment(s) to send the packet. This improves 1312 network efficiency compared to the regular behavior of forwarding 1313 every incoming multicast packet onto all LAN segments. An MLD 1314 snooping switch may also send out MLD Query messages (which is 1315 normally done by a device in MLD Router role) if no MLD Router is 1316 present. 1318 [RFC6636] discusses optimal tuning of the parameters of MLD for 1319 routers for mobile and wireless networks. These guidelines may be 1320 useful when implementing MLD in LLNs. 1322 Appendix B. CoAP-Observe Alternative to Group Communication 1324 The CoAP Observation extension [I-D.ietf-core-observe] can be used as 1325 a simple (but very limited) alternative for group communication. A 1326 group in this case consists of a CoAP server hosting a specific 1327 resource, plus all CoAP clients observing that resource. The server 1328 is the only group member that can send a group message. It does this 1329 by modifying the state of a resource under observation and 1330 subsequently notifying its observers of the change. Serial unicast 1331 is used for sending the notifications. This approach can be a simple 1332 alternative for networks where IP multicast is not available or too 1333 expensive. 1335 The CoAP-Observe approach is unreliable in the sense that, even 1336 though Confirmable CoAP messages may be used, there are no guarantees 1337 that an update will be received. For example, a client may believe 1338 it is observing a resource while in reality the server rebooted and 1339 lost its listener state. 1341 Authors' Addresses 1343 Esko Dijk (editor) 1344 Philips Research 1346 Email: esko.dijk@philips.com 1348 Akbar Rahman (editor) 1349 InterDigital Communications, LLC 1351 Email: Akbar.Rahman@InterDigital.com