RFC 10028

Updates to Dynamic IPv6 Multicast Address Group IDs

📅 published August 2026, from ietf

RFC 10028: Updates to Dynamic IPv6 Multicast Address Group IDs 🦋

  • Who wrote it: N. Karstens (Garmin), D. Farinacci (lispers.net), and M. McBride (Futurewei) 💅
  • Published by: the Internet Engineering Task Force (IETF), in August 2026 🗓️
  • Category: Standards Track, which means it's an actual Internet Standard 🔥
  • Updates: RFC 3307, "Allocation Guidelines for IPv6 Multicast Addresses" 🔄
  • Obsoletes: nothing is listed 🙅‍♀️
  • ISSN: 2070-1721

Abstract 💖

Okay, so this doc is all about the dynamic IPv6 multicast address range from RFC 3307 and why it's kinda struggling 😭 It describes the limitations of that range, which is specified in "Allocation Guidelines for IPv6 Multicast Addresses" (RFC 3307). It updates RFC 3307 by replacing those allocations with a brand-new IANA registry in the "IPv6 Multicast Address Space" registry group. 🗂️

It also sets up the starter contents of that new registry, and it's a whole lineup 🎀 There's 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. The Solicited-Node ones weren't noted in RFC 3307 before, so this doc finally gives them a spot. 🧚

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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841. 📚

Info about the current status of this document, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc10028. 💌

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) as they stand on the date of publication. Please actually read these, bestie, because they explain your rights and restrictions for this document. Code components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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 ✨

Okay, so for IPv6 multicast addresses, [RFC3307], Section 2 says the lower 32 bits of the address are the group ID. Those bits get mapped straight down to the link layer 🧚 Then it splits the group ID values into ranges based on how they get allocated. It's giving organization. 🗂️

[RFC3307], Section 4.3 is where dynamic assignment of group ID values lives, and it lists two approaches: server allocation and host allocation. The tea is that both of them get the SAME range of group ID values 💀 That means they can't really coexist without risking an address collision. It's also concerning that the dynamic range overlaps with the range used for Solicited-Node multicast addresses. (See [RFC4291], Section 2.7.1 for how that range is defined, and [RFC10019] for the problems that come up with duplicate group ID values on the network.) 😬

Only one server allocation protocol has been defined so far (see [RFC2730]). Meanwhile, [RFC10019] is pushing for a decentralized, zero-configuration host allocation protocol. 🌈 This document updates [RFC3307], Section 4.3 so multiple dynamic allocation protocols can coexist on the same network. It also means the dynamic IPv6 multicast group ID ranges use a registry, which lines up better with how protocol number assignment already works. Main character energy 👑

This document follows 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". 🙌 With SSM, a host subscribes to channel (S,G) and only receives packets sent to destination address G from source address S. Honestly, that's so iconic, because it cuts down on the need for coordinated dynamic assignment of G. Multiple distinct hosts could use the same value for G, and the traffic would still go to the node that asked for the stream (see [RFC8815], Section 3.2.2). 🦋

But SSM isn't universally supported (see [RFC4607], Section 6 and [RFC8815], Section 3.1), so this is a little bit of a bummer 🥺 This document defines a range of dynamic IPv6 multicast group IDs for environments that do support SSM. 🫶

3. Updated Dynamic Multicast Group IDs 🎀

Here's the rundown of the existing group ID allocations from [RFC3307], Section 4.3 and [RFC4291], Section 2.7.1, summed up in this 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 is already 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

So the MADCAP range gets trimmed down, but it's still a sizable allocation, which is a nice glow-up for the dynamic space 🌷 This doc also carves out ranges for SSM, Private Use, and Experimental Use. The Private Use range can be used in isolated deployments for things like manual address allocation (see [RFC8126], Section 4.1). 🔐 The Experimental Use range may be used to experiment with new dynamic allocation protocols (see [RFC8126], Section 4.2). 🧪 There are no restrictions on experimental scope, so these IDs may be used to run experiments over the open Internet. 🌐 Finally, this document also documents the range used for Solicited-Node multicast addresses. Everything else left over is reserved for future assignment as new protocols get developed. 🔮

Part 1 ends here, bestie! 💖 Part 2 picks up with Section 4 (Operational Considerations) next. 🧚

7.2. Informative References 📚

okay bestie, these are the extra reading picks the doc points to, so here's the whole list 💅

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
📦 where this page comes from