idnits 2.17.00 (12 Aug 2021) /tmp/idnits32643/draft-savola-mboned-mcast-rpaddr-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 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2003) is 7007 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 2373 (ref. 'ADDRARCH') (Obsoleted by RFC 3513) == Outdated reference: draft-ietf-mboned-anycast-rp has been published as RFC 3446 == Outdated reference: draft-ietf-msdp-spec has been published as RFC 3618 == Outdated reference: draft-ietf-pim-sm-v2-new has been published as RFC 4601 == Outdated reference: draft-ietf-ssm-arch has been published as RFC 4607 == Outdated reference: A later version (-03) exists of draft-savola-v6ops-multicast-issues-01 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet Draft CSC/FUNET 4 Expiration Date: September 2003 5 B. Haberman 6 Caspian Networks 8 March 2003 10 Embedding the Address of RP in IPv6 Multicast Address 12 draft-savola-mboned-mcast-rpaddr-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 As has been noticed, there is exists a huge deployment problem with 38 global, interdomain IPv6 multicast: PIM Renzesvous Points (RPs) have 39 no way of communicating the information about multicast sources to 40 other multicast domains, as there is no MSDP, and the whole 41 interdomain Any Source Multicast model is rendered unusable; SSM 42 avoids these problems. This memo outlines a way to embed the address 43 of the RP in the multicast address, solving the interdomain multicast 44 problem. The problem is three-fold: specify an address format, adjust 45 the operational procedures and configuration if necessary, and modify 46 PIM implementations of those who want to join or send to a group 47 (Designated Routers) or provide one (Rendezvous Points). In 48 consequence, there would be no need for interdomain MSDP. 50 Table of Contents 52 1. Introduction ............................................... 2 53 2. Unicast-Prefix-based Address Format ........................ 3 54 3. Modified Unicast-Prefix-based Address Format ............... 3 55 4. Embedding the Address of the RP in the Multicast Address ... 4 56 5. Examples ................................................... 5 57 5.1. Example 1 .............................................. 5 58 5.2. Example 2 .............................................. 5 59 5.3. Example 3 .............................................. 6 60 5.4. Example 4 .............................................. 6 61 6. Operational Requirements ................................... 6 62 6.1. Anycast-RP ............................................. 6 63 6.2. Guidelines for Assigning IPv6 Addresses to RPs ......... 6 64 7. Required PIM Modifications ................................. 7 65 7.1. Overview of the Model .................................. 8 66 8. Scalability/Usability Analysis ............................. 8 67 9. Acknowledgements ........................................... 9 68 10. Security Considerations ................................... 10 69 11. References ................................................ 11 70 11.1. Normative References .................................. 11 71 11.2. Informative References ................................ 11 72 Authors' Addresses ............................................. 11 73 A. Open Issues/Discussion ..................................... 12 75 1. Introduction 77 As has been noticed [V6MISSUES], there is exists a huge deployment 78 problem with global, interdomain IPv6 multicast: PIM [PIM] RPs have 79 no way of communicating the information about multicast sources to 80 other multicast domains, as there is no MSDP [MSDP], and the whole 81 interdomain Any Source Multicast model is rendered unusable; SSM 82 [SSM] avoids there problems. 84 This memo outlines a way to embed the address of the RP in the 85 multicast address, solving the interdomain multicast problem. The 86 problem is three-fold: specify an address format, adjust the 87 operational procedures and configuration if necessary, and modify PIM 88 implementations of DR's where receivers/senders are expected use the 89 multicast addressing as described in this memo. In consequence, 90 there would be no need for interdomain MSDP. 92 The solution is founded upon unicast-prefix-based IPv6 multicast 93 addressing [UNIPRFXM] and making some assumptions about IPv6 address 94 assignment for the RPs in the PIM domain. 96 Further, a change in how interdomain PIM operates with these 97 addresses is presented: multicast receivers' and senders' DR's join 98 or send to (respectively) the RP embedded in the address -- not their 99 locally configured RP. 101 It is self-evident that one can't embed, in the general case, two 102 128-bit addresses in one 128-bit address. In this memo, some 103 assumptions on how this could be done are made. If these assumptions 104 can't be followed, either operational procedures and configuration 105 must be slightly changed or this mechanism not be used. 107 The assignment of multicast addresses is outside the scope of this 108 document; however, the mechanisms are very probably similar to ones 109 used with [UNIPRFXM]. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Unicast-Prefix-based Address Format 117 As described in [UNIPRFXM], the multicast address format is as 118 follows: 120 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 121 +--------+----+----+--------+--------+----------------+----------+ 122 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 123 +--------+----+----+--------+--------+----------------+----------+ 125 Where flgs are "0011". (The first two bits are yet undefined and 126 thus zero.) 128 3. Modified Unicast-Prefix-based Address Format 130 This memo proposes a modification to the unicast-prefix-based address 131 format: 133 1. If the second high-order bit in "flgs" is set to 1, the address 134 of the RP is embedded in the multicast address, as described in 135 this memo. 137 2. If the second high-order bit in "flgs" was set to 1, interpret 138 the last low-order 4 bits of "reserved" field as signifying the 139 RP interface ID, as described in this memo. 141 In consequence, the address format becomes: 143 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 144 +--------+----+----+----+----+--------+----------------+----------+ 145 |11111111|flgs|scop|rsvd|RPad| plen | network prefix | group ID | 146 +--------+----+----+----+----+--------+----------------+----------+ 147 +-+-+-+-+ 148 flgs is a set of 4 flags: |0|R|P|T| 149 +-+-+-+-+ 151 R = 1 indicates a multicast address that embeds the address of the 152 PIM RP. Then P MUST BE set to 1, and consequently T MUST be set to 153 1, as specified in [UNIPRFXM]. 155 In the case that R = 1, the last 4 bits of previously reserved field 156 ("RPad") are interpreted as embedding the interface ID of the RP, as 157 specified in this memo. 159 R = 0 indicates a multicast address that does not embed the address 160 of the PIM RP and follows the semantics defined in [ADDRARCH] and 161 [UNIPRFXM]. In this context, the value of "RPad" has no meaning. 163 4. Embedding the Address of the RP in the Multicast Address 165 The address of the RP can only be embedded in unicast-prefix -based 166 addresses, but the scheme could be extended to other forms of 167 multicast addresses as well. Further, the mechanism cannot be 168 combined with SSM, as SSM has no RP's. 170 To identify whether an address is a multicast address as specified in 171 this memo and to be processed any further, it must satisfy all of the 172 below: 174 o it MUST be a multicast address and have R, P, and T flag bits set 175 to 1 (that is, be part of the prefix FF7::/12 or FFF::/12) 177 o "plen" MUST NOT be 0 (ie. not SSM) 179 o "plen" MUST NOT be greater than 96 181 The address of the RP can be obtained from a multicast address 182 satisfying the above criteria by taking the following steps: 184 1. take the last 96 bits of the multicast address add 32 zero bits 185 at the end, 187 2. zero the last 128-"plen" bits, and 188 3. replace the last 4 bits with the contents of "RPad". 190 One should note that there are several operational scenarios when 191 [UNIPRFXM] statement "All non-significant bits of the network prefix 192 field SHOULD be zero" is ignored. This is to allow multicast address 193 assignments to third parties which still use your RP; see example 2 194 below. 196 "Plen" higher than 64 SHOULD NOT be used as that would overlap with 197 the upper bits of multicast group-id. 199 The implementation MUST perform at least the same address validity 200 checks to the calculated RP address as to one received via other 201 means (like MSDP), to avoid e.g. the address being "::" or "::1". 203 One should note that the 4 bits reserved for "RPad" set the upper 204 bound for RP's per multicast group address; not the number of RP's in 205 a subnet, PIM domain or large-scale network. 207 5. Examples 209 5.1. Example 1 211 The network administrator of 3FFE:FFFF::/32 wants to set up an RP for 212 the network and all of his customers. He chooses network 213 prefix=3FFE:FFFF and plen=32, and wants to use this addressing 214 mechanism. The multicast addresses he will be able to use are of the 215 form: 217 FF7x:y20:3FFE:FFFF:zzzz:zzzz: 219 Where "x" is the multicast scope, "y" the interface ID of the RP 220 address, and "zzzz:zzzz" will be freely assignable within the PIM 221 domain. In this case, the address of the PIM RP would be: 223 3FFE:FFFF::y 225 (and "y" could be anything from 0 to F); the address 3FFE:FFFF::y/128 226 is added as a Loopback address and injected to the routing system. 228 5.2. Example 2 230 As above, the network administrator can also allocate multicast 231 addresses like "FF7x:y20:3FFE:FFFF:DEAD::/80" to some of his 232 customers within the PIM domain. In this case the RP address would 233 still be "3FFE:FFFF::y" (note the prefix length rule: "plen" does not 234 need to have anything to do with real unicast/multicast address 235 prefix lengths). 237 5.3. Example 3 239 In the above network, the network admin sets up addresses as above, 240 but an organization wants to have their own PIM domain; that's 241 reasonable. The organization can pick multicast addresses like 242 "FF7x:y30:3FFE:FFFF:BEEF::/80", and then their RP address would be 243 "3FFE:FFFF:BEEF::y". 245 5.4. Example 4 247 In the above networks, if the admin wants to specify the RP to be in 248 a non-zero /64 subnet, he could always use something like 249 "FF7x:y40:3FFE:FFFF:BEEF:FEED::/96", and then their RP address would 250 be "3FFE:FFFF:BEEF:FEED::y". There are still 32 bits of multicast 251 group-id's to assign to customers and self. 253 6. Operational Requirements 255 6.1. Anycast-RP 257 One should note that MSDP is also used, in addition to interdomain 258 connections between RPs, in anycast-RP [ANYCASTRP] -technique, for 259 sharing the state information between different RPs in one PIM 260 domain. However, there are other propositions, like [ANYPIMRP]. 262 Anycast-RP mechanism is incompatible with this addressing method 263 unless MSDP is specified and implemented. Alternatively, another 264 method for sharing state information could be used. 266 Anycast-RP and other possible RP failover mechanisms are outside of 267 the scope of this memo. 269 6.2. Guidelines for Assigning IPv6 Addresses to RPs 271 With this mechanism, the RP can be given basically any network prefix 272 up to /64 (and even beyond, by using the upper bits of multicast 273 group-id). The interface identifier will have to be manually 274 configured to match "RPad". 276 If an administrator wishes to use an RP address that does not conform 277 to the addressing topology, that address can be injected into the 278 routing system via a host route. This RP address SHOULD be assigned 279 out of the network's prefix in order to ensure aggregation at the 280 border. 282 7. Required PIM Modifications 284 The use of multicast addresses with embedded RP addresses requires 285 additional PIM processing. Namely, a PIM router will need to be able 286 to recognize the encoding and derive the RP address from the address 287 using the rules in section 4 and to be able to use the embedded RP, 288 instead of its own for multicast addresses in this specified range. 290 The two key places where these modifications are used are the 291 Designated Routers (DRs) on the receiver/sender networks and the RPs 292 in the domain where the embdedded address has been derived from (see 293 figure below). 295 For the foreign DR's (rtrR1, rtrR23, and rtrR4), this means sending 296 PIM Join/Prune/Register messages towards the foreign RP (rtrRP_S). 297 Naturally, PIM Register-Stop and other messages must also be allowed 298 from the foreign RP. DR's in the local PIM domain (rtrS) do the 299 same, but the RP used should the same as with regular Any-Source 300 Multicast (ASM); however, see the appendix for more. 302 For the RP (rtrRP_S), this means being able to recognize and validate 303 PIM messages which use RP-embedded addressing originated from any DR 304 at all. 306 In particular, there is no need to have all routers (like rtrBB) on 307 the path modified: this is a major benefit for quick deployment. 309 nodeS - rtrS - rtrRP_S - rtrBB -----+--- rtrR1 - node1 310 | | | 311 node2_S ---------+ | +-- rtrR23 - node2 312 | | 313 | +---- node3 314 | 315 +------------ rtrR4 - node4 317 In addition, the administration of the PIM domain will require a 318 policy decision on where the PIM messages to the encoded RP be sent; 319 this is typically assumed to everywhere unless explicitly configured 320 otherwise. 322 The extraction of the RP information from the multicast address 323 should be done during forwarding state creation. That is, if no 324 state exists for the multicast address, PIM must take the embedded RP 325 information into account when creating forwarding state. Depending 326 on administrative policy, this would result in a receiver's DR 327 initiating a PIM Join towards the foreign RP or a source's DR sending 328 PIM Register messages towards the foreign RP. 330 It should be noted that this approach removes the need to run inter- 331 domain MSDP. Multicast distribution trees in foreign networks can be 332 joined by issuing a PIM Join/Prune/Register to the RP address encoded 333 in the multicast address. 335 7.1. Overview of the Model 337 The steps when a receiver wishes to join a group are: 339 1. A receiver finds out a group address from some means (e.g. SDR 340 or a web page). 341 2. The receiver issues an MLD Report, joining the group. 342 3. The receiver's DR will initiate the PIM Join process towards 343 the RP embedded in the multicast address. 345 The steps when a sender wishes to send to a group are: 347 1. A sender finds out a group address from some means, whether in 348 an existing group (e.g. SDR, web page) or in a new group (e.g. 349 a call to the administrator for group assignment, use of a 350 multicast address assignment protocol). 351 2. The sender sends to the group. 352 3. The sender's DR will send the packets unicast-encapsulated in 353 PIM unicast-encapsulated in PIM Register-messages to the RP 354 address encoded in the multicast address (in the special case 355 that DR is the RP, such sending is only conceptual). 357 In both cases, the messages then go on as specified in [PIM] and 358 other specifications (e.g. Register-Stop and/or SPT Join); there is 359 no difference in them except for the fact that the RP address is 360 derived from the multicast address. 362 When sending or receiving, there is a special case when the DR is in 363 local domain, and information about RP to be used with the group is 364 available with conventional mechanisms, and that differs from the RP 365 embedded in the address; see the appendix for more information. 367 8. Scalability/Usability Analysis 369 Interdomain MSDP model for connecting PIM domains is mostly 370 hierarchical. The "embedded RP address" changes this to a mostly 371 flat, sender-centered, full-mesh virtual topology. 373 This may or may not cause some effects; it may or may not be 374 desirable. At the very least, it makes many things much more robust 375 as the number of third parties is minimized. A good scalability 376 analysis is needed. 378 In some cases (especially if e.g. every home user is employing site- 379 local multicast), some degree of hierarchy would be highly desirable, 380 for scalability (e.g. take the advantage of shared multicast state) 381 and administrative point-of-view. 383 Being able to join/send to remote RP's has security considerations 384 that are considered below, but it has an advantage too: every group 385 has a "home RP" which is able to control (to some extent) who are 386 able to send to the group. 388 One should note that the model presented here simplifies the PIM 389 multicast routing model slightly by removing the RP for senders and 390 receivers in foreign domains. One scalability consideration should 391 be noted: previously foreign sources sent the unicast-encapsulated 392 data to their local RP, now they do so to the foreign RP responsible 393 for the specific group. This is especially important with large 394 multicast groups where there are a lot of heavy senders -- 395 particularly if implementations do not handle unicast-decapsulation 396 well. 398 This model increases the amount of Internet-wide multicast state 399 slightly: the backbone routers might end up with at least temporary 400 (*, G) and (S, G, rpt) state in addition to (S, G) states between the 401 receivers and senders. Certainly, the amount of inter-domain 402 multicast traffic between sources and the embedded-RP will increase 403 compared to the ASM model with MSDP; however, the domain responsible 404 for the RP is expected to be able to handle this. 406 As the address of the RP is tied to the multicast address, in the 407 case of RP failure, PIM BSR mechanisms cannot pick a new RP; the 408 failover mechanisms, if used, for backup RP's are different, and 409 typically would depend on sharing one address. The failover 410 techniques are outside of the scope of this memo. 412 9. Acknowledgements 414 Jerome Durand commented on an early draft of this memo. Marshall 415 Eubanks noted an issue regarding short plen values. Tom Pusateri 416 noted problems with earlier SPT-join approach. Rami Lehtonen pointed 417 out issues with the scope of SA-state and provided extensive 418 commentary. The whole MboneD working group is also acknowledged for 419 the continued support and comments. 421 10. Security Considerations 423 The address of the PIM RP is embedded in the multicast address. RPs 424 may be a good target for Denial of Service attacks -- as they are a 425 single point of failure (excluding failover techniques) for a group. 426 In this way, the target would be clearly visible. However, it could 427 be argued that if interdomain multicast was to be made work e.g. with 428 MSDP, the address would have to be visible anyway (through via other 429 channels, which may be more easily securable). 431 As any RP will have to accept PIM Join/Prune/Register messages from 432 any DR's, this might cause a potential DoS attack scenario. However, 433 this can be mitigated by the fact that the RP can discard all such 434 messages for all multicast addresses that do not embed the address of 435 the RP, and if deemed important, the implementation could also allow 436 manual configuration of which multicast addresses or prefixes 437 embedding the RP could be used; however, at least with addresses, 438 this would increase the need for coordination between multicast 439 sources and administration. 441 In a similar fashion, DR's must accept similar PIM messages back from 442 the foreign RP's for which a receiver in DR's network has joined. 444 One consequence of the usage model is that it allows Internet-wide 445 multicast state creation (from receiver(s) in another domain to the 446 RP in another domain) compared to the domain wide state creation in 447 the MSDP model. 449 RPs may become a bit more single points of failure as anycast-RP 450 mechanism is not (at least immediately) available. This can be 451 partially mitigated by the fact that some other forms of failover are 452 still possible, and there should be less need to store state as with 453 MSDP. 455 The implementation MUST perform at least the same address validity 456 checks to the embedded RP address as to one received via other means 457 (like MSDP), to avoid the address being e.g. "::" or "::1". 459 TBD: the implications (if any) with regard to embedding the RP 460 address in the packets (e.g. packet laundering and DoS do not seem 461 possible due to the way multicast works, but more analysis is 462 needed). 464 11. References 466 11.1. Normative References 468 [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 469 Addressing Architecture", RFC2373, July 1998. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 [UNIPRFXM] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 475 Multicast Addresses", RFC3306, August 2002. 477 11.2. Informative References 479 [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and 480 MSDP", work-in-progress, draft-ietf-mboned-anycast- 481 rp-08.txt, May 2001. 483 [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", 484 work-in-progress, draft-farinacci-pim-anycast-rp-00.txt, 485 January 2003. 487 [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Sourc 488 Discovery Protocol (MSDP)", work-in-progress, 489 draft-ietf-msdp-spec-14.txt, November 2002. 491 [PIM] Fenner, B. et al, "Protocol Independent Multicast - 492 Sparse Mode (PIM-SM): Protocol Specification (Revised), 493 work-in-progress, draft-ietf-pim-sm-v2-new-06.txt, 494 December 2002. 496 [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", 497 work-in-progress, draft-ietf-ssm-arch-02.txt, 498 February 2003. 500 [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", 501 work-in-progress, draft-savola-v6ops-multicast- 502 issues-01.txt, November 2002. 504 Authors' Addresses 506 Pekka Savola 507 CSC/FUNET 508 Espoo, Finland 509 EMail: psavola@funet.fi 511 Brian Haberman 512 Caspian Networks 513 One Park Drive 514 Suite 400 515 Research Triangle Park, NC 27709 516 EMail: bkhabs@nc.rr.com 517 Phone: +1-919-949-4828 519 A. Open Issues/Discussion 521 The initial thought was to use only SPT join from local RP/DR to 522 foreign RP, rather than a full PIM Join to foreign RP. However, this 523 turned out to be problematic, as this kind of SPT joins where 524 disregarded because the path had not been set up before sending them. 525 A full join to foreign PIM domain is a much clearer approach. 527 One could argue that there can be more RPs than the 4-bit "RPad" 528 allows for, especially if anycast-RP cannot be used. In that light, 529 extending "RPad" to take full advantage of whole 8 bits would seem 530 reasonable. However, this would use up all of the reserved bits, and 531 leave no room for future flexibility. In case of large number of 532 RPs, an operational workaround could be to split the PIM domain: for 533 example, using two /33's instead of one /32 would gain another 16 RP 534 addresses. 536 Some hierarchy (e.g. two-level, "ISP/customer") for RPs could 537 possibly be added if necessary, but that would be torturing one 128 538 bits even more. 540 One particular case with a sender in the local domain is where 541 regular ASM RP would be X, and the embedded RP address would be Y. 542 This would typically be due to a misconfiguration, but the DR SHOULD 543 be conservative and use the configured address X. However, the 544 simplest approach, and one which would typically be least surprising, 545 would be the one where one would always use the embedded RP address 546 by default. Any other thoughts on that?