Updates to Dynamic IPv6 Multicast Address Group IDs

Updates to Dynamic IPv6 Multicast Address Group IDs Garmin International, Inc.

1200 E. 151st St. Olathe KS 66062-3426 United States of America nate.karstens@gmail.com

lispers.net

San Jose CA United States of America farinacci@gmail.com

Futurewei

United States of America michael.mcbride@futurewei.com

RTG pim MADCAP architecture This document describes limitations of the existing range of dynamic IPv6 multicast addresses specified in "Allocation Guidelines for IPv6 Multicast Addresses" (RFC 3307). It updates RFC 3307 by replacing these allocations with a new IANA registry in the "IPv6 Multicast Address Space" registry group. The document also defines initial contents of the new registry: a reduced allocation for the Multicast Address Dynamic Client Allocation Protocol (MADCAP) (RFC 2730), a range for Source-Specific Multicast (SSM), a Private Use range, a range for Experimental Use, and Solicited-Node multicast addresses (which were not previously noted in RFC 3307).

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

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 () 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 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

. Introduction
. Considerations for Source-Specific Multicast
. Updated Dynamic Multicast Group IDs
. Operational Considerations
. Security Considerations
. IANA Considerations
. References
- . Normative References
- . Informative References
Acknowledgements
Authors' Addresses

Introduction For IPv6 multicast addresses, defines the lower 32 bits of the IPv6 address, which are mapped directly to the link-layer, as the group ID, and then assigns ranges of group ID values based on how they are allocated. describes dynamic assignment of group ID values and lists two different approaches (server allocation and host allocation). However, both approaches are assigned the same range of group ID values, which means they cannot coexist without risking an address collision. Also concerning is that the group ID range for dynamic assignment overlaps with the range used for Solicited-Node multicast addresses (see for the definition of this range and for the discussion of problems associated with duplicate group ID values on the network). Only one server allocation protocol has been defined at the time of writing (see ), but advocates developing a decentralized, zero-configuration host allocation protocol. This document updates to allow multiple dynamic allocation protocols to coexist on the same network and so that dynamic IPv6 multicast group ID ranges use a registry to better align with current practices for protocol number assignment. This document adheres to the IPv6 multicast address architecture outlined in , , , et al.

Considerations for Source-Specific Multicast One of the benefits of Source-Specific Multicast (SSM) listed in is "[avoiding] the need for inter-host coordination when choosing source-specific addresses". SSM allows a host to subscribe to channel (S,G) and only receive packets for destination address G that are from source address S. This reduces the need for coordinated dynamic assignment of G because multiple distinct hosts could use the same value for G and traffic would still be directed to the node that requested the stream (see ). However, SSM is not universally supported (see and ). This document defines a range of dynamic IPv6 multicast group IDs for use in environments that do support SSM.

Updated Dynamic Multicast Group IDs Existing group ID allocations specified in and are summarized in the following table: Existing Allocations

Range	Solicited-Node	Server allocation (MADCAP)	Host allocation
0x80000000-0xFEFFFFFF	No	Yes	Yes
0xFF000000-0xFFFFFFFF	Yes	Yes	Yes

This document updates the allocations in and moves them into the new "Dynamic Multicast Group IDs" registry in the "IPv6 Multicast Address Space" registry group. The registry has been populated with the following entries: Updated Allocations

Range	Description	Reference
0x80000000-0x8FFFFFFF	MADCAP	Defined in , range assigned in RFC 10028
0x90000000-0xEFFFFFFF	Unassigned
0xF0000000-0xFCFFFFFF	Host allocation of SSM group addresses	RFC 10028
0xFD000000-0xFDFFFFFF	Reserved for Private Use	RFC 10028
0xFE000000-0xFEFFFFFF	Reserved for Experimental Use	RFC 10028
0xFF000000-0xFFFFFFFF	Solicited-Node multicast addresses

This reduces the range previously available for the Multicast Address Dynamic Client Allocation Protocol (MADCAP) while still providing a sizable allocation. It also allocates ranges for SSM, Private Use, and Experimental Use. The Private Use range can be used in isolated deployments for purposes such as manual address allocation (see ). The Experimental Use range may be used for experimentation with new dynamic allocation protocols (see ). There are no restrictions on experimental scope; these IDs may be used to run experiments over the open Internet. Finally, this documents the range used for Solicited-Node multicast addresses. All remaining entries are reserved for future assignment as new protocols are developed.

Operational Considerations This document reduces the range of group ID values available for MADCAP . At the time of writing, there is only one known implementation of MADCAP, and there are no known large-scale deployments. Any implementations of MADCAP (known or otherwise) should be updated to reflect the new group ID range set forth in . Any existing deployments of MADCAP should either use an updated implementation or operate in an environment without other IPv6 multicast address allocation protocols.

Security Considerations This document does not expand on any security considerations beyond what is discussed in and .

IANA Considerations IANA has created a new registry named "Dynamic Multicast Group IDs" in the "IPv6 Multicast Address Space" registry group. The "Standards Action" registration policy is required to update the registry. Each entry in the registry contains the following fields:

Range A range of 32-bit values rendered in hexadecimal. Values must be within the range 0x80000000 to 0xFFFFFFFF.
Description A description or protocol name assigned to the range.
Reference A document describing the assignment.

The registry initially contains the entries listed in and lists both and this document as references. IANA has also updated the references to "FF3X:0:0:0:0:0:8000:0-FF3X:0:0:0:0:0:FFFF:FFFF" in the "Unicast-based (Including SSM) Multicast Group IDs" registry in the "IPv6 Multicast Address Space" registry group. The registration procedure indicates that this range uses dynamic assignment according to the protocols listed in the new "Dynamic Multicast Group IDs" registry and includes a reference to this document. The description in the registry entry indicates that this range uses dynamic assignment according to the protocols listed in the new "Dynamic Multicast Group IDs" registry and the reference has been changed to this document.

References Normative References Multicast Address Dynamic Client Allocation Protocol (MADCAP) This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. [STANDARDS-TRACK] Allocation Guidelines for IPv6 Multicast Addresses IP Version 6 Addressing Architecture This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] Source-Specific Multicast for IP IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK] Informative References The Internet Multicast Address Allocation Architecture This document proposes a multicast address allocation architecture (MALLOC) for the Internet. This memo provides information for the Internet community. Updates to the IPv6 Multicast Addressing Architecture This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits. This document updates RFCs 3956, 3306, and 4291. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Deprecating Any-Source Multicast (ASM) for Interdomain Multicast This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM). Zeroconf Multicast Address Allocation Problem Statement and Requirements This document surveys current problems with existing protocols for automatically assigning multicast IP addresses in zero-configuration (zeroconf) networking environments. It addresses key challenges, such as link-layer 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 solution for 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 solutions for multicast address allocation that operate autonomously within local networks.

Acknowledgements Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this work. The authors are grateful to the members of the PIM Working Group for their early brainstorming sessions and review of this document and to the following individuals specifically:

for discussing MADCAP deployment in Microsoft products and the impact of changing the range of group IDs used by MADCAP
for recognizing the need for a range of addresses that can be allocated manually
for recommending a group ID block for SSM

Authors' Addresses Garmin International, Inc.

1200 E. 151st St. Olathe KS 66062-3426 United States of America nate.karstens@gmail.com

lispers.net

San Jose CA United States of America farinacci@gmail.com

Futurewei

United States of America michael.mcbride@futurewei.com