idnits 2.17.00 (12 Aug 2021) /tmp/idnits19741/draft-savola-mboned-mcast-rpaddr-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 2003) is 6939 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: draft-ietf-mboned-anycast-rp has been published as RFC 3446 == Outdated reference: draft-ietf-pim-sm-bsr has been published as RFC 5059 == Outdated reference: draft-ietf-msdp-spec has been published as RFC 3618 == Outdated reference: draft-ietf-pim-sm-v2-new has been published as RFC 4601 == Outdated reference: draft-ietf-ssm-arch has been published as RFC 4607 == Outdated reference: A later version (-03) exists of draft-savola-v6ops-multicast-issues-01 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Savola 2 Internet Draft CSC/FUNET 3 Expiration Date: November 2003 4 B. Haberman 5 Caspian Networks 7 May 2003 9 Embedding the Address of RP in IPv6 Multicast Address 11 draft-savola-mboned-mcast-rpaddr-03.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 To view the list Internet-Draft Shadow Directories, see 32 http://www.ietf.org/shadow.html. 34 Abstract 36 As has been noticed, there is exists a huge deployment problem with 37 global, interdomain IPv6 multicast: Protocol Independent Multicast - 38 Sparse Mode (PIM-SM) Rendezvous Points (RPs) have no way of 39 communicating the information about multicast sources to other 40 multicast domains, as there is no Multicast Source Discovery Protocol 41 (MSDP), and the whole interdomain Any Source Multicast model is 42 rendered unusable; SSM avoids these problems. This memo outlines a 43 way to embed the address of the RP in the multicast address, solving 44 the interdomain multicast problem. The problem is three-fold: specify 45 an address format, adjust the operational procedures and 46 configuration if necessary, and modify PIM-SM implementations of 47 those who want to join or send to a group (Designated Routers) or 48 provide one (Rendezvous Points). In consequence, there would be no 49 need for interdomain MSDP, and even intra-domain RP configuration 50 could be simplified. This memo updatres RFC 3306. 52 Table of Contents 54 1. Introduction ............................................... 2 55 2. Unicast-Prefix-based Address Format ........................ 3 56 3. Modified Unicast-Prefix-based Address Format ............... 4 57 4. Embedding the Address of the RP in the Multicast Address ... 4 58 5. Examples ................................................... 5 59 5.1. Example 1 .............................................. 5 60 5.2. Example 2 .............................................. 6 61 5.3. Example 3 .............................................. 6 62 5.4. Example 4 .............................................. 6 63 6. Operational Requirements ................................... 7 64 6.1. Anycast-RP ............................................. 7 65 6.2. Guidelines for Assigning IPv6 Addresses to RPs ......... 7 66 7. Required PIM-SM Modifications .............................. 7 67 7.1. Overview of the Model .................................. 8 68 8. Scalability/Usability Analysis ............................. 9 69 9. Acknowledgements ........................................... 10 70 10. Security Considerations ................................... 10 71 11. References ................................................ 11 72 11.1. Normative References .................................. 11 73 11.2. Informative References ................................ 11 74 Authors' Addresses ............................................. 12 75 A. Open Issues/Discussion ..................................... 12 77 1. Introduction 79 As has been noticed [V6MISSUES], there exists a huge deployment 80 problem with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs 81 have no way of communicating the information about multicast sources 82 to other multicast domains, as there is no MSDP [MSDP], and the whole 83 interdomain Any Source Multicast model is rendered unusable; SSM 84 [SSM] avoids these problems. 86 However, it has been noted that there are some problems with SSM 87 deployment and support: it seems unlikely that SSM could be usable as 88 the only interdomain multicast routing mechanism in the short term. 89 This memo proposes a short-to-midterm fix to interdomain multicast 90 routing, and provides an additional method for the RP discovery with 91 the intra-domain case. 93 This memo outlines a way to embed the address of the RP in the 94 multicast address, solving the interdomain multicast problem. The 95 problem is three-fold: specify an address format, adjust the 96 operational procedures and configuration if necessary, and modify 97 PIM-SM implementations used in the multicast path as described in 98 this memo. In consequence, there would be no need for interdomain 99 MSDP, and even intra-domain RP configuration could be simplified. 101 The solution is founded upon unicast-prefix-based IPv6 multicast 102 addressing [UNIPRFXM] and making some assumptions about IPv6 address 103 assignment for the RPs in the PIM-SM domain. 105 Further, a change in how interdomain PIM-SM operates with these 106 addresses is presented: multicast receivers' and senders' DR's join 107 or send to (respectively) the RP embedded in the address -- not their 108 otherwise locally configured RP (if any). 110 It is self-evident that one can't embed, in the general case, two 111 128-bit addresses in one 128-bit address. In this memo, some 112 assumptions on how this could be done are made. If these assumptions 113 can't be followed, either operational procedures and configuration 114 must be slightly changed or this mechanism not be used. 116 The assignment of multicast addresses is outside the scope of this 117 document; however, the mechanisms are very probably similar to ones 118 used with [UNIPRFXM]. 120 This memo updates the addressing format presented in RFC 3306. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. Unicast-Prefix-based Address Format 128 As described in [UNIPRFXM], the multicast address format is as 129 follows: 131 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 132 +--------+----+----+--------+--------+----------------+----------+ 133 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 134 +--------+----+----+--------+--------+----------------+----------+ 136 Where flgs are "0011". (The first two bits are yet undefined and 137 thus zero.) 139 3. Modified Unicast-Prefix-based Address Format 141 This memo proposes a modification to the unicast-prefix-based address 142 format: 144 1. If the second high-order bit in "flgs" is set to 1, the address 145 of the RP is embedded in the multicast address, as described in 146 this memo. 148 2. If the second high-order bit in "flgs" was set to 1, interpret 149 the last low-order 4 bits of "reserved" field as signifying the 150 RP interface ID, as described in this memo. 152 In consequence, the address format becomes: 154 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 155 +--------+----+----+----+----+--------+----------------+----------+ 156 |11111111|flgs|scop|rsvd|RPad| plen | network prefix | group ID | 157 +--------+----+----+----+----+--------+----------------+----------+ 158 +-+-+-+-+ 159 flgs is a set of 4 flags: |0|R|P|T| 160 +-+-+-+-+ 162 R = 1 indicates a multicast address that embeds the address of the 163 PIM-SM RP. Then P MUST BE set to 1, and consequently T MUST be set 164 to 1, as specified in [UNIPRFXM]. 166 In the case that R = 1, the last 4 bits of previously reserved field 167 ("RPad") are interpreted as embedding the interface ID of the RP, as 168 specified in this memo. 170 R = 0 indicates a multicast address that does not embed the address 171 of the PIM-SM RP and follows the semantics defined in [ADDRARCH] and 172 [UNIPRFXM]. In this context, the value of "RPad" has no meaning. 174 4. Embedding the Address of the RP in the Multicast Address 176 The address of the RP can only be embedded in unicast-prefix -based 177 addresses, but the scheme could be extended to other forms of 178 multicast addresses as well. Further, the mechanism cannot be 179 combined with SSM, as SSM has no RP's. 181 To identify whether an address is a multicast address as specified in 182 this memo and to be processed any further, it must satisfy all of the 183 below: 185 o it MUST be a multicast address and have R, P, and T flag bits set 186 to 1 (that is, be part of the prefix FF7::/12 or FFF::/12) 188 o "plen" MUST NOT be 0 (ie. not SSM) 190 o "plen" MUST NOT be greater than 64 192 The address of the RP can be obtained from a multicast address 193 satisfying the above criteria by taking the following steps: 195 1. take the last 96 bits of the multicast address add 32 zero bits 196 at the end, 198 2. zero the last 128-"plen" bits, and 200 3. replace the last 4 bits with the contents of "RPad". 202 One should note that there are several operational scenarios when 203 [UNIPRFXM] statement "All non-significant bits of the network prefix 204 field SHOULD be zero" is ignored -- and why the second step, above, 205 is necessary. This is to allow multicast address assignments to 206 third parties which still use your RP; see example 2 below. 208 "plen" higher than 64 MUST NOT be used as that would overlap with the 209 upper bits of multicast group-id. 211 The implementation MUST perform at least the same address validity 212 checks to the calculated RP address as to one received via other 213 means (like BSR [BSR] or MSDP), to avoid e.g. the address being "::" 214 or "::1". 216 One should note that the 4 bits reserved for "RPad" set the upper 217 bound for RP's per multicast group address; not the number of RP's in 218 a subnet, PIM-SM domain or large-scale network. 220 5. Examples 222 5.1. Example 1 224 The network administrator of 3FFE:FFFF::/32 wants to set up an RP for 225 the network and all of his customers. He chooses network 226 prefix=3FFE:FFFF and plen=32, and wants to use this addressing 227 mechanism. The multicast addresses he will be able to use are of the 228 form: 230 FF7x:y20:3FFE:FFFF:zzzz:zzzz: 232 Where "x" is the multicast scope, "y" the interface ID of the RP 233 address, and "zzzz:zzzz" will be freely assignable within the PIM-SM 234 domain. In this case, the address of the PIM-SM RP would be: 236 3FFE:FFFF::y 238 (and "y" could be anything from 0 to F); the address 3FFE:FFFF::y/128 239 is added as a Loopback address and injected to the routing system. 241 5.2. Example 2 243 As above, the network administrator can also allocate multicast 244 addresses like "FF7x:y20:3FFE:FFFF:DEAD::/80" to some of his 245 customers within the PIM-SM domain. In this case the RP address 246 would still be "3FFE:FFFF::y". 248 Note the second rule of deriving the RP address: the "plen" field in 249 the multicast address, (hex)20 = 32, refers to the length of "network 250 prefix" field considered when obtaining the RP address. In this 251 case, only the first 32 bits of the network prefix field, "3FFE:FFFF" 252 are preserved: the value of "plen" takes no stance on actual 253 unicast/multicast prefix lengths allocated or used in the networks, 254 here from 3FFE:FFFF:DEAD::/48. 256 5.3. Example 3 258 In the above network, the network admin sets up addresses as above, 259 but an organization wants to have their own PIM-SM domain; that's 260 reasonable. The organization can pick multicast addresses like 261 "FF7x:y30:3FFE:FFFF:BEEF::/80", and then their RP address would be 262 "3FFE:FFFF:BEEF::y". 264 5.4. Example 4 266 In the above networks, if the admin wants to specify the RP to be in 267 a non-zero /64 subnet, he could always use something like 268 "FF7x:y40:3FFE:FFFF:BEEF:FEED::/96", and then their RP address would 269 be "3FFE:FFFF:BEEF:FEED::y". There are still 32 bits of multicast 270 group-id's to assign to customers and self. 272 6. Operational Requirements 274 6.1. Anycast-RP 276 One should note that MSDP is also used, in addition to interdomain 277 connections between RPs, in anycast-RP [ANYCASTRP] -technique, for 278 sharing the state information between different RPs in one PIM-SM 279 domain. However, there are other propositions, like [ANYPIMRP]. 281 Anycast-RP mechanism is incompatible with this addressing method 282 unless MSDP is specified and implemented. Alternatively, another 283 method for sharing state information could be used. 285 Anycast-RP and other possible RP failover mechanisms are outside of 286 the scope of this memo. 288 6.2. Guidelines for Assigning IPv6 Addresses to RPs 290 With this mechanism, the RP can be given basically any network prefix 291 up to /64. The interface identifier will have to be manually 292 configured to match "RPad". 294 If an administrator wishes to use an RP address that does not conform 295 to the addressing topology, that address can be injected into the 296 routing system via a host route. This RP address SHOULD be assigned 297 out of the network's prefix in order to ensure aggregation at the 298 border. 300 7. Required PIM-SM Modifications 302 The use of multicast addresses with embedded RP addresses requires 303 additional PIM-SM processing. Namely, a PIM-SM router will need to 304 be able to recognize the encoding and derive the RP address from the 305 address using the rules in section 4 and to be able to use the 306 embedded RP, instead of its own for multicast addresses in this 307 specified range. 309 The three key places where these modifications are used are the 310 Designated Routers (DRs) on the receiver/sender networks, the 311 backbone networks, and the RPs in the domain where the embdedded 312 address has been derived from (see figure below). 314 For the foreign DR's (rtrR1, rtrR23, and rtrR4), this means sending 315 PIM-SM Join/Prune/Register messages towards the foreign RP (rtrRP_S). 316 Naturally, PIM-SM Register-Stop and other messages must also be 317 allowed from the foreign RP. DR's in the local PIM-SM domain (rtrS) 318 do the same. 320 For the RP (rtrRP_S), this means being able to recognize and validate 321 PIM-SM messages which use RP-embedded addressing originated from any 322 DR at all. 324 For the other routers on the path (rtrBB), this means recognizing and 325 validating that the Join/Prune PIM-SM messages using the embedded RP 326 addressing are on the right path towards the RP they think is in 327 charge of the particular address. 329 nodeS - rtrS - rtrRP_S - rtrBB -----+--- rtrR1 - node1 330 | | | 331 node2_S ---------+ | +-- rtrR23 - node2 332 | | 333 | +---- node3 334 | 335 +------------ rtrR4 - node4 337 In addition, the administration of the PIM-SM domains MAY have an 338 option to manually override the RP selection for the embedded RP 339 multicast addresses: the default policy SHOULD be to use the embedded 340 RP. 342 The extraction of the RP information from the multicast address 343 should be done during forwarding state creation. That is, if no 344 state exists for the multicast address, PIM-SM must take the embedded 345 RP information into account when creating forwarding state. Unless 346 otherwise dictated by the administrative policy, this would result in 347 a receiver's DR initiating a PIM-SM Join towards the foreign RP or a 348 source's DR sending PIM-SM Register messages towards the foreign RP. 350 It should be noted that this approach removes the need to run inter- 351 domain MSDP. Multicast distribution trees in foreign networks can be 352 joined by issuing a PIM-SM Join/Prune/Register to the RP address 353 encoded in the multicast address. 355 Also, the addressing model described here could be used to replace or 356 augment the intra-domain Bootstrap Router mechanism (BSR), as the RP- 357 mappings can be communicated by the multicast address assignment. 359 7.1. Overview of the Model 361 The steps when a receiver wishes to join a group are: 363 1. A receiver finds out a group address from some means (e.g. SDR 364 or a web page). 366 2. The receiver issues an MLD Report, joining the group. 367 3. The receiver's DR will initiate the PIM-SM Join process towards 368 the RP embedded in the multicast address. 370 The steps when a sender wishes to send to a group are: 372 1. A sender finds out a group address from some means, whether in 373 an existing group (e.g. SDR, web page) or in a new group (e.g. 374 a call to the administrator for group assignment, use of a 375 multicast address assignment protocol). 376 2. The sender sends to the group. 377 3. The sender's DR will send the packets unicast-encapsulated in 378 PIM-SM Register-messages to the RP address encoded in the 379 multicast address (in the special case that DR is the RP, such 380 sending is only conceptual). 382 In both cases, the messages then go on as specified in [PIM-SM] and 383 other specifications (e.g. Register-Stop and/or SPT Join); there is 384 no difference in them except for the fact that the RP address is 385 derived from the multicast address. 387 Sometimes, some information, using conventional mechanisms, about 388 another RP exists in the PIM-SM domain. The embedded RP SHOULD be 389 used by default, but there MAY be an option to switch the preference. 390 This is because especially when performing PIM-SM forwarding in the 391 transit networks, the routers must have the same notion of the RP, or 392 else the messages may be dropped. 394 8. Scalability/Usability Analysis 396 Interdomain MSDP model for connecting PIM-SM domains is mostly 397 hierarchical. The "embedded RP address" changes this to a mostly 398 flat, sender-centered, full-mesh virtual topology. 400 This may or may not cause some effects; it may or may not be 401 desirable. At the very least, it makes many things much more robust 402 as the number of third parties is minimized. A good scalability 403 analysis is needed. 405 In some cases (especially if e.g. every home user is employing site- 406 local multicast), some degree of hierarchy would be highly desirable, 407 for scalability (e.g. take the advantage of shared multicast state) 408 and administrative point-of-view. 410 Being able to join/send to remote RP's has security considerations 411 that are considered below, but it has an advantage too: every group 412 has a "home RP" which is able to control (to some extent) who are 413 able to send to the group. 415 One should note that the model presented here simplifies the PIM-SM 416 multicast routing model slightly by removing the RP for senders and 417 receivers in foreign domains. One scalability consideration should 418 be noted: previously foreign sources sent the unicast-encapsulated 419 data to their local RP, now they do so to the foreign RP responsible 420 for the specific group. This is especially important with large 421 multicast groups where there are a lot of heavy senders -- 422 particularly if implementations do not handle unicast-decapsulation 423 well. 425 This model increases the amount of Internet-wide multicast state 426 slightly: the backbone routers might end up with (*, G) and (S, G, 427 rpt) state between receivers and the RP, in addition to (S, G) states 428 between the receivers and senders. Certainly, the amount of inter- 429 domain multicast traffic between sources and the embedded-RP will 430 increase compared to the ASM model with MSDP; however, the domain 431 responsible for the RP is expected to be able to handle this. 433 As the address of the RP is tied to the multicast address, in the 434 case of RP failure, PIM-SM BSR mechanisms cannot pick a new RP; the 435 failover mechanisms, if used, for backup RP's are different, and 436 typically would depend on sharing one address. The failover 437 techniques are outside of the scope of this memo. 439 9. Acknowledgements 441 Jerome Durand commented on an early draft of this memo. Marshall 442 Eubanks noted an issue regarding short plen values. Tom Pusateri 443 noted problems with earlier SPT-join approach. Rami Lehtonen pointed 444 out issues with the scope of SA-state and provided extensive 445 commentary. Nidhi Bhaskar gave the draft a thorough review. The 446 whole MboneD working group is also acknowledged for the continued 447 support and comments. 449 10. Security Considerations 451 The address of the PIM-SM RP is embedded in the multicast address. 452 RPs may be a good target for Denial of Service attacks -- as they are 453 a single point of failure (excluding failover techniques) for a 454 group. In this way, the target would be clearly visible. However, it 455 could be argued that if interdomain multicast was to be made work 456 e.g. with MSDP, the address would have to be visible anyway (through 457 via other channels, which may be more easily securable). 459 As any RP will have to accept PIM-SM Join/Prune/Register messages 460 from any DR's, this might cause a potential DoS attack scenario. 461 However, this can be mitigated by the fact that the RP can discard 462 all such messages for all multicast addresses that do not embed the 463 address of the RP, and if deemed important, the implementation could 464 also allow manual configuration of which multicast addresses or 465 prefixes embedding the RP could be used; however, at least with 466 addresses, this would increase the need for coordination between 467 multicast sources and administration. 469 In a similar fashion, DR's must accept similar PIM-SM messages back 470 from the foreign RP's for which a receiver in DR's network has 471 joined. 473 One consequence of the usage model is that it allows Internet-wide 474 multicast state creation (from receiver(s) in another domain to the 475 RP in another domain) compared to the domain wide state creation in 476 the MSDP model. 478 RPs may become a bit more single points of failure as anycast-RP 479 mechanism is not (at least immediately) available. This can be 480 partially mitigated by the fact that some other forms of failover are 481 still possible, and there should be less need to store state as with 482 MSDP. 484 The implementation MUST perform at least the same address validity 485 checks to the embedded RP address as to one received via other means 486 (like BSR or MSDP), to avoid the address being e.g. "::" or "::1". 488 11. References 490 11.1. Normative References 492 [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing 493 Architecture", RFC3513, April 2003. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, March 1997. 498 [UNIPRFXM] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 499 Multicast Addresses", RFC3306, August 2002. 501 11.2. Informative References 503 [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and 504 MSDP", work-in-progress, draft-ietf-mboned-anycast- 505 rp-08.txt, May 2001. 507 [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", 508 work-in-progress, draft-farinacci-pim-anycast-rp-00.txt, 509 January 2003. 511 [BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for 512 PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm- 513 bsr-03.txt, February 2003. 515 [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Sourc 516 Discovery Protocol (MSDP)", work-in-progress, 517 draft-ietf-msdp-spec-16.txt, May 2003. 519 [PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - 520 Sparse Mode (PIM-SM): Protocol Specification (Revised), 521 work-in-progress, draft-ietf-pim-sm-v2-new-06.txt, 522 December 2002. 524 [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", 525 work-in-progress, draft-ietf-ssm-arch-03.txt, 526 May 2003. 528 [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", 529 work-in-progress, draft-savola-v6ops-multicast- 530 issues-01.txt, November 2002. 532 Authors' Addresses 534 Pekka Savola 535 CSC/FUNET 536 Espoo, Finland 537 EMail: psavola@funet.fi 539 Brian Haberman 540 Caspian Networks 541 One Park Drive 542 Suite 400 543 Research Triangle Park, NC 27709 544 EMail: bkhabs@nc.rr.com 545 Phone: +1-919-949-4828 547 A. Open Issues/Discussion 549 The initial thought was to use only SPT join from local RP/DR to 550 foreign RP, rather than a full PIM Join to foreign RP. However, this 551 turned out to be problematic, as this kind of SPT joins where 552 disregarded because the path had not been set up before sending them. 553 A full join to foreign PIM domain is a much clearer approach. 555 One could argue that there can be more RPs than the 4-bit "RPad" 556 allows for, especially if anycast-RP cannot be used. In that light, 557 extending "RPad" to take full advantage of whole 8 bits would seem 558 reasonable. However, this would use up all of the reserved bits, and 559 leave no room for future flexibility. In case of large number of 560 RPs, an operational workaround could be to split the PIM domain: for 561 example, using two /33's instead of one /32 would gain another 16 RP 562 addresses. 564 Some hierarchy (e.g. two-level, "ISP/customer") for RPs could 565 possibly be added if necessary, but that would be torturing one 128 566 bits even more. 568 One particular case, whether in the backbone or in the sender's 569 domain, is where the regular PIM-SM RP would be X, and the embedded 570 RP address would be Y. This could e.g. be a result of a default all- 571 multicast-to-one-RP group mapping, or a local policy decision. The 572 embedded RP SHOULD be used by default, but there MAY be an option to 573 change this preference. 575 Values 64 < "plen" < 96 would overlap with upper bits of the 576 multicast group-id; due to this restriction, "plen" must not exceed 577 64 bits. This is in line with RFC 3306.