﻿<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp "&#160;">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  docName="draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10"
  updates="3307"
  ipr="trust200902"
  submissionType="IETF"
  consensus="true">

  <front>
    <title abbrev="Dynamic IPv6 Mcast Addr Group ID Updates">Updates to Dynamic IPv6 Multicast Address Group IDs</title>

    <author fullname="Nate Karstens" initials="N" surname="Karstens">
      <organization abbrev="Garmin">Garmin International, Inc.</organization>
      <address>
        <postal>
          <street>1200 E. 151st St.</street>
          <city>Olathe</city>
          <region>KS</region>
          <code>66062-3426</code>
          <country>United States of America</country>
        </postal>
        <email>nate.karstens@gmail.com</email>
      </address>
    </author>

    <author fullname="Dino Farinacci" initials="D" surname="Farinacci">
      <organization>lispers.net</organization>
      <address>
        <postal>
          <city>San Jose</city>
          <region>CA</region>
          <country>United States of America</country>
        </postal>
        <email>farinacci@gmail.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <country>United States of America</country>
        </postal>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>

    <date day="14" month="February" year="2026"/>

    <abstract>
      <t>This document describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. It recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. The document also suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730), a range for SSM, a Private Use range, and Solicited-Node multicast addresses (which were not previously noted in RFC3307).</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>For IPv6 multicast addresses, <xref target="RFC3307" sectionFormat="of" 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. <xref target="RFC3307" sectionFormat="of" 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 range for dynamic assignment overlaps with the range used for Solicited-Node multicast addresses (see <xref target="RFC4291" sectionFormat="of" section="2.7.1"/>).</t>

      <t>Only one server allocation protocol has been defined so far (see <xref target="RFC2730"/>), but <xref target="I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps"/> advocates developing a decentralized, zero-configuration host allocation protocol. This document updates the dynamic IPv6 multicast group ID ranges to better align with current practices for protocol number assignment and to support development of additional dynamic allocation protocols.</t>

      <section anchor="requirements">
        <name>Requirements Language</name>
        <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>

    <section title="Considerations for Source-Specific Multicast">
      <t>One of the benefits of Source-Specific Multicast (SSM) listed in <xref target="RFC4607" sectionFormat="of" 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.</t>
      
      <t>However, SSM is not universally supported (<xref target="RFC4607" sectionFormat="comma" section="6"/> lists one example). This document defines a range of dynamic IPv6 multicast group IDs for use in environments that do support SSM.</t>
    </section>

    <section title="Updated Dynamic Multicast Group IDs">
      <t>Existing group ID allocations specified in <xref target="RFC3307" sectionFormat="comma" section="4.3"/> and <xref target="RFC4291" sectionFormat="comma" section="2.7.1"/> are summarized in the following table:</t>

      <table>
        <name>Existing Allocations</name>
        <thead>
          <tr>
            <th>Range</th>
            <th align="center">Solicited-Node</th>
            <th align="center">Server allocation<br/>(MADCAP)</th>
            <th align="center">Host allocation</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td><br/><br/><tt>0x80000000</tt>-<tt>0xFEFFFFFF</tt><br/><br/><br/></td>
            <td align="center"><br/><br/>No</td>
            <td align="center"><br/><br/>Yes</td>
            <td align="center"><br/><br/>Yes</td>
          </tr>
          <tr>
            <td><tt>0xFF000000</tt>-<tt>0xFFFFFFFF</tt></td>
            <td align="center">Yes</td>
            <td align="center">Yes</td>
            <td align="center">Yes</td>
          </tr>
        </tbody>
      </table>

      <t>This document updates the allocations in <xref target="RFC3307" sectionFormat="comma" section="4.3"/> and moves them into a new registry in the IPv6 Multicast Address Space Registry registry group. The registry shall be populated with the following entries:</t>

      <table anchor="groupIDs">
        <name>Updated Allocations</name>
        <thead>
          <tr>
            <th>Range</th>
            <th>Description</th>
            <th>Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td><tt>0x80000000</tt>-<tt>0x8FFFFFFF</tt></td>
            <td>MADCAP</td>
            <td>Defined in <xref target="RFC2730"/>, range assigned in [This document]</td>
          </tr>
          <tr>
            <td><tt>0x90000000</tt>-<tt>0xEFFFFFFF</tt></td>
            <td>Unassigned</td>
            <td><!--Empty--></td>
          </tr>
          <tr>
            <td><tt>0xF0000000</tt>-<tt>0xFDFFFFFF</tt></td>
            <td>Host allocation of SSM group addresses</td>
            <td><!--TODO: Replace with this document-->[This document]</td>
          </tr>
          <tr>
            <td><tt>0xFE000000</tt>-<tt>0xFEFFFFFF</tt></td>
            <td>Private Use</td>
            <td><!--TODO: Replace with this document-->[This document]</td>
          </tr>
          <tr>
            <td><tt>0xFF000000</tt>-<tt>0xFFFFFFFF</tt></td>
            <td>Solicited-Node multicast addresses</td>
            <td><xref target="RFC4291" sectionFormat="comma" section="2.7.1"/></td>
          </tr>
        </tbody>
      </table>

      <t>This reduces the range previously available for MADCAP, while still providing a sizable allocation. It also allocates ranges for SSM and for Private Use. The Private Use range can be used in isolated deployments for purposes such as manual address allocation or experimentation with new dynamic allocation protocols. Finally, this documents the range used for Solicited-Node multicast addresses. All remaining entries are reserved for future assignment as new protocols are developed.</t>
    </section>

    <section title="Security Considerations">
      <t>This document does not expand on any security considerations beyond what is discussed in <xref target="RFC3307"/> and <xref target="RFC2908"/>.</t>
    </section>

    <section title="IANA Considerations">
      <t>IANA should create a new registry named "Dynamic Multicast Group IDs" in the "IPv6 Multicast Address Space Registry" registry group. The "Standards Action" registration policy is required to update the registry. Each entry in the registry contains the following fields:</t>

      <ol>
        <li>Range<br />A range of 32-bit values rendered in hexadecimal. Values MUST be within the range for dynamic multicast address allocation mechanisms specified in <xref target="RFC3307"/>: <tt>0x80000000</tt> to <tt>0xFFFFFFFF</tt>.</li>
        <li>Description<br />A description or protocol name assigned to the range.</li>
        <li>Reference<br />A document describing the assignment.</li>
      </ol>

      <t>The registry shall initially contain the entries listed in <xref target="groupIDs"/>.</t>

      <t>IANA should also update the references to "<tt>FF3X:0:0:0:0:0:8000:0-FF3X:0:0:0:0:0:FFFF:FFFF</tt>" in the "Unicast-based (Including SSM) Multicast Group IDs" registry in the "IPv6 Multicast Address Space Registry" registry group. The registration procedure should indicate that this range uses dynamic assignment according to the protocols listed in the new "Dynamic Multicast Group IDs" registry and include a reference to this document. The description in the registry entry should indicate that this range uses dynamic assignment according to the protocols listed in the new "Dynamic Multicast Group IDs" registry and the reference should be changed to this document.</t>
    </section>

    <section title="Acknowledgement">
      <t>Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this work.</t>

      <t>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:</t>

      <ul>
        <li>Dave Thaler for discussing MADCAP deployment in Microsoft products and the impact of changing the range of group IDs used by MADCAP</li>
        <li>Stig Venaas for recognizing the need for a range of addresses that can be allocated manually</li>
        <li>Nico Cvitak for recommending a group ID block for SSM</li>
      </ul>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3307.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
    </references>
    <references title="Informative References">
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2730.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2908.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps.xml"/>
    </references>
  </back>
</rfc>
