--- 1/draft-ietf-mboned-embeddedrp-06.txt 2006-02-05 00:19:38.000000000 +0100 +++ 2/draft-ietf-mboned-embeddedrp-07.txt 2006-02-05 00:19:38.000000000 +0100 @@ -1,22 +1,22 @@ mboned Working Group P. Savola Internet Draft CSC/FUNET -Expiration Date: December 2004 +Expiration Date: January 2005 B. Haberman Caspian Networks - June 2004 + July 2004 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address - draft-ietf-mboned-embeddedrp-06.txt + draft-ietf-mboned-embeddedrp-07.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -43,21 +43,22 @@ multicast, and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. Table of Contents 1. Introduction ............................................... 2 1.1. Background ............................................. 2 1.2. Solution ............................................... 3 1.3. Assumptions and Scope .................................. 4 1.4. Terminology ............................................ 4 - 2. Unicast-Prefix-based Address Format ........................ 4 + 1.5. Abbreviations .......................................... 4 + 2. Unicast-Prefix-based Address Format ........................ 5 3. Modified Unicast-Prefix-based Address Format ............... 5 4. Embedding the Address of the RP in the Multicast Address ... 6 5. Examples ................................................... 7 5.1. Example 1 .............................................. 7 5.2. Example 2 .............................................. 7 5.3. Example 3 .............................................. 8 5.4. Example 4 .............................................. 8 6. Operational Considerations ................................. 9 6.1. RP Redundancy .......................................... 9 6.2. RP Deployment .......................................... 9 @@ -78,43 +79,43 @@ 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 not been, on purpose, specified for IPv6. - Therefore the whole interdomain Any Source Multicast model is + 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 (ASM) but can be used as a simple - solution for IPv6 intradomain ASM with scoped multicast addresses as - well. It can also be used as an automatic RP discovery mechanism in - those deployment scenarios which would have previously used the - Bootstrap Router protocol (BSR) [BSR]. + interdomain Any Source Multicast but can be used as a simple solution + for IPv6 intradomain ASM with scoped multicast addresses as well. It + can also be used as an automatic RP discovery mechanism in those + deployment scenarios which 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 @@ -122,20 +123,22 @@ 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 3306. + 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, either operational procedures and configuration must be slightly changed or this mechanism can not @@ -155,65 +158,73 @@ Embedded-RP behaves as if all the members of the group were all 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 + 2. Unicast-Prefix-based Address Format As described in [RFC3306], the multicast address format is as follows: | 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+----+----------------+----------+ |11111111|flgs|scop|reserved|plen| network prefix | group ID | +--------+----+----+--------+----+----------------+----------+ Where flgs are "0011". (The first two bits have been yet undefined, sent as zero and ignored on receipt.) 3. Modified Unicast-Prefix-based Address Format This memo specifies a modification to the unicast-prefix-based - address format: - - 1. If the two high-order bits in "flgs" are set to 01, the address - of the RP is embedded in the multicast address, as described in - this memo. - - 2. If the two high-order bit in "flgs" are set to 01, interpret - the last low-order 4 bits of "reserved" field as signifying the - RP interface ID ("RIID"), as described in this memo. - - The encoding and the protocol mode used when the two high-order bit - in "flgs" are set to 11 is intentionally unspecified until such time - that the highest-order bit is defined. - - In consequence, the address format becomes: + address format by specifying the second high-order bit ("R-bit") as + follows: | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | +--------+----+----+----+----+----+----------------+----------+ |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | +--------+----+----+----+----+----+----------------+----------+ +-+-+-+-+ flgs is a set of 4 flags: |0|R|P|T| +-+-+-+-+ R = 1 indicates a multicast address that embeds the address on the RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as - specified in [RFC3306]. If R = 1, but P is set to 0, the packet MUST - be discarded. The behaviour if T is set to 0 when P is set to 1 is - derived from [RFC3306] and is unspecified in this memo. + specified in [RFC3306]. In effect, this implies the prefix + FF70::/12. + + The behavior is unspecified if P or T is not set to 1, as then the + prefix would not be FF70::/12. Likewise, encoding and the protocol + mode used when the two high-order bit in "flgs" are set to 11 + ("FFF0::/12") is intentionally unspecified until such time that the + highest-order bit is defined. In the case that R = 1, the last 4 bits of the previously reserved field are interpreted as embedding the RP interface ID, as specified in this memo. R = 0 indicates a multicast address that does not embed the address of the RP and follows the semantics defined in [ADDRARCH] and [RFC3306]. In this context, the value of "RIID" MUST be sent as zero and MUST be ignored on receipt. @@ -221,49 +232,49 @@ The address of the RP can only be embedded in unicast-prefix -based ASM addresses. That is, to identify whether an address is a multicast address as specified in this memo and to be processed any further, it must satisfy all of the below: o it MUST be a multicast address and have R, P, and T flag bits set to 1 -- that is, be part of the prefix FF70::/12 (note that - FFF0::/12 is unspecified), + FFF0::/12 is yet unspecified), o "plen" MUST NOT be 0 (ie. not SSM), and o "plen" MUST NOT be greater than 64. The address of the RP can be obtained from a multicast address satisfying the above criteria by taking the two steps: 1. copy the first "plen" bits of the "network prefix" to a zeroed 128-bit address structure, and 2. replace the last 4 bits with the contents of "RIID". These two steps could be illustrated as follows: | 20 bits | 4 | 8 | 64 | 32 | +---------+----+----+----------------+----------+ |xtra bits|RIID|plen| network prefix | group ID | +---------+----+----+----------------+----------+ || \\ vvvvvvvvvvv || ``====> copy plen bits of "network prefix" - || +------------+------------------------+ + || +------------+--------------------------+ || | network pre| 0000000000000000000000 | - || +------------+------------------------+ + || +------------+--------------------------+ \\ ``=================> copy RIID to the last 4 bits - +------------+---------------------+--+ - | network pre| 0000000000000000000 |ID| - +------------+---------------------+--+ + +------------+---------------------+----+ + | network pre| 0000000000000000000 |RIID| + +------------+---------------------+----+ One should note that there are several operational scenarios (see Example 3 below) when [RFC3306] statement "all non-significant bits of the network prefix field SHOULD be zero" is ignored. This is to allow multicast group address allocations to be consistent with unicast prefixes, while the multicast addresses would still use the RP associated with the network prefix. "plen" higher than 64 MUST NOT be used as that would overlap with the high-order bits of multicast group-id. @@ -361,29 +372,31 @@ 6.1. RP Redundancy A technique called "Anycast RP" is used within a PIM-SM domain to share an address and multicast state information between a set of RP's mainly for redundancy purposes. Typically, MSDP has been used for that as well [ANYCASTRP]. There are also other approaches, like using PIM for sharing this information [ANYPIMRP]. The most feasible candidate for RP failover is using PIM for Anycast RP or "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP - address in the IGP without state sharing (depending on the redundancy - requirements, this may or may not be enough, though). However, the - redundancy mechanisms are outside of the scope of this memo. + address in the Interior Gateway Protocol (IGP) without state sharing + (depending on the redundancy requirements, this may or may not be + enough, though). However, the redundancy mechanisms are outside of + the scope of this memo. 6.2. RP Deployment - As there is no need to share inter-domain state with MSDP, each DR - connecting multicast sources could act as an RP without scalability - concerns about setting up and maintaining MSDP sessions. + As there is no need to share inter-domain state with MSDP, each + Designated Router connecting multicast sources could act as an RP + without scalability concerns about setting up and maintaining MSDP + sessions. This might be particularly attractive when concerned about RP redundancy. In the case where the DR close to a major source for a group acts as the RP, a certain amount of fate-sharing properties can be obtained without using any RP failover mechanisms: if the DR goes down, the multicast transmission may not work anymore in any case. Along the same lines, it's may also be desirable to distribute the RP responsibilities to multiple RPs. As long as different RPs serve different groups, this is trivial: each group could map to a @@ -420,25 +433,25 @@ MSDP advertisement filtering typically includes at least two capabilities: being able to filter who is able to create a global session ("source filtering"), and being able to filter which groups should be globally accessible ("group filtering"). These are done to prevent local groups from being advertised to the outside, or preventing unauthorized senders from creating global groups. However, such controls do not yet block the outsiders from using such groups, as they could join the groups even without Source Active - advertisement with an (S,G) Join by guessing/learning the source - and/or the group address. For proper protection, one should set up, - e.g., PIM multicast scoping borders at the border routers. - Therefore, embedded-RP has by default roughtly equivalent level of - "protection" as MSDP with SA filtering. + advertisement with a (Source, Group) or (S,G) Join by + guessing/learning the source and/or the group address. For proper + protection, one should set up, e.g., PIM multicast scoping borders at + the border routers. Therefore, embedded-RP has by default roughtly + equivalent level of "protection" as MSDP with SA filtering. A new issue with control comes from the fact that nodes in a "foreign domain" may register to an RP, or send PIM Join to an RP. (These have been possible in the past as well, to a degree, but only through willfull attempts or purposeful RP configuration at DRs.) The main threat in this case is that an outsider illegitimately uses the RP to host his/hers own group(s). This can be mitigated to an extent by filtering which groups or group ranges are allowed at the RP; more specific controls are beyond the scope of this memo. Note that this does not seem to be a serious threat in the first place as anyone @@ -480,21 +493,22 @@ 7.2. Overview of the Model This section gives a high-level, non-normative overview of how Embedded RP operates, as specified in the previous section. The steps when a receiver wishes to join a group are: 1. A receiver finds out a group address from some means (e.g., SDR or a web page). - 2. The receiver issues an MLD Report, joining the group. + 2. The receiver issues an Mulicast Listener Discovery (MLD) + Report, joining the group. 3. The receiver's DR will initiate the PIM-SM Join process towards the RP encoded in the multicast address, irrespective of whether it is in the "local" or "remote" PIM domain. The steps when a sender wishes to send to a group are: 1. A sender finds out a group address using an unspecified method (e.g, by contacting the administrator for group assignment or using a multicast address assignment protocol). 2. The sender sends to the group. @@ -573,39 +587,41 @@ 9. Acknowledgements Jerome Durand commented on an early draft 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 draft 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. The whole MboneD working group is - also acknowledged for the continued support and 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 + the continued support and comments. 10. Security Considerations The addresses of RPs are encoded in the multicast addresses -- and thus become 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 on considerations regarding failover and Section 6.2 on 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 DoS attack scenario. - However, this can be mitigated by the fact that 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 more length in [PIMSEC]. + from any DR, this might cause a potential Denial of Service attack + scenario. However, this can be mitigated by the fact that 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 more 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, it is desirable to be able to restrict (at the RP) which unicast addresses are allowed to send or join to a group. (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. @@ -661,34 +677,34 @@ 11.2. Informative References [ANYCAST] Hagino, J., Ettikan, K., "An analysis of IPv6 anycast", work-in-progress, draft-ietf-ipngwg-ipv6- anycast-analysis-02.txt, June 2003. [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and MSDP", RFC 3446, January 2003. [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", - work-in-progress, draft-ietf-pim-anycast-rp-00.txt, - November 2003. + work-in-progress, draft-ietf-pim-anycast-rp-02.txt, + June 2004. [BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm- bsr-03.txt, February 2003. [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast Routing Security Issues and Enhancements", - work-in-progress, draft-ietf-mboned-mroutesec-00.txt, - April 2004. + work-in-progress, draft-ietf-mboned-mroutesec-02.txt, + June 2004. [PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), work-in-progress, draft-ietf-pim-sm-v2-new-09.txt, February 2004. [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", work-in-progress, draft-ietf-ssm-arch-04.txt, October 2003. @@ -730,25 +746,26 @@ 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 DoS - 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]. + 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]. Intellectual Property Statement 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