Network Working Group N. Karstens Internet-Draft Garmin Intended status: Standards Track D. Farinacci Expires: 26 April 2027 lispers.net M. McBride Futurewei 23 October 2026 Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS draft-ietf-pim-ipv6-zeroconf-assignment-15 Abstract This document describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses that are unique at the link-layer. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish resource records under a new "eth-addr.arpa" domain. This protocol satisfies all of the requirements and most of the desired characteristics listed in RFC 10019. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 April 2027. Copyright Notice Copyright (c) 2026 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 (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Karstens, et al. Expires 26 April 2027 [Page 1] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Group ID Selection . . . . . . . . . . . . . . . . . . . 4 2.2. Address Generation . . . . . . . . . . . . . . . . . . . 4 2.3. Domain Name Assembly . . . . . . . . . . . . . . . . . . 5 2.4. Record Construction . . . . . . . . . . . . . . . . . . . 5 2.5. Probing . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Announcing and Responding . . . . . . . . . . . . . . . . 6 2.7. Conflict Detection and Resolution . . . . . . . . . . . . 6 2.8. Transmitting . . . . . . . . . . . . . . . . . . . . . . 7 2.9. Optimization . . . . . . . . . . . . . . . . . . . . . . 7 2.10. Defending . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Veto Records . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Use on Networks with Multiple Subnets . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. Domain Name Reservation Considerations . . . . . . . . . 9 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 7. Operational Considerations . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Example mDNS Messages . . . . . . . . . . . . . . . 14 Appendix B. Evaluation of Solution . . . . . . . . . . . . . . . 17 B.1. Collision Detection After Partition Repair . . . . . . . 19 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction [RFC10019] includes a problem statement and requirements for a zero- configuration method for dynamically assigning multicast addresses. This document describes a process that fulfills these requirements by having applications randomly assign IPv6 multicast group IDs from a specified range and using mDNS [RFC6762] to prevent collisions in both IPv6 and link-layer addresses. Note that DNS-based Service Discovery (DNS-SD) [RFC6763] uses several different DNS resource record types, published using either Unicast or Multicast DNS, to facilitate service discovery. This document Karstens, et al. Expires 26 April 2027 [Page 2] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 uses a single DNS resource record type (PTR), published using Multicast DNS (mDNS), to coordinate IPv6 multicast address assignment in a zero-configuration environment. The DNS resource records in this protocol may be published alongside records for other domain name services, such as DNS-SD, or they may be published alone. mDNS is used rather than a new protocol with the expectation that functionality for address assignment can be achieved using existing mDNS implementations. The protocol described in this document is well-suited for networks that rely on IPv6 multicast and already deploy mDNS. This document makes IANA assignments for use on Ethernet and other protocols based on the IEEE 802 architecture. It may be adapted for use with other link layers, but that is outside the scope of this document. As mentioned in [RFC6762], Section 21, mDNS is an algorithm that assumes cooperating participants. Due to its reliance on mDNS, this assumption applies to the protocol described in this document as well. 1.1. Requirements Language 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Procedure This section specifies how an application dynamically generates an IPv6 multicast address, uses mDNS to coordinate use of that address with other applications on the network, and begins transmitting its multicast stream. Because this protocol is focused specifically on allocating IPv6 multicast addresses, applications MUST send and receive mDNS messages using the IPv6 multicast address for mDNS (ff02::fb). In order to be compatible with existing mDNS implementations that require IPv4, applications MAY also send and receive mDNS messages using the IPv4 multicast address for mDNS (224.0.0.251). These addresses are documented in [RFC6762], Section 22. mDNS implementations used with this protocol MUST coordinate with all applications using the same mDNS implementation, as well as with other mDNS implementations running on the same host. Such coordination ensures that conflicts arising from independently generated, identical group IDs are detected during the probing phase, Karstens, et al. Expires 26 April 2027 [Page 3] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 allowing the affected applications to select alternate group IDs. Note that coordination between mDNS implementations running on the same host tends to happen naturally if transmitted multicast packets are looped back into the receive pipeline. The process an application uses from initialization to transmitting a multicast stream is divided into a series of steps, outlined below. 2.1. Group ID Selection When an application is preparing to transmit a multicast stream, it begins by selecting an IPv6 multicast group ID. If the application is either 1) transmitting a multicast stream for the first time or 2) responding to an address collision, then the application MUST select a random multicast group ID value from the range 0x90000000-0x9FFFFFFF. Section 5 details the request to assign this range from the "Dynamic Multicast Group IDs" registry. If the application has previously transmitted the multicast stream, then the selected multicast group ID is already in persistent storage (Optimization, Section 2.9). The application MUST proceed using the stored value. Note that the range of possible group ID values means that the probability that another application has chosen the same group ID is (n / 2^28), where n is the number of applications on the network. 2.2. Address Generation Once the IPv6 multicast group ID has been selected, the application MUST use this to generate two multicast addresses: 1. IPv6 Multicast Address This is a link-scoped IPv6 multicast address, calculated by combining the multicast group ID with the Interface Identifier (IID) of the link-local unicast address of the interface used to transmit the multicast stream, according to the format given in [RFC4489], Section 3. 2. Multicast Ethernet Address This is the corresponding multicast Ethernet address that will be used to transmit the data. It is calculated from the IPv6 multicast address, as described in [RFC2464], Section 7. Karstens, et al. Expires 26 April 2027 [Page 4] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 For example, consider a source address of fe80::a12:34ff:fe56:7890. If the selected group ID is 9abc:def0, then the calculated IPv6 multicast address would be ff32:ff:a12:34ff:fe56:7890:9abc:def0 and the multicast Ethernet address would be 33:33:9A:BC:DE:F0. 2.3. Domain Name Assembly Once the multicast Ethernet address is determined, the application MUST use this to assemble a domain name by encoding nibbles from the multicast Ethernet address as a sequence of lower-case hexadecimal digits, separated by dots, in reverse order, and ending with the suffix ".eth-addr.arpa" (a new domain in the .arpa registry). Considering the example in Address Generation (Section 2.2), the resulting domain name would be "0.f.e.d.c.b.a.9.3.3.3.3.eth- addr.arpa". Note that this is similar to how DNS resource records used for reverse mapping IPv6 addresses are created ([RFC3596], Section 2.5). As such, this document reserves the domain "9.3.3.3.3.eth-addr.arpa." as a Special-Use Domain in the "Special-Use Domain Names" registry (Section 5). The "3.3.3.3" component of this is taken from the 33:33 prefix used for mapping IPv6 multicast addresses to multicast Ethernet addresses and the "9" component indicates a multicast group ID in the range 0x90000000-0x9FFFFFFF. 2.4. Record Construction Once the domain name is assembled, the application MUST construct a unique PTR record using that domain name. The PTRDNAME field of this record MUST consist of a unique application identifier, in the form of one or more DNS labels, followed by the device's currently claimed mDNS host name (for example, "application.example.local."). Integrating a unique identifier in this manner allows for multiple applications to be on the same host. Note that the host will publish A/AAAA records for this same host name (for example, "example.local.") as part of its normal mDNS operation, though this is not a requirement for this design. To allow for the creation of veto records (Section 3), the first DNS label of the application identifier MUST NOT exceed 58 octets in length. This reflects the 63-octet limit specified in [RFC1035], Section 2.3.4 while also reserving space for a 5-octet suffix. Due to the presence of a host name in the PTRDNAME, the TTL value for the resource record SHOULD be 120. This aligns with guidance in [RFC6762], Section 10. Karstens, et al. Expires 26 April 2027 [Page 5] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 2.5. Probing After the PTR record is constructed, the application MUST use the mDNS probing algorithm described in [RFC6762], Section 8.1 to probe for a PTR record with the same name. Due to the large range of values for group IDs, it is unlikely that two applications would randomly choose the same group ID and begin probing at the same time. However, in that event, the conflict MUST be resolved according to the procedure in [RFC6762], Section 8.2. The loser of the conflict MUST return to Group ID Selection (Section 2.1) and choose a different group ID. 2.6. Announcing and Responding If the probing algorithm started in Probing (Section 2.5) completes without any conflict, then the application MUST announce the PTR record according to the procedure in [RFC6762], Section 8.3 and MUST respond to queries for the PTR record according to [RFC6762], Section 6. Because the PTR record was constructed with the host name in the PTRDNAME field (Record Construction, Section 2.4), if the host name changes due to a conflict, the host MUST announce an updated PTR record with the PTRDNAME field using the new host name. In accordance with the final paragraph of [RFC6762], Section 8.1, the host SHOULD skip Probing (Section 2.5) because it has already verified ownership of the domain name (Domain Name Assembly, Section 2.3). This process maintains accurate state while avoiding unnecessary traffic on the network. 2.7. Conflict Detection and Resolution The application MUST start a continuous query for the PTR record according to [RFC6762], Section 5.2. This helps detect a conflict in the event of a network partition and repair (Appendix B.1). If a conflict is detected at any time, then the application MUST resolve the conflict according to [RFC6762], Section 9. The losing application MUST stop transmitting that multicast stream and return to Group ID Selection (Section 2.1), choosing a new group ID. As before, this new group ID is also retained in persistent storage, overwriting any group ID previously saved for this multicast stream. The host network stack may monitor the network for traffic that uses the same destination multicast Ethernet address, but a different destination multicast IPv6 address. If this is detected, then the application MUST stop transmitting that multicast stream and return to Group ID Selection (Section 2.1), choosing a new group ID. It is Karstens, et al. Expires 26 April 2027 [Page 6] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 not necessary for both applications to select a new address, the goal is to have each multicast stream using a unique multicast address. No method to coordinate this between hosts is necessary and this protocol does not specify one. 2.8. Transmitting Once the PTR record is advertised and the continuous query started, the host MAY then begin transmitting multicast data using the multicast addresses from Address Generation (Section 2.2). 2.9. Optimization The application MUST retain the group ID value in persistent storage and use it the next time the multicast stream is transmitted. Any metadata associated with the stream, such as the network interface used to transmit, MUST also be stored. Keeping these values allows the network to quickly settle on a configuration and reduces the likelihood of future collisions, as long as the network is unchanged. Note that retaining these values does not permit the application to skip any of the preceding steps. This is consistent with [RFC6762], Section 10.2 and allows the application to recover from any network changes that may have occurred when it was offline. 2.10. Defending The application MUST defend the PTR record from probes as described in [RFC6762], Section 6. 3. Veto Records The network infrastructure may contain managed switches that maintain an internal multicast address table and use multicast snooping to intelligently direct multicast streams to interested receivers ([RFC4541]). The potential for address collisions in these types of managed switches is discussed in [RFC10019], Section 2. Veto records are used to resolve these address collisions. When a managed switch detects a multicast address collision it cannot resolve, it triggers a conflict with the application by publishing a veto record. A veto record is a unique PTR record using the string generated for the address as its name. The veto record's PTRDNAME field is created by appending the string "-veto" to the first DNS label that appears in the PTRDNAME field of the PTR record that caused the address collision (for example, "application-veto"). This Karstens, et al. Expires 26 April 2027 [Page 7] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 technique results in a veto PTR record that is always lexicographically later than the PTR record from the application (specifically, the first DNS label is always longer, so the first byte of the RDATA, which contains the length, always contains a larger value). In turn, this causes the veto record to always win the conflict resolution described in [RFC6762], Sections 8.2 and 9. Managed switches MUST publish veto records without probing. The TTL value for the veto record SHOULD be 120. Applications MUST respond to the conflict the same as to a collision, eventually resulting in a new group ID being acquired. As before, the application retains its new group ID in persistent storage, ensuring the same conflict is not repeated in the future. As such, it is unnecessary to store vetoes to persistent storage. If a managed switch transmitting a veto record determines that the PTR record for the address causing the conflict has become invalid (either due to receiving a goodbye packet or to record expiry), then it MUST query the network for the PTR record. If the managed switch does not receive a query response containing the PTR record after 10 seconds (as per [RFC6762], Section 10.4), then the managed switch MUST delay a random amount of time in the range 20-120 ms and then send a goodbye packet that invalidates the veto record. 4. Use on Networks with Multiple Subnets The link-scoped IPv6 multicast address created in Address Generation (Section 2.2) cannot be forwarded beyond the local link. Forwarding a multicast stream to other subnets requires a unicast-prefix based IPv6 multicast address ([RFC3306]) and multicast routing; procedures for doing so are outside the scope of this document. The protocol's reliance on cooperating hosts (Section 8) will always make it unsuited for use on the global Internet. [RFC8815] recommends Source-Specific Multicast in this environment. 5. IANA Considerations IANA should allocate a block of group IDs from the "Dynamic Multicast Group IDs" registry [REGISTRY] in the "IPv6 Multicast Address Space" registry group that was created by [RFC10028]. The range of this block should be 0x90000000-0x9FFFFFFF and the description should be "Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS". Karstens, et al. Expires 26 April 2027 [Page 8] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 The domain "eth-addr.arpa" should be registered in the .arpa registry (https://www.iana.org/domains/arpa). The usage should be "For mapping Ethernet addresses to local domain names for Zero- Configuration Assignment of IPv6 Multicast Addresses" and the reference should be this document. In accordance with [RFC3172], Section 3, the "eth-addr.arpa" domain is not delegated because it only has local significance. The only names this document defines under "eth-addr.arpa" are those under "9.3.3.3.3.eth-addr.arpa" (below). The Special-Use Domain "9.3.3.3.3.eth-addr.arpa." should be registered in the "Special-Use Domain Names" registry (https://www.iana.org/assignments/special-use-domain-names). Like other Multicast DNS domains ([RFC6762], Section 12), this domain is not delegated. 5.1. Domain Name Reservation Considerations [RFC6761], Section 5 includes a list of questions that must be answered when reserving a new Special-Use Domain Name. The answers to these questions for the "9.3.3.3.3.eth-addr.arpa." Special-Use Domain, and any names falling within this domain, are as follows: 1. Users are free to use these names as they would for any other reverse mapping domain. Because this mapping is closely related to the local network, users should be aware that these names are likely to yield different results on different networks. 2. Application software SHOULD recognize these names as a reverse mapping domain and MAY associate them with the protocol described in this document. This is to avoid user confusion. 3. Name resolution APIs and libraries SHOULD recognize these names as being used exclusively with mDNS, and so SHOULD NOT send queries for these names to their configured unicast DNS server(s). This is to avoid unnecessary traffic to the name server. 4. Caching DNS servers SHOULD recognize these names as being used exclusively with mDNS, SHOULD NOT attempt to look up resource records associated with these names, and SHOULD respond to any query with NXDOMAIN. This is to avoid unnecessary traffic to the name server. Karstens, et al. Expires 26 April 2027 [Page 9] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 5. Authoritative DNS servers SHOULD recognize these names as being used exclusively with mDNS and SHOULD respond to any query with NXDOMAIN. This is to avoid unnecessary traffic to the name server. 6. DNS server operators MUST NOT configure an authoritative DNS server to answer queries for these names. 7. DNS Registries/Registrars MUST NOT register "9.3.3.3.3.eth- addr.arpa." names. 6. Implementation Status Note to RFC Editor: please remove this entire section before publication, as well as the reference to [RFC7942]. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". A prototype for Linux using Avahi is available at . The main program in this repository allocates a single IPv6 multicast address from a specified group ID. The repository also contains a README with instructions on how to simulate a network partition. This technology has been implemented in production in Garmin's GPSMAP 9000 series of marine multifunction displays. Karstens, et al. Expires 26 April 2027 [Page 10] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 7. Operational Considerations Scalability of mDNS is an area of ongoing research and improvement ([RFC7558]). The protocol described in this document is subject to similar constraints. Under normal operating conditions, mDNS traffic is expected to grow linearly with the number of multicast streams. The protocol uses implicit availability: if an application does not receive any indication that an address is in use, then it assumes that the address is available for its own use. Because this coordination occurs using mDNS, any filtering of mDNS traffic by the host or network would prevent applications from coordinating use of multicast addresses. This may result in address collisions. Applications SHOULD keep timestamped logs of the following events to help troubleshoot issues with the protocol: * Selected group ID (Section 2.1) * Generated address (Section 2.2) * Conflicts encountered during probing (Section 2.5) * Conflicts detected after announcing (Section 2.7) * Multicast stream transmission (Section 2.8) Although Section 2.9 requires maintaining a persistent state, this functionality is nonetheless an optimization. The protocol is resilient to cases where none of the applications begin with persistent state (due to initial startup or clearing memory) and also to cases where all of the applications begin with the same persistent state (due to cloning a configuration). Although some of these cases do increase the likelihood that applications will experience a collision, the network will eventually reach a steady state. As such, operators have flexibility to determine when the expected behavior is to discard the persistent state and start over. When a collision occurs, Section 2.7 requires applications to cease transmitting until a new address is acquired. This process results in a brief pause in the multicast stream. This document does not specify a YANG model due to the decentralized, zero-configuration nature of the protocol. Karstens, et al. Expires 26 April 2027 [Page 11] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 8. Security Considerations Due to its reliance on mDNS, the Security Considerations for mDNS ([RFC6762], Section 21) apply to this document as well. As with mDNS itself, this protocol only works in environments where all hosts are cooperating. There are two types of messages that a bad actor could use to attack the network: 1. Conflict Response A bad actor could monitor the network for applications probing for "9.3.3.3.3.eth-addr.arpa" PTR records and repeatedly generate conflicting response messages, preventing the application from finding an unused address. 2. Veto Records A bad actor could generate veto records for addresses already allocated, repeatedly forcing the application to find a new address. Both message types would prevent the application from being able to transmit its multicast stream, denying service to the multicast group. Repeatedly forcing the application to attempt new addresses also increases network traffic. The protocol's use of implicit availability means that a bad actor that is able to filter mDNS traffic could neutralize the ability of applications to use mDNS to prevent collisions. In most networks, the probability of a random collision is low. Where hosts cannot rule out non-cooperating participants, the protections prescribed in [RFC6762], Section 21 apply. 9. References 9.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Karstens, et al. Expires 26 April 2027 [Page 12] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . [RFC4489] Park, J., Shin, M., and H. Kim, "A Method for Generating Link-Scoped IPv6 Multicast Addresses", RFC 4489, DOI 10.17487/RFC4489, April 2006, . [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC10028] Karstens, N., Farinacci, D., and M. McBride, "Updates to Dynamic IPv6 Multicast Address Group IDs", RFC 10028, DOI 10.17487/RFC10028, August 2026, . 9.2. Informative References [REGISTRY] Internet Assigned Numbers Authority, "Dynamic Multicast Group IDs Registry", . [RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, . [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, September 2002, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, . Karstens, et al. Expires 26 April 2027 [Page 13] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, "Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, DOI 10.17487/RFC7558, July 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8815] Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert, "Deprecating Any-Source Multicast (ASM) for Interdomain Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815, August 2020, . [RFC10019] Karstens, N., Farinacci, D., and M. McBride, "Zeroconf Multicast Address Allocation Problem Statement and Requirements", RFC 10019, DOI 10.17487/RFC10019, July 2026, . Appendix A. Example mDNS Messages This section illustrates the DNS message fields for the mDNS messages described in this document. The examples depict individual messages, not complete exchanges. The mDNS message format is specified in Section 18 of [RFC6762]. All domain names are fully qualified. The resource record TTL is 120 seconds in these examples; this value is illustrative. RDLENGTH values assume that PTRDNAME is encoded without DNS name compression. IPv6 and UDP headers are not shown. The encoded QCLASS value includes the unicast-response (QU) bit. The encoded resource record CLASS value includes the cache-flush bit. These bits are shown separately from the underlying DNS class, IN. Karstens, et al. Expires 26 April 2027 [Page 14] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 Figure 1 shows a probe for the PTR record. The question uses QTYPE ANY, and the proposed record appears in the Authority Section. This corresponds with the operation described in Section 2.5. Header: ID: 0 Flags: 0x0000 (all flags clear) QDCOUNT: 1 ANCOUNT: 0 NSCOUNT: 1 ARCOUNT: 0 Question Section: QNAME: 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa. QTYPE: ANY (255) QCLASS: IN (1) QU bit: 1 Encoded QCLASS: 0x8001 Answer Section: (empty) Authority Section: NAME: 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa. TYPE: PTR (12) CLASS: IN (1) Cache-flush bit: 0 Encoded CLASS: 0x0001 TTL: 120 RDLENGTH: 27 PTRDNAME: application.example.local. Additional Section: (empty) Figure 1: PTR Record Probe Figure 2 shows an announcement of the application PTR record following successful probing. The record appears in the Answer Section with the cache-flush bit set. This corresponds with the operation described in Section 2.6. Karstens, et al. Expires 26 April 2027 [Page 15] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 Header: ID: 0 Flags: 0x8400 (QR=1, AA=1; other flags clear) QDCOUNT: 0 ANCOUNT: 1 NSCOUNT: 0 ARCOUNT: 0 Question Section: (empty) Answer Section: NAME: 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa. TYPE: PTR (12) CLASS: IN (1) Cache-flush bit: 1 Encoded CLASS: 0x8001 TTL: 120 RDLENGTH: 27 PTRDNAME: application.example.local. Authority Section: (empty) Additional Section: (empty) Figure 2: PTR Record Announcement Figure 3 shows an announcement of the veto PTR record. The owner name is unchanged, but the PTRDNAME identifies the veto. This corresponds with the operation described in Section 3. Karstens, et al. Expires 26 April 2027 [Page 16] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 Header: ID: 0 Flags: 0x8400 (QR=1, AA=1; other flags clear) QDCOUNT: 0 ANCOUNT: 1 NSCOUNT: 0 ARCOUNT: 0 Question Section: (empty) Answer Section: NAME: 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa. TYPE: PTR (12) CLASS: IN (1) Cache-flush bit: 1 Encoded CLASS: 0x8001 TTL: 120 RDLENGTH: 18 PTRDNAME: application-veto. Authority Section: (empty) Additional Section: (empty) Figure 3: Veto PTR Record Announcement Appendix B. Evaluation of Solution [RFC10019] contains a list of criteria to evaluate potential solutions. The following is an analysis of how this protocol satisfies the requirements listed in that document: [REQ-1] Unique Address Assignment: Use of the protocol results in a unique address being assigned to the multicast group at both the network and link layers. [REQ-2] Resilience to Single Points of Failure: The protocol uses mDNS, which uses a peer-to-peer communication model and so has no single points of failure, as long as network connectivity is not interrupted. [REQ-3] Zero User Configuration: The protocol operates without requiring user or administrator configuration. [REQ-4] Coexistence with Multicast Address Allocation Solutions: This document assigns a range of group IDs from the "Dynamic Multicast Group IDs" registry for use with the protocol, which allows the protocol to coexist with other multicast IP address allocation solutions ([RFC10028]). Karstens, et al. Expires 26 April 2027 [Page 17] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 [REQ-5] Single-Subnet Operation: The protocol supports operation within a single IPv6 subnet. [REQ-6] No External Connectivity: The protocol does not require Internet access or connectivity to external infrastructure. [REQ-7] Supports Multiple Host Applications: Multiple applications on the same host are supported by 1) incorporating a unique application identifier into the PTR record's PTRDNAME field and by 2) requiring the mDNS implementation(s) on a host to facilitate interaction between those applications. [REQ-8] Collision Detection and Resolution: The protocol includes a mechanism to detect and resolve multicast address collisions at both the network and link layers. Appendix B.1 contains additional discussion about detecting and resolving collisions after a network partition is repaired. The following is an analysis of how this protocol satisfies the desirable characteristics listed in [RFC10019]: [CONS-1] Multi-Subnet Support: Operating the protocol across multiple subnets is outside the scope of this document (Section 4). [CONS-2] Standards Compatibility: The protocol uses existing protocols without requiring any changes. [CONS-3] Cross-Platform Availability: The protocol uses mDNS, which is implemented on many host platforms and operating systems. [CONS-4] Minimal Dependency on Manufacturing Data: The protocol does not rely on preloaded configuration or device-specific manufacturing data. [CONS-5] Low Overhead: The protocol uses mDNS, which is designed to minimize the volume and frequency of network traffic generated during normal operation. [CONS-6] Advertisement: This document does not prescribe any mechanism for advertising the IPv6 address used for the multicast stream. However, because the protocol already uses mDNS, a natural option for doing so would be to use DNS-SD ([RFC6763]) to advertise a "_udp" service and publish the address used for the multicast stream in a TXT record. Karstens, et al. Expires 26 April 2027 [Page 18] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 [CONS-7] Network Topology: Veto records ensure that the protocol works regardless of the underlying topology and adjacencies. B.1. Collision Detection After Partition Repair A network partition occurs when one part of a network is temporarily unable to communicate with another part of the network. This may happen, for example, if a switch goes offline. A partition repair happens when communication is fully restored to all parts of the network. Because mDNS is designed to be a low-bandwidth protocol, it can take a significant amount of time to detect a resource record collision after a network partition is repaired. This is not a concern on networks where all multicast streams are established before any likely partition event because all group IDs will have been selected and stored for future use. It is a greater concern on networks where multicast streams may be established at any time. Deployments on these networks may consider engaging supplemental detection and resolution mechanisms. Specifics of this functionality are open to future enhancement, but are considered out-of-scope for this document. Acknowledgement Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this work. Thanks also to the members of the PIM working group for their early brainstorming sessions and review of this draft, to Esko Dijk for his review of the draft, and to Gunter Van de Velde for his review and suggestions. Authors' Addresses Nate Karstens Garmin International, Inc. 1200 E. 151st St. Olathe, KS 66062-3426 United States of America Email: nate.karstens@gmail.com Karstens, et al. Expires 26 April 2027 [Page 19] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs October 2026 Dino Farinacci lispers.net San Jose, CA United States of America Email: farinacci@gmail.com Mike McBride Futurewei United States of America Email: michael.mcbride@futurewei.com Karstens, et al. Expires 26 April 2027 [Page 20]