idnits 2.17.00 (12 Aug 2021) /tmp/idnits36364/draft-savola-mboned-mcast-rpaddr-01.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 (February 2003) is 7035 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: August 2003 5 B. Haberman 6 Caspian Networks 8 February 2003 10 Embedding the Address of RP in IPv6 Multicast Address 12 draft-savola-mboned-mcast-rpaddr-01.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 RPs have no way of 39 communicating the information about multicast sources to other 40 multicast domains, as there is no MSDP, and the whole interdomain Any 41 Source Multicast model is rendered unusable; SSM avoids these 42 problems. This memo outlines a way to embed the address of the RP in 43 the multicast address, solving the interdomain multicast problem. The 44 problem is three-fold: specify an address format, adjust the 45 operational procedures and configuration if necessary, and modify PIM 46 implementations of those who want to join a group (DR's) or create 47 one (RP's). In consequence, there would be no need for interdomain 48 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 ................................... 9 69 11. References ................................................ 10 70 11.1. Normative References .................................. 10 71 11.2. Informative References ................................ 10 72 Authors' Addresses ............................................. 11 73 A. Open Issues/Discussion ..................................... 11 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 88 receiver-side PIM implementations. In consequence, there would be no 89 need for interdomain MSDP. 91 The solution is founded upon unicast-prefix-based IPv6 multicast 92 addressing [UNIPRFXM] and making some assumptions about IPv6 address 93 assignment for the RPs in the PIM domain. 95 Further, a change in how interdomain PIM operates with these 96 addresses is presented: multicast receivers' DR's join the RP 97 embedded in the address -- not their locally configured RP. 99 It is self-evident that one can't embed, in the general case, two 100 128-bit addresses in one 128-bit address. In this memo, some 101 assumptions on how this could be done are made. If these assumptions 102 can't be followed, either operational procedures and configuration 103 must be slightly changed or this mechanism not be used. 105 The assignment of multicast addresses is outside the scope of this 106 document. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 2. Unicast-Prefix-based Address Format 114 As described in [UNIPRFXM], the multicast address format is as 115 follows: 117 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 118 +--------+----+----+--------+--------+----------------+----------+ 119 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 120 +--------+----+----+--------+--------+----------------+----------+ 122 Where flgs are "0011". (The first two bits are yet undefined and 123 thus zero.) 125 3. Modified Unicast-Prefix-based Address Format 127 This memo proposes a modification to the unicast-prefix-based address 128 format: 130 1. If the second high-order bit in "flgs" is set to 1, the address 131 of the RP is embedded in the multicast address, as described in 132 this memo. 134 2. If the second high-order bit in "flgs" was set to 1, interpret 135 the last low-order 4 bits of "reserved" field as signifying the 136 RP interface ID, as described in this memo. 138 In consequence, the address format becomes: 140 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 141 +--------+----+----+----+----+--------+----------------+----------+ 142 |11111111|flgs|scop|rsvd|RPad| plen | network prefix | group ID | 143 +--------+----+----+----+----+--------+----------------+----------+ 144 +-+-+-+-+ 145 flgs is a set of 4 flags: |0|R|P|T| 146 +-+-+-+-+ 148 R = 1 indicates a multicast address that embeds the address of the 149 PIM RP. Then P MUST BE set to 1, and consequently T MUST be set to 150 1, as specified in [UNIPRFXM]. 152 In the case that R = 1, the last 4 bits of previously reserved field 153 ("RPad") are interpreted as embedding the interface ID of the RP, as 154 specified in this memo. 156 R = 0 indicates a multicast address that does not embed the address 157 of the PIM RP and follows the semantics defined in [ADDRARCH] and 158 [UNIPRFXM]. In this context, the value of "RPad" has no meaning. 160 4. Embedding the Address of the RP in the Multicast Address 162 The address of the RP can only be embedded in unicast-prefix -based 163 addresses, but the scheme could be extended to other forms of 164 multicast addresses as well. Further, the mechanism cannot be 165 combined with SSM, as SSM has no RP's. 167 To identify whether an address is a multicast address as specified in 168 this memo and to be processed any further, it must satisfy all of the 169 below: 171 o it MUST be a multicast address and have R, P, and T flag bits set 172 to 1 (that is, be part of the prefix FF7::/12 or FFF::/12) 174 o "plen" MUST NOT be 0 (ie. not SSM) 176 o "plen" MUST NOT be greater than 96 178 The address of the RP can be obtained from a multicast address 179 satisfying the above criteria by taking the following steps: 181 1. take the last 96 bits of the multicast address add 32 zero bits 182 at the end, 184 2. zero the last 128-"plen" bits, and 185 3. replace the last 4 bits with the contents of "RPad". 187 One should note that there are several operational scenarios when 188 [UNIPRFXM] statement "All non-significant bits of the network prefix 189 field SHOULD be zero" is ignored. This is to allow multicast address 190 assignments to third parties which still use your RP; see example 2 191 below. 193 "Plen" higher than 64 SHOULD NOT be used as that would overlap with 194 the upper bits of multicast group-id. 196 The implementation MUST perform at least the same address validity 197 checks to the calculated RP address as to one received via other 198 means (like MSDP), to avoid e.g. the address being "::" or "::1". 200 One should note that the 4 bits reserved for "RPad" set the upper 201 bound for RP's per multicast group address; not the number of RP's in 202 a subnet, PIM domain or large-scale network. 204 5. Examples 206 5.1. Example 1 208 The network administrator of 3FFE:FFFF::/32 wants to set up an RP for 209 the network and all of his customers. He chooses network 210 prefix=3FFE:FFFF and plen=32, and wants to use this addressing 211 mechanism. The multicast addresses he will be able to use are of the 212 form: 214 FF7x:y20:3FFE:FFFF:zzzz:zzzz: 216 Where "x" is the multicast scope, "y" the interface ID of the RP 217 address, and "zzzz:zzzz" will be freely assignable within the PIM 218 domain. In this case, the address of the PIM RP would be: 220 3FFE:FFFF::y 222 (and "y" could be anything from 0 to F); the address 3FFE:FFFF::y/128 223 is added as a Loopback address and injected to the routing system. 225 5.2. Example 2 227 As above, the network administrator can also allocate multicast 228 addresses like "FF7x:y20:3FFE:FFFF:DEAD::/80" to some of his 229 customers within the PIM domain. In this case the RP address would 230 still be "3FFE:FFFF::y" (note the prefix length rule: "plen" does not 231 need to have anything to do with real unicast/multicast address 232 prefix lengths). 234 5.3. Example 3 236 In the above network, the network admin sets up addresses as above, 237 but an organization wants to have their own PIM domain; that's 238 reasonable. The organization can pick multicast addresses like 239 "FF7x:y30:3FFE:FFFF:BEEF::/80", and then their RP address would be 240 "3FFE:FFFF:BEEF::y". 242 5.4. Example 4 244 In the above networks, if the admin wants to specify the RP to be in 245 a non-zero /64 subnet, he could always use something like 246 "FF7x:y40:3FFE:FFFF:BEEF:FEED::/96", and then their RP address would 247 be "3FFE:FFFF:BEEF:FEED::y". There are still 32 bits of multicast 248 group-id's to assign to customers and self. 250 6. Operational Requirements 252 6.1. Anycast-RP 254 One should note that MSDP is also used, in addition to interdomain 255 connections between RPs, in anycast-RP [ANYCASTRP] -technique, for 256 sharing the state information between different RPs in one PIM 257 domain. However, there are other propositions, like [ANYPIMRP]. 259 Anycast-RP mechanism is incompatible with this addressing method 260 unless MSDP is specified and implemented. Alternatively, another 261 method for sharing state information could be used. 263 Anycast-RP and other possible RP failover mechanisms are outside of 264 the scope of this memo. 266 6.2. Guidelines for Assigning IPv6 Addresses to RPs 268 With this mechanism, the RP can be given basically any network prefix 269 up to /64 (and even beyond, by using the upper bits of multicast 270 group-id). The interface identifier will have to be manually 271 configured to match "RPad". 273 If an administrator wishes to use an RP address that does not conform 274 to the addressing topology, that address can be injected into the 275 routing system via a host route. This RP address SHOULD be assigned 276 out of the network's prefix in order to ensure aggregation at the 277 border. 279 7. Required PIM Modifications 281 The use of multicast addresses with embedded RP addresses requires 282 additional PIM processing. Namely, a PIM router will need to be able 283 to recognize the encoding and derive the RP address from the address 284 using the rules in section 4 and to be able to use the embedded RP, 285 instead of its own for multicast addresses in this specified range. 287 The two key places where these modifications are used are the 288 Designated Routers (DRs) on the receiver networks and the RPs in the 289 sending domain (see figure below). 291 For the DR's (rtrR1, rtrR23, and rtrR4), this means sending PIM 292 Join/Prune/Register messages to the foreign RP (rtrRP_S). Naturally, 293 PIM Register-Stop and other messages must also be allowed from the 294 foreign RP. Receivers in the local PIM domain (receiverS) do the 295 same, but the RP used is the same as with regular Any-Source 296 Multicast (ASM). 298 For the RP (rtrRP_S), this means being able to recognize and validate 299 PIM messages originated from any DR at all and which use RP-embedded 300 addressing. 302 In particular, there is no need to have all routers on the path 303 modified: this is a major benefit for quick deployment. 305 source - rtrS - rtrRP_S - rtrBB -----+--- rtrR1 - receiver1 306 | | | 307 | | +-- rtrR23 - receiver2 308 receiverS -+ | | 309 | +---- receiver3 310 | 311 +------------ rtrR4 - receiver4 313 In addition, the administration of the PIM domain will require a 314 policy decision on where the PIM messages to the encoded RP be sent; 315 this is typically assumed to everywhere unless explicitly configured 316 otherwise. 318 The extraction of the RP information from the multicast address 319 should be done during forwarding state creation. That is, if no 320 state exists for the multicast address, PIM must take the embedded RP 321 information into account when creating forwarding state. Depending 322 on administrative policy, this would result in a receiver's DR 323 initiating a PIM Join towards the foreign RP. 325 It should be noted that this approach removes the need to run inter- 326 domain MSDP. Multicast distribution trees in foreign networks can be 327 joined by issuing a PIM Join/Prune/Register to the RP address encoded 328 in the multicast address. 330 7.1. Overview of the Model 332 The steps when a receiver wishes to join a group are: 334 1. A receiver finds out a group address from some means (e.g. SDR 335 or a web page) 336 2. The receiver issues an MLD Report Joining the group 337 3. The receiver's DR will initiate the PIM Join process towards 338 the RP embedded in the multicast address 340 The sender side has two cases: 342 1. A sender in the local domain. Nothing should be different 343 here. 344 2. A sender in a foreign domain. The DR will send the packets 345 unicast-encapsulated in PIM Register-messages to the RP address 346 encoded in the multicast address. The messages go on as 347 before, often with a Register-Stop and SPT Join; there is no 348 difference in them except for the fact that the RP address is 349 derived from the multicast address. 351 Whether a sender is in local or foreign domain can be distinguished 352 by checking whether the embedded address is one of RP's configured 353 using conventional mechanisms. Further mechanisms and behaviour is 354 TBD (also see the appendix). 356 8. Scalability/Usability Analysis 358 Interdomain MSDP model for connecting PIM domains is mostly 359 hierarchical. The "embedded RP address" changes this to a mostly 360 flat, sender-centered, full-mesh virtual topology. 362 This may or may not cause some effects; it may or may not be 363 desirable. At the very least, it makes many things much more robust 364 as the number of third parties is minimized. A good scalability 365 analysis is needed. 367 In some cases (especially if e.g. every home user is employing site- 368 local multicast), some degree of hierarchy would be highly desirable, 369 for scalability (e.g. take the advantage of shared multicast state) 370 and administrative point-of-view. 372 Being able to join/send to remote RP's has security considerations 373 that are considered below, but it has an advantage too: every group 374 has a "home RP" which is able to control (to some extent) who are 375 able to send to the group. 377 One should note that the model presented here simplifies the PIM 378 multicast routing model slightly by removing the receivers' local RP. 379 One scalability consideration should be noted: previously foreign 380 sources sent the unicast-encapsulated data to their local RP, now 381 they do so to foreign RP. This is especially important with large 382 multicast groups where there are a lot of heavy senders -- 383 particularly if implementations do not handle unicast-decapsulation 384 well. 386 9. Acknowledgements 388 Jerome Durand commented on an early draft of this memo. Marshall 389 Eubanks noted an issue regarding short plen values. Tom Pusateri 390 noted problems with earlier SPT-join approach. Rami Lehtonen pointed 391 out issues with the scope of SA-state. The whole MboneD working 392 group is also acknowledged for the continued support and comments. 394 10. Security Considerations 396 The address of the PIM RP is embedded in the multicast address. RPs 397 may be a good target for Denial of Service attacks, and in this way, 398 the target would be clearly visible. However, it could be argued 399 that if interdomain multicast was to be made work e.g. with MSDP, the 400 address would have to be visible anyway (through via other channels, 401 which may be more easily securable). 403 As any RP will have to accept PIM Join/Prune/Register messages from 404 any DR's, this might cause a potential DoS attack scenario. However, 405 this can be mitigated by the fact that the RP can discard all such 406 messages for all multicast addresses that do not embed the address of 407 the RP, and if deemed important, the implementation could also allow 408 manual configuration of which multicast addresses or prefixes 409 embedding the RP could be used; however, at least with addresses, 410 this would increase the need for coordination between multicast 411 sources and administration. 413 In a similar fashion, DR's must accept similar PIM messages back from 414 the foreign RP's for which a receiver in DR's network has joined. 416 One consequence of the usage model is that it allows Internet-wide 417 multicast state creation (from receiver(s) in another domain to the 418 RP in another domain) compared to the domain wide state creation in 419 the MSDP model. 421 RPs may become a bit more single points of failure as anycast-RP 422 mechanism is not (at least immediately) available. This can be 423 partially mitigated by the fact that some other forms of failover are 424 still possible, and there should be less need to store state as with 425 MSDP. 427 The implementation MUST perform at least the same address validity 428 checks to the embedded RP address as to one received via other means 429 (like MSDP), to avoid the address being e.g. "::" or "::1". 431 TBD: the implications (if any) with regard to embedding the RP 432 address in the packets (e.g. packet laundering and DoS do not seem 433 possible due to the way multicast works, but more analysis is 434 needed). 436 11. References 438 11.1. Normative References 440 [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 441 Addressing Architecture", RFC2373, July 1998. 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, March 1997. 446 [UNIPRFXM] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 447 Multicast Addresses", RFC3306, August 2002. 449 11.2. Informative References 451 [ANYCASTRP] Kim, D. et al, q(Anycast RP mechanism using PIM and 452 MSDP", work-in-progress, draft-ietf-mboned-anycast- 453 rp-08.txt, May 2001. 455 [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", 456 work-in-progress, draft-farinacci-pim-anycast-rp-00.txt, 457 January 2003. 459 [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Sourc 460 Discovery Protocol (MSDP)", work-in-progress, 461 draft-ietf-msdp-spec-14.txt, November 2002. 463 [PIM] Fenner, B. et al, "Protocol Independent Multicast - 464 Sparse Mode (PIM-SM): Protocol Specification (Revised), 465 work-in-progress, draft-ietf-pim-sm-v2-new-06.txt, 466 December 2002. 468 [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", 469 work-in-progress, draft-ietf-ssm-arch-00.txt, 470 November 2001. 472 [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", 473 work-in-progress, draft-savola-v6ops-multicast- 474 issues-01.txt, November 2002. 476 Authors' Addresses 478 Pekka Savola 479 CSC/FUNET 480 Espoo, Finland 481 EMail: psavola@funet.fi 483 Brian Haberman 484 Caspian Networks 485 One Park Drive 486 Suite 400 487 Research Triangle Park, NC 27709 488 EMail: bkhabs@nc.rr.com 489 Phone: +1-919-949-4828 491 A. Open Issues/Discussion 493 The initial thought was to use only SPT join from local RP/DR to 494 foreign RP, rather than a full PIM Join to foreign RP. However, this 495 turned out to be problematic, as this kind of SPT joins where 496 disregarded because the path had not been set up before sending them. 497 A full join to foreign PIM domain is a much clearer approach. 499 One could argue that there can be more RPs than the 4-bit "RPad" 500 allows for, especially if anycast-RP cannot be used. In that light, 501 extending "RPad" to take full advantage of whole 8 bits would seem 502 reasonable. However, this would use up all of the reserved bits, and 503 leave no room for future flexibility. In case of large number of 504 RPs, an operational workaround could be to split the PIM domain: for 505 example, using two /33's instead of one /32 would gain another 16 RP 506 addresses. 508 Some hierarchy (e.g. two-level, "ISP/customer") for RPs could 509 possibly be added if necessary, but that would be torturing one 128 510 bits even more. 512 One particular case with a sender in the local domain is where 513 regular ASM RP would be X, and the embedded RP address would be Y. 514 This would typically be due to a misconfiguration, but the DR SHOULD 515 be conservative and use the configured address X. Any other thoughts 516 on that?