Network Working Group N. Karstens Internet-Draft Garmin International Intended status: Standards Track D. Farinacci Expires: 24 January 2025 lispers.net M. McBride Futurewei 23 July 2024 Zero-Configuration Assignment of IPv6 Multicast Addresses draft-ietf-pim-ipv6-zeroconf-assignment-02 Abstract Describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses. Applications randomly assign multicast group IDs from a reserved range and prevent collisions by using 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 24 January 2025. Copyright Notice Copyright (c) 2024 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 Components Karstens, et al. Expires 24 January 2025 [Page 1] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs July 2024 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 . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. 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 reserved range and using mDNS to prevent collisions. Once the IPv6 multicast address has been assigned, the data contained the multicast stream may be advertised using the method described in [I-D.karstens-dnssd-dns-msd]. 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. Karstens, et al. Expires 24 January 2025 [Page 2] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs July 2024 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 should reserve 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 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. Once the PTR record is advertised, the host may then begin transmitting multicast data using the generated address. 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 may optionally monitor the bus 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. Karstens, et al. Expires 24 January 2025 [Page 3] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs July 2024 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. 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]). Karstens, et al. Expires 24 January 2025 [Page 4] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs July 2024 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 either repeatedly responding to queries for a given address or by flooding the network with traffic. 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. 7. References 7.1. Normative References [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-01, 8 May 2024, . Karstens, et al. Expires 24 January 2025 [Page 5] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs July 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . 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-02, 8 May 2024, . [I-D.karstens-dnssd-dns-msd] Karstens, N., Farinacci, D., and M. McBride, "DNS-Based Multicast Stream Discovery", Work in Progress, Internet- Draft, draft-karstens-dnssd-dns-msd-02, 6 November 2023, . [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 2020, . Karstens, et al. Expires 24 January 2025 [Page 6] Internet-Draft Zeroconf Assignment of IPv6 Mcast Addrs July 2024 Authors' Addresses Nate Karstens Garmin International Email: nate.karstens@gmail.com Dino Farinacci lispers.net Email: farinacci@gmail.com Mike McBride Futurewei Email: michael.mcbride@futurewei.com Karstens, et al. Expires 24 January 2025 [Page 7]