IPv6 multicast IDs: Updates to Dynamic IPv6 Multicast Address Group IDs
A new IANA registry carves up the dynamic IPv6 multicast group ID space so several allocation methods can coexist.
Karstens, N., Farinacci, D., and M. McBride, "Updates to Dynamic IPv6 Multicast Address Group IDs", RFC 10028, DOI 10.17487/RFC10028, August 2026, <https://www.rfc-editor.org/info/rfc10028>.
@misc{rfc10028,
series = {Request for Comments},
number = 10028,
howpublished = {RFC 10028},
publisher = {RFC Editor},
doi = {10.17487/RFC10028},
url = {https://www.rfc-editor.org/info/rfc10028},
author = {N. Karstens and D. Farinacci and M. McBride},
title = {{Updates to Dynamic IPv6 Multicast Address Group IDs}},
pagetotal = 6,
year = 2026,
month = aug,
} RFC text
Contents
Internet Engineering Task Force (IETF) N. Karstens
Request for Comments: 10028 Garmin
Updates: 3307 D. Farinacci
Category: Standards Track lispers.net
ISSN: 2070-1721 M. McBride
Futurewei
August 2026
Updates to Dynamic IPv6 Multicast Address Group IDs
Abstract
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
https://www.rfc-editor.org/info/rfc10028.
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 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. Considerations for Source-Specific Multicast
3. Updated Dynamic Multicast Group IDs
4. Operational Considerations
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
For IPv6 multicast addresses, [RFC3307], Section 2 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. [RFC3307], Section 4.3 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
[RFC4291], Section 2.7.1 for the definition of this range and
[RFC10019] 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 [RFC2730]), but [RFC10019] advocates developing a
decentralized, zero-configuration host allocation protocol. This
document updates [RFC3307], Section 4.3 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 [RFC4291], [RFC3307], [RFC7371], et al.
2. Considerations for Source-Specific Multicast
One of the benefits of Source-Specific Multicast (SSM) listed in
[RFC4607], Section 1 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 [RFC8815],
Section 3.2.2).
However, SSM is not universally supported (see [RFC4607], Section 6
and [RFC8815], Section 3.1). This document defines a range of
dynamic IPv6 multicast group IDs for use in environments that do
support SSM.
3. Updated Dynamic Multicast Group IDs
Existing group ID allocations specified in [RFC3307], Section 4.3 and
[RFC4291], Section 2.7.1 are summarized in the following table:
+=======================+================+============+============+
| Range | Solicited-Node | Server | Host |
| | | allocation | allocation |
| | | (MADCAP) | |
+=======================+================+============+============+
| 0x80000000-0xFEFFFFFF | No | Yes | Yes |
+-----------------------+----------------+------------+------------+
| 0xFF000000-0xFFFFFFFF | Yes | Yes | Yes |
+-----------------------+----------------+------------+------------+
Table 1: Existing Allocations
This document updates the allocations in [RFC3307], Section 4.3 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:
+=======================+=================+=======================+
| Range | Description | Reference |
+=======================+=================+=======================+
| 0x80000000-0x8FFFFFFF | MADCAP | Defined in [RFC2730], |
| | | range assigned in RFC |
| | | 10028 |
+-----------------------+-----------------+-----------------------+
| 0x90000000-0xEFFFFFFF | Unassigned | |
+-----------------------+-----------------+-----------------------+
| 0xF0000000-0xFCFFFFFF | Host allocation | RFC 10028 |
| | of SSM group | |
| | addresses | |
+-----------------------+-----------------+-----------------------+
| 0xFD000000-0xFDFFFFFF | Reserved for | RFC 10028 |
| | Private Use | |
+-----------------------+-----------------+-----------------------+
| 0xFE000000-0xFEFFFFFF | Reserved for | RFC 10028 |
| | Experimental | |
| | Use | |
+-----------------------+-----------------+-----------------------+
| 0xFF000000-0xFFFFFFFF | Solicited-Node | [RFC4291], |
| | multicast | Section 2.7.1 |
| | addresses | |
+-----------------------+-----------------+-----------------------+
Table 2: Updated Allocations
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
[RFC8126], Section 4.1). The Experimental Use range may be used for
experimentation with new dynamic allocation protocols (see [RFC8126],
Section 4.2). 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.
4. Operational Considerations
This document reduces the range of group ID values available for
MADCAP [RFC2730]. 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
Table 2. Any existing deployments of MADCAP should either use an
updated implementation or operate in an environment without other
IPv6 multicast address allocation protocols.
5. Security Considerations
This document does not expand on any security considerations beyond
what is discussed in [RFC3307] and [RFC2908].
6. 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:
1. Range
A range of 32-bit values rendered in hexadecimal. Values must be
within the range 0x80000000 to 0xFFFFFFFF.
2. Description
A description or protocol name assigned to the range.
3. Reference
A document describing the assignment.
The registry initially contains the entries listed in Table 2 and
lists both [RFC3307] 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.
7. References
7.1. Normative References
[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
DOI 10.17487/RFC2730, December 1999,
<https://www.rfc-editor.org/info/rfc2730>.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
<https://www.rfc-editor.org/info/rfc3307>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<https://www.rfc-editor.org/info/rfc4607>.
7.2. Informative References
[RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet
Multicast Address Allocation Architecture", RFC 2908,
DOI 10.17487/RFC2908, September 2000,
<https://www.rfc-editor.org/info/rfc2908>.
[RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6
Multicast Addressing Architecture", RFC 7371,
DOI 10.17487/RFC7371, September 2014,
<https://www.rfc-editor.org/info/rfc7371>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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, <https://www.rfc-editor.org/info/rfc8815>.
[RFC10019] Karstens, N., Farinacci, D., and M. McBride, "Zeroconf
Multicast Address Allocation Problem Statement and
Requirements", RFC 10019, DOI 10.17487/RFC10019, July
2026, <https://www.rfc-editor.org/info/rfc10019>.
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:
* Dave Thaler for discussing MADCAP deployment in Microsoft products
and the impact of changing the range of group IDs used by MADCAP
* Stig Venaas for recognizing the need for a range of addresses that
can be allocated manually
* Nico Cvitak for recommending a group ID block for SSM
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.com
AI ELI5
On this page
§1The Problem With the Old Range
An IPv6 multicast address ends in a 32-bit group ID, which is mapped directly to the link layer. RFC 3307 hands out ranges of group ID values depending on how they are allocated, and describes two ways to assign them dynamically: server allocation and host allocation.
The trouble is that both approaches were given the same range of group IDs, so they cannot coexist without risking an address collision. The dynamic range also overlaps the range used for Solicited-Node multicast addresses, which is defined in RFC 4291. RFC 10019 discusses the problems of duplicate group IDs on a network.
Only one server allocation protocol had been defined at the time of writing, RFC 2730 (MADCAP). RFC 10019 advocates a decentralized, zero-configuration host allocation protocol. RFC 10028 therefore updates Section 4.3 of RFC 3307 so that several dynamic allocation protocols can share one network, and so the ranges live in a registry like protocol numbers do.
Two groups were told to use the same set of numbers for their rooms, so they could end up in the same room by accident. This RFC fixes that mix-up.
§2Source-Specific Multicast and Why It Gets a Range
With Source-Specific Multicast (SSM), a host subscribes to a channel (S,G) and receives only packets for destination address G that come from source address S. RFC 4607 lists as a benefit that it avoids the need for inter-host coordination when choosing source-specific addresses.
That lowers the need for coordinated dynamic assignment of G. Several distinct hosts could use the same value for G, and traffic would still reach only the node that asked for the stream.
SSM is not universally supported, though. So this document defines a range of dynamic group IDs for environments that do support SSM.
If you only listen to one friend's walkie-talkie channel, it does not matter that other people picked the same channel number, because you only hear your friend.
§3The Updated Group ID Ranges
Before this document, the allocations from RFC 3307 and RFC 4291 were summarized as two ranges. The range 0x80000000-0xFEFFFFFF was open to both server (MADCAP) and host allocation. The range 0xFF000000-0xFFFFFFFF was open to those two and was also used by Solicited-Node addresses.
The new "Dynamic Multicast Group IDs" registry replaces that with distinct ranges:
0x80000000-0x8FFFFFFF: MADCAP0x90000000-0xEFFFFFFF: unassigned0xF0000000-0xFCFFFFFF: host allocation of SSM group addresses0xFD000000-0xFDFFFFFF: reserved for Private Use0xFE000000-0xFEFFFFFF: reserved for Experimental Use0xFF000000-0xFFFFFFFF: Solicited-Node multicast addresses
The Private Use range can serve isolated deployments, for example manual address allocation. The Experimental Use range may be used to try new dynamic allocation protocols, and there are no restrictions on experimental scope, so experiments may run over the open Internet. All remaining entries are reserved for future assignment as new protocols are developed.
The long list of numbers is cut into labeled blocks: one for the old system, one for a new kind of group, one for private use, one for experiments, and one for a special job. The rest stays empty until someone needs it.
- 0x80000000-0x8FFFFFFFMADCAP — Defined in RFC 2730; range assigned in RFC 10028.
- 0x90000000-0xEFFFFFFFUnassigned — Left for future allocation protocols.
- 0xF0000000-0xFCFFFFFFHost allocation of SSM — Host allocation of SSM group addresses.
- 0xFD000000-0xFDFFFFFFPrivate Use — Reserved for Private Use.
- 0xFE000000-0xFEFFFFFFExperimental Use — Reserved for Experimental Use.
- 0xFF000000-0xFFFFFFFFSolicited-Node — Solicited-Node multicast addresses (RFC 4291, Section 2.7.1).
§4Impact on MADCAP Deployments
The change shrinks the range of group IDs available to MADCAP, but still leaves a sizable allocation. The RFC says that, at the time of writing, there is only one known implementation of MADCAP and no known large-scale deployments.
Any MADCAP implementations, known or otherwise, should be updated to the new range in Table 2 of the RFC. Existing MADCAP deployments should either use an updated implementation or operate in an environment without other IPv6 multicast address allocation protocols.
The old system now gets a smaller set of rooms. Anyone still using it should switch to the new set or make sure nobody else is using the same building.
§5Security Considerations
The RFC adds nothing new here. It states that it does not expand on any security considerations beyond what is discussed in RFC 3307 and RFC 2908.
This change only reorganizes a list, so it brings no new safety worries beyond the ones already written down.
§6The New IANA Registry
IANA has created the "Dynamic Multicast Group IDs" registry in the "IPv6 Multicast Address Space" registry group. Updating it requires the "Standards Action" registration policy. Each entry has three fields: a Range of 32-bit values in hexadecimal within 0x80000000 to 0xFFFFFFFF, a Description, and a Reference. The registry starts with the entries described above and cites both RFC 3307 and this document.
IANA also updated the entry for 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. It now says the range uses dynamic assignment according to the protocols in the new registry, and its reference points to this document.
A keeper of the list, IANA, now has a new page for these room numbers. Changing it needs a formal standards decision, and the old page now points to the new one.