idnits 2.17.1 draft-ietf-mboned-embeddedrp-02.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 9 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (March 2004) is 7347 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-00 == 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: 5 errors (**), 0 flaws (~~), 6 warnings (==), 2 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: September 2004 5 B. Haberman 6 Caspian Networks 8 March 2004 10 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address 12 draft-ietf-mboned-embeddedrp-02.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 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 ............................................... 3 48 1.1. Background ............................................. 3 49 1.2. Solution ............................................... 3 50 1.3. Assumptions and Scope .................................. 4 51 1.4. Keywords ............................................... 4 52 2. Unicast-Prefix-based Address Format ........................ 4 53 3. Modified Unicast-Prefix-based Address Format ............... 5 54 4. Embedding the Address of the RP in the Multicast Address ... 5 55 5. Examples ................................................... 7 56 5.1. Example 1 .............................................. 7 57 5.2. Example 2 .............................................. 7 58 5.3. Example 3 .............................................. 8 59 5.4. Example 4 .............................................. 8 60 6. Operational Considerations ................................. 8 61 6.1. RP Redundancy .......................................... 8 62 6.2. RP Deployment .......................................... 8 63 6.3. Guidelines for Assigning IPv6 Addresses to RPs ......... 9 64 6.4. Use as a Substitute for BSR ............................ 9 65 7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 9 66 7.1. PIM-SM Group-to-RP Mapping ............................. 9 67 7.2. Overview of the Model .................................. 10 68 8. Scalability Analysis ....................................... 11 69 9. Acknowledgements ........................................... 12 70 10. Security Considerations ................................... 12 71 11. References ................................................ 13 72 11.1. Normative References .................................. 13 73 11.2. Informative References ................................ 13 74 Authors' Addresses ............................................. 14 75 A. Discussion about Design Tradeoffs .......................... 14 76 B. Changes .................................................... 15 77 B.1 Changes since -01 ....................................... 15 78 B.2 Changes since -00 ....................................... 15 79 Intellectual Property Statement ................................ 16 80 Full Copyright Statement ....................................... 16 82 1. Introduction 84 1.1. Background 86 As has been noticed [V6MISSUES], there exists a deployment problem 87 with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no 88 way of communicating the information about (active) multicast sources 89 to other multicast domains, as Multicast Source Discovery Protocol 90 (MSDP) [MSDP] has not been, on purpose, specified for IPv6. 91 Therefore the whole interdomain Any Source Multicast model is 92 rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these 93 problems but is not a complete solution for several reasons. 95 Further, it has been noted that there are some problems with the 96 support and deployment of mechanisms SSM would require [V6MISSUES]: 97 it seems unlikely that SSM could be usable as the only interdomain 98 multicast routing mechanism in the short term. 100 1.2. Solution 102 This memo describes a multicast address allocation policy in which 103 the address of the RP is encoded in the IPv6 multicast group address, 104 and specifies a PIM-SM group-to-RP mapping to use the encoding, 105 leveraging and extending unicast-prefix -based addressing [RFC3306]. 107 This mechanism not only provides a simple solution for IPv6 108 interdomain Any Source Multicast (ASM) but can be used as a simple 109 solution for IPv6 intradomain ASM with scoped multicast addresses as 110 well. It can also be used as an automatic RP discovery mechanism in 111 those deployment scenarios which would have previously used the 112 Bootstrap Router protocol (BSR) [BSR]. 114 The solution consists of three elements: 116 o A specification of a subrange of [RFC3306] IPv6 multicast group 117 addresses defined by setting one previously unused bit of the 118 Flags field to "1", 120 o A specification of the mapping by which such a group address 121 encodes the RP address that is to be used with this group, and 123 o A description of operational procedures to operate ASM with PIM- 124 SM on these IPv6 multicast groups. 126 Addresses in the subrange will be called embedded-RP addresses. 128 This scheme obviates the need for MSDP, and the routers are not 129 required to include any multicast configuration, except when they act 130 as an RP. 132 This memo updates the addressing format presented in RFC 3306. 134 1.3. Assumptions and Scope 136 In general, a 128-bit RP address can't be embedded into a 128-bit 137 group address with space left to carry the group identity itself. An 138 appropriate form of encoding is thus defined by requiring that the 139 Interface-IDs of RPs in the embedded-RP range can be assigned to be a 140 specific 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. Keywords 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 2. Unicast-Prefix-based Address Format 163 As described in [RFC3306], the multicast address format is as 164 follows: 166 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 167 +--------+----+----+--------+--------+----------------+----------+ 168 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 169 +--------+----+----+--------+--------+----------------+----------+ 171 Where flgs are "0011". (The first two bits have been yet undefined, 172 sent as zero and ignored on receipt.) 174 3. Modified Unicast-Prefix-based Address Format 176 This memo specifies a modification to the unicast-prefix-based 177 address format: 179 1. If the second high-order bit in "flgs" is set to 1, the address 180 of the RP is embedded in the multicast address, as described in 181 this memo. 183 2. If the second high-order bit in "flgs" is set to 1, interpret 184 the last low-order 4 bits of "reserved" field as signifying the 185 RP interface ID ("RIID"), as described in this memo. 187 In consequence, the address format becomes: 189 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 190 +--------+----+----+----+----+--------+----------------+----------+ 191 |11111111|flgs|scop|rsvd|RIID| plen | network prefix | group ID | 192 +--------+----+----+----+----+--------+----------------+----------+ 193 +-+-+-+-+ 194 flgs is a set of 4 flags: |0|R|P|T| 195 +-+-+-+-+ 197 R = 1 indicates a multicast address that embeds the address on the 198 RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as 199 specified in [RFC3306]. 201 In the case that R = 1, the last 4 bits of the previously reserved 202 field are interpreted as embedding the RP interface ID, as specified 203 in this memo. 205 R = 0 indicates a multicast address that does not embed the address 206 of the RP and follows the semantics defined in [ADDRARCH] and 207 [RFC3306]. In this context, the value of "RIID" MUST be sent as zero 208 and MUST be ignored on receipt. 210 4. Embedding the Address of the RP in the Multicast Address 212 The address of the RP can only be embedded in unicast-prefix -based 213 ASM addresses. 215 That is, to identify whether an address is a multicast address as 216 specified in this memo and to be processed any further, it must 217 satisfy all of the below: 219 o it MUST be a multicast address and have R, P, and T flag bits set 220 to 1 (that is, be part of the prefixes FF70::/12 or FFF0::/12), 222 o "plen" MUST NOT be 0 (ie. not SSM), and 224 o "plen" MUST NOT be greater than 64. 226 The address of the RP can be obtained from a multicast address 227 satisfying the above criteria by taking the two steps: 229 1. copy the first "plen" bits of the "network prefix" to a zeroed 230 128-bit address structure, and 231 2. replace the last 4 bits with the contents of "RIID". 233 These two steps could be illustrated as follows: 235 | 20 bits | 4 | 8 | 64 | 32 | 236 +---------+----+----+----------------+----------+ 237 |xtra bits|RIID|plen| network prefix | group ID | 238 +---------+----+----+----------------+----------+ 239 || \\ vvvvvvvvvvv 240 || ``====> copy plen bits of "network prefix" 241 || +------------+------------------------+ 242 || | network pre| 0000000000000000000000 | 243 || +------------+------------------------+ 244 \\ 245 ``=================> copy RIID to the last 4 bits 246 +------------+---------------------+--+ 247 | network pre| 0000000000000000000 |ID| 248 +------------+---------------------+--+ 250 One should note that there are several operational scenarios (see 251 Example 2 below) when [RFC3306] statement "all non-significant bits 252 of the network prefix field SHOULD be zero" is ignored. This is to 253 allow multicast group address allocations to be consistent with 254 unicast prefixes, while the multicast addresses would still use the 255 RP associated with the network prefix. 257 "plen" higher than 64 MUST NOT be used as that would overlap with the 258 high-order bits of multicast group-id. 260 When processing an encoding to get the RP address, the multicast 261 routers MUST perform at least the same address validity checks to the 262 calculated RP address as to one received via other means (like BSR 263 [BSR] or MSDP for IPv4). At least fe80::/10, ::/16, and ff00::/8 264 MUST be excluded. This is particularly important as the information 265 is obtained from an untrusted source, i.e., any Internet user's 266 input. 268 One should note that the 4 bits reserved for "RIID" set the upper 269 bound for RPs for the combination of scope, network prefix, and group 270 ID -- without varying any of these, you can have 4 bits worth of 271 different RPs. However, each of these is an IPv6 group address of 272 its own (i.e., there can be only one RP per multicast address). 274 5. Examples 276 Four examples of multicast address allocation and resulting group-to- 277 RP mappings are described here, to better illustrate the 278 possibilities provided by the encoding. 280 5.1. Example 1 282 The network administrator of 2001:DB8::/32 wants to set up an RP for 283 the network and all the customers. (S)he chooses network 284 prefix=2001:DB8 and plen=32, and wants to use this addressing 285 mechanism. The multicast addresses (s)he will be able to use are of 286 the form: 288 FF7x:y20:2001:DB8:zzzz:zzzz: 290 Where "x" is the multicast scope, "y" the interface ID of the RP 291 address, and "zzzz:zzzz" will be freely assignable to anyone. In this 292 case, the address of the RP would be: 294 2001:DB8::y 296 (and "y" could be anything from 1 to F, as 0 must not be used); the 297 address 2001:DB8::y/128 is added on a router as a loopback address 298 and injected to the routing system. 300 5.2. Example 2 302 As in Example 1, the network administrator can also allocate 303 multicast addresses like "FF7x:y20:2001:DB8:DEAD::/80" to some of 304 customers. In this case the RP address would still be "2001:DB8::y". 306 Note the second rule of deriving the RP address: the "plen" field in 307 the multicast address, 0x20 = 32, refers to the length of "network 308 prefix" field considered when obtaining the RP address. In this 309 case, only the first 32 bits of the network prefix field, "2001:DB8" 310 are preserved: the value of "plen" takes no stance on actual 311 unicast/multicast prefix lengths allocated or used in the networks, 312 here from 2001:DB8:DEAD::/48. 314 In short, this distinction allows more flexible RP address 315 configuration in the scenarios where it is desirable to have the 316 group addresses to be consistent with the unicast prefix allocations. 318 5.3. Example 3 320 In the network of Examples 1 and 2, the network admin sets up 321 addresses for use by their customers, but an organization wants to 322 have their own PIM-SM domain. The organization can pick multicast 323 addresses like "FF7x:y30:2001:DB8:BEEF::/80", and then their RP 324 address would be "2001:DB8:BEEF::y". 326 5.4. Example 4 328 In the above networks, if the administrator wants to specify the RP 329 to be in a non-zero /64 subnet, (s)he could always use something like 330 "FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would 331 be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast 332 group-id's to assign to customers and self. 334 6. Operational Considerations 336 This desction describes the major operational considerations for 337 those deploying this mechanism. 339 6.1. RP Redundancy 341 A technique called "Anycast RP" is used within a PIM-SM domain to 342 share an address and multicast state information between a set of 343 RP's mainly for redundancy purposes. Typically, MSDP has been used 344 for that as well [ANYCASTRP]. There are also other approaches, like 345 using PIM for sharing this information [ANYPIMRP]. 347 RP failover cannot be used with this specification without additional 348 mechanisms or techniques such as MSDP, PIM-SM extensions, or 349 "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP 350 address in the IGP without state sharing (depending on the redundancy 351 requirements, this may or may not be enough, though). However, the 352 redundancy mechanisms are outside of the scope of this memo. 354 6.2. RP Deployment 356 As there is no need to share inter-domain state with MSDP, each DR 357 connecting multicast sources could act as an RP without scalability 358 concerns about setting up and maintaining MSDP sessions. 360 This might be particularly attractive when concerned about RP 361 redundancy. In the case where the DR close to a major source for a 362 group acts as the RP, a certain amount of fate-sharing properties can 363 be obtained without using any RP failover mechanisms: if the DR goes 364 down, the multicast transmission may not work anymore in any case. 366 Along the same lines, it's may also be desirable to distribute the RP 367 responsibilities to multiple RPs. As long as different RPs serve 368 different groups, this is is trivial: each group could map to a 369 different RP (or sufficiently many different RPs that the load on one 370 RP is not a problem). However, load sharing one group faces the 371 similar challenges as Anycast-RP. 373 6.3. Guidelines for Assigning IPv6 Addresses to RPs 375 With this mechanism, the RP can be given basically any network prefix 376 up to /64. The interface identifier will have to be manually 377 configured to match "RIID". 379 RIID = 0 must not be used as using it would cause ambiguity with the 380 Subnet-Router Anycast Address [ADDRARCH]. 382 If an administrator wishes to use an RP address that does not conform 383 to the addressing topology but is still from the network provider's 384 prefix (e.g., an additional loopback address assigned on a router, as 385 described in example 1 in Section 5.1), that address can be injected 386 into the routing system via a host route. 388 6.4. Use as a Substitute for BSR 390 With embedded-RP, use of BSR or other RP configuration mechanisms 391 throughout the PIM domain is not necessary, as each group address 392 specifies the RP to be used. 394 7. The Embedded-RP Group-to-RP Mapping Mechanism 396 This section specifies the group-to-RP mapping mechanism works for 397 Embedded RP. 399 7.1. PIM-SM Group-to-RP Mapping 401 The only PIM-SM modification required is implementing this mechanism 402 as one group-to-RP mapping method. 404 The implementation will have to recognize the address format and 405 derive and use the RP address using the rules in Section 4. This 406 information is used at least when performing Reverse Path Forwarding 407 (RPF) lookups, when processing Join/Prune messages, or performing 408 Register-encapsulation. 410 To avoid loops and inconsistancies, the group-to-RP mapping specified 411 in this memo MUST be used for all embedded-RP groups (i.e., addresses 412 with prefix FF70::/12 or FFF0::/12). 414 It is worth noting that compared to the other group-to-RP mapping 415 mechanisms, which can be precomputed, the embedded-RP mapping must be 416 redone for every new IPv6 group address which would map to a 417 different RP. For efficiency, the results may be cached in an 418 implementation-specific manner, to avoid computation for every 419 embedded-RP packet. 421 This group-to-RP mapping mechanism must be supported by the DR 422 adjacent to the senders and any router on the path from any receiver 423 to the RP. Further, as the switch-over to Shortest Path Tree (SPT) 424 is also possible, it must be supported on the path between the 425 receivers and the senders as well. It also must be supported by any 426 router on the path from any sender to the RP -- in case the RP issues 427 a Register-Stop and Joins the sources. So, in practice, the 428 mechanism must be supported by all routers on any path between the 429 RP, receivers, and senders. 431 7.2. Overview of the Model 433 This section gives a high-level, non-normative overview of how 434 Embedded RP operates, as specified in the previous section. 436 The steps when a receiver wishes to join a group are: 438 1. A receiver finds out a group address from some means (e.g., SDR 439 or a web page). 440 2. The receiver issues an MLD Report, joining the group. 441 3. The receiver's DR will initiate the PIM-SM Join process towards 442 the RP encoded in the multicast address, irrespective of 443 whether it is in the "local" or "remote" PIM domain. 445 The steps when a sender wishes to send to a group are: 447 1. A sender finds out a group address using an unspecified method 448 (e.g, by contacting the administrator for group assignment or 449 using a multicast address assignment protocol). 450 2. The sender sends to the group. 451 3. The sender's DR will send the packets unicast-encapsulated in 452 PIM-SM Register-messages to the RP address encoded in the 453 multicast address (in the special case that DR is the RP, such 454 sending is only conceptual). 456 In fact, all the messages go as specified in [PIM-SM] -- embedded-RP 457 just acts as a group-to-RP mapping mechanism; instead of obtaining 458 the address of the RP from local configuration or configuration 459 protocols (e.g., BSR), it is derived transparently from the encoded 460 multicast address. 462 8. Scalability Analysis 464 Interdomain MSDP model for connecting PIM-SM domains is mostly 465 hierarchical in configuration and deployment, but flat with regard to 466 information distribution. The embedded-RP inter-domain model behaves 467 as if all of the Internet was a single PIM domain, with just one RP 468 per group. So, the inter-domain multicast becomes a flat, RP- 469 centered topology. The scaling issues are described below. 471 Previously foreign sources sent the unicast-encapsulated data to 472 their local RP, now they do so to the foreign RP "responsible" for 473 the specific group (i.e., the prefix where the group address was 474 derived from). This is especially important with large multicast 475 groups where there are a lot of heavy senders -- particularly if 476 implementations do not handle unicast-decapsulation well. 478 This model increases the amount of Internet-wide multicast state 479 slightly: the backbone routers might end up with (*, G) and (S, G, 480 rpt) state between receivers (and past receivers, for PIM Prunes) and 481 the RP, in addition to (S, G) states between the receivers and 482 senders, if SPT is used. However, the traditional ASM model also 483 requires MSDP state to propagate everywhere in inter-domain, so the 484 total amount of state is smaller. 486 The embedded-RP model is practically identical in both inter-domain 487 and intra-domain cases to the traditional PIM-SM in intra-domain. On 488 the other hand, PIM-SM has been deployed (in IPv4) in inter-domain 489 using MSDP; compared to that inter-domain model, this specification 490 simplifies the multicast routing by removing the RP for senders and 491 receivers in foreign domains, and eliminating the MSDP information 492 distribution. 494 As the address of the RP is tied to the multicast address, the RP 495 failure management becomes more difficult, as failover or redundancy 496 mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be used as-is. 497 On the other hand, Anycast-RP using PIM could be used. This 498 described briefly in Section 6.1. 500 The PIM-SM specification states, "Any RP address configured or 501 learned MUST be a domain-wide reachable address". What "reachable" 502 precisely means is not clear, even without embedded-RP. This 503 statement cannot be proven especially with the foreign RPs as one can 504 not even guarantee that the RP exists. Instead of configuring RPs 505 and DRs with a manual process (configuring a non-existent RP was 506 possible though rare), with this specification the hosts and users 507 using multicast indirectly specify the RP themselves, lowering the 508 expectancy of the RP reachability. This is a relatively significant 509 problem but not much different from the current multicast deployment: 510 e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result 511 [PIMSEC]. 513 Being able to join/send to remote RPs raises security concerns that 514 are considered separately, but it has an advantage too: every group 515 has a "responsible RP" which is able to control (to some extent) who 516 are able to send to the group. 518 A more extensive description and comparison of the inter-domain 519 multicast routing models (traditional ASM with MSDP, embedded-RP, 520 SSM) and their security properties has been described in [PIMSEC]. 522 9. Acknowledgements 524 Jerome Durand commented on an early draft of this memo. Marshall 525 Eubanks noted an issue regarding short plen values. Tom Pusateri 526 noted problems with an earlier SPT-join approach. Rami Lehtonen 527 pointed out issues with the scope of SA-state and provided extensive 528 commentary. Nidhi Bhaskar gave the draft a thorough review. 529 Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very 530 extensive feedback. The whole MboneD working group is also 531 acknowledged for the continued support and comments. 533 10. Security Considerations 535 The address of the RP is encoded in the multicast address -- and thus 536 become more visible as single points of failure. Even though this 537 does not significantly affect the multicast routing security, it may 538 expose the RP to other kinds of attacks. The operators are 539 encouraged to pay special attention to securing these routers. See 540 Section 6.1 on considerations regarding failover and Section 6.2 on 541 placement of RPs leading to a degree of fate-sharing properties. 543 As any RP will have to accept PIM-SM Join/Prune/Register messages 544 from any DR, this might cause a potential DoS attack scenario. 545 However, this can be mitigated by the fact that the RP can discard 546 all such messages for all multicast addresses that do not encode the 547 address of the RP. The implementation MAY also allow manual 548 configuration of which multicast addresses or prefixes embedding the 549 RP could be used. 551 In a similar fashion, when a receiver joins to an RP, the DRs must 552 accept similar PIM-SM messages back from RPs. However, this is not a 553 considerable threat. 555 One should observe that the embedded-RP threat model is actually 556 rather similar to SSM; both mechanisms significantly reduce the 557 threats at the sender side. On the receiver side, the threats are 558 somewhat comparable, as an attacker could do an MLDv2 (S,G) join 559 towards a non-existent source, which the local RP could not block 560 based on the MSDP information. 562 The implementation MUST perform at least the same address validity 563 checks to the embedded-RP address as to one received via other means; 564 at least fe80::/10, ::/16, and ff00::/8 should be excluded. This is 565 particularly important as the information is derived from the 566 untrusted source (i.e., any user in the Internet), not from the local 567 configuration. 569 A more extensive description and comparison of the inter-domain 570 multicast routing models (traditional ASM with MSDP, embedded-RP, 571 SSM) and their security properties has been done separately in 572 [PIMSEC]. 574 11. References 576 11.1. Normative References 578 [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing 579 Architecture", RFC3513, April 2003. 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, March 1997. 584 [RFC3306] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 585 Multicast Addresses", RFC3306, August 2002. 587 11.2. Informative References 589 [ANYCAST] Hagino, J., Ettikan, K., "An analysis of IPv6 590 anycast", work-in-progress, 591 draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt, June 2003. 593 [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and 594 MSDP", RFC 3446, January 2003. 596 [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", 597 work-in-progress, draft-ietf-pim-anycast-rp-00.txt, 598 November 2003. 600 [BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for 601 PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm- 602 bsr-03.txt, February 2003. 604 [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source 605 Discovery Protocol (MSDP)", RFC 3618, October 2003. 607 [PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast 608 Routing Security Issues and Enhancements", 609 work-in-progress, draft-savola-mboned-mroutesec-00.txt, 610 January 2004. 612 [PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - 613 Sparse Mode (PIM-SM): Protocol Specification (Revised), 614 work-in-progress, draft-ietf-pim-sm-v2-new-09.txt, 615 February 2004. 617 [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", 618 work-in-progress, draft-ietf-ssm-arch-04.txt, 619 October 2003. 621 [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", 622 work-in-progress, draft-savola-v6ops-multicast- 623 issues-03.txt, February 2004. 625 Authors' Addresses 627 Pekka Savola 628 CSC/FUNET 629 Espoo, Finland 630 EMail: psavola@funet.fi 632 Brian Haberman 633 Caspian Networks 634 One Park Drive, Suite 300 635 Research Triangle Park, NC 27709 636 EMail: brian@innovationslab.net 637 Phone: +1-919-949-4828 639 A. Discussion about Design Tradeoffs 641 It has been argued that instead of allowing the operator to specify 642 RIID, the value could be pre-determined (e.g., "1"). However, this 643 has not been adopted, as this eliminates address assignment 644 flexibility from the operator. 646 Values 64 < "plen" < 96 would overlap with upper bits of the 647 multicast group-id; due to this restriction, "plen" must not exceed 648 64 bits. This is in line with RFC 3306. 650 The embedded-RP addressing could be used to convey other information 651 (other than RP address) as well, for example, what should be the RPT 652 threshold for PIM-SM. These could be, whether feasible or not, 653 encoded in the RP address somehow, or in the multicast group address. 654 In any case, such modifications are beyond the scope of this memo. 656 For the cases where the RPs do not exist or are unreachable, or too 657 much state is being generated to reach in a resource exhaustion DoS 658 attack, some forms of rate-limiting or other mechanisms could be 659 deployed to mitigate the threats while trying not to disturb the 660 legitimate usage. However, as the threats are generic, they are 661 considered out of scope and discussed separately in [PIMSEC]. 663 The mechanism is not usable with Bidirectional PIM without protocol 664 extensions, as pre-computing the Designated Forwarder is not 665 possible. 667 B. Changes 669 [[ RFC-Editor: please remove before publication ]] 671 B.1 Changes since -01 673 o Lots of editorial cleanups and some reorganization, without 674 technical changes. 675 o Remove the specification that RIID=0 SHOULD NOT be accepted, but 676 state that they "must not" be used (implementation vs. 677 operational wording). 678 o Specify that the RP address MUST NOT be of prefixes fe80::/10, 679 ::/16, or ff00::/8. 681 B.2 Changes since -00 683 o Lots of editorial cleanups, or cleanups without techinical 684 changes. 685 o Reinforce the notion of Embedded RP just being a group-to-RP 686 mapping mechanism (causing substantive rewriting in section 7); 687 highlight the fact that precomputing the group-to-RP mapping is 688 not possible. 689 o Add (a bit) more text on RP redundancy and deployment tradeoffs 690 wrt. RPs becoming SPoF. 691 o Clarify the usability/scalability issues in section 8. 692 o Clarify the security issues in Sections 8, Security 693 Considerations and Appendix A, mainly by referring to a separate 694 document. 695 o Add a MUST that embedded-RP mappings must be honored by 696 implementations. 698 Intellectual Property Statement 700 The IETF takes no position regarding the validity or scope of any 701 intellectual property or other rights that might be claimed to 702 pertain to the implementation or use of the technology described in 703 this document or the extent to which any license under such rights 704 might or might not be available; neither does it represent that it 705 has made any effort to identify any such rights. Information on the 706 IETF's procedures with respect to rights in standards-track and 707 standards-related documentation can be found in BCP-11. Copies of 708 claims of rights made available for publication and any assurances of 709 licenses to be made available, or the result of an attempt made to 710 obtain a general license or permission for the use of such 711 proprietary rights by implementors or users of this specification can 712 be obtained from the IETF Secretariat. 714 The IETF invites any interested party to bring to its attention any 715 copyrights, patents or patent applications, or other proprietary 716 rights which may cover technology that may be required to practice 717 this standard. Please address the information to the IETF Executive 718 Director. 720 Full Copyright Statement 722 Copyright (C) The Internet Society (2003). All Rights Reserved. 724 This document and translations of it may be copied and furnished to 725 others, and derivative works that comment on or otherwise explain it 726 or assist in its implementation may be prepared, copied, published 727 and distributed, in whole or in part, without restriction of any 728 kind, provided that the above copyright notice and this paragraph are 729 included on all such copies and derivative works. However, this 730 document itself may not be modified in any way, such as by removing 731 the copyright notice or references to the Internet Society or other 732 Internet organizations, except as needed for the purpose of 733 developing Internet standards in which case the procedures for 734 copyrights defined in the Internet Standards process must be 735 followed, or as required to translate it into languages other than 736 English. 738 The limited permissions granted above are perpetual and will not be 739 revoked by the Internet Society or its successors or assignees. 741 This document and the information contained herein is provided on an 742 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 743 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 744 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 745 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 746 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 748 Acknowledgement 750 Funding for the RFC Editor function is currently provided by the 751 Internet Society.