Updates to Dynamic IPv6 Multicast Address Group IDs

Internet-Draft	Dynamic IPv6 Mcast Addr Group ID Updates	May 2024
Karstens, et al.	Expires 9 November 2024	[Page]

Abstract

Describes limitations of the existing range of dynamic IPv6 multicast addresses specified in RFC3307. Recommends replacing these allocations with a new registry in the IPv6 Multicast Address Space Registry registry group. Suggests initial contents of the new registry: a reduced allocation for MADCAP (RFC2730) and solicited-node multicast addresses (which were not previously noted in RFC3307).¶

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 9 November 2024.¶

Copyright Notice

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.¶

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 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 so far (see [RFC2730]), but [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.¶

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. 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:¶

Table 1: Existing Allocations
`0x80000000`-`0xFEFFFFFF`		Server allocation (MADCAP)	Host allocation
`0xFF000000`-`0xFFFFFFFF`	Solicited-node

This document updates the allocations in [RFC3307], 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:¶

Table 2: Updated Allocations
Range	Description	Reference
`0x80000000`-`0x8FFFFFFF`	MADCAP	[RFC2730]
`0x90000000`-`0xFEFFFFFF`	Unassigned
`0xFF000000`-`0xFFFFFFFF`	Solicited-node multicast addresses	[RFC4291], Section 2.7.1

This reduces the range previously available for MADCAP, while still providing a sizable allocation. In addition, this documents the range used for solicited-node multicast addresses and reserves the remaining entries for future protocol development.¶

4. IANA Considerations

IANA should create a new registry named "Dynamic Multicast Group IDs" in the "IPv6 Multicast Address Space Registry" registry group. This registry shall initially contain the entries listed in Table 2. The "Standards Action" registration policy is required to update the registry.¶

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" 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.¶

5. Acknowledgement

Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this research.¶

Thanks also to the members of the PIM working group for their early brainstorming sessions and review of this draft.¶

Finally, thanks to Dave Thaler for discussing MADCAP deployment in Microsoft products and the impact of changing the range of group IDs used by MADCAP.¶

6. References

6.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>.
[RFC3307]: Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, <https://www.rfc-editor.org/info/rfc3307>.
[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>.

6.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-01, 8 May 2024, <https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-pim-zeroconf-mcast-addr-alloc-ps/>.
[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>.
[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>.