idnits 2.17.1 draft-ietf-mboned-embeddedrp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 794. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 784. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 15) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7217 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3513 (ref. 'ADDRARCH') (Obsoleted by RFC 4291) == Outdated reference: A later version (-07) exists of draft-ietf-pim-anycast-rp-02 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-03 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-09 == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-04 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 mboned Working Group P. Savola 2 Internet Draft CSC/FUNET 3 Expiration Date: January 2005 4 B. Haberman 5 Caspian Networks 7 July 2004 9 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address 11 draft-ietf-mboned-embeddedrp-07.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This memo defines an address allocation policy in which the address 38 of the Rendezvous Point (RP) is encoded in an IPv6 multicast group 39 address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), 40 this can be seen as a specification of a group-to-RP mapping 41 mechanism. This allows an easy deployment of scalable inter-domain 42 multicast, and simplifies the intra-domain multicast configuration as 43 well. This memo updates the addressing format presented in RFC 3306. 45 Table of Contents 47 1. Introduction ............................................... 2 48 1.1. Background ............................................. 2 49 1.2. Solution ............................................... 3 50 1.3. Assumptions and Scope .................................. 4 51 1.4. Terminology ............................................ 4 52 1.5. Abbreviations .......................................... 4 53 2. Unicast-Prefix-based Address Format ........................ 5 54 3. Modified Unicast-Prefix-based Address Format ............... 5 55 4. Embedding the Address of the RP in the Multicast Address ... 6 56 5. Examples ................................................... 7 57 5.1. Example 1 .............................................. 7 58 5.2. Example 2 .............................................. 7 59 5.3. Example 3 .............................................. 8 60 5.4. Example 4 .............................................. 8 61 6. Operational Considerations ................................. 9 62 6.1. RP Redundancy .......................................... 9 63 6.2. RP Deployment .......................................... 9 64 6.3. Guidelines for Assigning IPv6 Addresses to RPs ......... 9 65 6.4. Use as a Substitute for BSR ............................ 10 66 6.5. Controlling the Use of RPs ............................. 10 67 7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 11 68 7.1. PIM-SM Group-to-RP Mapping ............................. 11 69 7.2. Overview of the Model .................................. 11 70 8. Scalability Analysis ....................................... 12 71 9. Acknowledgements ........................................... 13 72 10. Security Considerations ................................... 14 73 11. References ................................................ 15 74 11.1. Normative References .................................. 15 75 11.2. Informative References ................................ 15 76 Authors' Addresses ............................................. 16 77 A. Discussion about Design Tradeoffs .......................... 16 79 1. Introduction 81 1.1. Background 83 As has been noticed [V6MISSUES], there exists a deployment problem 84 with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no 85 way of communicating the information about (active) multicast sources 86 to other multicast domains, as Multicast Source Discovery Protocol 87 (MSDP) [MSDP] has not been, on purpose, specified for IPv6. 88 Therefore the whole interdomain Any Source Multicast (ASM) model is 89 rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these 90 problems but is not a complete solution for several reasons, as noted 91 below. 93 Further, it has been noted that there are some problems with the 94 support and deployment of mechanisms SSM would require [V6MISSUES]: 95 it seems unlikely that SSM could be usable as the only interdomain 96 multicast routing mechanism in the short term. 98 1.2. Solution 100 This memo describes a multicast address allocation policy in which 101 the address of the RP is encoded in the IPv6 multicast group address, 102 and specifies a PIM-SM group-to-RP mapping to use the encoding, 103 leveraging and extending unicast-prefix -based addressing [RFC3306]. 105 This mechanism not only provides a simple solution for IPv6 106 interdomain Any Source Multicast but can be used as a simple solution 107 for IPv6 intradomain ASM with scoped multicast addresses as well. It 108 can also be used as an automatic RP discovery mechanism in those 109 deployment scenarios which would have previously used the Bootstrap 110 Router protocol (BSR) [BSR]. 112 The solution consists of three elements: 114 o A specification of a subrange of [RFC3306] IPv6 multicast group 115 addresses defined by setting one previously unused bit of the 116 Flags field to "1", 118 o A specification of the mapping by which such a group address 119 encodes the RP address that is to be used with this group, and 121 o A description of operational procedures to operate ASM with PIM- 122 SM on these IPv6 multicast groups. 124 Addresses in the subrange will be called embedded-RP addresses. 126 This scheme obviates the need for MSDP, and the routers are not 127 required to include any multicast configuration, except when they act 128 as an RP. 130 This memo updates the addressing format presented in RFC 3306. 132 Some design tradeoffs are discussed in Appendix A. 134 1.3. Assumptions and Scope 136 A 128-bit RP address can't be embedded into a 128-bit group address 137 with space left to carry the group identity itself. An appropriate 138 form of encoding is thus defined by requiring that the Interface-IDs 139 of RPs in the embedded-RP range can be assigned to be a specific 140 value. 142 If these assumptions can't be followed, either operational procedures 143 and configuration must be slightly changed or this mechanism can not 144 be used. 146 The assignment of multicast addresses is outside the scope of this 147 document; it is up to the RP and applications to ensure that group 148 addresses are unique using some unspecified method. However, the 149 mechanisms are very probably similar to ones used with [RFC3306]. 151 Similarly, RP failure management methods, such as Anycast-RP, are out 152 of scope for this document. These do not work without additional 153 specification or deployment. This is covered briefly in Section 6.1. 155 1.4. Terminology 157 Embedded-RP behaves as if all the members of the group were all 158 intra-domain to the information distribution. However, as it gives a 159 solution for the global IPv6 multicast Internet, spanning multiple 160 administrative domains, we say it is a solution for inter-domain 161 multicast. 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 1.5. Abbreviations 169 ASM Any Source Multicast 170 BSR Bootstrap Router 171 DR Designated Router 172 IGP Interior Gateway Protocol 173 MLD Multicast Listener Discovery 174 MSDP Multicast Source Discovery Protocol 175 PIM Protocol Independent Multicast 176 PIM-SM Protocol Independent Multicast - Sparse Mode 177 RIID RP Interface ID (as specified in this memo) 178 RP Rendezvous Point 179 RPF Reverse Path Forwarding 180 SPT Shortest Path Tree 181 SSM Source-specific Multicast 183 2. Unicast-Prefix-based Address Format 185 As described in [RFC3306], the multicast address format is as 186 follows: 188 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 189 +--------+----+----+--------+----+----------------+----------+ 190 |11111111|flgs|scop|reserved|plen| network prefix | group ID | 191 +--------+----+----+--------+----+----------------+----------+ 193 Where flgs are "0011". (The first two bits have been yet undefined, 194 sent as zero and ignored on receipt.) 196 3. Modified Unicast-Prefix-based Address Format 198 This memo specifies a modification to the unicast-prefix-based 199 address format by specifying the second high-order bit ("R-bit") as 200 follows: 202 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 203 +--------+----+----+----+----+----+----------------+----------+ 204 |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | 205 +--------+----+----+----+----+----+----------------+----------+ 206 +-+-+-+-+ 207 flgs is a set of 4 flags: |0|R|P|T| 208 +-+-+-+-+ 210 R = 1 indicates a multicast address that embeds the address on the 211 RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as 212 specified in [RFC3306]. In effect, this implies the prefix 213 FF70::/12. 215 The behavior is unspecified if P or T is not set to 1, as then the 216 prefix would not be FF70::/12. Likewise, encoding and the protocol 217 mode used when the two high-order bit in "flgs" are set to 11 218 ("FFF0::/12") is intentionally unspecified until such time that the 219 highest-order bit is defined. 221 In the case that R = 1, the last 4 bits of the previously reserved 222 field are interpreted as embedding the RP interface ID, as specified 223 in this memo. 225 R = 0 indicates a multicast address that does not embed the address 226 of the RP and follows the semantics defined in [ADDRARCH] and 227 [RFC3306]. In this context, the value of "RIID" MUST be sent as zero 228 and MUST be ignored on receipt. 230 4. Embedding the Address of the RP in the Multicast Address 232 The address of the RP can only be embedded in unicast-prefix -based 233 ASM addresses. 235 That is, to identify whether an address is a multicast address as 236 specified in this memo and to be processed any further, it must 237 satisfy all of the below: 239 o it MUST be a multicast address and have R, P, and T flag bits set 240 to 1 -- that is, be part of the prefix FF70::/12 (note that 241 FFF0::/12 is yet unspecified), 243 o "plen" MUST NOT be 0 (ie. not SSM), and 245 o "plen" MUST NOT be greater than 64. 247 The address of the RP can be obtained from a multicast address 248 satisfying the above criteria by taking the two steps: 250 1. copy the first "plen" bits of the "network prefix" to a zeroed 251 128-bit address structure, and 252 2. replace the last 4 bits with the contents of "RIID". 254 These two steps could be illustrated as follows: 256 | 20 bits | 4 | 8 | 64 | 32 | 257 +---------+----+----+----------------+----------+ 258 |xtra bits|RIID|plen| network prefix | group ID | 259 +---------+----+----+----------------+----------+ 260 || \\ vvvvvvvvvvv 261 || ``====> copy plen bits of "network prefix" 262 || +------------+--------------------------+ 263 || | network pre| 0000000000000000000000 | 264 || +------------+--------------------------+ 265 \\ 266 ``=================> copy RIID to the last 4 bits 267 +------------+---------------------+----+ 268 | network pre| 0000000000000000000 |RIID| 269 +------------+---------------------+----+ 271 One should note that there are several operational scenarios (see 272 Example 3 below) when [RFC3306] statement "all non-significant bits 273 of the network prefix field SHOULD be zero" is ignored. This is to 274 allow multicast group address allocations to be consistent with 275 unicast prefixes, while the multicast addresses would still use the 276 RP associated with the network prefix. 278 "plen" higher than 64 MUST NOT be used as that would overlap with the 279 high-order bits of multicast group-id. 281 When processing an encoding to get the RP address, the multicast 282 routers MUST perform at least the same address validity checks to the 283 calculated RP address as to one received via other means (like BSR 284 [BSR] or MSDP for IPv4). At least fe80::/10, ::/16, and ff00::/8 285 MUST be excluded. This is particularly important as the information 286 is obtained from an untrusted source, i.e., any Internet user's 287 input. 289 One should note that the 4 bits reserved for "RIID" set the upper 290 bound for RPs for the combination of scope, network prefix, and group 291 ID -- without varying any of these, you can 2^4-1 = 15 different RPs 292 (as RIID=0 is reserved, see section 6.3). However, each of these is 293 an IPv6 group address of its own (i.e., there can be only one RP per 294 multicast address). 296 5. Examples 298 Four examples of multicast address allocation and resulting group-to- 299 RP mappings are described here, to better illustrate the 300 possibilities provided by the encoding. 302 5.1. Example 1 304 The network administrator of 2001:DB8::/32 wants to set up an RP for 305 the network and all the customers, by placing it on an existing 306 subnet, e.g., 2001:DB8:BEEF:FEED::/64. 308 In that case, the group addresses would be something like 309 "FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would 310 be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast 311 group-id's to assign to customers and self ("y" could be anything 312 from 1 to F, as 0 must not be used). 314 5.2. Example 2 316 As in Example 1, the network administrator of 2001:DB8::/32 wants to 317 set up the RP, but to make it more flexible, wants to place it on a 318 specifically routed subnet, and wants to keep larger address space 319 for group allocations. That is, the administrator selects the least 320 specific part of the unicast prefix, with plen=32, and the group 321 addresses will be from the multicast prefix: 323 FF7x:y20:2001:DB8::/64 325 Where "x" is the multicast scope, "y" the interface ID of the RP 326 address, and there are 64 bits for group-id's or assignments. In 327 this case, the address of the RP would be: 329 2001:DB8::y 331 The address 2001:DB8::y/128 is assigned to a router as a loopback 332 address and injected to the routing system; if the network 333 administrator sets up only one or a couple of RPs (and e.g., not one 334 RP per subnet), this approach may be preferable to the one described 335 in Example 1. 337 5.3. Example 3 339 As in Example 2, the network administrator can also assign multicast 340 prefixes like "FF7x:y20:2001:DB8:DEAD::/80" to some of customers. In 341 this case the RP address would still be "2001:DB8::y". (Note that 342 this is just a more specific subcase of Example 2, where the 343 administrator assigns a multicast prefix, not just invidial group- 344 id's.) 346 Note the second rule of deriving the RP address: the "plen" field in 347 the multicast address, 0x20 = 32, refers to the length of "network 348 prefix" field considered when obtaining the RP address. In this 349 case, only the first 32 bits of the network prefix field, "2001:DB8" 350 are preserved: the value of "plen" takes no stance on actual 351 unicast/multicast prefix lengths allocated or used in the networks, 352 here from 2001:DB8:DEAD::/48. 354 In short, this distinction allows more flexible RP address 355 configuration in the scenarios where it is desirable to have the 356 group addresses to be consistent with the unicast prefix allocations. 358 5.4. Example 4 360 In the network of Examples 1, 2 and 3, the network admin sets up 361 addresses for use by their customers, but an organization wants to 362 have their own PIM-SM domain. The organization can pick multicast 363 addresses like "FF7x:y30:2001:DB8:BEEF::/80", and then their RP 364 address would be "2001:DB8:BEEF::y". 366 6. Operational Considerations 368 This section describes the major operational considerations for those 369 deploying this mechanism. 371 6.1. RP Redundancy 373 A technique called "Anycast RP" is used within a PIM-SM domain to 374 share an address and multicast state information between a set of 375 RP's mainly for redundancy purposes. Typically, MSDP has been used 376 for that as well [ANYCASTRP]. There are also other approaches, like 377 using PIM for sharing this information [ANYPIMRP]. 379 The most feasible candidate for RP failover is using PIM for Anycast 380 RP or "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP 381 address in the Interior Gateway Protocol (IGP) without state sharing 382 (depending on the redundancy requirements, this may or may not be 383 enough, though). However, the redundancy mechanisms are outside of 384 the scope of this memo. 386 6.2. RP Deployment 388 As there is no need to share inter-domain state with MSDP, each 389 Designated Router connecting multicast sources could act as an RP 390 without scalability concerns about setting up and maintaining MSDP 391 sessions. 393 This might be particularly attractive when concerned about RP 394 redundancy. In the case where the DR close to a major source for a 395 group acts as the RP, a certain amount of fate-sharing properties can 396 be obtained without using any RP failover mechanisms: if the DR goes 397 down, the multicast transmission may not work anymore in any case. 399 Along the same lines, it's may also be desirable to distribute the RP 400 responsibilities to multiple RPs. As long as different RPs serve 401 different groups, this is trivial: each group could map to a 402 different RP (or sufficiently many different RPs that the load on one 403 RP is not a problem). However, load sharing one group faces the 404 similar challenges as Anycast-RP. 406 6.3. Guidelines for Assigning IPv6 Addresses to RPs 408 With this mechanism, the RP can be given basically any unicast 409 network prefix up to /64. The interface identifier will have to be 410 manually configured to match "RIID". 412 RIID = 0 must not be used as using it would cause ambiguity with the 413 Subnet-Router Anycast Address [ADDRARCH]. 415 If an administrator wishes to use an RP address that does not conform 416 to the addressing topology but is still from the network provider's 417 unicast prefix (e.g., an additional loopback address assigned on a 418 router, as described in example 2 in Section 5.1), that address can 419 be injected into the routing system via a host route. 421 6.4. Use as a Substitute for BSR 423 With embedded-RP, use of BSR or other RP configuration mechanisms 424 throughout the PIM domain is not necessary, as each group address 425 specifies the RP to be used. 427 6.5. Controlling the Use of RPs 429 Compared to the MSDP inter-domain ASM model, the control and 430 management of who can use an RP and how changes slightly and deserves 431 explicit discussion. 433 MSDP advertisement filtering typically includes at least two 434 capabilities: being able to filter who is able to create a global 435 session ("source filtering"), and being able to filter which groups 436 should be globally accessible ("group filtering"). These are done to 437 prevent local groups from being advertised to the outside, or 438 preventing unauthorized senders from creating global groups. 440 However, such controls do not yet block the outsiders from using such 441 groups, as they could join the groups even without Source Active 442 advertisement with a (Source, Group) or (S,G) Join by 443 guessing/learning the source and/or the group address. For proper 444 protection, one should set up, e.g., PIM multicast scoping borders at 445 the border routers. Therefore, embedded-RP has by default roughtly 446 equivalent level of "protection" as MSDP with SA filtering. 448 A new issue with control comes from the fact that nodes in a "foreign 449 domain" may register to an RP, or send PIM Join to an RP. (These have 450 been possible in the past as well, to a degree, but only through 451 willfull attempts or purposeful RP configuration at DRs.) The main 452 threat in this case is that an outsider illegitimately uses the RP to 453 host his/hers own group(s). This can be mitigated to an extent by 454 filtering which groups or group ranges are allowed at the RP; more 455 specific controls are beyond the scope of this memo. Note that this 456 does not seem to be a serious threat in the first place as anyone 457 with a /64 unicast prefix can create an own RP, without having to 458 illegitimately get it from someone else. 460 7. The Embedded-RP Group-to-RP Mapping Mechanism 462 This section specifies the group-to-RP mapping mechanism for Embedded 463 RP. 465 7.1. PIM-SM Group-to-RP Mapping 467 The only PIM-SM modification required is implementing this mechanism 468 as one group-to-RP mapping method. 470 The implementation will have to recognize the address format and 471 derive and use the RP address using the rules in Section 4. This 472 information is used at least when performing Reverse Path Forwarding 473 (RPF) lookups, when processing Join/Prune messages, or performing 474 Register-encapsulation. 476 To avoid loops and inconsistancies, for addresses in the range 477 FF70::/12, the Embedded-RP mapping MUST be considered to be the 478 longest possible match and higher priority than any other mechanism. 480 It is worth noting that compared to the other group-to-RP mapping 481 mechanisms, which can be precomputed, the embedded-RP mapping must be 482 redone for every new IPv6 group address which would map to a 483 different RP. For efficiency, the results may be cached in an 484 implementation-specific manner, to avoid computation for every 485 embedded-RP packet. 487 This group-to-RP mapping mechanism must be supported by the RP, the 488 DR adjacent to the senders and any router on the path from any 489 receiver to the RP. Paths for Shortest Path Tree (SPT) formation and 490 Register-Stop do not require the support, as those are accomplished 491 with an (S,G) Join. 493 7.2. Overview of the Model 495 This section gives a high-level, non-normative overview of how 496 Embedded RP operates, as specified in the previous section. 498 The steps when a receiver wishes to join a group are: 500 1. A receiver finds out a group address from some means (e.g., SDR 501 or a web page). 502 2. The receiver issues an Mulicast Listener Discovery (MLD) 503 Report, joining the group. 504 3. The receiver's DR will initiate the PIM-SM Join process towards 505 the RP encoded in the multicast address, irrespective of 506 whether it is in the "local" or "remote" PIM domain. 508 The steps when a sender wishes to send to a group are: 510 1. A sender finds out a group address using an unspecified method 511 (e.g, by contacting the administrator for group assignment or 512 using a multicast address assignment protocol). 513 2. The sender sends to the group. 514 3. The sender's DR will send the packets unicast-encapsulated in 515 PIM-SM Register-messages to the RP address encoded in the 516 multicast address (in the special case that DR is the RP, such 517 sending is only conceptual). 519 In fact, all the messages go as specified in [PIM-SM] -- embedded-RP 520 just acts as a group-to-RP mapping mechanism; instead of obtaining 521 the address of the RP from local configuration or configuration 522 protocols (e.g., BSR), it is derived transparently from the encoded 523 multicast address. 525 8. Scalability Analysis 527 Interdomain MSDP model for connecting PIM-SM domains is mostly 528 hierarchical in configuration and deployment, but flat with regard to 529 information distribution. The embedded-RP inter-domain model behaves 530 as if every group formed its own Internet-wide PIM domain, with the 531 group mapping to a single RP, wherever the receivers or senders are. 532 So, the inter-domain multicast becomes a flat, RP-centered topology. 533 The scaling issues are described below. 535 Previously foreign sources sent the unicast-encapsulated data to 536 their "local" RP, now they do so to the "foreign" RP responsible for 537 the specific group. This is especially important with large 538 multicast groups where there are a lot of heavy senders -- 539 particularly if implementations do not handle unicast-decapsulation 540 well. 542 With IPv4 ASM multicast, there is roughly two kinds of Internet-wide 543 state: MSDP (propagated everywhere), and multicast routing state (on 544 the receiver or sender branches). The former is eliminated, but the 545 backbone routers might end up with (*, G) and (S, G, rpt) state 546 between receivers (and past receivers, for PIM Prunes) and the RP, in 547 addition to (S, G) states between the receivers and senders, if SPT 548 is used. However, the total amount of state is smaller. 550 The embedded-RP model is practically identical in both inter-domain 551 and intra-domain cases to the traditional PIM-SM in intra-domain. On 552 the other hand, PIM-SM has been deployed (in IPv4) in inter-domain 553 using MSDP; compared to that inter-domain model, this specification 554 simplifies the tree construction (i.e., multicast routing) by 555 removing the RP for senders and receivers in foreign domains, and 556 eliminating the MSDP information distribution. 558 As the address of the RP is tied to the multicast address, the RP 559 failure management becomes more difficult, as the deployed failover 560 or redundancy mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be 561 used as-is. However, Anycast-RP using PIM provides equal redundancy; 562 this described briefly in Section 6.1. 564 The PIM-SM specification states, "Any RP address configured or 565 learned MUST be a domain-wide reachable address". What "reachable" 566 precisely means is not clear, even without embedded-RP. This 567 statement cannot be proven especially with the foreign RPs as one can 568 not even guarantee that the RP exists. Instead of manually 569 configuring RPs and DRs (configuring a non-existent RP was possible 570 though rare), with this specification the hosts and users using 571 multicast indirectly specify the RP themselves, lowering the 572 expectancy of the RP reachability. This is a relatively significant 573 problem but not much different from the current multicast deployment: 574 e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result 575 [PIMSEC]. 577 Being able to join/send to remote RPs raises security concerns that 578 are considered separately, but it has an advantage too: every group 579 has a "responsible RP" which is able to control (to some extent) who 580 are able to send to the group. 582 A more extensive description and comparison of the inter-domain 583 multicast routing models (traditional ASM with MSDP, embedded-RP, 584 SSM) and their security properties has been described in [PIMSEC]. 586 9. Acknowledgements 588 Jerome Durand commented on an early draft of this memo. Marshall 589 Eubanks noted an issue regarding short plen values. Tom Pusateri 590 noted problems with an earlier SPT-join approach. Rami Lehtonen 591 pointed out issues with the scope of SA-state and provided extensive 592 commentary. Nidhi Bhaskar gave the draft a thorough review. 593 Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very 594 extensive feedback. In particular, Pavlin Radoslavov, Dino 595 Farinacci, Nidhi Bhaskar, and Jerome Durand provided good comments 596 during and after WG last call. Mark Allman, Bill Fenner, Thomas 597 Narten, and Alex Zinin provided substantive comments during the IESG 598 evaluation. The whole MboneD working group is also acknowledged for 599 the continued support and comments. 601 10. Security Considerations 603 The addresses of RPs are encoded in the multicast addresses -- and 604 thus become more visible as single points of failure. Even though 605 this does not significantly affect the multicast routing security, it 606 may expose the RP to other kinds of attacks. The operators are 607 encouraged to pay special attention to securing these routers. See 608 Section 6.1 on considerations regarding failover and Section 6.2 on 609 placement of RPs leading to a degree of fate-sharing properties. 611 As any RP will have to accept PIM-SM Join/Prune/Register messages 612 from any DR, this might cause a potential Denial of Service attack 613 scenario. However, this can be mitigated by the fact that the RP can 614 discard all such messages for all multicast addresses that do not 615 encode the address of the RP. Both the sender- and receiver-based 616 attacks are described at more length in [PIMSEC]. 618 Additionally the implementation SHOULD also allow manual 619 configuration of which multicast prefixes are allowed to be used. 620 This can be used to limit the use of the RP to designated groups 621 only. In some cases, it is desirable to be able to restrict (at the 622 RP) which unicast addresses are allowed to send or join to a group. 623 (However, note that Join/Prune messages would still leave state in 624 the network, and Register messages can be spoofed [PIMSEC].) 625 Obviously, these controls are only possible at the RP, not at the 626 intermediate routers or the DR. 628 It is RECOMMENDED that routers supporting this specification do not 629 act as RPs unless explicitly configured to do so; as becoming an RP 630 does not require any advertisement (e.g., through BSR or manually), 631 otherwise any router could potentially become an RP (and be abused as 632 such). Further, multicast groups or group ranges to-be-served MAY 633 need to be explicitly configured at the RPs, to protect from being 634 used unwillingly. Note that the more specific controls (e.g., 635 "insider-must-create" or "invite-outsiders" models) to who is allowed 636 to use the groups are beyond the scope of this memo. 638 Excluding internal-only groups from MSDP advertisements does not 639 protect the groups from outsiders, only offers security by obscurity; 640 embedded-RP offers similar level of protection. When real protection 641 is desired, e.g., PIM scoping should be set up at the borders; this 642 is described at more length in Section 6.5. 644 One should observe that the embedded-RP threat model is actually 645 rather similar to SSM; both mechanisms significantly reduce the 646 threats at the sender side. On the receiver side, the threats are 647 somewhat comparable, as an attacker could do an MLDv2 (S,G) join 648 towards a non-existent source, which the local RP could not block 649 based on the MSDP information. 651 The implementation MUST perform at least the same address validity 652 checks to the embedded-RP address as to one received via other means; 653 at least fe80::/10, ::/16, and ff00::/8 should be excluded. This is 654 particularly important as the information is derived from the 655 untrusted source (i.e., any user in the Internet), not from the local 656 configuration. 658 A more extensive description and comparison of the inter-domain 659 multicast routing models (traditional ASM with MSDP, embedded-RP, 660 SSM) and their security properties has been done separately in 661 [PIMSEC]. 663 11. References 665 11.1. Normative References 667 [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing 668 Architecture", RFC3513, April 2003. 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, March 1997. 673 [RFC3306] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 674 Multicast Addresses", RFC3306, August 2002. 676 11.2. Informative References 678 [ANYCAST] Hagino, J., Ettikan, K., "An analysis of IPv6 679 anycast", work-in-progress, draft-ietf-ipngwg-ipv6- 680 anycast-analysis-02.txt, June 2003. 682 [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and 683 MSDP", RFC 3446, January 2003. 685 [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", 686 work-in-progress, draft-ietf-pim-anycast-rp-02.txt, 687 June 2004. 689 [BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for 690 PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm- 691 bsr-03.txt, February 2003. 693 [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source 694 Discovery Protocol (MSDP)", RFC 3618, October 2003. 696 [PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast 697 Routing Security Issues and Enhancements", 698 work-in-progress, draft-ietf-mboned-mroutesec-02.txt, 699 June 2004. 701 [PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - 702 Sparse Mode (PIM-SM): Protocol Specification (Revised), 703 work-in-progress, draft-ietf-pim-sm-v2-new-09.txt, 704 February 2004. 706 [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", 707 work-in-progress, draft-ietf-ssm-arch-04.txt, 708 October 2003. 710 [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", 711 work-in-progress, draft-savola-v6ops-multicast- 712 issues-03.txt, February 2004. 714 Authors' Addresses 716 Pekka Savola 717 CSC/FUNET 718 Espoo, Finland 719 EMail: psavola@funet.fi 721 Brian Haberman 722 Caspian Networks 723 One Park Drive, Suite 300 724 Research Triangle Park, NC 27709 725 EMail: brian@innovationslab.net 726 Phone: +1-919-949-4828 728 A. Discussion about Design Tradeoffs 730 The document only specifies FF70::/12 for now; if/when the upper-most 731 bit is used, one must specify how FFF0::/12 applies to Embedded-RP. 732 For example, a different mode of PIM or another protocol might use 733 that range, in contrast to FF70::/12, as currently specified, being 734 for PIM-SM only. 736 Instead of using flags bits ("FF70::/12"), one could have used the 737 left-most reserved bits instead ("FF3x:8000::/17"). 739 It has been argued that instead of allowing the operator to specify 740 RIID, the value could be pre-determined (e.g., "1"). However, this 741 has not been adopted, as this eliminates address assignment 742 flexibility from the operator. 744 Values 64 < "plen" < 96 would overlap with upper bits of the 745 multicast group-id; due to this restriction, "plen" must not exceed 746 64 bits. This is in line with RFC 3306. 748 The embedded-RP addressing could be used to convey other information 749 (other than RP address) as well, for example, what should be the RPT 750 threshold for PIM-SM. These could be, whether feasible or not, 751 encoded in the RP address somehow, or in the multicast group address. 752 In any case, such modifications are beyond the scope of this memo. 754 For the cases where the RPs do not exist or are unreachable, or too 755 much state is being generated to reach in a resource exhaustion 756 Denial of Service attack, some forms of rate-limiting or other 757 mechanisms could be deployed to mitigate the threats while trying not 758 to disturb the legitimate usage. However, as the threats are 759 generic, they are considered out of scope and discussed separately in 760 [PIMSEC]. 762 Intellectual Property Statement 764 The IETF takes no position regarding the validity or scope of any 765 Intellectual Property Rights or other rights that might be claimed to 766 pertain to the implementation or use of the technology described in 767 this document or the extent to which any license under such rights 768 might or might not be available; nor does it represent that it has 769 made any independent effort to identify any such rights. Information 770 on the IETF's procedures with respect to rights in IETF Documents can 771 be found in BCP 78 and BCP 79. 773 Copies of IPR disclosures made to the IETF Secretariat and any 774 assurances of licenses to be made available, or the result of an 775 attempt made to obtain a general license or permission for the use of 776 such proprietary rights by implementers or users of this 777 specification can be obtained from the IETF on-line IPR repository at 778 http://www.ietf.org/ipr. 780 The IETF invites any interested party to bring to its attention any 781 copyrights, patents or patent applications, or other proprietary 782 rights that may cover technology that may be required to implement 783 this standard. Please address the information to the IETF at ietf- 784 ipr@ietf.org. 786 Disclaimer of Validity 788 This document and the information contained herein are provided on an 789 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 790 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 791 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 792 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 793 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 794 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 796 Copyright Statement 798 Copyright (C) The Internet Society (2004). This document is subject 799 to the rights, licenses and restrictions contained in BCP 78, and 800 except as set forth therein, the authors retain all their rights. 802 Acknowledgement 804 Funding for the RFC Editor function is currently provided by the 805 Internet Society.