Updates to Dynamic IPv6 Multicast Address Group IDs
draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-11
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Nathan Karstens , Dino Farinacci , Mike McBride | ||
| Last updated | 2026-02-26 (Latest revision 2026-02-14) | ||
| Replaces | draft-karstens-pim-updt-ipv6-dyn-mcast-addr-grp-id | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
INTDIR Telechat review
(of
-10)
by Daniel Migault
Ready w/nits
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Stig Venaas | ||
| Shepherd write-up | Show Last changed 2025-12-09 | ||
| IESG | IESG state | IESG Evaluation | |
| Consensus boilerplate | Yes | ||
| Telechat date |
(None)
Has enough positions to pass. |
||
| Responsible AD | Gunter Van de Velde | ||
| Send notices to | stig@venaas.com | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-11
Network Working Group N. Karstens
Internet-Draft Garmin
Updates: 3307 (if approved) D. Farinacci
Intended status: Standards Track lispers.net
Expires: 30 August 2026 M. McBride
Futurewei
26 February 2026
Updates to Dynamic IPv6 Multicast Address Group IDs
draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-11
Abstract
This document describes limitations of the existing range of dynamic
IPv6 multicast addresses specified in RFC3307. It recommends
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 MADCAP
(RFC2730), a range for SSM, a Private Use range, and Solicited-Node
multicast addresses (which were not previously noted in RFC3307,
Allocation Guidelines for IPv6 Multicast Addresses).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 August 2026.
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.
Karstens, et al. Expires 30 August 2026 [Page 1]
Internet-Draft Dynamic IPv6 Mcast Addr Group ID Updates February 2026
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Considerations for Source-Specific Multicast . . . . . . . . 3
3. Updated Dynamic Multicast Group IDs . . . . . . . . . . . . . 3
4. Operational Considerations . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
For IPv6 multicast addresses, Section 2 of [RFC3307] 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. Section 4.3 of [RFC3307]
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 Section 2.7.1 of [RFC4291]).
Only one server allocation protocol has been defined at the time of
writing (see [RFC2730]), but
[I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] advocates developing a
decentralized, zero-configuration host allocation protocol. This
document updates Section 4.3 of [RFC3307] so that dynamic IPv6
multicast group ID ranges better align with current practices for
protocol number assignment and additional dynamic allocation
protocols may be developed.
Karstens, et al. Expires 30 August 2026 [Page 2]
Internet-Draft Dynamic IPv6 Mcast Addr Group ID Updates February 2026
1.1. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Considerations for Source-Specific Multicast
One of the benefits of Source-Specific Multicast (SSM) listed in
Section 1 of [RFC4607] 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
Karstens, et al. Expires 30 August 2026 [Page 3]
Internet-Draft Dynamic IPv6 Mcast Addr Group ID Updates February 2026
This document updates the allocations in [RFC3307], Section 4.3 and
moves them into a new registry in the IPv6 Multicast Address Space
registry group. The registry shall be populated with the following
entries:
+=======================+=================+=======================+
| Range | Description | Reference |
+=======================+=================+=======================+
| 0x80000000-0x8FFFFFFF | MADCAP | Defined in [RFC2730], |
| | | range assigned in |
| | | [This document] |
+-----------------------+-----------------+-----------------------+
| 0x90000000-0xEFFFFFFF | Unassigned | |
+-----------------------+-----------------+-----------------------+
| 0xF0000000-0xFDFFFFFF | Host allocation | [This document] |
| | of SSM group | |
| | addresses | |
+-----------------------+-----------------+-----------------------+
| 0xFE000000-0xFEFFFFFF | Private Use | [This document] |
+-----------------------+-----------------+-----------------------+
| 0xFF000000-0xFFFFFFFF | Solicited-Node | [RFC4291], |
| | multicast | Section 2.7.1 |
| | addresses | |
+-----------------------+-----------------+-----------------------+
Table 2: Updated Allocations
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.
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.
Karstens, et al. Expires 30 August 2026 [Page 4]
Internet-Draft Dynamic IPv6 Mcast Addr Group ID Updates February 2026
5. Security Considerations
This document does not expand on any security considerations beyond
what is discussed in [RFC3307] and [RFC2908].
6. IANA Considerations
This document requests IANA create 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 shall initially contain the entries listed in Table 2,
and shall list both [RFC3307] and this document as references.
IANA should also update 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
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.
7. Acknowledgement
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:
Karstens, et al. Expires 30 August 2026 [Page 5]
Internet-Draft Dynamic IPv6 Mcast Addr Group ID Updates February 2026
* 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
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps]
Karstens, N., Farinacci, D., and M. McBride, "Zeroconf
Multicast Address Allocation Problem Statement and
Requirements", Work in Progress, Internet-Draft, draft-
ietf-pim-zeroconf-mcast-addr-alloc-ps-11, 12 February
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
pim-zeroconf-mcast-addr-alloc-ps-11>.
Karstens, et al. Expires 30 August 2026 [Page 6]
Internet-Draft Dynamic IPv6 Mcast Addr Group ID Updates February 2026
[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>.
[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>.
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
Karstens, et al. Expires 30 August 2026 [Page 7]