information distribution. The embedded-RP inter-domain model behaves
as if every group formed its own Internet-wide PIM domain, with the
group mapping to a single RP, wherever the receivers or senders are
located. Hence, the inter-domain multicast becomes a flat, RP-
centered topology. The scaling issues are described below.
Previously, foreign sources sent the unicast-encapsulated data to
their "local" RP; now they are sent to the "foreign" RP responsible
for the specific group. This is especially important with large
multicast groups where there are a lot of heavy senders --
particularly if implementations do not handle unicast-decapsulation
well.
With IPv4 ASM multicast, there are roughly two kinds of Internet-wide
state: MSDP (propagated everywhere), and multicast routing state (on
the receiver or sender branches). The former is eliminated, but the
backbone routers might end up with (*, G) and (S, G, rpt) state
between receivers (and past receivers, for PIM Prunes) and the RP, in
addition to (S, G) states between the receivers and senders, if SPT
is used. However, the total amount of state is smaller.
In both inter-domain and intra-domain cases, the embedded-RP model is
practically identical to the traditional PIM-SM in intra-domain. On
the other hand, PIM-SM has been deployed (in IPv4) in inter-domain
using MSDP; compared to that inter-domain model, this specification
simplifies the tree construction (i.e., multicast routing) by
removing the RP for senders and receivers in foreign domains and
eliminating the MSDP information distribution.
As the address of the RP is tied to the multicast address, the RP
failure management becomes more difficult, as the deployed failover
or redundancy mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be
used as-is. However, Anycast-RP using PIM provides equal redundancy;
this described briefly in Section 6.1.
The PIM-SM specification states, "Any RP address configured or
learned MUST be a domain-wide reachable address". What "reachable"
precisely means is not clear, even without embedded-RP. This
statement cannot be proven, especially with the foreign RPs, as one
cannot even guarantee that the RP exists. Instead of manually
configuring RPs and DRs (configuring a non-existent RP was possible,
though rare), with this specification the hosts and users using
multicast indirectly specify the RP themselves, lowering the
expectancy of the RP reachability. This is a relatively significant
problem but not much different from the current multicast deployment:
e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result
[PIMSEC].
Being able to join/send to remote RPs raises security concerns that
are considered separately, but it has an advantage too: every group
has a "responsible RP" that is able to control (to some extent) who
is able to send to the group.
A more extensive description and comparison of the inter-domain
multicast routing models (traditional ASM with MSDP, embedded-RP,
SSM) and their security properties has been described in [PIMSEC].
9. Acknowledgements
Jerome Durand commented on an early version of this memo. Marshall
Eubanks noted an issue regarding short plen values. Tom Pusateri
noted problems with an earlier SPT-join approach. Rami Lehtonen
pointed out issues with the scope of SA-state and provided extensive
commentary. Nidhi Bhaskar gave the document a thorough review.
Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very
extensive feedback. In particular, Pavlin Radoslavov, Dino
Farinacci, Nidhi Bhaskar, and Jerome Durand provided good comments
during and after WG last call. Mark Allman, Bill Fenner, Thomas
Narten, and Alex Zinin provided substantive comments during the IESG
evaluation. The whole MboneD working group is also acknowledged for
continued support and comments.
10. Security Considerations
The addresses of RPs are encoded in the multicast addresses, thus
becoming more visible as single points of failure. Even though this
does not significantly affect the multicast routing security, it may
expose the RP to other kinds of attacks. The operators are
encouraged to pay special attention to securing these routers. See
Section 6.1 for considerations regarding failover and Section 6.2 for
placement of RPs leading to a degree of fate-sharing properties.
As any RP will have to accept PIM-SM Join/Prune/Register messages
from any DR, this might cause a potential Denial of Service attack
scenario. However, this can be mitigated, as the RP can discard all
such messages for all multicast addresses that do not encode the
address of the RP. Both the sender- and receiver-based attacks are
described at greater length in [PIMSEC].
Additionally, the implementation SHOULD also allow manual
configuration of which multicast prefixes are allowed to be used.
This can be used to limit the use of the RP to designated groups
only. In some cases, being able to restrict (at the RP) which
unicast addresses are allowed to send or join to a group is
desirable. (However, note that Join/Prune messages would still leave
state in the network, and Register messages can be spoofed [PIMSEC].)
Obviously, these controls are only possible at the RP, not at the
intermediate routers or the DR.
It is RECOMMENDED that routers supporting this specification do not
act as RPs unless explicitly configured to do so, as becoming an RP
does not require any advertisement (e.g., through BSR or manually).
Otherwise, any router could potentially become an RP (and be abused
as such). Further, multicast groups or group ranges to-be-served MAY
need to be explicitly configured at the RPs, to protect them from
being used unwillingly. Note that the more specific controls (e.g.,
"insider-must-create" or "invite-outsiders" models) as to who is
allowed to use the groups are beyond the scope of this memo.
Excluding internal-only groups from MSDP advertisements does not
protect the groups from outsiders but only offers security by
obscurity; embedded-RP offers similar level of protection. When real
protection is desired, PIM scoping for example, should be set up at
the borders. This is described at more length in Section 6.5.
One should observe that the embedded-RP threat model is actually
rather similar to SSM; both mechanisms significantly reduce the
threats at the sender side. On the receiver side, the threats are
somewhat comparable, as an attacker could do an MLDv2 (S,G) join
towards a non-existent source, which the local RP could not block
based on the MSDP information.
The implementation MUST perform at least the same address validity
checks to the embedded-RP address as it would to one received via
other means; at least fe80::/10, ::/16, and ff00::/8 should be
excluded. This is particularly important, as the information is
derived from the untrusted source (i.e., any user in the Internet),
not from the local configuration.
A more extensive description and comparison of the inter-domain
multicast routing models (traditional ASM with MSDP, embedded-RP,
SSM) and their security properties has been done separately in
[PIMSEC].
11. References
11.1. Normative References
[ADDRARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
11.2. Informative References
[ANYCAST] Hagino, J. and K. Ettikan, "An analysis of IPv6 anycast",
Work in Progress, June 2003.
[ANYCASTRP] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci,
"Anycast Rendevous Point (RP) mechanism using Protocol
Independent Multicast (PIM) and Multicast Source
Discovery Protocol (MSDP)", RFC 3446, January 2003.
[ANYPIMRP] Farinacci, D. and Y. Cai, "Anycast-RP using PIM", Work in
Progress, June 2004.
[BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for
PIM Sparse Mode", Work in Progress, July 2004.
[MSDP] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
[PIMSEC] Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast
Routing Security Issues and Enhancements", Work in
Progress, October 2004.
[PIM-SM] Fenner, B. et al, "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification (Revised)",
Work in Progress, July 2004.
[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP",
Work in Progress, September 2004.
[V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work in
Progress, September 2004.
A. Discussion about Design Tradeoffs
The document only specifies FF70::/12 for now; if/when the upper-most
bit is used, one must specify how FFF0::/12 applies to Embedded-RP.
For example, a different mode of PIM or another protocol might use
that range, in contrast to FF70::/12, as currently specified, being
for PIM-SM only.
Instead of using flags bits ("FF70::/12"), one could have used the
leftmost reserved bits instead ("FF3x:8000::/17").
It has been argued that instead of allowing the operator to specify
RIID, the value could be pre-determined (e.g., "1"). However, this
has not been adopted, as this eliminates address assignment
flexibility from the operator.
Values 64 < "plen" < 96 would overlap with upper bits of the
multicast group-id; due to this restriction, "plen" must not exceed
64 bits. This is in line with RFC 3306.
The embedded-RP addressing could be used to convey other information
(other than RP address) as well, for example, what should be the RPT
threshold for PIM-SM. These could be, whether feasible or not,
encoded in the RP address somehow, or in the multicast group address.
In any case, such modifications are beyond the scope of this memo.
For the cases where the RPs do not exist or are unreachable, or too
much state is being generated to reach in a resource exhaustion
Denial of Service attack, some forms of rate-limiting or other
mechanisms could be deployed to mitigate the threats while trying not
to disturb the legitimate usage. However, as the threats are
generic, they are considered out of scope and discussed separately in
[PIMSEC].
Authors’ Addresses
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
Brian Haberman
Johns Hopkins University Applied Physics Lab
11100 Johns Hopkins Road
Laurel, MD 20723-6099
US
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.