Network Working Group                                        N. KarstensInternet-Draft                                                    GarminIntended status: Standards Track                            D. FarinacciExpires: 3 April 2026                                        lispers.net                                                              M. McBride                                                               Futurewei                                                       30 September 2025       Zero-Configuration Assignment of IPv6 Multicast Addresses               draft-ietf-pim-ipv6-zeroconf-assignment-07Abstract   Describes a zero-configuration protocol for dynamically assigning   IPv6 multicast addresses.  Applications randomly assign multicast   group IDs from a specified range and prevent collisions by using   Multicast DNS (mDNS) to publish records in a new "eth-addr.arpa"   special-use domain.  This protocol satisfies all of the criteria   listed in draft-ietf-pim-zeroconf-mcast-addr-alloc-ps.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 3 April 2026.Copyright Notice   Copyright (c) 2025 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   and restrictions with respect to this document.  Code ComponentsKarstens, et al.          Expires 3 April 2026                  [Page 1]Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs  September 2025   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.  Veto Records  . . . . . . . . . . . . . . . . . . . . . .   4   3.  Evaluation of Solution  . . . . . . . . . . . . . . . . . . .   4   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5     4.1.  Domain Name Reservation Considerations  . . . . . . . . .   5   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   5   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   71.  Introduction   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] 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.   Note that DNS-based Service Discovery (DNS-SD) [RFC6763] uses several   different DNS record types, published using either Unicast or   Multicast DNS, to facilitate service discovery.  This document uses a   single DNS record type (PTR), published using Multicast DNS, to   coordinate IPv6 multicast address assignment in a zero-configuration   environment.  The DNS 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 in favor of a new protocol   with the expectation that functionality for address assignment can be   achieved using existing mDNS implementations.   This protocol is well-suited for networks that rely on IPv6 multicast   and already deploy mDNS.Karstens, et al.          Expires 3 April 2026                  [Page 2]Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs  September 20251.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   When an application is preparing to transmit a multicast stream, it   first generates a random group ID in the range 0x90000000-0x9FFFFFFF,   which IANA is REQUESTED to assign from the "Dynamic Multicast Group   IDs" registry (see Section 4).  It combines this with the Interface   Identifier (IID) of the intended source address for the multicast   stream to generate a link-scoped IPv6 multicast address [RFC4489].   The application then calculates the multicast Ethernet address that   will be used to transmit the data ([RFC2464], Section 7) and uses   that to construct a string like a reverse-mapping domain, using a new   "eth-addr.arpa" special-use domain.   For example, given a source address of fe80::a12:34ff:fe56:7890, the   IPv6 multicast address may be ff32:00ff:a12:34ff:fe56:7890:9abc:def0,   the group ID 9abc:def0, the multicast Ethernet address   33:33:9A:BC:DE:F0, and the resulting string is   "0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa".   The application then uses the mDNS probing algorithm described in   [RFC6762], Section 8.1 to continuously query for a PTR record with   the same name as the generated string.  If the probing algorithm   completes without any conflict, then the application begins   advertising its own unique PTR record using that name.  The PTRDNAME   field consists of a unique application identifier, in the form of a   DNS label, followed by the device's 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 A/AAAA records may also be published for this host name   ("example.local."), though this is not a requirement for this design.   Because this protocol is focused specifically on allocating IPv6   multicast addresses, records MUST be published using the IPv6   multicast address for mDNS, but MAY also be published using the IPv4   multicast address for mDNS.   Once the PTR record is advertised, the host may then begin   transmitting multicast data using the generated address.Karstens, et al.          Expires 3 April 2026                  [Page 3]Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs  September 2025   The application shall retain the group ID value and use it the next   time the multicast stream is transmitted.  This allows the network to   quickly settle on a configuration that will never have another   collision as long as the network is unchanged.   If a conflict is detected at any point, then the application stops   transmitting that multicast stream and starts the process over using   a different group ID.   The host network stack may optionally 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 responds the same as a collision.   While intended primarily for allocating IPv6 multicast addresses on   the same subnet (link-local scope), the same technique could also   apply to a larger network as long as mDNS traffic is routed between   subnets (for any scope excluding global scope).2.1.  Veto Records   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] describes collisions   occurring in the network infrastructure.  When an infrastructure   component detects a 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 and the PTRDNAME field set to the string "veto",   formatted as a DNS label.  The veto record is published without   probing.   Applications respond to the conflict the same as to a collision.  The   application retains its new group ID, so the same conflict is not   repeated in the future.3.  Evaluation of Solution   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] contains a list of   criteria to evaluate potential solutions.  The protocol described in   this document satisfies all of the required criteria.   However, because mDNS is designed to be a low-bandwidth protocol, it   can take a signficant amount of time to detect a 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.Karstens, et al.          Expires 3 April 2026                  [Page 4]Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs  September 2025   It is a greater concern on networks where multicast streams may be   established at any time.  Deployments on these networks may consider   engaging a detection mechanism and prompting hosts to send   unsolicited mDNS response messages when the partition is repaired.   The protocol described in this document also satisfies the   recommended criteria, to the extent that a deployment supports   publishing mDNS-based DNS-SD records across multiple subnets (see   [RFC8766]).4.  IANA Considerations   IANA should allocate a block of group IDs from the "Dynamic Multicast   Group IDs" registry in the "IPv6 Multicast Address Space Registry"   registry group that was created by   [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id].  The range of this   block should be 0x90000000-0x9FFFFFFF and the description should be   the title of this document.   The special-use domain "eth-addr.arpa" should be registered in the   .arpa registry (https://www.iana.org/domains/arpa) and the "Special-   Use Domain Names" registry (https://www.iana.org/assignments/special-   use-domain-names).  This domain should not be delegated.4.1.  Domain Name Reservation Considerations   The "eth-addr.arpa." domain is effectively a reverse-mapping domain   and so has the same considerations as the reverse-mapping domains   listed in [RFC6761], Section 6.1.5.  Security Considerations   This algorithm only works in environments where all hosts are   cooperating.  Malicious hosts could deny service by repeatedly   triggering address conflicts.6.  Acknowledgement   Special thanks to the National Marine Electronics Association for   their contributions in developing marine industry standards and their   support for this research.   Thanks also to the members of the PIM working group for their early   brainstorming sessions and review of this draft, and to Esko Dijk for   his review of the draft.7.  ReferencesKarstens, et al.          Expires 3 April 2026                  [Page 5]Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs  September 20257.1.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <https://www.rfc-editor.org/info/rfc2119>.   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet              Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,              <https://www.rfc-editor.org/info/rfc2464>.   [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,              <https://www.rfc-editor.org/info/rfc4489>.   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",              RFC 6761, DOI 10.17487/RFC6761, February 2013,              <https://www.rfc-editor.org/info/rfc6761>.   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,              DOI 10.17487/RFC6762, February 2013,              <https://www.rfc-editor.org/info/rfc6762>.   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,              May 2017, <https://www.rfc-editor.org/info/rfc8174>.7.2.  Informative References   [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id]              Karstens, N., Farinacci, D., and M. McBride, "Updates to              Dynamic IPv6 Multicast Address Group IDs", Work in              Progress, Internet-Draft, draft-ietf-pim-updt-ipv6-dyn-              mcast-addr-grp-id-07, 25 August 2025,              <https://datatracker.ietf.org/doc/html/draft-ietf-pim-              updt-ipv6-dyn-mcast-addr-grp-id-07>.   [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps]              Karstens, N., Farinacci, D., and M. McBride, "Zeroconf              Multicast Address Allocation Problem Statement and              Requirements", Work in Progress, Internet-Draft, draft-              ietf-pim-zeroconf-mcast-addr-alloc-ps-07, 30 September              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-              pim-zeroconf-mcast-addr-alloc-ps-07>.Karstens, et al.          Expires 3 April 2026                  [Page 6]Internet-Draft   Zeroconf Assignment of IPv6 Mcast Addrs  September 2025   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,              <https://www.rfc-editor.org/info/rfc6763>.   [RFC8766]  Cheshire, S., "Discovery Proxy for Multicast DNS-Based              Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June              2020, <https://www.rfc-editor.org/info/rfc8766>.Authors' Addresses   Nate Karstens   Garmin International, Inc.   1200 E. 151st St.   Olathe, KS 66062-3426   United States of America   Email: nate.karstens@gmail.com   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.comKarstens, et al.          Expires 3 April 2026                  [Page 7]