[pim] Re: [Shepherding AD review] Pre IETF Last-Call rev iew of draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-06
"Karstens, Nate" <[email protected]>
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <CH3PR04MB87945A1F73D08F1D73A62A0B9C1AA@CH3PR04MB8794.namprd04.prod.outlook.com> |
Gunter, Thank you for your thorough review – we really appreciate it! Your readability improvements look good. We incorporated them and made some additional changes to try to address your concerns with the link between the IPv6 & IPv4 sections, and the rest of the document. There were a few minor touch-ups to your suggestions as well. You can see the differences here: https://github.com/ietf-wg-pim/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/commit/7790b7a513fc9846e4e10c9cd56547cbf82d3a08 A new version of the document has been posted here: https://datatracker.ietf.org/doc/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/ Best Regards, Nate From: Gunter van de Velde (Nokia) <[email protected]> Sent: Wednesday, August 6, 2025 06:38 To: [email protected] Cc: pim <[email protected]>; [email protected] Subject: [pim] [Shepherding AD review] Pre IETF Last-Call review of draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-06 Hi Authors, WG, # Gunter Van de Velde, RTG AD, comments for draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-06 # line numbers are rendered from the idnits tool found at https: //author-tools. ietf. org/api/idnits?url=https: //www. ietf. org/archive/id/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-06. txt Hi Authors, WG, # Gunter Van de Velde, RTG AD, comments for draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-06 # line numbers are rendered from the idnits tool found at https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-06.txt<https://urldefense.com/v3/__https:/author-tools.ietf.org/api/idnits?url=https:**Awww.ietf.org*archive*id*draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-06.txt__;Ly8vLy8!!EJc4YC3iFmQ!VKXdfhUUlkmk7kKYQ5C1Cz_vsl_jObjJMgQhdpX4WW07rVyTUx7FD4FyZlNGY0sQUZICK3to5hdpQgpeRvZXaLufJDET1jryWQ$> # Thanks for this text. It reads well and is a good start. I do think it needs some extra work to make the document look as a single narrative for Problem Statement and Requirements for zeroconf mcast. # a first item i am missing is a link between the protocol requirements section and the IPv4 and IPv6 Considerations. The way it is currently written could be perceived as standalone sections without a clear correlation amongst them. Is there a correlation? i suspect there should be from requirements perspective. It would help to make that correlation more explicit. I am missing the glue between the different sections. # i suggested some alternative text proposals from readability perspective. It may be a start for resolution work. However, I do believe there is some work required to glue the sections together in a narrative for Problem Statement and Requirements for zeroconf mcast networks. # Many thanks for the shepherd writeup from Stig Venaas. #GENERIC COMMENTS #================ 13 Abstract 14 15 This document describes a network that requires unique multicast 16 addresses to distribute data. Various challenges are discussed, such 17 as the use of multicast snooping to ensure efficient use of 18 bandwidth, limitations of switch hardware, problems associated with 19 address collisions, and the need to avoid user configuration. After 20 all limitations were considered it was determined that multicast 21 addresses need to be dynamically-assigned by a decentralized, zero- 22 configuration protocol. 23 24 Requirements and recommendations for suitable protocols are listed 25 and specific considerations for assigning IPv4 and IPv6 addresses are 26 reviewed. The document closes with several solutions that are 27 precluded from consideration. GV> Alternative proposal " This document defines the problem space and associated requirements for automatically assigning multicast addresses in zero-configuration ("zeroconf") networking environments. It addresses key challenges, such as address collisions, hardware limitations, multicast snooping inefficiencies, and the need to avoid manual configuration. Based on these challenges, it derives requirements for a lightweight, decentralized protocol capable of dynamically allocating unique multicast group addresses without central coordination. The document presents explicit requirements covering discovery, allocation, conflict detection and resolution, and lease management. It also evaluates considerations specific to IPv6 and IPv4 multicast address ranges, and identifies approaches that are unsuited for zeroconf deployment. This foundation serves as a reference for developing future multicast address allocation protocols that operate autonomously within local networks. " 79 Marine networks contain a combination of sensors, controls, and 80 displays. Installations vary widely depending on the design and 81 intended purpose of the boat and the amount of redundancy required. 82 Sensors on these networks can be a mix of low-cost, low-bandwidth 83 devices, like temperature or fluid sensors, and high-bandwidth 84 devices, like radar, sonar, and video cameras. In most cases, these 85 networks use a single subnet and therefore require layer-2 switches 86 to be deployed. 87 88 The most optimal way to distribute sensor data to all displays on the 89 network is multicast. However, use of traditional switches can be 90 problematic when both high-bandwidth and low-bandwidth devices are 91 installed. Low-bandwidth devices are commonly designed with a low- 92 speed link to reduce cost, and the multicast stream from the high- 93 bandwidth device can overwhelm this link. Switch hardware at the low 94 price points that are acceptable to the market do not support source- 95 specific multicast. Instead, multicast streams are differentiated by 96 destination address and switches with multicast snooping [RFC4541] in 97 a default-block configuration are used to isolate multicast streams 98 to the ports with devices that request the data. 99 100 This technique presents several challenges. First, defining an 101 industry-standard set of pre-allocated addresses is not practical due 102 to the wide variety of network designs. Manually configuring 103 addresses for each device is not a user-friendly solution. MADCAP 104 [RFC2730] could be used to dynamically assign addresses, but its 105 reliance on a dedicated server results in a single point of failure 106 for the system, which is not acceptable for the target environment. 107 Finally, this method is susceptible to link-layer address collisions 108 (see Section 2 for further discussion). 109 110 The desired solution needs to be a decentralized, zero-configuration 111 protocol for dynamically assigning multicast addresses. This 112 document serves as a basis for developing suitable protocols by 113 defining the problem, discussing constraints, and listing 114 requirements. GV> The complete section 1 goes from the assumption that the reader assumes that Marine networks is only an example of zeroconf multicast networks. This can be more explicitly written. What about the below alternative proposal: " Multicast communication is commonly used in networks that need to distribute data from one sender to multiple receivers efficiently. In some environments, such as small or isolated networks, multicast must operate without centralized servers or manual configuration. These are referred to as zero-configuration (zeroconf) multicast networks. One example of such an environment is marine networks, which typically include a mix of sensors, controls, and displays. These networks vary in complexity depending on the size and design of the vessel. Devices may range from low-cost temperature or fluid sensors to high-bandwidth sources such as radar, sonar, or video feeds. Most marine networks are built on a single subnet and rely on Layer 2 Ethernet switches to connect devices. In these networks, multicast is the most efficient method for distributing sensor data to multiple displays. However, challenges arise when high-bandwidth multicast streams overload links to low-bandwidth devices. Cost-effective switches often do not support source-specific multicast (SSM), so IGMP snooping [RFC4541] is used to control multicast delivery. This method introduces limitations, especially in environments where switch hardware lacks advanced multicast filtering capabilities. While marine networks illustrate these issues well, the challenges they face are not unique. Many other zeroconf multicast environments, such as industrial automation, small-scale AV systems, or ad hoc sensor networks, share similar constraints. This document outlines the problem space for zeroconf multicast address allocation, describes the key limitations of current solutions such as MADCAP [RFC2730], and defines a set of requirements for a decentralized, zero-configuration multicast address allocation protocol. " 124 2. Address Collisions 125 126 Link-layer address collisions are a concern in three cases. 127 128 First, many Ethernet chips include the ability to filter out unwanted 129 traffic. This is typically configured by the network stack in 130 response to an application joining a multicast group. Any link-layer 131 address collision would require that the network stack use CPU time 132 to filter out traffic by its network-layer multicast address, which 133 reduces performance. 134 135 Networks that use multicast snooping switches are also susceptible to 136 address collisions. According to Section 4 of [RFC4541], most switch 137 vendors forward multicast traffic based only on the link-layer 138 address (see the results for Q2 and Q3). This means that unwanted 139 data will be transmitted over the link and, depending on the nature 140 of the data, may result in a low-bandwidth link being saturated by a 141 high-bandwidth stream. Additional concerns related to the overlap of 142 IPv6 and link-layer addresses are discussed in [RFC4541], Section 3. 143 144 Functionality of the network infrastructure may also result in 145 address collisions. For example, the switch described in 146 [US6690667B1] uses a hash table with buckets to store forwarding 147 information for each link-layer address. If all of the buckets at a 148 given location in the hash table are used, then any subsequent 149 attempt to use an address that hashes to that same location will 150 fail. GV> " Address collisions are a key concern in multicast networks, particularly when devices rely on zero-configuration operation. Collisions occur when two or more multicast groups are assigned the same link-layer (MAC) address, leading to performance or forwarding issues. This section outlines three scenarios where such collisions can cause problems. First, many Ethernet interfaces allow filtering of multicast traffic directly in hardware. When an application joins a multicast group, the network stack typically programs the hardware to accept only traffic for that group. However, if two groups share the same link-layer address, the hardware cannot distinguish them. The network stack is then forced to process unwanted traffic in software, reducing performance and increasing CPU usage. Second, networks that use multicast snooping switches are particularly vulnerable. As described in [RFC4541], Section 4, many switches forward multicast traffic based solely on the link-layer address, without considering the network-layer group (see the results for Q2 and Q3). In such cases, if two multicast streams share the same MAC address, traffic may be sent to devices that did not request it. This is especially problematic when low-bandwidth links are overwhelmed by high-bandwidth streams. Additional concerns related to the overlap of IPv6 and link-layer addresses are discussed in [RFC4541], Section 3. Third, the internal design of some switches can also contribute to collisions. For example, certain switch implementations [US6690667B1] use hash tables to store forwarding entries based on MAC addresses. If multiple addresses hash to the same location and the table fills up, additional entries may be dropped or rejected, resulting in forwarding failures. These examples highlight why a collision-resistant multicast address allocation mechanism is essential in zeroconf environments. " 152 3. Protocol Requirements 153 154 A decentralized, zero-configuration protocol for dynamic multicast 155 address assignment MUST have the following characteristics: 156 157 1. Does not rely on a single point of failure 158 159 2. Does not depend on user configuration 160 161 3. Coexists with other multicast address assignment protocols 162 163 4. Supports operation on a single subnet 164 165 5. Does not require an Internet connection 166 167 6. Supports multiple applications on the same host 168 169 7. Detects and resolves address collisions 170 171 Note that an extreme case of address collision may occur after a 172 network partition, when intermittent link failure temporarily divides 173 the network into multiple segments. 174 175 A protocol SHOULD ideally have the following characteristics: 176 177 1. Supports operation across multiple subnets 178 179 2. Does not require significant changes to existing standards 180 181 3. Uses functionality commonly available on a variety of platforms 182 4. Uses capabilities commonly provided to unprivileged applications 183 184 5. Avoids depending on configuration data loaded during device 185 manufacture 186 187 6. Minimizes network traffic GV> The text in this section leans upon BCP14 normative language, which does not apply to informational documents as there is no formal procedure. Propose to use the following alternate write-up, slightly adding additional contexts instead: " A protocol intended for decentralized, zero-configuration multicast address assignment is expected to operate in dynamic, infrastructure-free environments. To be effective in such contexts, the protocol is expected to exhibit the following characteristics: 1. Resilience to Failure: The protocol should function without reliance on a single point of failure, ensuring that operation continues even if individual devices or links become unavailable. 2. Zero User Configuration: It should operate without requiring user or administrator configuration, allowing seamless deployment in unmanaged networks. 3. Protocol Coexistence: The design should allow coexistence with other multicast address allocation methods, including both manual assignment and existing dynamic protocols. 4. Single-Subnet Operation: It should support effective operation within a single IP subnet, which is typical in link-local or isolated network environments. 5. No External Connectivity: The protocol should not require Internet access or connectivity to external infrastructure. 6. Host-Level Multiplexing: It should support multiple applications on the same host, each independently allocating and using multicast addresses. 7. Collision Detection and Resolution: The protocol should include mechanisms to detect and resolve multicast address collisions, including those that may occur due to network partitions and subsequent re-merging of segments. Note: In rare cases, collisions may arise after a temporary network partition, when different parts of the network allocate the same multicast address independently. Upon reconnection, such collisions should be detectable and resolved gracefully. In addition to the above, the following characteristics are considered desirable: 1. Multi-Subnet Support: Support for operation across multiple subnets is beneficial in more complex or routed environments. 2. Standards Compatibility: The protocol should aim to minimize the need for changes to existing protocols or standards. 3. Cross-Platform Availability: It should use capabilities that are widely available across platforms and operating systems. 4. Support for Unprivileged Applications: The protocol should function without requiring elevated privileges, enabling broader applicability in user-space applications. 5. Minimal Dependency on Manufacturing Data: It should avoid reliance on pre-loaded configuration or device-specific manufacturing data. 6. Low Overhead: The protocol should minimize the volume and frequency of network traffic generated during normal operation. " 189 4. IPv6 Considerations 190 191 The IPv6 multicast address guidelines specified in [RFC3307] are 192 well-structured and robust. Section 2 defines the lower 32 bits of 193 the IPv6 address, which are mapped directly to the link-layer, as the 194 group ID, and then assigns ranges of group ID values based on how 195 they are allocated. Section 4.3 describes dynamic assignment of 196 group ID values and lists two different approaches (server allocation 197 and host allocation). However, both approaches are assigned the same 198 range of group ID values, which means they cannot coexist without 199 risking an address collision. Also concerning is that the range for 200 dynamic assignment overlaps with the range used for solicited-node 201 multicast addresses (see Section 2.7.1 of [RFC4291]). GV> This section makes it unclear what exactly is the consideration for IPv6. I tried to revise the section, but have the perception certain things are missing or can be explained more accurate. For example, adding an example of the different parts of the group id ranges, or by adding a use case. " The rules for IPv6 multicast addresses, described in [RFC3307], are generally well-organized and reliable. In that document, Section 2 explains that the last 32 bits of an IPv6 multicast address, called the group ID, are mapped directly to the Ethernet MAC address. Different parts of the group ID range are assigned based on how the address is allocated. Section 4.3 of the same RFC describes two ways to assign group IDs dynamically: one where a server assigns addresses, and one where hosts assign addresses themselves. However, both methods use the same group ID range, which creates a risk of address collisions if both are used at the same time. An additional concern is that this dynamic range overlaps with the range used for solicited, node multicast addresses, a special type of multicast used by IPv6 for functions like neighbor discovery (see Section 2.7.1 of [RFC4291]). This overlap increases the risk of unintentional conflicts. " 203 5. IPv4 Considerations 205 Section 6.4 of [RFC1112] recognizes that more than one IPv4 multicast 206 address can be mapped to the same Ethernet multicast address. This 207 is because the lowest 23 bits are mapped to the Ethernet multicast 208 address. A 32-bit IPv4 multicast address has a 4-bit prefix, which 209 leaves 5 bits inconsequential to the operation, or 32 addresses. 211 The guidelines for allocating IPv4 multicast addresses in [RFC5771] 212 did not anticipate a need to avoid address collisions. As such, the 213 recommendation for all new designs using dynamic assignment is to use 214 IPv6. If this is not feasible, then the recommendation is for the 215 protocol to assign addresses from a suitable range in the 216 Administratively Scoped Block (239.0.0.0/8) and be aware of other 217 applications on the network using addresses it may collide with. GV> readability alternative. I like the suggestion to prefer IPv6 :-) " In IPv4, multicast addresses can sometimes cause conflicts at the Ethernet (link-layer) level. As explained in Section 6.4 of [RFC1112], this happens because only the lower 23 bits of an IPv4 multicast address are used to generate the Ethernet multicast address. Since an IPv4 multicast address is 32 bits and starts with a fixed 4-bit prefix, this means up to 32 different multicast IP addresses can map to the same Ethernet address. As a result, devices may receive multicast traffic they didn’t ask for. The address allocation guidelines in [RFC5771] did not account for this type of collision when they were created. Because of this limitation, the recommended approach for new designs that need dynamic multicast address assignment is to use IPv6 instead of IPv4. However, if using IPv4 is necessary, then multicast addresses should be chosen carefully from within the Administratively Scoped Block (239.0.0.0/8). Additionally, the protocol should try to avoid using addresses that may already be in use by other applications on the same network, to minimize the risk of conflicts. " 219 6. Excluded Solutions 220 221 The prefix for IPv4 and IPv6 multicast messages being transmitted on 222 Ethernet are specified in [RFC1112], Section 6.4 and [RFC2464], 223 Section 7, respectively. Allowing a different prefix would support 224 at least two solutions that are being excluded from consideration. 225 226 First, reducing the size of the prefix would increase the size of the 227 group ID, thereby reducing the probability of an address collision. 228 229 Because link-layer addresses are only relevant on the local subnet, 230 it would also be possible to develop a new protocol to dynamically 231 map network-layer multicast addresses to link-layer multicast 232 addresses in an operation somewhat analogous to DHCP. Multicast 233 packets routed from outside the network could have the address mapped 234 at ingress without any assignment protocol. 235 236 Ultimately, it was determined that using a different prefix would be 237 a significant change, and would be unlikely to receive widespread 238 platform support for quite some time. 239 240 With IPv4, assigning 32 separate address ranges in the registry could 241 prevent address collisions. However, this approach was rejected 242 because of the caution in [RFC5771] against further assignments due 243 to the relatively small size of the IPv4 multicast address space. GV> " The way multicast IP addresses are mapped to Ethernet (link-layer) multicast addresses is already defined in existing standards: [RFC1112] for IPv4 and [RFC2464] for IPv6. These standards specify a fixed prefix used in creating the Ethernet multicast address. Changing this prefix would open the door to new solutions, but those are not being considered here for practical reasons. One idea is to reduce the size of the fixed prefix, which would leave more bits available for the group ID. This would make address collisions less likely. Another idea is to create a new protocol that dynamically maps multicast IP addresses to Ethernet addresses, similar to how DHCP assigns IP addresses. This protocol could work locally on a subnet, and routers could adjust the mapping for incoming multicast traffic at the network edge. However, these ideas would require significant changes to how network devices handle multicast traffic. Since existing hardware and operating systems are built around the current standards, it’s unlikely that such changes would be widely supported anytime soon. Another potential solution for IPv4 was to assign 32 separate, non-overlapping address ranges to avoid collisions altogether. But this was rejected because [RFC5771] discourages new allocations, given how limited the IPv4 multicast address space already is. " Kind Regards, Gunter Van de Velde Routing Area Director ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. _______________________________________________ pim mailing list -- [email protected] To unsubscribe send an email to [email protected]