idnits 2.17.1 draft-ietf-mboned-embeddedrp-00.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. -- The abstract seems to indicate that this document updates RFC3306, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 111 has weird spacing: '...in this subra...' -- 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 (October 2003) is 7470 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 (-12) exists of draft-ietf-pim-sm-bsr-03 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-08 == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-03 == Outdated reference: A later version (-03) exists of draft-savola-v6ops-multicast-issues-02 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mboned Working Group P. Savola 3 Internet Draft CSC/FUNET 4 Expiration Date: April 2004 5 B. Haberman 6 Caspian Networks 8 October 2003 10 Embedding the Address of RP in IPv6 Multicast Address 12 draft-ietf-mboned-embeddedrp-00.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 To view the list Internet-Draft Shadow Directories, see 33 http://www.ietf.org/shadow.html. 35 Abstract 37 There exists a huge deployment problem with global, interdomain IPv6 38 multicast: Protocol Independent Multicast - Sparse Mode (PIM-SM) 39 Rendezvous Points (RPs) have no way of communicating the information 40 about multicast sources to other multicast domains, as there is no 41 Multicast Source Discovery Protocol (MSDP), and the whole interdomain 42 Any Source Multicast (ASM) model is rendered unusable; Source 43 Specific Multicast (SSM) avoids these problems but is not considered 44 readily deployable at the moment. This memo defines a PIM-SM group- 45 to-RP mapping which encodes the address of the RP in the IPv6 46 multicast address. In consequence, there would be no need for 47 interdomain MSDP, and even intra-domain RP configuration could be 48 simplified. This memo updates RFC 3306. 50 Table of Contents 52 1. Introduction ............................................... 2 53 2. Unicast-Prefix-based Address Format ........................ 4 54 3. Modified Unicast-Prefix-based Address Format ............... 4 55 4. Embedding the Address of the RP in the Multicast Address ... 5 56 5. Examples ................................................... 6 57 5.1. Example 1 .............................................. 6 58 5.2. Example 2 .............................................. 6 59 5.3. Example 3 .............................................. 6 60 5.4. Example 4 .............................................. 7 61 6. Operational Requirements ................................... 7 62 6.1. Anycast-RP ............................................. 7 63 6.2. Guidelines for Assigning IPv6 Addresses to RPs ......... 7 64 7. Required PIM-SM Modifications .............................. 7 65 7.1. Overview of the Model .................................. 9 66 8. Scalability/Usability Analysis ............................. 9 67 9. Acknowledgements ........................................... 11 68 10. Security Considerations ................................... 11 69 11. References ................................................ 12 70 11.1. Normative References .................................. 12 71 11.2. Informative References ................................ 12 72 Authors' Addresses ............................................. 13 73 A. Discussion about Design Tradeoffs .......................... 13 74 Intellectual Property Statement ................................ 14 75 Full Copyright Statement ....................................... 15 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 It has been noted that there are some problems with SSM deployment 87 and support: it seems unlikely that SSM could be usable as the only 88 interdomain multicast routing mechanism in the short term. This memo 89 proposes a fix to interdomain multicast routing, and provides an 90 additional method for the RP discovery with the intra-domain case. 92 This document proposes a solution to the group-to-RP mapping problem 93 which leverages and extends [RFC3306] by encoding the RP address of 94 the IPv6 multicast group into the group address itself. 96 This mechanism not only provides a simple solution for IPv6 97 interdomain ASM but can be used as a simple solution for IPv6 98 intradomain ASM on scoped addresses, as well. The use as a substitute 99 for Bootstrap Router protocol (BSR) [BSR] is also possible. 101 The solution consists of two elements applicable to a subrange of 102 [RFC3306] IPv6 multicast group addresses which are defined by setting 103 one previously unused bit of the Flags field to "1": 105 o A specification of the mapping by which such a group address 106 encodes the RP address that is to be used with this group, and 108 o A specification of optional and mandatory procedures to operate 109 ASM with PIM-SM on these IPv6 multicast groups. 111 Addresses in this subrange will be called embedded-RP addresses. If 112 used in the interdomain, a mechanism similar to MSDP is not required 113 for these addresses and RP configuration for these addresses can be 114 as simple as zero configuration for routers supporting this 115 specification. 117 It is self-evident that a 128 bit RP address can in general not be 118 embedded into a 128-bit group address with space left to carry a 119 group identity itself. An appropriate form of encoding is thus 120 defined, and it is assumed that the Interface-ID of RPs in the 121 embedded-RP range can be assigned to be specific values. 123 If these assumptions can't be followed, either operational procedures 124 and configuration must be slightly changed or this mechanism can not 125 be used. 127 The assignment of multicast addresses is outside the scope of this 128 document; however, the mechanisms are very probably similar to ones 129 used with [RFC3306]. 131 This memo updates the addressing format presented in RFC 3306. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2. Unicast-Prefix-based Address Format 139 As described in [RFC3306], the multicast address format is as 140 follows: 142 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 143 +--------+----+----+--------+--------+----------------+----------+ 144 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 145 +--------+----+----+--------+--------+----------------+----------+ 147 Where flgs are "0011". (The first two bits are yet undefined and 148 thus zero.) 150 3. Modified Unicast-Prefix-based Address Format 152 This memo proposes a modification to the unicast-prefix-based address 153 format: 155 1. If the second high-order bit in "flgs" is set to 1, the address 156 of the RP is embedded in the multicast address, as described in 157 this memo. 159 2. If the second high-order bit in "flgs" was set to 1, interpret 160 the last low-order 4 bits of "reserved" field as signifying the 161 RP interface ID, as described in this memo. 163 In consequence, the address format becomes: 165 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 166 +--------+----+----+----+----+--------+----------------+----------+ 167 |11111111|flgs|scop|rsvd|RPad| plen | network prefix | group ID | 168 +--------+----+----+----+----+--------+----------------+----------+ 169 +-+-+-+-+ 170 flgs is a set of 4 flags: |0|R|P|T| 171 +-+-+-+-+ 173 R = 1 indicates a multicast address that embeds the address of the 174 PIM-SM RP. Then P MUST BE set to 1, and consequently T MUST be set 175 to 1, as specified in [RFC3306]. 177 In the case that R = 1, the last 4 bits of previously reserved field 178 ("RPad") are interpreted as embedding the interface ID of the RP, as 179 specified in this memo. 181 R = 0 indicates a multicast address that does not embed the address 182 of the PIM-SM RP and follows the semantics defined in [ADDRARCH] and 183 [RFC3306]. In this context, the value of "RPad" has no meaning. 185 4. Embedding the Address of the RP in the Multicast Address 187 The address of the RP can only be embedded in unicast-prefix -based 188 ASM addresses. 190 To identify whether an address is a multicast address as specified in 191 this memo and to be processed any further, it must satisfy all of the 192 below: 194 o it MUST be a multicast address and have R, P, and T flag bits set 195 to 1 (that is, be part of the prefix FF7::/12 or FFF::/12), 197 o "plen" MUST NOT be 0 (ie. not SSM), and 199 o "plen" MUST NOT be greater than 64. 201 The address of the RP can be obtained from a multicast address 202 satisfying the above criteria by taking the following steps: 204 1. take the last 96 bits of the multicast address add 32 zero bits 205 at the end, 207 2. zero the last 128-"plen" bits, and 209 3. replace the last 4 bits with the contents of "RPad". 211 One should note that there are several operational scenarios when 212 [RFC3306] statement "all non-significant bits of the network prefix 213 field SHOULD be zero" is ignored -- and why the second step, above, 214 is necessary. This is to allow multicast address assignments to 215 third parties which still use your RP; see example 2 below. 217 "plen" higher than 64 MUST NOT be used as that would overlap with the 218 upper bits of multicast group-id. 220 The implementation MUST perform at least the same address validity 221 checks to the calculated RP address as to one received via other 222 means (like BSR [BSR] or MSDP for IPv4), to avoid e.g. the address 223 being "::" or "::1". 225 One should note that the 4 bits reserved for "RPad" set the upper 226 bound for RPs per multicast group address; not the number of RPs in a 227 subnet, PIM-SM domain or large-scale network. 229 5. Examples 231 5.1. Example 1 233 The network administrator of 3FFE:FFFF::/32 wants to set up an RP for 234 the network and all of his customers. He chooses network 235 prefix=3FFE:FFFF and plen=32, and wants to use this addressing 236 mechanism. The multicast addresses he will be able to use are of the 237 form: 239 FF7x:y20:3FFE:FFFF:zzzz:zzzz: 241 Where "x" is the multicast scope, "y" the interface ID of the RP 242 address, and "zzzz:zzzz" will be freely assignable within the PIM-SM 243 domain. In this case, the address of the PIM-SM RP would be: 245 3FFE:FFFF::y 247 (and "y" could be anything from 0 to F); the address 3FFE:FFFF::y/128 248 is added as a Loopback address and injected to the routing system. 250 5.2. Example 2 252 As above, the network administrator can also allocate multicast 253 addresses like "FF7x:y20:3FFE:FFFF:DEAD::/80" to some of his 254 customers within the PIM-SM domain. In this case the RP address 255 would still be "3FFE:FFFF::y". 257 Note the second rule of deriving the RP address: the "plen" field in 258 the multicast address, (hex)20 = 32, refers to the length of "network 259 prefix" field considered when obtaining the RP address. In this 260 case, only the first 32 bits of the network prefix field, "3FFE:FFFF" 261 are preserved: the value of "plen" takes no stance on actual 262 unicast/multicast prefix lengths allocated or used in the networks, 263 here from 3FFE:FFFF:DEAD::/48. 265 5.3. Example 3 267 In the above network, the network admin sets up addresses as above, 268 but an organization wants to have their own PIM-SM domain; that's 269 reasonable. The organization can pick multicast addresses like 270 "FF7x:y30:3FFE:FFFF:BEEF::/80", and then their RP address would be 271 "3FFE:FFFF:BEEF::y". 273 5.4. Example 4 275 In the above networks, if the admin wants to specify the RP to be in 276 a non-zero /64 subnet, he could always use something like 277 "FF7x:y40:3FFE:FFFF:BEEF:FEED::/96", and then their RP address would 278 be "3FFE:FFFF:BEEF:FEED::y". There are still 32 bits of multicast 279 group-id's to assign to customers and self. 281 6. Operational Requirements 283 6.1. Anycast-RP 285 One should note that MSDP is also used, in addition to interdomain 286 connections between RPs, in anycast-RP [ANYCASTRP] -technique, for 287 sharing the state information between different RPs in one PIM-SM 288 domain. However, there are other propositions, like [ANYPIMRP]. 290 Anycast-RP mechanism is incompatible with this addressing method 291 unless MSDP is specified and implemented. Alternatively, another 292 method for sharing state information could be used. 294 Anycast-RP and other possible RP failover mechanisms are outside of 295 the scope of this memo. 297 6.2. Guidelines for Assigning IPv6 Addresses to RPs 299 With this mechanism, the RP can be given basically any network prefix 300 up to /64. The interface identifier will have to be manually 301 configured to match "RPad". 303 RPad = 0 SHOULD NOT be used as using it would cause ambiguity with 304 the Subnet-Router Anycast Address [ADDRARCH]. 306 If an administrator wishes to use an RP address that does not conform 307 to the addressing topology but is still from the network provider's 308 prefix (e.g. an additional loopback address assigned on a router), 309 that address can be injected into the routing system via a host 310 route. 312 7. Required PIM-SM Modifications 314 The use of multicast addresses with embedded RP addresses requires 315 additional PIM-SM processing. Namely, a PIM-SM router will need to 316 be able to recognize the encoding and derive the RP address from the 317 address using the rules in section 4 and to be able to use the 318 embedded RP, instead of its own for multicast addresses in this 319 specified range. 321 The three key places where these modifications are used are the 322 Designated Routers (DRs) on the receiver/sender networks, the 323 backbone networks, and the RPs in the domain where the embdedded 324 address has been derived from (see figure below). 326 For the foreign DRs (rtrR1, rtrR23, and rtrR4), this means sending 327 PIM-SM Join/Prune/Register messages towards the foreign RP (rtrRP_S). 328 Naturally, PIM-SM Register-Stop and other messages must also be 329 allowed from the foreign RP. DRs in the local PIM-SM domain (rtrS) 330 do the same. 332 For the RP (rtrRP_S), this means being able to recognize and validate 333 PIM-SM messages which use RP-embedded addressing originated from any 334 DR at all. 336 For the other routers on the path (rtrBB), this means recognizing and 337 validating that the Join/Prune PIM-SM messages using the embedded RP 338 addressing are on the right path towards the RP they think is in 339 charge of the particular address. 341 nodeS - rtrS - rtrRP_S - rtrBB -----+--- rtrR1 - node1 342 | | | 343 node2_S ---------+ | +-- rtrR23 - node2 344 | | 345 | +---- node3 346 | 347 +------------ rtrR4 - node4 349 In addition, the administration of the PIM-SM domains MAY have an 350 option to manually override the RP selection for the embedded RP 351 multicast addresses: the default policy SHOULD be to use the embedded 352 RP. 354 The extraction of the RP information from the multicast address 355 should be done during forwarding state creation. That is, if no 356 state exists for the multicast address, PIM-SM must take the embedded 357 RP information into account when creating forwarding state. Unless 358 otherwise dictated by the administrative policy, this would result in 359 a receiver's DR initiating a PIM-SM Join towards the foreign RP or a 360 source's DR sending PIM-SM Register messages towards the foreign RP. 362 It should be noted that this approach removes the need to run inter- 363 domain MSDP. Multicast distribution trees in foreign networks can be 364 joined by issuing a PIM-SM Join/Prune/Register to the RP address 365 encoded in the multicast address. 367 Also, the addressing model described here could be used to replace or 368 augment the intra-domain Bootstrap Router mechanism (BSR), as the RP- 369 mappings can be communicated by the multicast address assignment. 371 7.1. Overview of the Model 373 The steps when a receiver wishes to join a group are: 375 1. A receiver finds out a group address from some means (e.g. SDR 376 or a web page). 377 2. The receiver issues an MLD Report, joining the group. 378 3. The receiver's DR will initiate the PIM-SM Join process towards 379 the RP embedded in the multicast address. 381 The steps when a sender wishes to send to a group are: 383 1. A sender finds out a group address from some means, whether in 384 an existing group (e.g. SDR, web page) or in a new group (e.g. 385 a call to the administrator for group assignment, use of a 386 multicast address assignment protocol). 387 2. The sender sends to the group. 388 3. The sender's DR will send the packets unicast-encapsulated in 389 PIM-SM Register-messages to the RP address encoded in the 390 multicast address (in the special case that DR is the RP, such 391 sending is only conceptual). 393 In both cases, the messages then go on as specified in [PIM-SM] and 394 other specifications (e.g. Register-Stop and/or SPT Join); there is 395 no difference in them except for the fact that the RP address is 396 derived from the multicast address. 398 Sometimes, some information, using conventional mechanisms, about 399 another RP exists in the PIM-SM domain. The embedded RP SHOULD be 400 used by default, but there MAY be an option to switch the preference. 401 This is because especially when performing PIM-SM forwarding in the 402 transit networks, the routers must have the same notion of the RP, or 403 else the messages may be dropped. 405 8. Scalability/Usability Analysis 407 Interdomain MSDP model for connecting PIM-SM domains is mostly 408 hierarchical. The "embedded RP address" changes this to a mostly 409 flat, sender-centered, full-mesh virtual topology. 411 This may or may not cause some effects; it may or may not be 412 desirable. At the very least, it makes many things much more robust 413 as the number of third parties is minimized. A good scalability 414 analysis is needed. 416 In some cases (especially if e.g. every home user is employing site- 417 local multicast), some degree of hierarchy would be highly desirable, 418 for scalability (e.g. to take the advantage of shared multicast 419 state) and administrative point-of-view. 421 Being able to join/send to remote RPs has security considerations 422 that are considered below, but it has an advantage too: every group 423 has a "home RP" which is able to control (to some extent) who are 424 able to send to the group. 426 One should note that the model presented here simplifies the PIM-SM 427 multicast routing model slightly by removing the RP for senders and 428 receivers in foreign domains. One scalability consideration should 429 be noted: previously foreign sources sent the unicast-encapsulated 430 data to their local RP, now they do so to the foreign RP responsible 431 for the specific group. This is especially important with large 432 multicast groups where there are a lot of heavy senders -- 433 particularly if implementations do not handle unicast-decapsulation 434 well. 436 This model increases the amount of Internet-wide multicast state 437 slightly: the backbone routers might end up with (*, G) and (S, G, 438 rpt) state between receivers and the RP, in addition to (S, G) states 439 between the receivers and senders. Certainly, the amount of inter- 440 domain multicast traffic between sources and the embedded-RP will 441 increase compared to the ASM model with MSDP; however, the domain 442 responsible for the RP is expected to be able to handle this. 444 As the address of the RP is tied to the multicast address, in the 445 case of RP failure PIM-SM BSR mechanisms cannot pick a new RP; the 446 failover mechanisms, if used, for backup RPs are different, and 447 typically would depend on sharing one address. The failover 448 techniques are outside of the scope of this memo. 450 The PIM-SM specification states, "Any RP address configured or 451 learned MUST be a domain-wide reachable address". What this means is 452 not clear, even without embedded-RP. However, typically this 453 statement cannot be proven especially with the foreign RPs (typically 454 one can not even guarantee that the RP exists!). The bottom line is 455 that while traditionally the configuration of RPs and DRs was 456 typically a manual process, and e.g. configuring a non-existant RP 457 was possible, but here the hosts and users which use multicast 458 indirectly specify the RP. 460 9. Acknowledgements 462 Jerome Durand commented on an early draft of this memo. Marshall 463 Eubanks noted an issue regarding short plen values. Tom Pusateri 464 noted problems with earlier SPT-join approach. Rami Lehtonen pointed 465 out issues with the scope of SA-state and provided extensive 466 commentary. Nidhi Bhaskar gave the draft a thorough review. The 467 whole MboneD working group is also acknowledged for the continued 468 support and comments. 470 10. Security Considerations 472 The address of the PIM-SM RP is embedded in the multicast address. 473 RPs may be a good target for Denial of Service attacks -- as they are 474 a single point of failure (excluding failover techniques) for a 475 group. In this way, the target would be clearly visible. However, it 476 could be argued that if interdomain multicast was to be made work 477 e.g. with MSDP, the address would have to be visible anyway (through 478 via other channels, which may be more easily securable). 480 As any RP will have to accept PIM-SM Join/Prune/Register messages 481 from any DR, this might cause a potential DoS attack scenario. 482 However, this can be mitigated by the fact that the RP can discard 483 all such messages for all multicast addresses that do not embed the 484 address of the RP, and if deemed important, the implementation could 485 also allow manual configuration of which multicast addresses or 486 prefixes embedding the RP could be used, so that only the pre-agreed 487 sources could use the RP. 489 In a similar fashion, when a receiver joins to an RP, the DRs must 490 accept similar PIM-SM messages back RPs. 492 One consequence of the usage model is that it allows Internet-wide 493 multicast state creation (from receiver(s) in another domain to the 494 RP in another domain) compared to the domain wide state creation in 495 the MSDP model. 497 One should observe that the embedded RP threat model is actually 498 pretty similar to SSM; both mechanisms significantly reduce the 499 threats at the sender side, but have new ones in the receiver side, 500 as any receiver can try to join any non-existant group or channel, 501 and the local DR or RP cannot readily reject such joins (based on 502 MSDP information). 504 RPs may become a bit more single points of failure as anycast-RP 505 mechanism is not (at least immediately) available. This can be 506 partially mitigated by the fact that some other forms of failover are 507 still possible, and there should be less need to store state as with 508 MSDP. 510 The implementation MUST perform at least the same address validity 511 checks to the embedded RP address as to one received via other means 512 (like BSR or MSDP), to avoid the address being e.g. "::" or "::1". 514 11. References 516 11.1. Normative References 518 [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing 519 Architecture", RFC3513, April 2003. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC3306] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 525 Multicast Addresses", RFC3306, August 2002. 527 11.2. Informative References 529 [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and 530 MSDP", RFC 3446, January 2003. 532 [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", 533 work-in-progress, draft-farinacci-pim-anycast-rp-00.txt, 534 January 2003. 536 [BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for 537 PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm- 538 bsr-03.txt, February 2003. 540 [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Sourc 541 Discovery Protocol (MSDP)", work-in-progress, 542 draft-ietf-msdp-spec-20.txt, May 2003. 544 [PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - 545 Sparse Mode (PIM-SM): Protocol Specification (Revised), 546 work-in-progress, draft-ietf-pim-sm-v2-new-08.txt, 547 October 2003. 549 [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", 550 work-in-progress, draft-ietf-ssm-arch-03.txt, 551 May 2003. 553 [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", 554 work-in-progress, draft-savola-v6ops-multicast- 555 issues-02.txt, October 2003. 557 Authors' Addresses 559 Pekka Savola 560 CSC/FUNET 561 Espoo, Finland 562 EMail: psavola@funet.fi 564 Brian Haberman 565 Caspian Networks 566 One Park Drive, Suite 300 567 Research Triangle Park, NC 27709 568 EMail: brian@innovationslab.net 569 Phone: +1-919-949-4828 571 A. Discussion about Design Tradeoffs 573 The initial thought was to use only SPT join from local RP/DR to 574 foreign RP, rather than a full PIM Join to foreign RP. However, this 575 turned out to be problematic, as this kind of SPT joins where 576 disregarded because the path had not been set up before sending them. 577 A full join to foreign PIM domain is a much clearer approach. 579 One could argue that there should be more RPs than the 4-bit "RPad" 580 allows for, especially if anycast-RP cannot be used. In that light, 581 extending "RPad" to take full advantage of whole 8 bits would seem 582 reasonable. However, this would use up all of the reserved bits, and 583 leave no room for future flexibility. In case of large number of 584 RPs, an operational workaround could be to split the PIM domain: for 585 example, using two /33's instead of one /32 would gain another 16 (or 586 15, if zero is not used) RP addresses. Note that the limit of 4 bits 587 worth of RPs just depends on the prefix the RP address is derived 588 from; one can use multiple prefixes in a domain, and the limit of 16 589 (or 15) RPs should never really be a problem. 591 Some hierarchy (e.g. two-level, "ISP/customer") for RPs could 592 possibly be added if necessary, but that would be torturing one 128 593 bits even more. 595 One particular case, whether in the backbone or in the sender's 596 domain, is where the regular PIM-SM RP would be X, and the embedded 597 RP address would be Y. This could e.g. be a result of a default all- 598 multicast-to-one-RP group mapping, or a local policy decision. The 599 embedded RP SHOULD be used by default, but there MAY be an option to 600 change this preference. 602 Values 64 < "plen" < 96 would overlap with upper bits of the 603 multicast group-id; due to this restriction, "plen" must not exceed 604 64 bits. This is in line with RFC 3306. 606 The embedded RP addressing could be used to convey other information 607 (other than RP address) as well, for example, what should be the RPT 608 threshold for PIM-SM. These could be encoded in the RP address 609 somehow, or in the multicast group address. However, such 610 modifications are beyond the scope of this memo. 612 Some kind of rate-limiting functions, ICMP message responses, or 613 similar could be defined for the case of when the RP embedded in the 614 address is not willing to serve for the specific group (or doesn't 615 even exist). Typically this would result in the datagrams getting 616 blackholed or rejected with ICMP. In particular, a case for 617 "rejection" or "source quench" -like messages would be in the case 618 that a source keeps transmitting a huge amount of data, which is sent 619 to a foreign RP using Register message but is discarded if the RP 620 doesn't allow the source host to transmit: the RP should be able to 621 indicate to the DR, "please limit the amount of Register messages", 622 or "this source sending to my group is bogus". Note that such "kiss- 623 of-death" packets have an authentication problem; spoofing them could 624 result in an entirely different kind of Denial of Service, for 625 legitimate sources. One possibility here would be to specify some 626 form of "return routability" check for DRs and RPs; for example, if a 627 DR receives packets from a host to group G G (resulting in RP address 628 R), the DR would send only a limited amount of packets to R until it 629 has heard back from R (a "positive acknowledgement"). It is not 630 clear whether this needs to be considered or specified in more 631 detail. 633 Could this model work with bidir-PIM? Is it feasible? Not sure, not 634 familiar enough with bidir-PIM. 636 Intellectual Property Statement 638 The IETF takes no position regarding the validity or scope of any 639 intellectual property or other rights that might be claimed to 640 pertain to the implementation or use of the technology described in 641 this document or the extent to which any license under such rights 642 might or might not be available; neither does it represent that it 643 has made any effort to identify any such rights. Information on the 644 IETF's procedures with respect to rights in standards-track and 645 standards-related documentation can be found in BCP-11. Copies of 646 claims of rights made available for publication and any assurances of 647 licenses to be made available, or the result of an attempt made to 648 obtain a general license or permission for the use of such 649 proprietary rights by implementors or users of this specification can 650 be obtained from the IETF Secretariat. 652 The IETF invites any interested party to bring to its attention any 653 copyrights, patents or patent applications, or other proprietary 654 rights which may cover technology that may be required to practice 655 this standard. Please address the information to the IETF Executive 656 Director. 658 Full Copyright Statement 660 Copyright (C) The Internet Society (2003). All Rights Reserved. 662 This document and translations of it may be copied and furnished to 663 others, and derivative works that comment on or otherwise explain it 664 or assist in its implementation may be prepared, copied, published 665 and distributed, in whole or in part, without restriction of any 666 kind, provided that the above copyright notice and this paragraph are 667 included on all such copies and derivative works. However, this 668 document itself may not be modified in any way, such as by removing 669 the copyright notice or references to the Internet Society or other 670 Internet organizations, except as needed for the purpose of 671 developing Internet standards in which case the procedures for 672 copyrights defined in the Internet Standards process must be 673 followed, or as required to translate it into languages other than 674 English. 676 The limited permissions granted above are perpetual and will not be 677 revoked by the Internet Society or its successors or assignees. 679 This document and the information contained herein is provided on an 680 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 681 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 682 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 683 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 684 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 686 Acknowledgement 688 Funding for the RFC Editor function is currently provided by the 689 Internet Society.