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