Updates to Dynamic IPv6 Multicast Address Group IDs
RFC 10028



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