RFC 7390
Group Communication for the Constrained Application Protocol (CoAP)
RFC 7390 💖
Group Communication for the Constrained Application Protocol (CoAP) 🎀
Okay so, this is RFC 7390, and the title is literally the whole vibe ✨ It was written by A. Rahman, Ed. (InterDigital Communications, LLC) and E. Dijk, Ed. (Philips Research), and it was published by the IETF in October 2014. Its category is Experimental, and its ISSN is 2070-1721 🧚 The header doesn't have any Obsoletes or Updates line, so it doesn't list any RFCs it obsoletes or updates.
Abstract 🌸
Bestie, CoAP is a specialized web transfer protocol built for constrained devices on constrained networks 🦋 Constrained devices will often naturally hang out in groups. In a building automation setup, for example, all the lights in one room might need to switch on or off together. This spec explains how CoAP should be used in a group communication context 💅 It details an approach for running CoAP on top of IP multicast, using the CoAP features that already exist plus some new ones added here. It also has a bunch of use cases and protocol flows to show the important ideas, and it finishes with guidance for deploying this across different network topologies 🔥
Status of This Memo 🎀
This document isn't an Internet Standards Track specification. It was published so people can examine it, try out experimental implementations, and evaluate it 👀
It defines an Experimental Protocol for the Internet community. The IETF produced it, and it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not everything the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 for that 💖
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7390 🧚
Copyright Notice 💜
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🌈 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Conventions and Terminology . . . . . . . . . . . . . . . 4
2. Protocol Considerations . . . . . . . . . . . . . . . . . . . 5
2.1. IP Multicast Background . . . . . . . . . . . . . . . . . 5
2.2. Group Definition and Naming . . . . . . . . . . . . . . . 6
2.3. Port and URI Configuration . . . . . . . . . . . . . . . 7
2.4. RESTful Methods . . . . . . . . . . . . . . . . . . . . . 9
2.5. Request and Response Model . . . . . . . . . . . . . . . 9
2.6. Membership Configuration . . . . . . . . . . . . . . . . 10
2.6.1. Background . . . . . . . . . . . . . . . . . . . . . 10
2.6.2. Membership Configuration RESTful Interface . . . . . 11
2.7. Request Acceptance and Response Suppression Rules . . . . 17
2.8. Congestion Control . . . . . . . . . . . . . . . . . . . 19
2.9. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 20
2.10. Exceptions . . . . . . . . . . . . . . . . . . . . . . . 21
3. Use Cases and Corresponding Protocol Flows . . . . . . . . . 22
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Network Configuration . . . . . . . . . . . . . . . . . . 22
3.3. Discovery of Resource Directory . . . . . . . . . . . . . 25
3.4. Lighting Control . . . . . . . . . . . . . . . . . . . . 26
3.5. Lighting Control in MLD-Enabled Network . . . . . . . . . 30
3.6. Commissioning the Network Based on Resource Directory . . 31
4. Deployment Guidelines . . . . . . . . . . . . . . . . . . . . 32
4.1. Target Network Topologies . . . . . . . . . . . . . . . . 32
4.2. Networks Using the MLD Protocol . . . . . . . . . . . . . 33
4.3. Networks Using RPL Multicast without MLD . . . . . . . . 33
4.4. Networks Using MPL Forwarding without MLD . . . . . . . . 34
4.5. 6LoWPAN Specific Guidelines for the 6LBR . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 35
5.1. Security Configuration . . . . . . . . . . . . . . . . . 35
5.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3. Threat Mitigation . . . . . . . . . . . . . . . . . . . . 36
5.3.1. WiFi Scenario . . . . . . . . . . . . . . . . . . . . 37
5.3.2. 6LoWPAN Scenario . . . . . . . . . . . . . . . . . . 37
5.3.3. Future Evolution . . . . . . . . . . . . . . . . . . 37
5.4. Monitoring Considerations . . . . . . . . . . . . . . . . 38
5.4.1. General Monitoring . . . . . . . . . . . . . . . . . 38
5.4.2. Pervasive Monitoring . . . . . . . . . . . . . . . . 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
6.1. New 'core.gp' Resource Type . . . . . . . . . . . . . . . 39
6.2. New 'coap-group+json' Internet Media Type . . . . . . . . 39
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Normative References . . . . . . . . . . . . . . . . . . 41
7.2. Informative References . . . . . . . . . . . . . . . . . 43
Appendix A. Multicast Listener Discovery (MLD) . . . . . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 461. Introduction ✨
1.1. Background
CoAP is a web transfer protocol based on Representational State Transfer (REST), made for resource constrained devices that run on an IP network [RFC7252]. It's got a lot in common with HTTP [RFC7230], but it also has some key differences 🍓 Constrained devices can come in huge numbers, and they're usually connected to each other by what they do or where they are. For example, every light switch in a building might be one group, and all the thermostats might be another. Groups can be set up ahead of time, before deployment, or they can form dynamically while things are running 🧚 When information needs to go to or come from a group of devices, group communication can improve efficiency and latency, and it can cut bandwidth needs for a given application. HTTP doesn't have any equivalent to CoAP group communication, which is kind of a big deal 💀
1.2. Scope
Group communication is a one-to-many relationship between CoAP endpoints 💖 To be specific, one CoAP client can get or set resources on multiple CoAP servers at the same time, using CoAP over IP multicast. Picture a CoAP light switch that turns a bunch of lights in a room on or off with one CoAP group communication PUT request, then deals with all the (unicast) responses that might come back 😭
The basic stuff, like sending CoAP requests over IP multicast and processing the (unicast IP) responses, is covered in Section 8 of [RFC7252]. To make group communication more complete, this specification adds new CoAP processing (such as new rules for reusing Token values, request suppression, and proxy operation) and a new management interface for RESTful group membership configuration 🫶
CoAP group communication runs in the Any Source Multicast (ASM) mode [RFC5110] of IP multicast operation. That means there's no restriction on which source node sends (originates) the CoAP messages to the IP multicast group. For example, the source node may or may not be part of the IP multicast group. And there's no limit on how many source nodes there can be 👑
Section 9.1 of [RFC7252] supports several DTLS-based security modes for CoAP over unicast IP, but it doesn't specify any security modes for CoAP over IP multicast. So, per [RFC7252], CoAP over IP multicast is assumed to be not encrypted, not authenticated, and not access controlled 🙈 This document assumes the same security model (see Section 5.1). Still, there are some promising security approaches being developed that should be considered in the future for protecting CoAP group communications (see Section 5.3.3) 🔮
1.3. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words aren't in ALL CAPS (like "should" or "Should"), they just have their usual English meanings and aren't [RFC2119] key words 💅
Also, this document refers back to other RFCs, especially [RFC7252], to help explain the overall CoAP group communication features. But using [RFC2119] key words is reserved for the new CoAP functionality this specification introduces 🎀
This document assumes you already know the terms and concepts used in [RFC7252]. On top of that, it defines the following terminology 🦋
Group Communication: A source node sends one application-layer (for example, CoAP) message that gets delivered to multiple destination nodes, and all the destinations are identified as belonging to a specific group. The source node itself may be part of the group. The underlying mechanisms for CoAP group communication are UDP/IP multicast for the requests and unicast UDP/IP for the responses. The network involved may be a constrained network, like a low-power, lossy network 🌈
Reliable Group Communication: A special case of group communication where, for each destination node, it's guaranteed that the node either 1) eventually receives the message sent by the source node or 2) doesn't receive the message and the source node gets notified of the non-reception event. An example of a reliable group communication protocol is [RFC5740] ⭐
Multicast: Sending a message to multiple destination nodes with one network invocation. There are various ways to implement multicast, including layer 2 (Media Access Control) and layer 3 (IP) mechanisms 💜
IP Multicast: A specific multicast approach based on IP multicast addresses, as defined in "IANA Guidelines for IPv4 Multicast Address Assignments" [RFC5771] and "IP Version 6 Addressing Architecture" [RFC4291]. A complete IP multicast solution may include support for managing group memberships and IP multicast routing/forwarding (see Section 2.1) 🧚
Low-Power and Lossy Network (LLN): A type of constrained IP network where devices are interconnected by low-power and lossy links. The links may be made of one or more technologies, such as IEEE 802.15.4, Bluetooth Low Energy (BLE), Digital Enhanced Cordless Telecommunication (DECT), and IEEE P1901.2 power-line communication 🍓
2. Protocol Considerations ✨
2.1. IP Multicast Background
okay so IP multicast has been evolving for decades 🦋 and you've got standards like Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] 💅. It's literally everywhere: enterprise networks (video conferencing, anyone?), smart home stuff like Universal Plug and Play (UPnP), and carrier IPTV. The packet economy and minimal host complexity make it super attractive for group communication in constrained environments 🌸.
To get IP multicast working beyond link-local (LL) scope, an IP multicast routing or forwarding protocol has to be active on IP routers 👑. For LLNs, the routing one is the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) (Section 12 of [RFC6550]), and the forwarding one is the Multicast Protocol for Low-Power and Lossy Networks (MPL) [MCAST-MPL]. RPL and MPL don't depend on each other. Each can be used in isolation, and both can be used together in a network 🫶. PIM-SM [RFC4601] is often used for multicast routing in traditional IP networks (i.e., networks that are not constrained).
IP multicast can also run in an LL scope. That means no routing is involved, and an IP multicast message is only received over the link on which it was sent 🧚.
For a complete IP multicast solution, you need more than a routing/forwarding protocol. A "listener" protocol may be needed so devices can subscribe to groups (see Section 4.2). Also, a multicast forwarding proxy node [RFC4605] may be required 🍓.
IP multicast is generally classified as an unreliable service, because packets are not guaranteed to be delivered to each and every member of the group 😭. So it can't be directly used as a basis for "reliable group communication" as defined in Section 1.3. The level of reliability can be increased, though, by using a multicast protocol that performs periodic retransmissions, as MPL does, for example 💖.
2.2. Group Definition and Naming
A CoAP group is a set of CoAP endpoints, where each endpoint is configured to receive CoAP group communication requests sent to the group's associated IP multicast address ✨. Each endpoint responds to a request individually, and that response is always sent back as unicast. An endpoint can be a member of multiple groups, and its group membership can dynamically change over time 🎀.
All CoAP server nodes SHOULD join the "All CoAP Nodes" multicast group (Section 12.8 of [RFC7252]) by default to enable CoAP discovery 🔥. For IPv4, the address is 224.0.1.187. For IPv6, a server node joins at least both the link-local scoped address ff02::fd and the site-local scoped address ff05::fd. IPv6 addresses of other scopes MAY be enabled 🌈.
A CoAP group URI has the scheme 'coap' and includes, in the authority part, either a group IP multicast address or a hostname (e.g., Group Fully Qualified Domain Name (FQDN)) that can be resolved to the group IP multicast address. A group URI also contains an optional CoAP port number in the authority part. Group URIs follow the regular CoAP URI syntax (Section 6 of [RFC7252]) 🌸.
Note: A group URI is needed to initiate CoAP group communications. For CoAP client implementations, it is recommended to use the URI decomposition method of Section 6.4 of [RFC7252] in such a way that a CoAP group communication request is generated from a group URI 💅.
For sending nodes, it is recommended to use the IP multicast address literal in a group URI. (This is because DNS infrastructure may not be deployed in many constrained network deployments 🙈.) However, if a group hostname is used, it can be uniquely mapped to an IP multicast address via DNS resolution (if supported). Here are some examples of hierarchical group FQDN naming (and scoping) for a building control application 🏢:
URI authority Targeted group of nodes
--------------------------------------- --------------------------
all.bldg6.example.com "all nodes in building 6"
all.west.bldg6.example.com "all nodes in west wing,
building 6"
all.floor1.west.bldg6.example.com "all nodes in floor 1,
west wing, building 6"
all.bu036.floor1.west.bldg6.example.com "all nodes in office bu036,
floor 1, west wing,
building 6"Similarly, if supported, reverse mapping (from IP multicast address to Group FQDN) is possible using the reverse DNS resolution technique ([RFC1033]). Reverse mapping is important, for example, in troubleshooting, where you translate IP multicast addresses back into human-readable hostnames to show in a diagnostics user interface 🔍.
2.3. Port and URI Configuration
A CoAP server that is a member of a group listens for CoAP messages on the group's IP multicast address, usually on the CoAP default UDP port, 5683 🎀. If the group uses a specified non-default UDP port, be careful to make sure all group members are configured to use that same port 👀.
Different ports for the same IP multicast address are preferably not used to specify different CoAP groups. If disjoint groups share the same IP multicast address, then all the devices interested in one group will accept IP traffic meant for the other disjoint groups too, only to discard it higher up in their IP stack (based on UDP port discrimination) 🙃.
CoAP group communication will not work if there is diversity in the authority port (e.g., different dynamic port addresses across the group), or if other parts of the group URI, such as the path or the query, differ on different endpoints. So some measures must be present to ensure uniformity in port number and resource names/locations within a group 🧩. All CoAP group communication requests MUST be sent using a port number according to one of the options below:
- A preconfigured port number.
- If the client is configured to use service discovery including URI and port discovery, it uses the port number obtained via a service discovery lookup operation for the targeted CoAP group.
- Use the default CoAP UDP port (5683).
For a CoAP server node that supports resource discovery, the default port 5683 must be supported (Section 7.1 of [RFC7252]) for the "All CoAP Nodes" group. Regardless of the method used to select the port number, the same port MUST be used across all CoAP servers in a group and across all CoAP clients performing the group requests 💜.
All CoAP group communication requests SHOULD operate on group URI paths in one of the following ways:
- Preconfigured group URI paths, if available. Implementers are free to define the paths as they see fit. However, note that [RFC7320] prescribes that a specification must not constrain or define the structure or semantics for any path component. So for this reason, a predefined URI path is not specified in this document and also must not be provided in other specifications 📜.
- If the client is configured to use default Constrained RESTful Environments (CoRE) resource discovery, it uses URI paths retrieved from a "/.well-known/core" lookup on a group member. The URI paths the client will use MUST be known to be available also in all other endpoints in the group. The URI path configuration mechanism on servers MUST ensure that these URIs (identified as being supported by the group) are configured on all group endpoints 🫶.
- If the client is configured to use another form of service discovery, it uses group URI paths from an equivalent service discovery lookup that returns the resources supported by all group members.
- If the client has received a group URI through a previous RESTful interaction with a trusted server, it can use this URI in a CoAP group communication request. For example, a commissioning tool may instruct a sensor device in this way about which target group (group URI) it should report sensor events to 🌷.
However, whichever URI path is selected, the same path MUST be used across all CoAP servers in a group and all CoAP clients performing the group requests 🔐.
2.4. RESTful Methods
Group communication most often uses the idempotent CoAP methods GET and PUT 🍃. The idempotent method DELETE can also be used. The non-idempotent CoAP method POST may only be used for group communication if the resource being POSTed to has been designed to cope with the unreliable and lossy nature of IP multicast. For example, a client may resend a multicast POST request for additional reliability. Some servers will receive the request two times while others may receive it only once. For idempotent methods, all these servers will end up in the same state, but for POST this is not guaranteed, so the resource POST operation must be specifically designed to take message loss into account 🫠.
2. Protocol Considerations
2.5. Request and Response Model ✨
Okay so rule number one: every CoAP request sent over IP multicast must be Non-confirmable 🫶 (Section 8.1 of [RFC7252]). The Message ID in a multicast CoAP message is used for optional message deduplication, and you can read all about that in Section 4.5 of [RFC7252] 🍓
A server can optionally send a unicast response back to a CoAP group request, like a "2.05 Content" reply to a group GET 💖 The unicast responses a client gets back might be a mix of success codes (like 2.05 Content) and failure codes (like 4.04 Not Found), because every server processes things on its own 💅 The detailed rules for accepting multicast requests and suppressing unicast responses are in Section 2.7 ✨
A CoAP request sent over IP multicast, plus any unicast response it causes, must take the congestion control rules from Section 2.8 into account 🦋
A client can tell which server responded by the source IP address of the UDP message carrying the CoAP response, or by any other unique identifier (like something in the CoAP payload) 👑 If a client sent multiple group requests, responses still get matched to the right request using the CoAP Token 🧚
Here's the tea 🫖 Token reuse is trickier for multicast than for unicast. In unicast, getting a response basically frees up the Token, because no more responses are coming. But with multicast, the number of responses isn't capped ahead of time, so getting one response can't be your green light to "free up" a Token 💀 Reusing a Token too early could mess up response/request matching on the client, and that's a protocol error, not a vibe. So the time between reusing Token values for multicast requests MUST be greater than:
NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAYwhere NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of [RFC7252]. MAX_SERVER_RESPONSE_DELAY is defined here as the expected maximum response delay across all the servers a client can send a multicast request to. That delay includes the maximum Leisure time period from Section 8.2 of [RFC7252]. CoAP doesn't set a time limit for server response delay, so it's on you to think about it 🙈
With the default CoAP parameters, the Token reuse time MUST be greater than 250 seconds plus MAX_SERVER_RESPONSE_DELAY. The preferred move is to generate a brand new unique Token for every multicast request, so a Token is never reused at all 🌈 If a client has to reuse Tokens for some reason, and MAX_SERVER_RESPONSE_DELAY is unknown, then MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline. In that case, the time between Token reuses is set to a value greater than 500 seconds ⭐
2.6. Membership Configuration 🌸
2.6.1. Background
2.6.1.1. Member Discovery
Okay, so CoAP groups, and who's in them, can be discovered through the lookup interfaces in the Resource Directory (RD) defined in [CoRE-RD] 🧚 You don't need this discovery interface to invoke CoAP group communications, but it's a potentially useful complementary interface for managing CoAP groups overall. Other ways to discover groups, like proprietary management systems, work too. An example of doing some of the RD-based lookups is given in Section 3.6 💜
2.6.1.2. Configuring Members
There are three ways a CoAP endpoint can get its group membership configured, bestie 🎀 First, the membership can be preconfigured before the node gets deployed. Second, a node can be programmed to discover (query) its own group membership using a specific service discovery means. Third, another node (like a commissioning device) can configure it.
For the first one, the preconfigured group info might be an IP multicast address, or a hostname (FQDN) that the endpoint resolves later, during operation, to an IP multicast address using DNS (if supported) 🍓
For the second one, a CoAP endpoint can look up its group membership using techniques like DNS-based Service Discovery (DNS-SD) and RD [CoRE-RD] 🔍
For the third one, which is typical in scenarios like building control, a dynamic commissioning tool figures out which group(s) a sensor or actuator node belongs to, then writes that info to the node. The node can then join the correct IP multicast group(s) on its network interface 🦋 The info written per group can again be an IP multicast address or a hostname.
2.6.2. Membership Configuration RESTful Interface
Endpoints from different manufacturers need to play nicely, so an OPTIONAL CoAP membership configuration RESTful interface is described here for configuring endpoints with the relevant group information 🫶 This covers the third case from above. To use this interface, a client uses unicast CoAP methods (GET/PUT/POST/DELETE). It's a way of configuring group info on individual endpoints.
Also, some form of authorization should be used (preferably unicast DTLS-secured CoAP per Section 9.1 of [RFC7252]) so that only authorized controllers can configure an endpoint's group membership 🔐
It's important to note that other approaches may be used to configure CoAP endpoints with the relevant group information 👑 These alternatives may support a subset or a superset of the membership configuration RESTful interface described in this document. For example, a simple interface that just reads the endpoint's group info could be built with a classical Management Information Base (MIB) approach, like the one in [RFC3433] 💅
2.6.2.1. CoAP-Group Resource Type and Media Type
CoAP endpoints implementing the membership configuration RESTful interface MUST support the CoAP group configuration Internet Media Type application/coap-group+json (Section 6.2) 🎀
A resource offering this representation can be annotated for direct discovery [RFC6690] using the Resource Type (rt=) Link Target Attribute core.gp, where gp is shorthand for "group" (Section 6.1) ✨ An authorized client uses this media type to query or manage a CoAP endpoint's group membership, as covered in the following subsections.
The Group Configuration resource and its sub-resources have a content format based on JavaScript Object Notation (JSON), as indicated by the application/coap-group+json media type 🌈 The resource includes zero or more group membership JSON objects [RFC7159], in the format defined in Section 2.6.2.4. Each group membership JSON object has one or more key/value pairs (defined below) and represents a single IP multicast group membership for the CoAP endpoint. Each key/value pair is encoded as a member of the JSON object, where the key is the member name and the value is the member's value 🧁
Here are four different group membership objects, bestie:
{ "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
{ "n": "sensors.floor2.east.bldg6.example.com" }
{ "n": "coap-test",
"a": "224.0.1.187:56789" }
{ "a": "[ff15::c0a7:15:c001]" }The OPTIONAL "n" key/value pair stands for "name" and identifies the group with a hostname (and optionally a port number), like an FQDN 🌸 The OPTIONAL "a" key/value pair specifies the IP multicast address (and optionally a port number) of the group. It holds either an IPv4 address (in dotted-decimal notation) or an IPv6 address. You can parse the address with the following ABNF rule, which refers to the definitions in Section 3.2.2 of [RFC3986] that are also used in the base CoAP (Section 6 of [RFC7252]):
group-address = IPv4address [ ":" port ]
/ "[" IPv6address "]" [":" port ]In any group membership object, if the IP address is known when the object is created, it goes in the "a" key/value pair. If the "a" value can't be provided, then the "n" value MUST be included, containing a valid hostname with an optional port number that can be translated to an IP multicast address via DNS 🔥
group-name = host [ ":" port ]If the port number isn't provided, the endpoint will try to look up the port number from DNS, as long as it supports a method to do that. The possible DNS methods include DNS SRV [RFC2782] or DNS-SD [RFC6763]. If port lookup isn't supported or isn't provided by DNS, the default CoAP port (5683) is assumed 🧚
After any change on a Group Configuration resource, the endpoint MUST effect registration/deregistration from the corresponding IP multicast group(s), using APIs such as IPV6_RECVPKTINFO [RFC3542] 💖
2.6.2.2. Creating a New Multicast Group Membership (POST)
Method: POST
URI Template: /{+gp}
Location-URI Template: /{+gp}/{index}
URI Template Variables:
gp - Group Configuration Function Set path (mandatory).
index - Group index. Index MUST be a string of maximum two (2)
alphanumeric ASCII characters (case insensitive). It MUST be
locally unique to the endpoint server. It indexes the particular
endpoint's list of group memberships.
Example:
Req: POST /coap-group
Content-Format: application/coap-group+json
{ "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
Res: 2.01 Created
Location-Path: /coap-group/12Okay, the index variable is where it gets picky 🙈 It MUST be a string of at most two (2) alphanumeric ASCII characters (case insensitive), and it MUST be locally unique to the endpoint server. It's what indexes that particular endpoint's list of group memberships 🫶
For the gp variable, it is recommended to use the path coap-group by default 🍓 The "a" key/value pair is always used if it's given. The "n" pair is only used when there's no "a" pair. If only the "n" pair is given, the CoAP endpoint does DNS resolution to get the IP multicast address from the hostname in "n". If DNS resolution isn't successful, then the endpoint doesn't attempt joining or listening to any multicast group for that case, since the IP multicast address is unknown 😭
After any change on a Group Configuration resource, the endpoint MUST effect registration/deregistration from the corresponding IP multicast group(s), using APIs such as IPV6_RECVPKTINFO [RFC3542] 💅 When a POST payload contains an "a", which is an IP multicast address the endpoint is already subscribed to, no change to that subscription is needed ✨
2.6.2.3. Deleting a Single Group Membership (DELETE)
Method: DELETE
URI Template: {+location}
URI Template Variables:
location - The Location-Path returned by the CoAP server
as a result of a successful group creation.
Example:
Req: DELETE /coap-group/12
Res: 2.02 DeletedDeleting is the easy part, periodt 💅 You pass in the location, which is the Location-Path the CoAP server gave back when the group was successfully created, and the server replies with 2.02 Deleted 🦋
2.6.2.4. Reading All Group Memberships at Once (GET) ✨
Okay bestie, a unicast GET on the CoAP-group resource gives you back a JSON object full of keys and values 💅. The keys are the member names (aka group indices), and the values are the matching group membership objects. Each group membership object describes one IP multicast group membership 🦋. If nothing is configured, you just get an empty JSON object back 🫶
- Method:
GET - URI Template:
/{+gp} - URI Template Variables:
gp- see Section 2.6.2.2
Example:
Req: GET /coap-group
Res: 2.05 Content
Content-Format: application/coap-group+json
{ "8" :{ "a": "[ff15::4200:f7fe:ed37:14ca]" },
"11":{ "n": "sensors.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:25cb]" },
"12":{ "n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567" }
}Heads up 🙈 The IPv6 address string you get back represents the same address you submitted when you created the membership. It might look a little different though, because IPv6 has more than one allowed way to format the same address (see [RFC5952]).
2.6.2.5. Reading a Single Group Membership (GET) 🍓
This is basically Section 2.6.2.4, except you only read one group membership 🧚. If the group index you asked for doesn't exist, you get a 4.04 Not Found response 💀
- Method:
GET - URI Template 1:
{+location} - URI Template 2:
/{+gp}/{index} - URI Template Variables:
location- see Section 2.6.2.3gp,index- see Section 2.6.2.2
Example:
Req: GET /coap-group/12
Res: 2.05 Content
Content-Format: application/coap-group+json
{"n": "All-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]:4567"}2.6.2.6. Creating/Updating All Group Memberships at Once (PUT) 👑
A unicast PUT with a group configuration media type as the payload replaces all the current group memberships on the endpoint with the new ones in the request 🌸. This operation MUST only be used to delete or update group membership objects that the CoAP client invoking it is responsible for. Whether you're responsible is based on application-level knowledge. For example, a commissioning tool is responsible for any group membership objects it created 🔥
- Method:
PUT - URI Template:
/{+gp} - URI Template Variables:
gp- see Section 2.6.2.2
Example (replacing all existing group memberships with two new group memberships):
Example: (replacing all existing group memberships with two new
group memberships)
Req: PUT /coap-group
Content-Format: application/coap-group+json
{ "1":{ "a": "[ff15::4200:f7fe:ed37:1234]" },
"2":{ "a": "[ff15::4200:f7fe:ed37:5678]" }
}
Res: 2.04 ChangedExample (clearing all group memberships at once):
Example: (clearing all group memberships at once)
Req: PUT /coap-group
Content-Format: application/coap-group+json
{}
Res: 2.04 ChangedAfter a successful PUT on the Group Configuration resource, the endpoint MUST effect registration to any new IP multicast group(s) and deregistration from any previous IP multicast group(s), meaning any that are no longer present in the new memberships 🦋. An API such as IPV6_RECVPKTINFO [RFC3542] SHOULD be used for this purpose ✨ Also, the endpoint MUST take into account the group indices present in the new resource when it generates any new unique group indices in the future 💜
2.6.2.7. Updating a Single Group Membership (PUT) 🎀
A unicast PUT with a group membership JSON object replaces an existing group membership on the endpoint with the new one in the request. You can use this to update a group membership 💖
- Method:
PUT - URI Template 1:
{+location} - URI Template 2:
/{+gp}/{index} - URI Template Variables:
location- see Section 2.6.2.3gp,index- see Section 2.6.2.2
Example (group name and IP multicast port change):
Example: (group name and IP multicast port change)
Req: PUT /coap-group/12
Content-Format: application/coap-group+json
{"n": "All-My-Devices.floor1.west.bldg6.example.com",
"a": "[ff15::4200:f7fe:ed37:abcd]"}
Res: 2.04 ChangedAfter a successful PUT on the Group Configuration resource, the endpoint MUST effect registration to any new IP multicast group(s) and deregistration from any previous IP multicast group(s), meaning any that are no longer present in the new membership 🌈 An API such as IPV6_RECVPKTINFO [RFC3542] SHOULD be used for this purpose 💅
2.7. Request Acceptance and Response Suppression Rules 🦋
CoRE Link Format [RFC6690] and Section 8 of CoAP [RFC7252] define behaviors for the following:
- IP multicast request acceptance: in which cases a CoAP request is accepted and executed, and when it is not.
- IP multicast response suppression: in which cases the CoAP response to an already executed request is returned to the requesting endpoint, and when it is not.
A CoAP response is not the same thing as a CoAP ACK 🙈 Servers never send ACKs in response to an IP multicast CoAP request. This section summarizes these behaviors first, then gives extra guidelines for response suppression. A bunch of IP multicast example applications are also included to show how the whole approach works 🧚
To apply any rules for request and/or response suppression, a CoAP server MUST be aware that an incoming request arrived via IP multicast, which it can find out by using APIs such as IPV6_RECVPKTINFO [RFC3542] 👑
For IP multicast request acceptance, the behaviors are:
- A server SHOULD NOT accept an IP multicast request that cannot be "authenticated" in some way (i.e, cryptographically or by some multicast boundary limiting the potential sources); see Section 11.3 of [RFC7252]. See Section 5.3 for examples of multicast boundary limiting methods 🔒
- A server SHOULD NOT accept an IP multicast discovery request with a query string (as defined in CoRE Link Format [RFC6690]) if filtering [RFC6690] is not supported by the server 🫶
- A server SHOULD NOT accept an IP multicast request that acts on a specific resource for which IP multicast support is not required. (Note that for the resource "/.well-known/core", IP multicast support is required if "multicast resource discovery" is supported as specified in Section 1.2.1 of [RFC6690].) Implementers are advised to disable IP multicast support by default on any other resource, until explicitly enabled by an application or by configuration 💀
- Otherwise, accept the IP multicast request ✨
For IP multicast response suppression, the behaviors are:
- A server SHOULD NOT respond to an IP multicast discovery request if the filter specified by the request's query string does not match 🙈
- A server MAY choose not to respond to an IP multicast request if there's nothing useful to respond back (e.g., error or empty response) 🌸
The response suppression behaviors above come with these extra guidelines. CoAP servers SHOULD implement configurable response suppression, enabling at least the following options per resource that supports IP multicast requests:
- Suppression of all 2.xx success responses;
- Suppression of all 4.xx client errors;
- Suppression of all 5.xx server errors; and
- Suppression of all 2.05 responses with empty payload.
Here's how CoAP group communication example applications use response suppression 💅
- CoAP resource discovery: Suppress 2.05 responses with empty payload and all 4.xx and 5.xx errors.
- Lighting control: Suppress all 2.xx responses after a lighting change command.
- Update configuration data in a group of devices using group communication PUT: No suppression at all. The client uses collected responses to identify which group members did not receive the new configuration and then attempts using CoAP CON unicast to update those specific group members. Note that in this case, the client implements a "reliable group communication" (as defined in Section 1.3) function using additional, non-standardized functions above the CoAP layer 🧚
- IP multicast firmware update by sending blocks of data: Suppress all 2.xx and 5.xx responses. After having sent all IP multicast blocks, the client checks each endpoint by unicast to identify which data blocks are still missing in each endpoint 🔥
- Conditional reporting for a group (e.g., sensors) based on a group URI query: Suppress all 2.05 responses with empty payload (i.e., if a query produces no matching results) 🍓
2.8. Congestion Control 🌊
CoAP group communication requests may result in a multitude of responses from different nodes, which could cause congestion 😭 So both sending IP multicast requests and sending the unicast CoAP responses to those multicast requests SHOULD be conservatively controlled 🫶
CoAP [RFC7252] reduces IP multicast-specific congestion risks through these measures:
- A server MAY choose not to respond to an IP multicast request if there's nothing useful to respond to (e.g., error or empty response); see Section 8.2 of [RFC7252]. See Section 2.7 for more detailed guidelines on response suppression 🌸
- A server SHOULD limit the support for IP multicast requests to specific resources where multicast operation is required (Section 11.3 of [RFC7252]) 🎀
- An IP multicast request MUST be Non-confirmable (Section 8.1 of [RFC7252]) 🔒
- A response to an IP multicast request SHOULD be Non-confirmable (Section 5.2.3 of [RFC7252]) 💖
- A server does not respond immediately to an IP multicast request and SHOULD first wait for a time that is randomly picked within a predetermined time interval called the Leisure (Section 8.2 of [RFC7252]) ⭐
Extra guidelines from this document for reducing congestion risks:
- A server in an LLN SHOULD only support group communication GET for resources that are small. For example, the payload of the response is limited to approximately 5% of the IP Maximum Transmit Unit (MTU) size, so it fits into a single link-layer frame in case IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see Section 4 of [RFC4944]) is used 🧚
- A server can minimize the payload length in response to a group communication GET on "/.well-known/core" by using hierarchy in arranging link descriptions for the response. An example of this is given in Section 5 of [RFC6690] 🦋
- A server can also minimize the payload length of a response to a group communication GET (e.g., on "/.well-known/core") using CoAP blockwise transfers [BLOCKWISE-CoAP], returning only a first block of the CoRE Link Format description. For this reason, a CoAP client sending an IP multicast CoAP request to "/.well-known/core" SHOULD support core-block 💅
- A client SHOULD use CoAP group communication with the smallest possible IP multicast scope that fulfills the application needs. As an example, site-local scope is always preferred over global scope IP multicast if this fulfills the application needs. Similarly, realm-local scope is always preferred over site-local scope if this fulfills the application needs 👑
More guidelines specific to the use of CoAP in 6LoWPAN networks [RFC4919] are given in Section 4.5 of this document 🌈
2.9. Proxy Operation 🎀
okay so CoAP (Section 5.7.2 of [RFC7252]) lets a client ask a forward-proxy to handle its CoAP request for it 🧚. The client either puts the request group URI as a string in the Proxy-URI option, or uses the Proxy-Scheme option with the group URI built from the usual Uri-* options. This works totally fine for unicast requests 💖. The problem is when a group communication request goes through a proxy like this, because handling the (unicast) responses gets messy 😭.
A proxy could collect every individual (unicast) response to a CoAP group communication request and then send the client just one (aggregated) response 📦. But this has some issues:
- Aggregating (unicast) responses in a proxy is hard 💀. The proxy doesn't know how many members are in the group, or how many of them will actually respond. It also doesn't know how long to wait before deciding it's time to send the aggregated response back to the client.
- CoAP doesn't define a default format for squishing multiple responses into one single response 🙈.
Or, if a proxy sticks strictly to the rules for a CoAP Proxy (Section 5.7.2 of [RFC7252]), it would just forward every individual (unicast) response to the client, with no aggregation at all ✨. This has issues too:
- The client might get confused, since it may not have known that the
Proxy-URIpointed to a group URI target 😵. It might be expecting just one (unicast) response and suddenly get multiple, which could lead to fault conditions in the application 🚨. - Each individual CoAP response shows up as coming from the CoAP Proxy (IP source address), not from the server that actually produced it 👻. So the client has no way to figure out which server sent which response 💅.
Because of all this, a CoAP Proxy SHOULD NOT support processing an IP multicast CoAP request, and should instead return a 501 (Not Implemented) response in that case 🙅♀️. There IS an exception where the proxy can process it, but only if ALL of the following conditions are met 👑:
- The CoAP Proxy MUST be explicitly configured (whitelist) to allow proxied IP multicast requests from a specific client(s) 🔐.
- The proxy SHOULD return individual (unicast) CoAP responses to the client (i.e., not aggregated) 📬. The only exception to that is when a (future) standardized aggregation format is being used ⭐.
- It MUST be known to the person or entity doing the proxy's configuration, or verified in some way, that the client on the whitelist supports receiving multiple responses to a proxied unicast CoAP request 🫶.
2.10. Exceptions 🦋
CoAP group communication using IP multicast is seriously efficient and fast, and it has other perks too 🚀. But group communication isn't always doable on every network 🥺. The main reason is that IP multicast just isn't (fully) supported on the network.
For example, say only RPL [RFC6550] is running on a network, and its optional multicast support is turned off. Then there's no IP multicast routing at all 😭. The only multicast that works here is link-local IPv6 multicast. That means any CoAP group communication request only reaches nodes on the local link, no matter what scope value is used in the IPv6 destination address 📍.
CoAP Observe [OBSERVE-CoAP] is a feature that lets a client "observe" resources (basically, it gets a representation of a resource and the server keeps that representation updated over time) 👀. CoAP Observe does NOT support group communication mode 🙅♀️. It only works in unicast mode, period 💅.
3. Use Cases and Corresponding Protocol Flows 🌈
3.1. Introduction 🧚
Here's where we see CoAP group communication in action, through these two use cases and their protocol flows 🎬:
- Discovery of RD [CoRE-RD]: finding the local CoAP RD, which holds links to resources stored on other CoAP servers [RFC6690] 🔍.
- Lighting Control: synchronous operation of a group of IPv6-connected lights (e.g., 6LoWPAN [RFC4944] lights) 💡✨.
3.2. Network Configuration 🏠
To make these use cases make sense, we define two IPv6 network configurations 🫶. Both are built on the topology shown in Figure 1, and the two configurations are:
- Subnets are 6LoWPAN networks, and the routers Rtr-1 and Rtr-2 are 6LoWPAN Border Routers (6LBRs) [RFC6775] 🦋.
- Subnets are Ethernet links, and the routers Rtr-1 and Rtr-2 are multicast-capable Ethernet routers 🌸.
Both configurations also come with these details 💜:
- A big room (Room-A) with three lights (Light-1, Light-2, Light-3) controlled by a light switch (Light Switch) 💡. The devices are split into two subnets. In real life there could be way more lights (up to several hundreds!), but we only show three here for clarity 🙈.
- Light-1 and the light switch are connected to a router (Rtr-1) 🔌.
- Light-2 and Light-3 are connected to another router (Rtr-2) 🔌.
- The routers are connected to an IPv6 network backbone (Network Backbone) that is also multicast enabled 🌐. In the general case, that means the network backbone and Rtr-1/Rtr-2 support a PIM-based multicast routing protocol and Multicast Listener Discovery (MLD) for forming groups 🧠.
- A CoAP RD is connected to the network backbone 🗂️.
- The DNS server (DNS Server) is optional 🤷♀️. If it IS there (connected to the network backbone), then certain DNS-based features are available, like DNS resolution of the hostname to the IP multicast address 🪄. If it's NOT there, then the network needs different provisioning, e.g., IP multicast addresses are hard-coded into devices, manually configured, or obtained via a service discovery method 🛠️.
- A controller (CoAP client) is connected to the backbone, and it's able to control various building functions, including lighting 🎛️💅.
################################################
# ********************** Room-A #
# ** Subnet-1 ** # Network
# * ** # Backbone
# * +----------+ * # |
# * | Light |-------+ * # |
# * | Switch | | * # |
# * +----------+ +---------+ * # |
# * | Rtr-1 |-----------------------------+
# * +---------+ * # |
# * +----------+ | * # |
# * | Light-1 |--------+ * # |
# * +----------+ * # |
# ** ** # |
# ************************** # |
# # |
# ********************** # +------------+ |
# ** Subnet-2 ** # | DNS Server | |
# * ** # | (Optional) |--+
# * +----------+ * # +------------+ |
# * | Light-2 |-------+ * # |
# * | | | * # |
# * +----------+ +---------+ * # |
# * | Rtr-2 |-----------------------------+
# * +---------+ * # |
# * +----------+ | * # |
# * | Light-3 |--------+ * # |
# * +----------+ * # +------------+ |
# ** ** # | Controller |--+
# ************************** # | Client | |
################################################ +------------+ |
+------------+ |
| CoAP | |
| Resource |-----------------+
| Directory |
+------------+
Figure 1: Network Topology of a Large Room (Room-A)3.3. Discovery of Resource Directory ✨
okay bestie, so here's how the CoAP RD gets found for the network in Figure 1 🦋 The whole protocol flow is in Figure 2:
- Light-2 is installed and powered on for the first time 💡
- Then Light-2 searches for the local CoAP RD by sending out a group communication GET request (with the "/.well-known/core?rt=core.rd" request URI) to the site-local "All CoAP Nodes" multicast address (ff05:::fd) 🔍
- That multicast message goes to each node in Subnet-2. Rtr-2 forwards it into the network backbone, where the CoAP RD receives it. All the other nodes in Subnet-2 ignore the group communication GET request because it's qualified by the query string "?rt=core.rd" (which means it should only be processed by the endpoint if it has a resource of type "core.rd") 🙈
- The CoAP RD sends back a unicast response with the requested content, which is a CoRE Link Format representation of a resource of type "core.rd" 💌
- Note that the flow is only shown for Light-2 for clarity. Similar flows happen for Light-1, Light-3, and the light switch when they're first installed 👀
The CoAP RD may also be discovered by other means, like assuming a default location (e.g., on a 6LBR), using DHCP, or an anycast address, etc. 🌸 But these approaches don't invoke CoAP group communication, so we won't dig into them here. (See [CoRE-RD] for more details.)
For other discovery use cases, like finding local CoAP servers, services, or resources, CoAP group communication can be used in a similar way to the use case above. For example, link-local, realm-local, admin-local, or site-local scoped discovery can be done this way ✨
Light CoAP
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 RD
| | | | | | |
| | | | | | |
********************************** | | |
* Light-2 is installed * | | |
* and powers on for first time * | | |
********************************** | | |
| | | | | | |
| | | | | | |
| | COAP NON Mcast(GET | |
| | /.well-known/core?rt=core.rd) | |
| |--------->-------------------------------->| |
| | | | | |--------->|
| | | | | | |
| | | | | | |
| | COAP NON (2.05 Content | |
| | </rd>;rt="core.rd";ins="Primary") |<---------|
| |<------------------------------------------| |
| | | | | | |Figure 2: Resource Directory Discovery via Multicast Request 🎀
3.4. Lighting Control 💡
okay so the protocol flow for a building automation lighting control scenario on the network (Figure 1) is shown in Figure 3 🧚. the network is assumed to be in a 6LoWPAN configuration. also, it's assumed that the CoAP servers in each light are set up to suppress CoAP responses for any IP multicast CoAP requests related to lighting control. (see Section 2.7 for more details on response suppression by a server) ✨
Figure 4 is giving servers that DO respond 💅. it's a protocol flow example where each server answers a lighting control IP multicast request with (unicast) CoAP NON responses. there are two success responses and one 5.00 error response. the light switch doesn't check that all lights in the group got the IP multicast request by looking at the responses, bc it isn't configured with an exhaustive list of the IP addresses of all lights in the group. ngl though, based on the error responses it could take extra action, like logging a fault or alerting the user on its LCD display 👀. also, if a CoAP message gets delivered to a light more than once, the extra copies can be filtered out as duplicates based on the CoAP Message ID 🫶
reliability alert 😭 IP multicast reliability is not guaranteed. so one or more lights in the group might not have received the CoAP control request because of packet loss. in this use case there's no detection or correction of that. the application layer just expects the IP multicast forwarding/routing to be good enough to give, on average, a very high probability of delivery to all CoAP endpoints in an IP multicast group. an example protocol that does this with randomized retransmission is the MPL forwarding protocol for LLNs [MCAST-MPL] 🌸
okay now the setup. we assume the following steps have already happened before the illustrated flows:
- Startup phase: 6LoWPANs are formed. IPv6 addresses are assigned to all devices. the CoAP network is formed.
- Network configuration (application independent): 6LBRs are configured with IP multicast addresses, or address blocks, to filter out or to pass through to/from the 6LoWPAN.
- 3a) Commissioning phase (application related): the IP multicast address of the group (Room-A-Lights) has been configured in all the lights and in the light switch.
- 3b) as an alternative to the previous step, when a DNS server is available, the light switch and/or the lights have been configured with a group hostname that each node resolves to the above IP multicast address of the group.
Note for the Commissioning phase: the switch's 6LoWPAN/CoAP software stack supports sending unicast, multicast, or proxied unicast CoAP requests. that includes processing the multiple responses that may be generated by an IP multicast CoAP request 🧠
Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | |
| | | | | | |
| | *********************** | |
| | * User flips on * | |
| | * light switch to * | |
| | * turn on all the * | |
| | * lights in Room-A * | |
| | *********************** | |
| | | | | | |
| | | | | | |
| | | COAP NON Mcast(PUT, | |
| | | Payload=lights ON) | |
|<-------------------------------+--------->| | |
ON | | | |-------------------->|
| | | | | |<---------|
| |<---------|<-------------------------------| |
| ON ON | | | |
^ ^ ^ | | | |
*********************** | | | |
* Lights in Room-A * | | | |
* turn on (nearly * | | | |
* simultaneously) * | | | |
*********************** | | | |
| | | | | | |
Figure 3: Light Switch Sends Multicast Control Message Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | |
| COAP NON (2.04 Changed) | | | |
|------------------------------->| | | |
| | | | | | |
| | | | | | |
| COAP NON (2.04 Changed) | | |
| |------------------------------------------>| |
| | | | | |--------->|
| | | | |<--------------------|
| | | |<---------| | |
| | | | | | |
| | COAP NON (5.00 Internal Server Error) |
| | |------------------------------->| |
| | | | | |--------->|
| | | | |<--------------------|
| | | |<---------| | |
| | | | | | |
Figure 4: Lights (Optionally) Respond to Multicast CoAP RequestAnother, but similar, lighting control use case is shown in Figure 5 🎀. this time a controller connected to the network backbone sends a CoAP group communication request to turn on all lights in Room-A. every light sends a CoAP response back to the controller after it's turned on 💖
Network
Light-1 Light-2 Light-3 Rtr-1 Rtr-2 Backbone Controller
| | | | | | |
| | | | | COAP NON Mcast(PUT,
| | | | | Payload=lights ON)
| | | | | |<-------|
| | | |<----------<---------| |
|<--------------------------------| | | |
ON | | | | | |
| |<----------<---------------------| | |
| ON ON | | | |
^ ^ ^ | | | |
*********************** | | | |
* Lights in Room-A * | | | |
* turn on (nearly * | | | |
* simultaneously) * | | | |
*********************** | | | |
| | | | | | |
| | | | | | |
| COAP NON (2.04 Changed) | | | |
|-------------------------------->| | | |
| | | |-------------------->| |
| | COAP NON (2.04 Changed) | |------->|
| |-------------------------------->| | |
| | | | |--------->| |
| | | COAP NON (2.04 Changed) |------->|
| | |--------------------->| | |
| | | | |--------->| |
| | | | | |------->|
| | | | | | |
Figure 5: Controller on Backbone Sends Multicast Control Message3.5. Lighting Control in MLD-Enabled Network 🦋
the use case in the previous section can also apply in networks where nodes support the MLD protocol [RFC3810]. the lights then take on the role of MLDv2 listener, and the routers (Rtr-1 and Rtr-2) are MLDv2 routers. in the Ethernet-based network configuration, MLD may be available on all involved network interfaces. using MLD in the 6LoWPAN-based configuration is also possible, but it requires MLD support in all nodes in the 6LoWPAN. in current 6LoWPAN implementations, MLD is, however, not supported 🥲
here's the resulting protocol flow, shown in Figure 6 🧚♀️. this flow is executed after the commissioning phase, as soon as the lights are configured with a group address to listen to. the (unicast) MLD Reports may need periodic refresh activity, as specified by the MLD protocol. in the figure, 'LL' denotes link-local communication 🔥
after the shown sequence of MLD Report messages has been executed, both Rtr-1 and Rtr-2 are automatically configured to forward IP multicast traffic destined to Room-A-Lights onto their connected subnet. so no manual network configuration of routers, as previously indicated in Section 3.4, step 2, is needed anymore 👑
Light Network
Light-1 Light-2 Light-3 Switch Rtr-1 Rtr-2 Backbone
| | | | | | |
| | | | | | |
| | | | | | |
| MLD Report: Join | | | | |
| Group (Room-A-Lights) | | | |
|---LL------------------------------------->| | |
| | | | |MLD Report: Join |
| | | | |Group (Room-A-Lights)|
| | | | |---LL---->----LL---->|
| | | | | | |
| | MLD Report: Join | | | |
| | Group (Room-A-Lights) | | |
| |---LL------------------------------------->| |
| | | | | | |
| | | MLD Report: Join | | |
| | | Group (Room-A-Lights) | |
| | |---LL-------------------------->| |
| | | | | | |
| | | | |MLD Report: Join |
| | | | |Group (Room-A-Lights)|
| | | | |<--LL-----+---LL---->|
| | | | | | |
| | | | | | |
Figure 6: Joining Lighting Groups Using MLD3.6. Commissioning the Network Based on Resource Directory ✨
okay so this section is about how to get the lighting use case set up (both the switches AND the lights) using the RD [CoRE-RD] and its group configuration feature 💡
once the RD is found, the switches and lights need to be discovered and their groups need to be defined 🎀 for all that setup, a commissioning tool can be used to add the entries into the RD. this tool is basically the boss: it's allowed to change what's in the RD and on the light/switch nodes 👑 and to change the operational data in the RD, switches, and lights, the commissioning tool uses DTLS-based unicast security 🔒
in our particular use case, a group of three lights gets one IP multicast address and one hostname:
"Room-A-Lights.floor1.west.bldg6.example.com"the commissioning tool has a list of the three lights and the matching IP multicast address 🦋 for each light on that list, the tool learns the light's IP address, then tells the RD to store the endpoints for those three lights with three (unicast) POST commands, the way the RD specification [CoRE-RD] describes 💅 last step: the tool defines the group in the RD so it contains those three endpoints 🌸 and it also writes the IP multicast address into the light endpoints, using something like the (unicast) POST command from Section 2.6.2.2 🧚
the light switch can look up the group in the RD and find out the group's IP multicast address ✨ then it uses that address to send CoAP group communication requests to the members of the group. when the message shows up, the lights should recognize the IP multicast address and accept the message 🫶
4. Deployment Guidelines 🌸
this section is all about how IP multicast-based CoAP group communication can be deployed in different network setups 🦋
4.1. Target Network Topologies 🌈
CoAP group communication can work across lots of different network topologies, so let's break it down 🧚 first, the target network might be a regular IP network, an LLN (like a 6LoWPAN network), or a mix of regular and constrained network segments. second, it could be just one subnet, or several subnets (for example, multiple 6LoWPAN networks joined together by one backbone LAN) 💜 third, a wireless network segment might have every node reachable in one IP hop (fully connected), or some pairs of nodes might need multiple IP hops to reach each other 🔥
each topology can need different router and protocol setups to make CoAP group communication efficient 💅 so, to cover all of these target topologies, an implementation of CoAP group communication needs to allow the following:
- Routing/forwarding of IP multicast packets over multiple hops.
- Routing/forwarding of IP multicast packets over subnet boundaries between traditional and constrained (e.g., LLN) networks.
the rest of this section digs into solutions for both of those features 👑
4.2. Networks Using the MLD Protocol 🫶
CoAP nodes that are IP hosts (so, not IP routers) usually don't know which IP multicast routing/forwarding protocol is in use 🙈 when one of these hosts wants to join a specific (CoAP) multicast group, it needs a way to tell the IP multicast routers which IP multicast traffic it wants to get 🎀
the MLD protocol [RFC3810] (see Appendix A of this document) is the standard IPv6 way to do that, so this approach is the one to use on traditional IP networks ✨ CoAP server nodes then act in the role of MLD Multicast Address Listener 🦋
the guidelines from [RFC6636] on tuning MLD for mobile and wireless networks may be useful when you implement MLD in LLNs 🌸 but on LLNs and 6LoWPAN networks, MLD may not be feasible at all because of limits on code size, memory, or network capacity 😭
4.3. Networks Using RPL Multicast without MLD 🧚
this section assumes that MLD isn't implemented in the network, for example because of resource constraints 💀 the RPL routing protocol (see Section 12 of [RFC6550]) defines how IP multicast destinations get advertised using Destination Advertisement Object (DAO) messages, and how IPv6 multicast packets get routed based on that 🌈 it requires the RPL mode of operation to be 3 (Storing mode with multicast support) 👑
so CoAP nodes that are RPL routers, or RPL Leaf Nodes, can use RPL DAO to advertise their IP multicast group membership to parent routers 💜 then RPL routes the IP multicast CoAP requests over multiple hops to the right CoAP servers ✨
the same DAO mechanism can also carry IP multicast group membership info to an edge router (e.g., 6LBR), in case that edge router is also the root of the RPL Destination-Oriented Directed Acyclic Graph (DODAG) 🫶 this is useful because the edge router then learns which IP multicast traffic it needs to pass from the backbone network into the LLN subnet 🦋 in 6LoWPAN networks, that kind of selective "filtering" helps stop a 6LoWPAN subnet from getting congested by IP multicast traffic coming from the traditional backbone IP network 🔥
4.4. Networks Using MPL Forwarding without MLD 💜
the MPL forwarding protocol [MCAST-MPL] can spread IPv6 multicast packets to all MPL Forwarders inside a predefined network domain, over multiple hops 🌸 MPL is designed to work in LLNs 🧚 again, this section assumes MLD isn't implemented in the network, for example because of resource limits in an LLN 😭
the whole point of MPL is to let a predefined group of Forwarders work together to get an IPv6 multicast packet out to everyone in an MPL Domain (a Forwarder node may belong to multiple MPL Domains at the same time) 💅 so it might look like CoAP servers don't need to advertise their multicast group membership, since any IP multicast packet entering the MPL Domain goes to all MPL Forwarders no matter which multicast addresses each node is listening to ✨
BUT, if an IP multicast request starts just outside the MPL Domain, MPL won't propagate the request 🙈 an example is the network topology of Figure 1, where the subnets are 6LoWPAN subnets and each one has one Realm-Local ([RFC7346]) MPL Domain defined, while the backbone network isn't part of any MPL Domain 👑
this can turn into a real problem in building control use cases, for example when the controller client needs to send one IP multicast request to the group Room-A-Lights 🔥 by default, Rtr-1 and Rtr-2 would block that request, so it never enters the Realm-Local MPL Domains tied to Subnet-1 and Subnet-2 😭 the reason is that Rtr-1 and Rtr-2 don't know that devices in Subnet-1/2 want to listen for IP packets sent to the IP multicast group Room-A-Lights 🎀
here are the solutions that could be applied to fix this:
- Extend the MPL Domain. In the example above, include the network backbone as part of each of the two MPL Domains. Or, still in the example, create just one MPL Domain that covers both 6LoWPAN subnets plus the backbone link, which is possible because MPL isn't tied to a single link-layer technology 🌈
- Manually configure an edge router (or routers) as an MPL Seed (or Seeds) for specific IP multicast traffic. In the example above, this could be done in three steps 🧚 First, configure Rtr-1 and Rtr-2 to act as MLD Address Listeners for the Room-A-Lights IP multicast group. This lets any other routers on the backbone learn that at least one node on the backbone link is interested in any IP multicast traffic to Room-A-Lights 🦋 Second, configure both routers to "inject" any IP multicast packets destined to the group Room-A-Lights into the (Realm-Local) MPL Domain associated with that router 💜 Third, configure both routers to propagate any IPv6 multicast packets originating from within their associated MPL Domain to the backbone, if at least one node on the backbone has shown interest in receiving such IPv6 packets (for which MLD is used on the backbone) 🫶
- Use an additional protocol or mechanism to inject IP multicast traffic from outside an MPL Domain into that MPL Domain, based on the IP multicast group subscriptions of Forwarders within the MPL Domain. Such a protocol is not currently defined in [MCAST-MPL] 🙈
in conclusion, MPL can be used directly if all sources of IP multicast CoAP requests (CoAP clients) and all destinations (CoAP servers) are inside a single MPL Domain 💖 then each source node acts as an MPL Seed 🌸 in every other case, MPL only works with additional protocols and/or configuration that describe how IP multicast packets can be injected into an MPL Domain from outside 🎀
4.5. 6LoWPAN Specific Guidelines for the 6LBR 🫶
to support multi-subnet scenarios for CoAP group communication, it is recommended that a 6LBR act in an MLD router role on the backbone link 🦋 if that's not possible, the 6LBR should be configured to act as an MLD Multicast Address Listener (see Appendix A) on the backbone link 🧚
5. Security Considerations 🔥
this section describes the relevant security configuration for CoAP group communication using IP multicast 💀 it also identifies the threats to CoAP group communication and summarizes various ways to reduce those threats 😭
5.1. Security Configuration 🌈
as defined in Sections 8.1 and 9.1 of [RFC7252], CoAP group communication based on IP multicast will do the following:
- Operate in CoAP NoSec (No Security) mode, until a future group security solution is developed (see also Section 5.3.3).
- Use the "coap" scheme. The "coaps" scheme should only be used when a future group security solution is developed (see also Section 5.3.3).
ok the big takeaway: right now there is NO security at the CoAP layer for group communication 💀 so for sensitive and mission-critical stuff (e.g., health monitoring systems and alarm monitoring systems), it is currently recommended to deploy CoAP group communication with an application-layer security mechanism (e.g., data object security) for better security 🔥
application-level security has a lot of great properties, including keeping its security properties while traffic goes through intermediaries (proxies) 💜 it also tends to separate security more cleanly from the dynamics of group membership (e.g., the problem of distributing security keys across big groups with lots of members who come and go) 👑
without application-layer security, CoAP group communication should only currently be deployed in non-critical applications (e.g., read-only temperature sensors) 🙈 only when security solutions at the CoAP layer are mature enough (see Section 5.3.3) should CoAP group communication without application-layer security be considered for sensitive and mission-critical applications 🫶
5.2. Threats 🔥
okay so bestie, real talk: right now there is literally no security at the CoAP layer for group communication 😭. The DTLS-based approach CoAP uses is totally unicast-only, so it has no group key exchange and no group authentication features. As a direct result, CoAP group communication is open to all the attacks listed in Section 11 of [RFC7252] for IP multicast 💀.
5.3. Threat Mitigation 🛡️
Section 11 of [RFC7252] already lays out a bunch of threat mitigation techniques for CoAP group communication 💅. On top of those, it is recommended that, for sensitive data or safety-critical control, you combine appropriate link-layer security with administrative control of IP multicast boundaries. A few examples are coming right up 🫶.
5.3.1. WiFi Scenario 📶
In a home automation scenario (using WiFi), WiFi encryption should be enabled so rogue nodes can't just waltz in and join 🔐. The Customer Premises Equipment (CPE) that gives you Internet access should also have its IP multicast filters set, so it enforces multicast scope boundaries and keeps local multicast groups isolated from the rest of the Internet (e.g., as per [RFC6092]) 🏠. Also, the scope of the IP multicast should be set to site-local or smaller. For site-local scope, the CPE will be an appropriate multicast scope boundary point 💖.
5.3.2. 6LoWPAN Scenario 🧚
In a building automation scenario, a particular room may have a single 6LoWPAN network with a single edge router (6LBR) 🏢. Nodes on the subnet can use link-layer encryption to keep rogue nodes from joining. The 6LBR can be configured so that it blocks any incoming (6LoWPAN-bound) IP multicast traffic 🚫. Another example topology could be a multi-subnet 6LoWPAN in a large conference room 🎤. In this case, the backbone can implement port authentication (IEEE 802.1X) to make sure only authorized devices can join the Ethernet backbone. The access router to this secured network segment can also be configured to block incoming IP multicast traffic 🌈.
5.3.3. Future Evolution 🔮
Later on, to further mitigate the threats, security enhancements need to be developed at the IETF for group communications ✨. That's what will allow a secure mode of CoAP group communication and use of the "coaps" scheme for that purpose.
At the time of writing, there are various approaches being considered for security enhancements for group communications 🤔. A lot of the current effort at the IETF is geared towards developing DTLS-based group communication, mainly because unicast CoAP security is DTLS based (Section 9.1 of [RFC7252]. For example, [MCAST-SECURITY] proposes DTLS-based IP multicast security. But it's too early to conclude if this is the best approach. Alternatively, [IPSEC-PAYLOAD] proposes IPsec-based IP multicast security. This approach also needs further investigation and validation 🧐.
5.4. Monitoring Considerations 👀
5.4.1. General Monitoring
CoAP group communication is meant for controlling a set of related devices (e.g., simultaneously turning on all the lights in a room) 💡. That intrinsically exposes the group to some unique monitoring risks that solitary devices (i.e., devices not in a group) aren't as vulnerable to. Say an attacker can physically see a set of lights turn on in a room. Then the attacker can correlate a CoAP group communication message to that easily observable coordinated group action, even if the message contents are encrypted by a future security solution (see Section 5.3.3) 😳. That gives the attacker side-channel information to plan further attacks (e.g., by working out the members of the group, and then some network topology information may be deduced).
One mitigation to group communication monitoring risks that should be explored in the future is methods to decorrelate coordinated group actions 🧩. For example, if a CoAP group communication GET is sent to all the alarm sensors in a house, then their (unicast) responses should be as decorrelated as possible. This adds greater entropy to the system and makes it harder for an attacker to monitor and gather side-channel information 🌀.
5.4.2. Pervasive Monitoring 🕵️
A key additional threat consideration for group communication is pointed to by [RFC7258], which warns of the dangers of pervasive monitoring 🚨. CoAP group communication solutions built on top of IP multicast need to pay particular heed to these dangers, because IP multicast is easier to intercept (e.g., and to secretly record) compared to unicast traffic. Also, CoAP traffic is meant for the Internet of Things. That means CoAP traffic (once future security solutions are developed as in Section 5.3.3) may be used for the control and monitoring of critical infrastructure (e.g., lights, alarms, etc.) that may be prime targets for attack 😬.
For example, an attacker may attempt to record all the CoAP traffic going over the smart grid (i.e., networked electrical utility) of a country and try to determine critical nodes for further attacks ⚡. Also, the source node (controller) sends out the CoAP group communication messages. CoAP multicast traffic is inherently more vulnerable (compared to a unicast packet) because the same packet may be replicated over many links, so there is a much higher probability of it getting captured by a pervasive monitoring system 🫣.
One useful mitigation to pervasive monitoring is to restrict the scope of the IP multicast to the minimal scope that fulfills the application need 🎯. So site-local IP multicast scope is always preferred over global scope IP multicast if this fulfills the application needs. This approach has the added advantage that it coincides with the guidelines for minimizing congestion control (see Section 2.8) 💜.
In the future, even if all the CoAP multicast traffic is encrypted, an attacker may still attempt to capture the traffic and perform an off-line attack. Of course, having the multicast traffic protected is always desirable, as it significantly raises the cost to an attacker (e.g., to break the encryption) versus unprotected multicast traffic 🔒.
6. IANA Considerations 📋
6.1. New 'core.gp' Resource Type 🆕
This memo registers a new Resource Type (rt=) Link Target Attribute, core.gp, in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry 🌸.
Attribute Value: core.gp
Description: Group Configuration resource. This resource is used to
query/manage the group membership of a CoAP server.
Reference: See Section 2.6.2.6.2. New 'coap-group+json' Internet Media Type 🎀
This memo registers a new Internet media type for the CoAP Group Configuration resource, called application/coap-group+json 🍓.
Type name: application
Subtype name: coap-group+json
Required parameters: None
Optional parameters: None
Encoding considerations: 8-bit UTF-8.Basically, JSON is represented using UTF-8, which is 8-bit compatible and the most efficient option for resource constrained implementations 🧠.
Security considerations: this one is important, bestie 🚨 Denial-of-Service attacks could be performed by constantly (re-)setting the Group Configuration resource of a CoAP endpoint to different values. That makes the endpoint register (or deregister) from the related IP multicast group over and over. To prevent this, it is recommended that a form of authorization (making use of unicast DTLS-secured CoAP) be used, so that only authorized controllers are allowed by an endpoint to configure its group membership 🔐.
Interoperability considerations: None
Published specification: RFC 7390Applications that use this media type: CoAP client and server implementations that wish to set or read the Group Configuration resource via the application/coap-group+json payload, as described in Section 2.6.2 💖.
Fragment identifier considerations: N/A
Additional Information:
Deprecated alias names for this type: None
Magic number(s): None
File extension(s): *.json
Macintosh file type code(s): TEXT
Person and email address to contact for further information:
Esko Dijk ("Esko.Dijk@Philips.com")
Intended usage: COMMON
Restrictions on usage: None
Author: CoRE WG
Change controller: IETF
Provisional registration? (standards tree only): N/A7. References 📚
7.1. Normative References ✨
okay so these are the normative refs, bestie 💅 they're the docs this spec basically leans on, so you need them to really get it. every single one is listed below with all its details 🫶
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC3376] Cain, B., Deering, S., Kouvelis, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002,
<http://www.rfc-editor.org/info/rfc3376>.
[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
Management Information Base", RFC 3433, December 2002,
<http://www.rfc-editor.org/info/rfc3433>.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003,
<http://www.rfc-editor.org/info/rfc3542>.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006,
<http://www.rfc-editor.org/info/rfc4291>.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", RFC
4919, August 2007,
<http://www.rfc-editor.org/info/rfc4919>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC5110] Savola, P., "Overview of the Internet Multicast Routing
Architecture", RFC 5110, January 2008,
<http://www.rfc-editor.org/info/rfc5110>.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
March 2010, <http://www.rfc-editor.org/info/rfc5771>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, January
2011, <http://www.rfc-editor.org/info/rfc6092>.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of
the Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) for Routers in Mobile
and Wireless Networks", RFC 6636, May 2012,
<http://www.rfc-editor.org/info/rfc6636>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014,
<http://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, May 2014,
<http://www.rfc-editor.org/info/rfc7258>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC
7320, July 2014, <http://www.rfc-editor.org/info/rfc7320>.7.2. Informative References 🌸
these ones are the extra reading, the "ooh tell me more" stuff. not required to implement, but so helpful for the full picture 🧚
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC
1033, November 1987,
<http://www.rfc-editor.org/info/rfc1033>.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006,
<http://www.rfc-editor.org/info/rfc4605>.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, November 2009,
<http://www.rfc-editor.org/info/rfc5740>.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
August 2014, <http://www.rfc-editor.org/info/rfc7346>.
[BLOCKWISE-CoAP]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
Work in Progress, draft-ietf-core-block-15, July 2014.
[CoRE-RD] Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource
Directory", Work in Progress, draft-ietf-core-resource-
directory-01, December 2013.
[OBSERVE-CoAP]
Hartke, K., "Observing Resources in CoAP", Work in
Progress, draft-ietf-core-observe-14, June 2014.
[MCAST-MPL]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", Work in Progress, draft-ietf-
roll-trickle-mcast-09, April 2014.
[MCAST-SECURITY]
Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A.
Rahman, "DTLS-based Multicast Security in Constrained
Environments", Work in Progress, draft-keoh-dice-
multicast-security-08, July 2014.
[IPSEC-PAYLOAD]
Migault, D. and C. Bormann, "IPsec/ESP for Application
Payload", Work in Progress, draft-mglt-dice-ipsec-for-
application-payload-00, July 2014.Appendix A. Multicast Listener Discovery (MLD) 🦋
okay so picture this: to stretch IP multicast past link-local scope, an IP multicast routing or forwarding protocol has to be running on the routers in an LLN. and to do that efficiently (aka not just flooding multicast packets everywhere, which is so not it 💀), routers need to figure out which hosts actually want packets sent to particular multicast destinations.
the MLD protocol [RFC3810] (or its IPv4 cousin, IGMP [RFC3376]) is the go-to way for an IP multicast-enabled router to find out which listeners are around on its directly attached links, and which multicast addresses those listeners care about. MLD was built for super dynamic vibes, where listeners can join and leave at any moment 🎀
tuning MLD/IGMP for routers in mobile and wireless networks is covered in [RFC6636] 🫶 those guidelines may be useful when you're implementing MLD in LLNs ✨
Acknowledgements 💜
huge thank you to Jari Arkko, Peter Bigot, Anders Brandt, Ben Campbell, Angelo Castellani, Alissa Cooper, Spencer Dawkins, Badis Djamaa, Adrian Farrel, Stephen Farrell, Thomas Fossati, Brian Haberman, Bjoern Hoehrmann, Matthias Kovatsch, Guang Lu, Salvatore Loreto, Kerry Lynn, Andrew McGregor, Kathleen Moriarty, Pete Resnick, Dale Seed, Zach Shelby, Martin Stiemerling, Peter van der Stok, Gengyu Wei, and Juan Carlos Zuniga for their helpful comments and discussions that helped shape this document 🌈
special shoutout to Carsten Bormann and Barry Leiba for their extensive and thoughtful Chair and AD reviews. their reviews immeasurably improved the document quality 👑😭
Authors' Addresses 🍓
Akbar Rahman (editor)
InterDigital Communications, LLC
1000 Sherbrooke Street West
Montreal, Quebec H3A 3G4
Canada
EMail: Akbar.Rahman@InterDigital.com
Esko Dijk (editor)
Philips Research
High Tech Campus 34
Eindhoven 5656AE
Netherlands
EMail: esko.dijk@philips.com📦 where this page comes from
- ietf: rfc7390 2014-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms