idnits 2.17.00 (12 Aug 2021) /tmp/idnits33100/draft-savola-mboned-mcast-rpaddr-00.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: ---------------------------------------------------------------------------- == Line 246 has weird spacing: '...sharing the s...' -- 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 (October 2002) is 7158 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-00 Summary: 5 errors (**), 0 flaws (~~), 8 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: April 2003 5 B. Haberman 6 Caspian Networks 8 October 2002 10 Embedding the Address of RP in IPv6 Multicast Address 12 draft-savola-mboned-mcast-rpaddr-00.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 46 receiver-side PIM implementations. In consequence, there would be no 47 need for interdomain MSDP. 49 Table of Contents 51 1. Introduction ............................................... 2 52 2. Unicast-Prefix-based Address Format ........................ 3 53 3. Modified Unicast-Prefix-based Address Format ............... 3 54 4. Embedding the Address of the RP in the Multicast Address ... 4 55 5. Examples ................................................... 5 56 5.1. Example 1 .............................................. 5 57 5.2. Example 2 .............................................. 5 58 5.3. Example 3 .............................................. 5 59 5.4. Example 4 .............................................. 6 60 6. Operational Requirements ................................... 6 61 6.1. Anycast-RP ............................................. 6 62 6.2. Guidelines for Assigning IPv6 Addresses to RPs ......... 6 63 7. Required PIM Modifications ................................. 6 64 8. Scalability/Usability Analysis ............................. 7 65 9. Acknowledgements ........................................... 8 66 10. Security Considerations ................................... 8 67 11. References ................................................ 8 68 11.1. Normative References .................................. 8 69 11.2. Informative References ................................ 9 70 Authors' Addresses ............................................. 9 71 A. Open Issues/Discussion ..................................... 9 73 1. Introduction 75 As has been noticed [V6MISSUES], there is exists a huge deployment 76 problem with global, interdomain IPv6 multicast: PIM [PIM] RPs have 77 no way of communicating the information about multicast sources to 78 other multicast domains, as there is no MSDP [MSDP], and the whole 79 interdomain Any Source Multicast model is rendered unusable; SSM 80 [SSM] avoids there problems. 82 This memo outlines a way to embed the address of the RP in the 83 multicast address, solving the interdomain multicast problem. The 84 problem is three-fold: specify an address format, adjust the 85 operational procedures and configuration if necessary, and modify 86 receiver-side PIM implementations. In consequence, there would be no 87 need for interdomain MSDP. 89 The solution is founded upon unicast-prefix-based IPv6 multicast 90 addressing [UNIPRFXM] and making some assumptions about IPv6 address 91 assignment for the RPs in the PIM domain. 93 It is self-evident that one can't embed, in the general case, two 94 128-bit addresses in one 128-bit address. In this memo, some 95 assumptions on how this could be done are made. If these assumptions 96 can't be followed, either operational procedures and configuration 97 must be slightly changed or this mechanism not be used. 99 The assignment of multicast addresses is outside the scope of this 100 document. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. Unicast-Prefix-based Address Format 108 As described in [UNIPRFXM], the multicast address format is as 109 follows: 111 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 112 +--------+----+----+--------+--------+----------------+----------+ 113 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 114 +--------+----+----+--------+--------+----------------+----------+ 116 Where flgs are "0011". (The first two bits are yet undefined and 117 thus zero.) 119 3. Modified Unicast-Prefix-based Address Format 121 This memo proposes a modification to the unicast-prefix-based address 122 format: 124 1. If the second high-order bit in "flgs" is set to 1, the address 125 of the RP is embedded in the multicast address, as described in 126 this memo. 128 2. If the second high-order bit in "flgs" was set to 1, interpret 129 the last low-order 4 bits of "reserved" field as signifying the 130 RP interface ID, as described in this memo. 132 In consequence, the address format becomes: 134 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 135 +--------+----+----+----+----+--------+----------------+----------+ 136 |11111111|flgs|scop|rsvd|RPad| plen | network prefix | group ID | 137 +--------+----+----+----+----+--------+----------------+----------+ 138 +-+-+-+-+ 139 flgs is a set of 4 flags: |0|R|P|T| 140 +-+-+-+-+ 142 R = 1 indicates a multicast address that embeds the address of the 143 PIM RP. Then P MUST BE set to 1, and consequently T MUST be set to 144 1, as specified in [UNIPRFXM]. 146 In the case that R = 1, the last 4 bits of previously reserved field 147 ("RPad") are interpreted as embedding the interface ID of the RP, as 148 specified in this memo. 150 R = 0 indicates a multicast address that does not embed the address 151 of the PIM RP and follows the semantics defined in [ADDRARCH] and 152 [UNIPRFXM]. In this context, the value of "RPad" has no meaning. 154 4. Embedding the Address of the RP in the Multicast Address 156 The address of the RP can only be embedded in unicast-prefix -based 157 addresses, but the scheme could be extended to other forms of 158 multicast addresses as well. Further, the mechanism cannot be 159 combined with SSM. 161 To identify whether an address is a multicast address as specified in 162 this memo and to be processed any further, it must satisfy all of the 163 bullets: 165 o it MUST be part of the prefix FF7::/12 167 o "plen" MUST NOT be 0 (ie. not SSM) 169 o "plen" MUST NOT be greater than 96 171 The address of the RP can be obtained from a multicast address by 172 taking the following steps: 174 1. take the last 96 bits of the multicast address add 32 zero bits 175 at the end, 177 2. zero the last 128-"plen" bits, and 179 3. replace the last 4 bits with the contents of "RPad". 181 One should note that there are several operational scenarios when 182 [UNIPRFXM] statement "All non-significant bits of the network prefix 183 field SHOULD be zero" is ignored. This is to allow multicast address 184 assignments to third parties which still use your RP; see example 2 185 below. 187 "Plen" higher than 64 SHOULD NOT be used as that would overlap with 188 the upper bits of multicast group-id. 190 The implementation MUST perform at least the same address validity 191 checks to the calculated RP address as to one received via other 192 means (like MSDP), to avoid e.g. the address being "::" or "::1". 194 5. Examples 196 5.1. Example 1 198 The network administrator of 3FFE:FFFF::/32 wants to set up an RP for 199 the network and all of his customers. He chooses network 200 prefix=3FFE:FFFF and plen=32, and wants to use this addressing 201 mechanism. The multicast addresses he will be able to use are of the 202 form: 204 FF7x:y20:3FFE:FFFF:zzzz:zzzz: 206 Where "x" is the multicast scope, "y" the interface ID of the RP 207 address, and "zzzz:zzzz" will be freely assignable within the PIM 208 domain. In this case, the address of the PIM RP would be: 210 3FFE:FFFF::y 212 (and "y" could be anything from 0 to F); the address 3FFE:FFFF::y/128 213 is added as a Loopback address and injected to the routing system. 215 5.2. Example 2 217 As above, the network administrator can also allocate multicast 218 addresses like "FF7x:y20:3FFE:FFFF:DEAD::/80" to some of his 219 customers within the PIM domain. In this case the RP address would 220 still be "3FFE:FFFF::y" (note the prefix length rule: "plen" does not 221 need to have anything to do with real unicast/multicast address 222 prefix lengths). 224 5.3. Example 3 226 In the above network, the network admin sets up addresses as above, 227 but an organization wants to have their own PIM domain; that's 228 reasonable. The organization can pick multicast addresses like 229 "FF7x:y30:3FFE:FFFF:BEEF::/80", and then their RP address would be 230 "3FFE:FFFF:BEEF::y". 232 5.4. Example 4 234 In the above networks, if the admin wants to specify the RP to be in 235 a non-zero /64 subnet, he could always use something like 236 "FF7x:y40:3FFE:FFFF:BEEF:FEED::/96", and then their RP address would 237 be "3FFE:FFFF:BEEF:FEED::y". There are still 32 bits of multicast 238 group-id's to assign to customers and self. 240 6. Operational Requirements 242 6.1. Anycast-RP 244 One should note that MSDP is also used, in addition to interdomain 245 connections between RPs, in anycast-RP [ANYCASTRP] -technique, for 246 sharing the state information between different RPs in one PIM 247 domain. 249 Anycast-RP mechanism is incompatible with this addressing method 250 unless unless MSDP is specified and implemented. Alternatively, 251 another method for sharing state information could be defined. 253 Anycast-RP and other possible RP failover mechanisms are outside of 254 the scope of this memo. 256 6.2. Guidelines for Assigning IPv6 Addresses to RPs 258 With this mechanism, the RP can be given basically any network prefix 259 up to /64 (and even beyond, by using the upper bits of multicast 260 group-id). The interface identifier will have to be manually 261 configured. 263 If an administrator wishes to use an RP address that does not conform 264 to the addressing topology, that address can be injected into the 265 routing system via a host route. This RP address SHOULD be assigned 266 out of the network's prefix in order to ensure aggregation at the 267 border. 269 7. Required PIM Modifications 271 The use of multicast addresses with embedded RP addresses requires 272 additional PIM processing. Namely, a PIM router will need to be able 273 to recognize the encoding and derive the RP address from the address 274 using the rules in section 4. 276 The two key places where these modifications are used are the 277 Designated Routers (DRs) on the receiver networks and the RPs in the 278 receiving domain (see figure below). For the DR's (rtrR1, rtrR23, 279 and rtrR4), this would be similar to the RPT -> SPT switchover 280 scenario. For the RPs (rtrRP_R123 and rtrRP_R4) the scenario would 281 be the same as building an SPT to a foreign source based on MSDP 282 information. In particular, there is no need to have all routers on 283 the path modified: this is a major benefit for quick deployment. 285 source - rtrS - rtrRP_S - rtrBB - rtrRP_R123 - rtrR1 - receiver1 286 | | 287 | +------- rtrR23 - receiver2 288 | | 289 | +----- receiver3 290 | 291 +---- rtrRP_R4 --- rtrR4 - receiver4 293 In addition, the administration of the PIM domain will require a 294 policy decision on where the SPT towards the encoded RP should be 295 built. 297 The extraction of the RP information from the multicast address 298 should be done during forwarding state creation. That is, if no 299 state exists for the multicast address, PIM must take the embedded RP 300 information into account when creating forwarding state. Depending 301 on administrative policy, this could result in a receiver's DR 302 initiating an SPT towards the foreign RP, or the local RP initiating 303 an SPT towards the foreign RP. 305 It should be noted that this approach removes the need to run inter- 306 domain MSDP. Multicast distribution trees in foreign networks can be 307 joined by issuing an SPT towards the RP address encoded in the 308 multicast address. 310 8. Scalability/Usability Analysis 312 Interdomain MSDP model for connecting PIM domains is mostly 313 hierarchical. The "embedded RP address" changes this to a mostly 314 flat, full-mesh virtual topology. 316 This may or may not cause some effects; it may or may not be 317 desirable. At the very least, it makes many things much more robust 318 as the number of third parties is minimized. A good scalability 319 analysis is needed. 321 In some cases (especially if e.g. every home user is employing site- 322 local multicast), some degree of hierarchy would be highly desirable, 323 for scalability (e.g. take the advantage of shared multicast state) 324 and administrative point-of-view. 326 9. Acknowledgements 328 Jerome Durand commented on an early draft of this memo. Marshall 329 Eubanks noted an issue regarding short plen values. 331 10. Security Considerations 333 The address of the PIM RP is embedded in the multicast address. RPs 334 may be a good target for Denial of Service attacks, and in this way, 335 the target would be clearly visible. However, it could be argued 336 that if interdomain multicast was to be made work e.g. with MSDP, the 337 address would have to be visible anyway (through via other channels, 338 which may be more easily securable). 340 RPs may become a bit more single points of failure as anycast-RP 341 mechanism is not (at least immediately) available. This can be 342 partially mitigated by the fact that some other forms of failover are 343 still possible, and there should be less need to store state as with 344 MSDP. 346 The implementation MUST perform at least the same address validity 347 checks to the embedded RP address as to one received via other means 348 (like MSDP), to avoid the address being e.g. "::" or "::1". 350 TBD: the implications (if any) with regard to embedding the RP 351 address in the packets (e.g. packet laundering and DoS do not seem 352 possible due to the way multicast works, but more analysis is 353 needed). 355 11. References 357 11.1. Normative References 359 [ADDRARCH] Hinden, R., Deering, S., "IP Version 6 360 Addressing Architecture", RFC2373, July 1998. 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 [UNIPRFXM] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 366 Multicast Addresses", RFC3306, August 2002. 368 11.2. Informative References 370 [ANYCASTRP] Kim, D. et al, q(Anycast RP mechanism using PIM and 371 MSDP", work-in-progress, draft-ietf-mboned-anycast- 372 rp-08.txt, May 2001. 374 [MSDP] Farinacci, D. et al, "Multicast Source Discovery Protocol 375 (MSDP)", work-in-progress, draft-ietf-msdp-spec-13.txt 376 (expired), 2002. 378 [PIM] Fenner, B. et al, "Protocol Independent Multicast - 379 Sparse Mode (PIM-SM): Protocol Specification (Revised), 380 work-in-progress, draft-ietf-pim-sm-v2-new-05.txt, 381 March 2002. 383 [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", 384 work-in-progress, draft-ietf-ssm-arch-00.txt, 385 November 2001. 387 [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", 388 work-in-progress, draft-savola-v6ops-multicast- 389 issues-00.txt, October 2002. 391 Authors' Addresses 393 Pekka Savola 394 CSC/FUNET 395 Espoo, Finland 396 EMail: psavola@funet.fi 398 Brian Haberman 399 Caspian Networks 400 One Park Drive 401 Suite 400 402 Research Triangle Park, NC 27709 403 EMail: bkhabs@nc.rr.com 404 Phone: +1-919-949-4828 406 A. Open Issues/Discussion 408 One could argue that there can be more RPs than the 4-bit "RPad" 409 allows for, especially if anycast-RP cannot be used. In that light, 410 extending "RPad" to take full advantage of whole 8 bits would seem 411 reasonable. However, this would use up all of the reserved bits, and 412 leave no room for future flexibility. In case of large number of 413 RPs, an operational workaround could be to split the PIM domain: for 414 example, using two /33's instead of one /32 would gain another 16 RP 415 addresses. 417 Some hierarchy (e.g. two-level, "ISP/customer") for RPs could 418 possibly be added if necessary, but that would be torturing one 128 419 bits even more.