1. Introduction
1.1. Background
As has been noticed [V6MISSUES], there exists a deployment problem
with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no
way of communicating the information about (active) multicast sources
to other multicast domains, as Multicast Source Discovery Protocol
(MSDP) [MSDP] has deliberately not been specified for IPv6.
Therefore the whole interdomain Any Source Multicast (ASM) model is
rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these
problems but is not a complete solution for several reasons, as noted
below.
Further, it has been noted that there are some problems with the
support and deployment of mechanisms SSM would require [V6MISSUES]:
it seems unlikely that SSM could be usable as the only interdomain
multicast routing mechanism in the short term.
1.2. Solution
This memo describes a multicast address allocation policy in which
the address of the RP is encoded in the IPv6 multicast group address,
and specifies a PIM-SM group-to-RP mapping to use the encoding,
leveraging, and extending unicast-prefix-based addressing [RFC3306].
This mechanism not only provides a simple solution for IPv6
interdomain Any Source Multicast but can be used as a simple solution
for IPv6 intra-domain ASM with scoped multicast addresses as well.
It can also be used as an automatic RP discovery mechanism in those
deployment scenarios that would have previously used the Bootstrap
Router protocol (BSR) [BSR].
The solution consists of three elements:
o A specification of a subrange of [RFC3306] IPv6 multicast group
addresses defined by setting one previously unused bit of the
Flags field to "1",
o a specification of the mapping by which such a group address
encodes the RP address that is to be used with this group, and
o a description of operational procedures to operate ASM with PIM-SM
on these IPv6 multicast groups.
Addresses in the subrange will be called embedded-RP addresses.
This scheme obviates the need for MSDP, and the routers are not
required to include any multicast configuration, except when they act
as an RP.
This memo updates the addressing format presented in RFC 3306prop.
Some design tradeoffs are discussed in Appendix A.
1.3. Assumptions and Scope
A 128-bit RP address can't be embedded into a 128-bit group address
with space left to carry the group identity itself. An appropriate
form of encoding is thus defined by requiring that the Interface-IDs
of RPs in the embedded-RP range can be assigned to be a specific
value.
If these assumptions can't be followed, operational procedures and
configuration must be slightly changed, or this mechanism can't be
used.
The assignment of multicast addresses is outside the scope of this
document; it is up to the RP and applications to ensure that group
addresses are unique by using some unspecified method. However, the
mechanisms are probably similar to those used with [RFC3306].
Similarly, RP failure management methods, such as Anycast-RP, are out
of scope for this document. These do not work without additional
specification or deployment. This is covered briefly in Section 6.1.
1.4. Terminology
Embedded-RP behaves as if all the members of the group were intra-
domain to the information distribution. However, as it gives a
solution for the global IPv6 multicast Internet, spanning multiple
administrative domains, we say it is a solution for inter-domain
multicast.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.5. Abbreviations
ASM Any Source Multicast
BSR Bootstrap Router
DR Designated Router
IGP Interior Gateway Protocol
MLD Multicast Listener Discovery
MSDP Multicast Source Discovery Protocol
PIM Protocol Independent Multicast
PIM-SM Protocol Independent Multicast - Sparse Mode
RIID RP Interface ID (as specified in this memo)
RP Rendezvous Point
RPF Reverse Path Forwarding
SPT Shortest Path Tree
SSM Source-Specific Multicast
