ietf-corpus

rfc-3956

Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address

P. Savola, B. Haberman
date2004-11 streamIETF areaops wgmboned statusPROPOSED STANDARD pages18 canonicalhttps://www.rfc-editor.org/rfc/rfc3956 doi10.17487/RFC3956
This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK]

updated by

updates

Extracted elements (27)

design-rationale §1.3

A full 128-bit RP address cannot be embedded in a 128-bit group address while preserving group identity. The solution encodes only the network prefix (up to 64 bits) plus a 4-bit RIID, requiring RP administrators to manually configure the RP's interface ID to match the RIID.

multicast, ip

design-rationale §1.1

MSDP was deliberately not specified for IPv6, leaving PIM-SM with no way to propagate active source information across domains and rendering interdomain ASM unusable. Embedded-RP was designed to fill this gap without requiring MSDP, by making the RP address self-describing in the group address.

multicast, routing

design-rationale §6.3

RIID=0 is reserved rather than usable because the all-zeros interface identifier is defined as the Subnet-Router Anycast Address in RFC 3513; using it for RIID would introduce ambiguity in the derived RP address.

multicast, ip

design-rationale §A

RIID was not pre-determined to a fixed value (e.g., '1') because doing so would eliminate address assignment flexibility for operators. Allowing the operator to choose any RIID value from 1–F enables flexible RP placement across different network topologies and prefix lengths.

multicast, ip

design-rationale §A

The 'plen' field is capped at 64 because values from 65 to 95 would overlap with the high-order bits of the multicast group-id field, corrupting group identity. This is consistent with the constraint in RFC 3306.

multicast, ip

design-rationale §A

The R-bit flag approach (yielding FF70::/12) was chosen over using the leftmost reserved bits (which would have produced FF3x:8000::/17). The flag-bit approach leverages the existing P and T bit semantics from RFC 3306 and keeps the address format extensions coherent.

multicast, ip

interoperability-note §8

Embedded-RP eliminates the need for MSDP in interdomain IPv6 ASM. Senders' DRs send PIM-SM Register messages directly to the foreign RP encoded in the multicast group address, removing the MSDP source-active information distribution mesh entirely.

multicast, routing

interoperability-note §3

This document updates RFC 3306 by defining the previously unused second high-order flag bit (R-bit) of the IPv6 multicast address and by reinterpreting the last 4 bits of the RFC 3306 reserved field as RIID when R=1.

multicast, ip

interoperability-note §6.4

With embedded-RP, BSR or other RP configuration mechanisms are not required throughout the PIM domain, since each embedded-RP group address self-identifies the RP. Embedded-RP can fully replace BSR for automatic RP discovery in compatible deployments.

multicast, routing

normative-requirement §7.1 MUST

For addresses in the range FF70::/12, the Embedded-RP group-to-RP mapping MUST be considered the longest possible match and MUST have higher priority than any other mechanism such as BSR or static configuration.

multicast, routing

normative-requirement §10 SHOULD

Implementations SHOULD allow manual configuration of which multicast prefixes are allowed at an RP, to restrict the RP to serving designated groups only and protect it from unauthorized use.

multicast, security

normative-requirement §10 RECOMMENDED

It is RECOMMENDED that routers supporting this specification do not act as RPs unless explicitly configured to do so, since becoming an RP requires no advertisement. Multicast groups or group ranges to be served MAY need to be explicitly configured at the RP.

multicast, security

normative-requirement §4 MUST

Multicast routers MUST perform at least the same address validity checks on the RP address derived from the multicast encoding as on RP addresses received via other means. At minimum, fe80::/10, ::/16, and ff00::/8 MUST be excluded from valid RP addresses.

multicast, security

normative-requirement §6.3 MUST NOT

RIID=0 MUST NOT be used in embedded-RP multicast addresses, as it would be ambiguous with the Subnet-Router Anycast Address (all-zeros interface identifier) defined in RFC 3513.

multicast, ip

normative-requirement §4 MUST

To qualify as an embedded-RP address, a multicast address MUST have 'flgs' set to 0111 (prefix FF70::/12), 'plen' MUST NOT be 0 (excluding SSM), and 'plen' MUST NOT be greater than 64.

multicast, ip

normative-requirement §3 MUST

When R=0, the RIID field MUST be sent as zero and MUST be ignored on receipt; the address follows standard RFC 3306 and RFC 3513 semantics with no RP embedding.

multicast, ip

normative-requirement §3 MUST

When R=1, P MUST be set to 1 and T MUST be set to 1, as required by RFC 3306, making the effective prefix FF70::/12. Behavior is unspecified if P or T is not 1.

multicast, ip

normative-requirement §3 SHOULD NOT

Without further IETF specification, implementations SHOULD NOT treat the FFF0::/12 range (flags high-order two bits both set to 1) as Embedded-RP; the encoding and protocol mode for that range are intentionally unspecified.

multicast, ip

protocol-element §7.1

The embedded-RP group-to-RP mapping mechanism operates as a PIM-SM group-to-RP mapping method. Routers use the derived RP address for RPF lookups, Join/Prune processing, and Register-encapsulation. Results may be cached per-implementation to avoid recomputation per packet.

multicast, routing

protocol-element §3

The R-bit is the second high-order bit of the 4-bit flags field. When R=1, the address embeds the RP address and implies prefix FF70::/12, requiring P=1 and T=1. When R=0, semantics follow RFC 3306/RFC 3513 and RIID must be sent as zero and ignored.

multicast, ip

protocol-element §3

The RIID (RP Interface ID) is a 4-bit field encoding the last 4 bits of the RP's IPv6 interface identifier. RIID=0 is reserved; valid values are 1–F, providing at most 15 distinct RPs per (scope, network prefix, group ID) combination.

multicast, ip

protocol-element §4

The RP unicast address is derived from an embedded-RP multicast address by two steps: (1) copy the first 'plen' bits of the network prefix into a zeroed 128-bit address, then (2) replace the last 4 bits with the RIID value. This yields the unicast RP address without any out-of-band signaling.

multicast, ip, routing

security-consideration §10

Any RP must accept PIM-SM Join/Prune/Register messages from any DR in the Internet, creating a potential Denial of Service vector. Mitigation: the RP can discard all such messages for multicast addresses that do not encode the RP's own address.

multicast, security

security-consideration §10

Embedded-RP offers protection roughly equivalent to MSDP with SA filtering — i.e., security by obscurity. For real access control, PIM multicast scoping borders must be deployed at domain edges. Nodes in foreign domains can register to or send PIM Joins to the RP without further restriction.

multicast, security

security-consideration §10

Embedding the RP address in the multicast group address makes RPs more visible as single points of failure and may expose them to targeted attacks beyond those affecting multicast routing itself. Operators should apply extra hardening to RP routers.

multicast, security

security-consideration §10

The embedded-RP address is derived from an untrusted source (any Internet user's multicast address choice). The MUST-level validity check excluding fe80::/10, ::/16, and ff00::/8 is therefore especially critical, as a crafted group address could otherwise redirect traffic to a malicious or nonexistent RP.

multicast, security

wire-format §3

The modified unicast-prefix-based IPv6 multicast address format (128 bits total): 8-bit 0xFF | 4-bit flags (0|R|P|T) | 4-bit scope | 4-bit rsvd | 4-bit RIID | 8-bit plen | 64-bit network prefix | 32-bit group ID. This modifies RFC 3306 by splitting the previously 8-bit reserved field into a 4-bit reserved portion and a 4-bit RP Interface ID (RIID) field, and defining the R-bit.

multicast, ip