--- 1/draft-ietf-mboned-embeddedrp-05.txt 2006-02-05 00:19:37.000000000 +0100 +++ 2/draft-ietf-mboned-embeddedrp-06.txt 2006-02-05 00:19:37.000000000 +0100 @@ -2,21 +2,21 @@ mboned Working Group P. Savola Internet Draft CSC/FUNET Expiration Date: December 2004 B. Haberman Caspian Networks June 2004 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address - draft-ietf-mboned-embeddedrp-05.txt + draft-ietf-mboned-embeddedrp-06.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 @@ -38,22 +38,22 @@ 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. Table of Contents - 1. Introduction ............................................... 3 - 1.1. Background ............................................. 3 + 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 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 @@ -68,26 +68,20 @@ 7.1. PIM-SM Group-to-RP Mapping ............................. 11 7.2. Overview of the Model .................................. 11 8. Scalability Analysis ....................................... 12 9. Acknowledgements ........................................... 13 10. Security Considerations ................................... 14 11. References ................................................ 15 11.1. Normative References .................................. 15 11.2. Informative References ................................ 15 Authors' Addresses ............................................. 16 A. Discussion about Design Tradeoffs .......................... 16 - B. Changes .................................................... 17 - B.4 Changes since -04 ....................................... 17 - B.3 Changes since -03 ....................................... 17 - B.2 Changes since -02 ....................................... 17 - B.3 Changes since -01 ....................................... 18 - B.4 Changes since -00 ....................................... 18 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. @@ -203,21 +197,23 @@ | 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]. + 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. 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. @@ -304,42 +300,45 @@ be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast group-id's to assign to customers and self ("y" could be anything from 1 to F, as 0 must not be used). 5.2. Example 2 As in Example 1, the network administrator of 2001:DB8::/32 wants to set up the RP, but to make it more flexible, wants to place it on a specifically routed subnet, and wants to keep larger address space for group allocations. That is, the administrator selects the least - specific part of the prefix, with plen=32, and the group addresses - will be of the form: + specific part of the unicast prefix, with plen=32, and the group + addresses will be from the multicast prefix: - FF7x:y20:2001:DB8:zzzz:zzzz: + FF7x:y20:2001:DB8::/64 Where "x" is the multicast scope, "y" the interface ID of the RP - address, and "zzzz:zzzz" will be assignable to anyone. In this case, - the address of the RP would be: + address, and there are 64 bits for group-id's or assignments. In + this case, the address of the RP would be: 2001:DB8::y The address 2001:DB8::y/128 is assigned to a router as a loopback address and injected to the routing system; if the network administrator sets up only one or a couple of RPs (and e.g., not one RP per subnet), this approach may be preferable to the one described in Example 1. 5.3. Example 3 - As in Example 2, the network administrator can also allocate - multicast addresses like "FF7x:y20:2001:DB8:DEAD::/80" to some of - customers. In this case the RP address would still be "2001:DB8::y". + As in Example 2, the network administrator can also assign multicast + prefixes like "FF7x:y20:2001:DB8:DEAD::/80" to some of customers. In + this case the RP address would still be "2001:DB8::y". (Note that + this is just a more specific subcase of Example 2, where the + administrator assigns a multicast prefix, not just invidial group- + id's.) Note the second rule of deriving the RP address: the "plen" field in the multicast address, 0x20 = 32, refers to the length of "network prefix" field considered when obtaining the RP address. In this case, only the first 32 bits of the network prefix field, "2001:DB8" are preserved: the value of "plen" takes no stance on actual unicast/multicast prefix lengths allocated or used in the networks, here from 2001:DB8:DEAD::/48. In short, this distinction allows more flexible RP address @@ -387,32 +386,32 @@ 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 different RP (or sufficiently many different RPs that the load on one RP is not a problem). However, load sharing one group faces the similar challenges as Anycast-RP. 6.3. Guidelines for Assigning IPv6 Addresses to RPs - With this mechanism, the RP can be given basically any network prefix - up to /64. The interface identifier will have to be manually - configured to match "RIID". + With this mechanism, the RP can be given basically any unicast + network prefix up to /64. The interface identifier will have to be + manually configured to match "RIID". RIID = 0 must not be used as using it would cause ambiguity with the Subnet-Router Anycast Address [ADDRARCH]. If an administrator wishes to use an RP address that does not conform to the addressing topology but is still from the network provider's - prefix (e.g., an additional loopback address assigned on a router, as - described in example 2 in Section 5.1), that address can be injected - into the routing system via a host route. + unicast prefix (e.g., an additional loopback address assigned on a + router, as described in example 2 in Section 5.1), that address can + be injected into the routing system via a host route. 6.4. Use as a Substitute for BSR With embedded-RP, use of BSR or other RP configuration mechanisms throughout the PIM domain is not necessary, as each group address specifies the RP to be used. 6.5. Controlling the Use of RPs Compared to the MSDP inter-domain ASM model, the control and @@ -436,42 +435,42 @@ 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 - with a /64 prefix can create an own RP, without having to + with a /64 unicast prefix can create an own RP, without having to illegitimately get it from someone else. 7. The Embedded-RP Group-to-RP Mapping Mechanism This section specifies the group-to-RP mapping mechanism for Embedded RP. 7.1. PIM-SM Group-to-RP Mapping The only PIM-SM modification required is implementing this mechanism as one group-to-RP mapping method. The implementation will have to recognize the address format and derive and use the RP address using the rules in Section 4. This information is used at least when performing Reverse Path Forwarding (RPF) lookups, when processing Join/Prune messages, or performing Register-encapsulation. - To avoid loops and inconsistancies, the group-to-RP mapping specified - in this memo MUST be used for all embedded-RP groups (i.e., addresses - with prefix FF70::/12). + To avoid loops and inconsistancies, for addresses in the range + FF70::/12, the Embedded-RP mapping MUST be considered to be the + longest possible match and higher priority than any other mechanism. It is worth noting that compared to the other group-to-RP mapping mechanisms, which can be precomputed, the embedded-RP mapping must be redone for every new IPv6 group address which would map to a different RP. For efficiency, the results may be cached in an implementation-specific manner, to avoid computation for every embedded-RP packet. This group-to-RP mapping mechanism must be supported by the RP, the DR adjacent to the senders and any router on the path from any @@ -737,79 +736,20 @@ 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]. -B. Changes - - [[ RFC-Editor: please remove before publication ]] - - B.4 Changes since -04 - - o Only update the boilerplates. - - B.3 Changes since -03 - - o Further clarifications, especially regarding Inter/intra-domain - terminology. - o Recommend more strongly that multicast groups can be configured, - and that they should be explicitly configured, to protect against - abuse. - o Note that more detailed controls on who can use a multicast - address are out of scope. - o Add discussion about controls/manageability and how that has - changed from the MSDP model. - - B.2 Changes since -02 - - o Clarified security considerations, wrt. RPs being abused by third - parties and policy controls at the RP. - o Clarified that only RPs, DRs next to sources sending to embedded- - RP groups, and routers between the receivers and the RPs need to - have support this mapping. - o Try to be clearer that FF70::/12 is meant for PIM-SM at the - moment, while FFF0::/12 is unspecified. - - o Minor miscellaneous changes. - - B.3 Changes since -01 - - o Lots of editorial cleanups and some reorganization, without - technical changes. - o Remove the specification that RIID=0 SHOULD NOT be accepted, but - state that they "must not" be used (implementation vs. - operational wording). - o Specify that the RP address MUST NOT be of prefixes fe80::/10, - ::/16, or ff00::/8. - - B.4 Changes since -00 - - o Lots of editorial cleanups, or cleanups without techinical - changes. - o Reinforce the notion of Embedded RP just being a group-to-RP - mapping mechanism (causing substantive rewriting in section 7); - highlight the fact that precomputing the group-to-RP mapping is - not possible. - o Add (a bit) more text on RP redundancy and deployment tradeoffs - wrt. RPs becoming SPoF. - o Clarify the usability/scalability issues in section 8. - o Clarify the security issues in Sections 8, Security - Considerations and Appendix A, mainly by referring to a separate - document. - o Add a MUST that embedded-RP mappings must be honored by - implementations. - 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 be found in BCP 78 and BCP 79.