Allocation Guidelines for IPv6 Multicast Addresses
Extracted elements (17)
Permanent group IDs (range 0x40000000–0x7FFFFFFF) differ from permanent multicast addresses in that they offer a global service identifier reusable across multiple servers and scopes. For example, a single group ID for NTP allows clients to locate NTP servers regardless of the upper 96 bits of the address.
The guidelines are driven by the need to avoid IPv6 multicast address collision at both the IPv6 layer and the link-layer. Several physical media (e.g., Ethernet, FDDI) map the low-order 32 bits of the IPv6 multicast address into the link-layer destination address, so collisions at the group ID level produce link-layer collisions.
The T bit is used to distinguish dynamically allocated addresses from permanently assigned ones at the link-layer. Since the high-order bit of the group ID equals the T flag value, requiring T=1 for dynamic addresses and placing dynamic group IDs in the upper half (0x80000000–0xFFFFFFFF) achieves the same separation in both the IP address and mapped link-layer address.
These guidelines are not limited to MADCAP servers; they apply to any environment where IPv6 multicast addresses are delegated, assigned, or selected, including SSM application servers and zeroconf nodes. All approved permanent IPv6 multicast address requests result in a unique group ID reserved across all valid IPv6 multicast scopes.
All dynamically allocated IPv6 multicast addresses MUST have the T bit set to 1, distinguishing them from permanently assigned addresses at both the IPv6 layer and the link-layer.
Allocation servers MUST use the group ID range 0x80000000 to 0xFFFFFFFF when allocating IPv6 multicast addresses via a server-based mechanism such as MADCAP.
Any entity responsible for allocating IPv6 multicast addresses MUST implement the guidelines specified in this document. This applies to documents or entities assigning permanent addresses, allocating dynamic addresses, or defining permanent group identifiers.
For host-based allocation, the generated group ID MUST fall in the range 0x80000000 to 0xFFFFFFFF, accomplished by setting the high-order bit of the generated number to 1.
Multicast addresses assigned by IANA MUST have the T bit set to 0 and the P bit set to 0. These are permanent addresses allocated with group IDs in the range 0x00000001 to 0x3FFFFFFF on an Expert Review basis.
For host-based dynamic allocation, the group ID portion is created using either a pseudo-random 32-bit number or a 32-bit number generated per RFC 1750 guidelines, with the high-order bit forced to 1 to place the result in the range 0x80000000 to 0xFFFFFFFF.
Permanent IPv6 multicast addresses are allocated by IANA with group IDs in the range 0x00000001 to 0x3FFFFFFF (or 0x100 to 0x3FFFFFFF for IPv6-only addresses), on an Expert Review basis.
Permanent IPv6 multicast group identifiers provide a global identifier for a service offered by numerous servers, allocated in the range 0x40000000 to 0x7FFFFFFF. Unlike permanent multicast addresses, a permanent group ID identifies a service regardless of the upper 96 bits of the multicast address.
Source-specific multicast (SSM) group addresses are formed by generating a 96-bit multicast prefix (FF3x::/96 as defined in RFC 3306) and concatenating it with a group ID selected per these guidelines.
The group ID is defined as the low-order 32 bits of the IPv6 multicast address. Group IDs of 32 bits or fewer generate unique link-layer addresses within a given multicast scope, which is critical for media that map IPv6 multicast addresses to link-layer destinations.
IANA rules for permanent IPv6 multicast addresses define four ranges: group IDs 1–0x3FFFFFFF for addresses with IPv4 counterparts; 0x100–0x3FFFFFFF for IPv6-only permanent addresses; 0x40000000–0x7FFFFFFF for permanent group IDs; and 0x80000000–0xFFFFFFFF reserved for dynamic allocation mechanisms.
This document requests creation of a new IANA registry for permanent IPv6 multicast group IDs, covering the range 0x40000000 to 0x7FFFFFFF, allocated on an Expert Review basis. These IDs are intended for use across multiple domains with the unicast-prefix-based multicast architecture.
The allocation mechanisms described do not alter the security properties of Any Source or Source Specific multicast service models. However, the ability to allocate large blocks of addresses can enable Denial-of-Service attacks; RFC 2908 contains a more in-depth discussion of security issues surrounding dynamic multicast address allocation.