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