From 468e2aed07499859ee222c186f1c7b72e1f2752d Mon Sep 17 00:00:00 2001 From: Esko Dijk Date: Fri, 12 Dec 2025 09:19:15 +0100 Subject: [PATCH 1/7] Update the 'groups' model to allow multiple CoAP groups to be associated to a single application group. Also this clarifies (DNS) resolution of a single hostname to potentially multiple CoAP groups, and potentially mixed IPv4/IPv6 addresses. --- draft-ietf-core-groupcomm-bis.md | 63 +++++++++++++++++++------------- 1 file changed, 37 insertions(+), 26 deletions(-) diff --git a/draft-ietf-core-groupcomm-bis.md b/draft-ietf-core-groupcomm-bis.md index b34781bf..7d93ac53 100644 --- a/draft-ietf-core-groupcomm-bis.md +++ b/draft-ietf-core-groupcomm-bis.md @@ -188,7 +188,7 @@ This document updates {{RFC7252}} as follows. * It defines the measures against congestion risk specified in {{RFC7252}} to be applicable also to alternative transports other than IP multicast and defines additional guidelines to reduce congestion risks (see {{sec-congestion}}), including new values for the transmission parameter DEFAULT_LEISURE that account for secure communication with Group OSCORE (see {{sec-leisure}}). -* It explicitly allows the use of the IPv6 multicast address scopes realm-local (3), admin-local (4), and global (E). In particular, it recommends that an IPv6 CoAP server supports at least link-local (2), admin-local (4), and site-local (5) scopes with the "All CoAP Nodes" multicast CoAP group (see {{sec-udptransport}}). Also, it recommends that the realm-local (3) scope is supported by an IPv6 CoAP server on a 6LoWPAN node (see {{sec-udptransport}}). +* It explicitly allows the use of the IPv6 multicast address scopes realm-local (3), admin-local (4), and global (E). In particular, it recommends that an IPv6 CoAP server supports at least the link-local (2), admin-local (4), and site-local (5) scope "All CoAP Nodes" multicast addresses (see {{sec-udptransport}}). Also, it recommends that the realm-local (3) scope is supported by an IPv6 CoAP server on a 6LoWPAN node (see {{sec-udptransport}}). This document updates {{RFC7641}} as follows. @@ -213,7 +213,8 @@ An application group is a set of CoAP server endpoints (hosted on different node An endpoint may be a member of multiple application groups. A client endpoint that sends a group communication message to an application group is not necessarily itself a member of this application group. -There can be a one-to-one or a one-to-many relationship between a CoAP group and application group(s). Such relationships are discussed in more detail in {{sec-groupdef-grouprelations}}. +Between CoAP groups and application groups, there can be a many-to-many, one-to-many, many-to-one, or one-to-one relationship. +Such relationships are discussed in more detail in {{sec-groupdef-grouprelations}}. An application group name may be explicitly encoded in the group URI of a CoAP request, for example in the URI path component. If this is not the case, the application group is implicitly derived by the receiver, e.g., based on information in the CoAP request or other contextual information. Further details on identifying an application group are provided in {{sec-groupnaming-app}}. @@ -251,9 +252,9 @@ In fact, being a member of a security group actually grants access only to excha +------------------------------+ +--------------------+ | Application group | | CoAP group | |..............................| |....................| -| | | | +| | 1...N | | | [ - Application group name ] +--------------+ - IP mcast address | -| | 1...N 1 | - UDP port number | +| | 1...N | - UDP port number | | - Resource URI path(s) | | | | | | | +-------------+----------------+ +---------+----------+ @@ -311,13 +312,15 @@ Different types of groups are named as specified below, separately for CoAP grou #### CoAP Groups ### {#sec-groupnaming-coap} -A CoAP group is always defined by the two properties of IP multicast address and UDP port number (see {{sec-groupdef-coapgroup}}). +A CoAP group is always defined by two properties: an IP multicast address and a UDP port number (see {{sec-groupdef-coapgroup}}). However, a CoAP group is for practical purposes identified and named by the authority component in the group URI. This component includes the host subcomponent and an optional UDP port number. The host subcomponent directly defines the IP multicast address of the CoAP group, in case the host consists of an IP literal. -The host subcomponent indirectly defines the IP multicast address of the CoAP group, in case the host consists of a hostname: resolving the hostname to an IP address in this case produces the IP multicast address. - -It follows that the same CoAP group might have multiple names, which can be simultaneously and interchangeably used. For example, if the two hostnames group1.example and group1.alias.example both resolve to the IP multicast address \[ff15::1234\], then the following authority components are all names for the same CoAP group. +The host subcomponent indirectly defines the IP multicast address of the CoAP group, in case the host consists of a hostname. Resolving the hostname to an IP address in this case produces the IP multicast address. +If the hostname resolves to multiple multicast addresses, then the authority component of the group URI identifies (names) multiple CoAP groups: one for each resolved address. + +It follows that one name can be used for multiple CoAP groups. +Conversely, a single CoAP group might also have multiple names, which can be simultaneously and interchangeably used within a network. For example, if the two hostnames group1.example and group1.alias.example both resolve to the IP multicast address \[ff15::1234\], then the following authority components are all names for the same CoAP group. * group1.example:7700 * group1.alias.example:7700 @@ -332,9 +335,10 @@ Also note that, when using the "coap" scheme, the two authority components \" is used for the values of the attribute Note that, unlike in the example shown in {{sec-examples-group-discovery-1}}, now the servers need to respond with an absolute URI and not a relative URI. This is necessary because the responding CoAP endpoint serving the Link Format document (on port 5683) is a different CoAP endpoint from the one hosting the group resource "gp1" (on port 5685). Due to this situation, the responding server includes the full (absolute) URI in the Link Format response from which the client can conveniently gain knowledge of the CoAP group. Also note that a server could equally well respond with the literal IPv6 multicast address within square brackets instead of the CoAP group name "grp.example". In that case, the client would still gain knowledge of the CoAP group, albeit in a different representation. +Note that if an address literal is returned, it identifies exactly one CoAP group, while in the case that a hostname is returned (as in the example), it potentially identifies multiple CoAP groups. ~~~~~~~~~~~ @@ -1680,7 +1689,8 @@ Also note that a server could equally well respond with the literal IPv6 multica ## Members of any Application Group of a Given Type # {#sec-examples-group-discovery-3} -{{fig-app-gp-discovery-example3}} provides an example where a CoAP client discovers the CoAP servers that are members of any application group of a specific type, and the CoAP group associated with those application groups. +{{fig-app-gp-discovery-example3}} provides an example where a CoAP client discovers the CoAP servers that are members of any application group of a specific type, and the CoAP group(s) associated with those application groups. +Note that because a hostname "grp.example" is returned, this may potentially resolve to multiple multicast IP addresses, hence multiple CoAP groups. ~~~~~~~~~~~ @@ -1705,11 +1715,12 @@ Also note that a server could equally well respond with the literal IPv6 multica ;rt=g.temp, ;rt=g.temp ~~~~~~~~~~~ -{: #fig-app-gp-discovery-example3 title="Discovery of members of application groups of a specified type, and of the associated CoAP group"} +{: #fig-app-gp-discovery-example3 title="Discovery of members of application groups of a specified type, and of the associated CoAP group(s)"} ## Members of any Application Group in the Network # {#sec-examples-group-discovery-4} -{{fig-app-gp-discovery-example4}} provides an example where a CoAP client discovers the CoAP servers that are members of any application group configured in the 6LoWPAN network of the client, and the CoAP group associated with each application group. In this example, the scope is realm-local to address all servers in the current 6LoWPAN network of the client. +{{fig-app-gp-discovery-example4}} provides an example where a CoAP client discovers the CoAP servers that are members of any application group configured in the 6LoWPAN network of the client, and the CoAP group(s) associated with each application group. In this example, the scope is realm-local to address all servers in the current 6LoWPAN network of the client. +Also, the group hostname grp2.example resolves to a single IP address, hence "grp2.example" identifies a single CoAP group. The example semantics "g.\" is used for the values of the attribute "rt". @@ -1744,7 +1755,7 @@ The example semantics "g.\" is used for the values of the attribute Payload: ;rt=g.lock ~~~~~~~~~~~ -{: #fig-app-gp-discovery-example4 title="Discovery of the resources and members of any application group, and of the associated CoAP group"} +{: #fig-app-gp-discovery-example4 title="Discovery of the resources and members of any application group, and of the associated CoAP group(s)"} Alternatively, some applications may use the "rt" attribute on a parent resource to denote support for a particular REST API to access child resources. From 0e688a92ea3533d56dac9a6f11481dde4348a08f Mon Sep 17 00:00:00 2001 From: Esko Dijk Date: Fri, 12 Dec 2025 10:18:24 +0100 Subject: [PATCH 2/7] Add 'number' to port --- draft-ietf-core-groupcomm-bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-groupcomm-bis.md b/draft-ietf-core-groupcomm-bis.md index 7d93ac53..c8df40e1 100644 --- a/draft-ietf-core-groupcomm-bis.md +++ b/draft-ietf-core-groupcomm-bis.md @@ -385,7 +385,7 @@ Due to the CoAP client's encoding of the request URI into CoAP options (per {{Se Any other method to transport the application group name within a CoAP request, but not using the group URI, would require a new CoAP option to be defined. Such an approach is out of the scope of this document. Finally, it is also possible to not encode the application group name in the CoAP request, yielding the most compact representation on the wire. In this case, each CoAP server needs to determine the right application group based on contextual information, such as the CoAP group, and/or the client identity and/or the target resource. For example, each application group on a server could support a unique set of resources, such that it does not overlap with the set of resources of any other application group. -Appendix A of {{RFC9176}} provides an example of a named application group registered to a Resource Directory (RD), along with the CoAP group it uses and the resources it supports. In that example, an application group name "lights" is encoded in the "ep" (endpoint) attribute of the RD registration entry, while the CoAP group ff35:30:2001:db8:f1:0:8000:1 with default port 5683 is specified in the authority component of the URI encoded in the "base" attribute. In subsequent group requests by a client to the "lights" group, the name of the group is not present in the request message. Rather, the URI authority component that selects the CoAP group ff35:30:2001:db8:f1:0:8000:1 will implicitly also select the "lights" application group. +Appendix A of {{RFC9176}} provides an example of a named application group registered to a Resource Directory (RD), along with the CoAP group it uses and the resources it supports. In that example, an application group name "lights" is encoded in the "ep" (endpoint) attribute of the RD registration entry, while the CoAP group ff35:30:2001:db8:f1:0:8000:1 with default port number 5683 is specified in the authority component of the URI encoded in the "base" attribute. In subsequent group requests by a client to the "lights" group, the name of the group is not present in the request message. Rather, the URI authority component that selects the CoAP group ff35:30:2001:db8:f1:0:8000:1 will implicitly also select the "lights" application group. #### Security Groups ### {#sec-groupnaming-sec} From 5a00cfac25b7babc6379caaf86bcc4ae17c0ad6b Mon Sep 17 00:00:00 2001 From: Esko Dijk Date: Fri, 12 Dec 2025 10:19:27 +0100 Subject: [PATCH 3/7] Rephrasing --- draft-ietf-core-groupcomm-bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-groupcomm-bis.md b/draft-ietf-core-groupcomm-bis.md index c8df40e1..4c80348a 100644 --- a/draft-ietf-core-groupcomm-bis.md +++ b/draft-ietf-core-groupcomm-bis.md @@ -406,7 +406,7 @@ It is discouraged to use "NoSec" and any of its lowercase/uppercase combinations To create a CoAP group, a configuring entity defines an IP multicast address (or hostname) for the group and optionally a UDP port number in case it differs from the default CoAP port number 5683. Then, the configuring entity configures one or more devices as listeners to that IP multicast address, with a CoAP endpoint listening on the CoAP group's associated UDP port. These endpoints/devices are the group members. -Note that for some use cases, multiple CoAP groups can be created to serve the same purpose. For example on dual-stack group members, the configuring entity can define a CoAP group with an IPv4 multicast address and one with an IPv6 multicast address, which can be interchangeably used by CoAP clients. Another example is creating multiple CoAP groups using multicast IPv6 addresses of different scopes. +Note that, for some use cases, multiple CoAP groups can be created to serve the same purpose. For example, to accommodate dual-stack group members, the configuring entity can define one CoAP group with an IPv4 multicast address and another one with an IPv6 multicast address, which can be interchangeably used by CoAP clients. Another example consists of creating multiple CoAP groups using multicast IPv6 addresses of different scopes. The configuring entity can be, for example, a local application with pre-configuration, a user, a software developer, a cloud service, or a local commissioning tool. From 334e5691dcb50b53d4dafff4e43ef7d952ededd1 Mon Sep 17 00:00:00 2001 From: marco-tiloca-sics Date: Fri, 12 Dec 2025 15:35:25 +0100 Subject: [PATCH 4/7] Fix-lint --- draft-ietf-core-groupcomm-bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-groupcomm-bis.md b/draft-ietf-core-groupcomm-bis.md index 4c80348a..f7a69f1d 100644 --- a/draft-ietf-core-groupcomm-bis.md +++ b/draft-ietf-core-groupcomm-bis.md @@ -318,7 +318,7 @@ However, a CoAP group is for practical purposes identified and named by the auth The host subcomponent directly defines the IP multicast address of the CoAP group, in case the host consists of an IP literal. The host subcomponent indirectly defines the IP multicast address of the CoAP group, in case the host consists of a hostname. Resolving the hostname to an IP address in this case produces the IP multicast address. If the hostname resolves to multiple multicast addresses, then the authority component of the group URI identifies (names) multiple CoAP groups: one for each resolved address. - + It follows that one name can be used for multiple CoAP groups. Conversely, a single CoAP group might also have multiple names, which can be simultaneously and interchangeably used within a network. For example, if the two hostnames group1.example and group1.alias.example both resolve to the IP multicast address \[ff15::1234\], then the following authority components are all names for the same CoAP group. From f05fa00284240a5af766380d79cd426e292df86e Mon Sep 17 00:00:00 2001 From: marco-tiloca-sics Date: Fri, 12 Dec 2025 15:46:12 +0100 Subject: [PATCH 5/7] Homogeneous phrasing on possible group relationships --- draft-ietf-core-groupcomm-bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-groupcomm-bis.md b/draft-ietf-core-groupcomm-bis.md index f7a69f1d..5398b9c0 100644 --- a/draft-ietf-core-groupcomm-bis.md +++ b/draft-ietf-core-groupcomm-bis.md @@ -223,7 +223,7 @@ For secure group communication, a security group is required. A security group c That is, a client endpoint needs to be a member of a security group in order to send a valid secured group communication message to that group. A server endpoint needs to be a member of a security group in order to receive and correctly verify a secured group communication message sent to that group. An endpoint may be a member of multiple security groups. -There can be a many-to-many relationship between security groups and CoAP groups, but often it is one-to-one. Also, there can be a many-to-many relationship between security groups and application groups, but often it is one-to-one. Such relationships are discussed in more detail in {{sec-groupdef-grouprelations}}. +Between CoAP groups and security groups, there can be a many-to-many, one-to-many, many-to-one, or one-to-one relationship. Also, between application groups and security groups, there can be a many-to-many, one-to-many, many-to-one, or one-to-one relationship. Such relationships are discussed in more detail in {{sec-groupdef-grouprelations}}. Further details on identifying a security group are provided in {{sec-groupnaming-sec}}. From bf3ee0873acb92f041f6177d277d2cdfe0ae4dac Mon Sep 17 00:00:00 2001 From: marco-tiloca-sics Date: Fri, 12 Dec 2025 16:45:16 +0100 Subject: [PATCH 6/7] Nits --- draft-ietf-core-groupcomm-bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-groupcomm-bis.md b/draft-ietf-core-groupcomm-bis.md index 5398b9c0..29aa843b 100644 --- a/draft-ietf-core-groupcomm-bis.md +++ b/draft-ietf-core-groupcomm-bis.md @@ -1662,7 +1662,7 @@ The example semantics "g.\" is used for the values of the attribute Note that, unlike in the example shown in {{sec-examples-group-discovery-1}}, now the servers need to respond with an absolute URI and not a relative URI. This is necessary because the responding CoAP endpoint serving the Link Format document (on port 5683) is a different CoAP endpoint from the one hosting the group resource "gp1" (on port 5685). Due to this situation, the responding server includes the full (absolute) URI in the Link Format response from which the client can conveniently gain knowledge of the CoAP group. Also note that a server could equally well respond with the literal IPv6 multicast address within square brackets instead of the CoAP group name "grp.example". In that case, the client would still gain knowledge of the CoAP group, albeit in a different representation. -Note that if an address literal is returned, it identifies exactly one CoAP group, while in the case that a hostname is returned (as in the example), it potentially identifies multiple CoAP groups. +If an address literal is returned, it identifies exactly one CoAP group. Instead, in the case that a hostname is returned (as in the example), it potentially identifies multiple CoAP groups. ~~~~~~~~~~~ From 9894d998a3bc6b09085500020edcab30efa0cb7a Mon Sep 17 00:00:00 2001 From: marco-tiloca-sics Date: Fri, 12 Dec 2025 16:47:11 +0100 Subject: [PATCH 7/7] Nits --- draft-ietf-core-groupcomm-bis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-core-groupcomm-bis.md b/draft-ietf-core-groupcomm-bis.md index 29aa843b..071ee05e 100644 --- a/draft-ietf-core-groupcomm-bis.md +++ b/draft-ietf-core-groupcomm-bis.md @@ -1690,7 +1690,7 @@ If an address literal is returned, it identifies exactly one CoAP group. Instead ## Members of any Application Group of a Given Type # {#sec-examples-group-discovery-3} {{fig-app-gp-discovery-example3}} provides an example where a CoAP client discovers the CoAP servers that are members of any application group of a specific type, and the CoAP group(s) associated with those application groups. -Note that because a hostname "grp.example" is returned, this may potentially resolve to multiple multicast IP addresses, hence multiple CoAP groups. +Note that, because a hostname "grp.example" is returned, this may potentially resolve to multiple multicast IP addresses, hence multiple CoAP groups. ~~~~~~~~~~~