idnits 2.17.1 draft-savola-v6ops-multicast-issues-03.txt: -(332): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There is 1 instance of lines with non-ascii characters in the document. == 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 197: '...a scope boundary MUST also be a a site...' RFC 2119 keyword, line 300: '... MLD report MUST be generated for ev...' 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 (February 2004) is 7376 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) == Missing Reference: 'PIMANYRP' is mentioned on line 246, but not defined == Unused Reference: 'BSR' is defined on line 372, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3446 (ref. 'ANYCASTRP') == Outdated reference: A later version (-07) exists of draft-ietf-mboned-embeddedrp-01 ** Downref: Normative reference to an Experimental RFC: RFC 3618 (ref. 'MSDP') ** Obsolete normative reference: RFC 2461 (ref. 'NDISC') (Obsoleted by RFC 4861) == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-08 == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-04 == 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 (-12) exists of draft-ietf-magma-snoop-10 == Outdated reference: A later version (-04) exists of draft-bhattach-diot-pimso-00 Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Savola 2 Internet Draft CSC/FUNET 3 Expiration Date: August 2004 4 February 2004 6 IPv6 Multicast Deployment Issues 8 draft-savola-v6ops-multicast-issues-03.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 There are many issues concerning the deployment and implementation, 34 and to a lesser degree, specification of IPv6 multicast. This memo 35 describes known problems, trying to raise awareness. Currently, 36 global IPv6 interdomain multicast is impossible except using SSM: 37 there is no way to convey information about multicast sources between 38 PIM-SM RPs; the situation is analyzed, and a technique called 39 Embedded RP is offered as a solution. The deploability of SSM and 40 Embedded RP is also considered. In addition, an issue regarding 41 link-local multicast-blocking Ethernet switches is brought up. 42 Finally, the requirement for functionality like MLD snooping is 43 noted. 45 Table of Contents 47 1. Introduction ............................................... 2 48 2. Issues with Multiple PIM Domains and Any Source Multicast .. 3 49 2.1. Changing the Multicast Usage Model ..................... 3 50 2.2. Implementing MSDP for IPv6 Interdomain Multicast ....... 4 51 2.3. Implementing Another Multicast Routing Protocol ........ 4 52 2.4. Embedding the RP Address in an IPv6 Multicast Address .. 4 53 2.5. Site-local Group Scoping ............................... 5 54 3. Issues with SSM and Embedded RP ............................ 5 55 3.1. SSM Deployment ......................................... 5 56 3.2. RP Failover with Embedded RP .......................... 6 57 4. Neighbor Discovery Using Multicast ......................... 6 58 5. Functionality Like MLD Snooping ............................ 7 59 6. Security Considerations .................................... 7 60 7. Acknowledgements ........................................... 8 61 8. References ................................................. 8 62 8.1. Normative References ................................... 8 63 8.2. Informative References ................................. 8 64 Author's Address ............................................... 9 65 Intellectual Property Statement ................................ 9 66 Full Copyright Statement ....................................... 10 68 1. Introduction 70 There are many issues concerning the deployment and implementation, 71 and to a lesser degree, specification of IPv6 multicast. This memo 72 describes known problems, trying to raise awareness. 74 Currently, global IPv6 interdomain multicast is impossible except 75 using SSM: there is no way to convey information about multicast 76 sources between PIM-SM RPs; site-scoped multicast problematic. A few 77 possible solutions, such as Embedded RP [EMBEDRP] are outlined or 78 referred to. These are discussed in section 2. Deployment issues 79 with both SSM and Embedded RP are discussed separately in section 3. 81 In addition, an issue regarding link-local multicast -blocking 82 Ethernet switches is brought up. Finally, the requirement for 83 functionality like MLD snooping is noted. These are discussed in 84 sections 4 and 5, respectively. 86 [MULTIGAP] analyses the more generic set of issues with multicast; 87 this memo focuses on critical issues regarding IPv6. 89 2. Issues with Multiple PIM Domains and Any Source Multicast 91 For both administrative and technical reasons, there must be multiple 92 Protocol-Independent Multicast - Sparse Mode (PIM-SM) [PIM-SM] 93 domains in the Internet, which means there will be multiple PIM-SM 94 Rendezvous Points (RPs) -- and communication mechanisms between these 95 RPs will become critical. 97 These issues only come up with classical Any Source Multicast; 98 Source-Specific Multicast [SSM] does not require RPs and is not 99 affected, as the multicast "channel" is identified by the combination 100 and can be communicated out-of-band. 102 In IPv4, notification of multicast sources between these PIM RPs is 103 done with Multicast Source Discovery Protocol (MSDP) [MSDP]. Many 104 consider this a sub-optimal, but unfortunately necessary, solution; 105 when it was specified, it was only meant as a "stop-gap" measure. 107 Below, some issues and solutions or work-arounds are described. 109 2.1. Changing the Multicast Usage Model 111 As "Any Source Multicast" -model has been found to be complex and a 112 bit problematic, there may be an incentive to move to SSM for good 113 (at least for most cases). Below two paragraphs are adapted from 114 [PIMSO]: 116 The most serious criticism of the SSM architecture is that it does 117 not support shared trees which may be useful for supporting many-to- 118 many applications. In the short-term this is not a serious concern 119 since the multicast application space is likely to be dominated by 120 one-to-many applications. Some other classes of multicast 121 applications that are likely to emerge in the future are few-to-few 122 (e.g. private chat rooms, whiteboards), few-to-many (e.g., video 123 conferencing, distance learning) and many-to-many (e.g., large chat 124 rooms, multi-user games). The first two classes can be easily handled 125 using a few one-to-many source-based trees. 127 The issue of many-to-many multicasting service on top of a SSM 128 architecture is an open issue at this point. However, some feel that 129 even many-to-many applications should be handled with multiple one- 130 to-many instead of shared trees. 132 In any case, even though SSM would avoid mentioned problems, it is 133 far from being generally implemented, much less deployed, yet. 135 2.2. Implementing MSDP for IPv6 Interdomain Multicast 137 One could argue that currently, the easiest stop-gap solution (to a 138 stop-gap solution) would be to specify IPv6 TLV's for MSDP. This 139 would be fairly straightforward, and existing implementations would 140 probably be relatively easily modifiable. 142 There has been some resistance to this, as MSDP was not supposed to 143 last this long in the first place. 145 2.3. Implementing Another Multicast Routing Protocol 147 One possibility might be to specify and/or implement a different 148 multicast routing protocol. In fact, Border Gateway Multicast 149 Protocol (BGMP) [BGMP] has been specified for a few years; however, 150 it seems quite complex and there have been no implementations. 151 Lacking deployment experience and specification analysis, it is 152 difficult to say which problems it might solve (and possibly, which 153 new ones to introduce). 155 In conclusion, looking for a solution in BGMP may not be realistic in 156 this time frame. 158 2.4. Embedding the RP Address in an IPv6 Multicast Address 160 One way to work around these problems would be to allocate and assign 161 multicast addresses in such a fashion that the address of the RP 162 could be automatically calculated from the multicast address. 164 At the first glance, this appears to be an impossible problem: the 165 address of the RP, as well as the multicast address, are both 128 166 bits long; in the general case, embedding one in the other is 167 impossible. 169 However, making some assumptions about multicast addressing, this is 170 can be done -- a proposed solution is presented in a different memo 171 [EMBEDRP]. Additionally, this requires a PIM-SM implementation of 172 the Embedded RP group-to-RP mapping mechanism which takes this 173 encoding to the account. 175 One should note that MSDP is also used in "Anycast RP" [ANYCASTRP] 176 -technique, for sharing the state information between different RP's 177 in one PIM domain; unless other proposals, such as [ANYPIMRP], are 178 deployed, or MSDP for IPv6 implemented, Anycast-RP technique cannot 179 be used. 181 However, a "cold failover" variant of anycast-RP (for long-term 182 redundancy only) would still be possible. In this mechanism, multiple 183 routers would be configured with the RP address, but only one would 184 be active at the time: if the RP goes down, another takes its place. 185 The multicast state stored in the RP would be lost, though, unless it 186 is copied by some out-of-band mechanism (e.g. placing the backup RP 187 absolutely on-the-path and have it snoop all the relevant packets). 189 2.5. Site-local Group Scoping 191 Site-local groups must be their own PIM domains to prevent site-local 192 data leaking to other sites. A more complex possibility would be to 193 implement something resembling "BSR border" feature which would 194 filter out all site-local components in PIM packets: if this is not 195 done very carefully, site-local information will leak to the global 196 network. This is operationally difficult, and PIM working group has 197 come to consensus that a scope boundary MUST also be a a site 198 boundary for certain critical PIM messages (e.g. C-RP and Bootstrap). 200 Especially if site-local multicast is used (and the site also wants 201 to engage in global multicast), there will be a huge number of 202 domains and communication required between them. This will increase 203 the need for a global multicast solution. 205 3. Issues with SSM and Embedded RP 207 This section briefly describes some challenges with SSM deployment, 208 and gaps caused by the introduction of Embedded RP. 210 3.1. SSM Deployment 212 To be deployed, SSM requires changes to routers, MLD-snooping 213 Ethernet switches, host systems, APIs, and the multicast usage 214 models. 216 Introducing SSM support in the routers has been straightforward. 218 IGMP-snooping Ethernet switches have been a more difficult issue, 219 though [SSMSNOOP]; some which perform IGMPv2 snooping discard IGMPv3 220 reports or queries, or multicast transmissions associated to them. 221 If MLDv1 snooping had been implemented, this would likely have 222 affected that as well. 224 Host systems require MLDv2 support. The situation has become 225 slightly better with respect to MLDv2 support for end systems. The 226 multicast source filtering API specification has also been completed; 227 its deployment is likely roughly equal (or slightly worse) than 228 MLDv2. The API is required for creating SSM applications. 230 Now the most difficult problem, multicast usage models, remains a 231 problem. SSM is an excellent fit for one-to-many distribution 232 topologies, and porting such applications to use SSM would likely be 233 rather simple. However, a significant number of current applications 234 are many-to-many (e.g., conferencing applications) which cannot be 235 converted to SSM without significant effort, including, for example, 236 out-of-band source discovery. For such applications to be usable for 237 IPv6 at least in a short to medium term, Any Source Multicast -like 238 techniques seem to be required. 240 3.2. RP Failover with Embedded RP 242 Embedded RP provides a means for ASM multicast without inter-domain 243 MSDP. However, to continue providing failover mechanisms for RPs, a 244 form of state sharing, called Anycast-RP, should still be supported. 245 MSDP could still be used for that; an alternative is doing the same 246 in PIM itself [PIMANYRP]. 248 However, one should note that as Embedded RP does not require MSDP 249 peerings between the RPs, it's possible to deploy more RPs in a PIM 250 domain. For example, the scalability and redundancy could be 251 achieved by co-locating RP functionality in the DRs: each major 252 source, which "owns" a group, could have its own DR act as the RP. 253 This has about the same redundancy characteristics as using SSM -- so 254 there may not be an actually very urgent need for Anycast-RP if 255 operational methods to include fate-sharing of the groups is 256 followed. 258 4. Neighbor Discovery Using Multicast 260 Neighbor Discovery [NDISC] uses link-local multicast in Ethernet 261 media, not broadcast as does ARP with IPv4. This may cause some 262 operational problems with some equipment. 264 The author has seen one brand of managed Ethernet switches, and heard 265 reports of a few unmanaged switches, that do not forward IPv6 link- 266 layer multicast packets to other ports at all. In essence, native 267 IPv6 is impossible with this equipment. Investigation is still going 268 on whether these issues can be worked around. 270 However, it seems likely this may be a problem with some switches 271 that build multicast forwarding state based on Layer 3 information 272 (and do not support IPv6); state using Layer 2 information would work 273 just fine [MLDSNOOP]. 275 For the deployment of IPv6, it would be important to find out how 276 this can be fixed (e.g. how exactly this breaks specifications) and 277 how one can identify which equipment could case problems like these 278 (and whether there are workarounds). 280 One workaround might be to implement a toggle in the nodes that would 281 use link-layer broadcast instead of multicast as a fallback solution. 282 However, this would have to be used in all the systems in the same 283 segment one wishes to communicate with. 285 5. Functionality Like MLD Snooping 287 On Ethernet, multicast frames are forwarded to every port, even 288 without subscribers (or IPv6 support). 290 Especially if multicast traffic is relatively heavy (e.g. video 291 streaming), it becomes particularly important to have some feature 292 like Multicast Listener Discovery (MLD) snooping implemented in the 293 equipment, most importantly Ethernet switches [MLDSNOOP]. 295 In addition, there have been some misunderstandings wrt. which 296 multicast addresses (in particular, link-locals) MLD reports 297 (utilized in the snooping) should be generated for. If all 298 implementations do not generate enough MLD reports, the introduction 299 of MLD snooping could cause them being blocked out. To clarify, a 300 MLD report MUST be generated for every group except all-nodes 301 (ff02::1 -- which is forwarded to all ports); this also includes all 302 the other link-local groups. 304 Looking at the actual problem from a higher view, it is not clear 305 that MLD snooping is the right long-term solution. It makes the 306 switches complex, requires the processing of datagrams above the 307 link-layer, and should be discouraged [MULTIGAP]: the whole idea of 308 L2-only devices having be able to peek into L3 datagrams seems like a 309 severe layering violation -- and often the devices aren't upgradeable 310 in any way. Better mechanisms could be having routers tell switches 311 which multicasts to forward where (e.g. [CGMP]) or by using some 312 other mechanisms [GARP]. 314 6. Security Considerations 316 Only deployment/implementation issues are considered, and these do 317 not have any particular security considerations; security 318 considerations for each technology are covered in the respective 319 specifications. 321 One fairly obvious issue raised in this memo is that if there is no 322 adminsitrative PIM domain border between site-local multicast 323 domains, the site-local traffic could very easily flow into other 324 sites and the Internet. 326 7. Acknowledgements 328 Early discussions with Stig Venaas, Jerome Durand, Tim Chown et al. 329 led to the writing of this draft. Brian Haberman offered extensive 330 comments along the way. "Itojun" Hagino brought up the need for MLD 331 snooping in a presentation. Bill Nickless pointed out issues in the 332 gap analysis and provided a pointer to GARP/GMRP; H�vard Eidnes made 333 a case for a protocol like CGMP. Leonard Giuliano pointed out a more 334 complete analysis of SSM with different kind of applications. 336 8. References 338 8.1. Normative References 340 [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and 341 MSDP", RFC 3446, January 2003. 343 [EMBEDRP] Savola, P., Haberman, B., "Embedding the RP Address 344 in an IPv6 Multicast Address", work-in-progress, 345 draft-ietf-mboned-embeddedrp-01.txt, Feb 2004. 347 [MSDP] Fenner, B., Meyer, D., "Multicast Source Discovery 348 Protocol", RFC 3618, Oct 2003. 350 [NDISC] Narten, T., Nordmark, E., Simpson W., "Neighbor Discovery 351 for IP Version 6 (IPv6)", RFC2461, December 1998. 353 [PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - 354 Sparse Mode (PIM-SM): Protocol Specification (Revised)", 355 work-in-progress, draft-ietf-pim-sm-v2-new-08.txt, 356 October 2003. 358 [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", 359 work-in-progress, draft-ietf-ssm-arch-04.txt, 360 Oct 2003. 362 8.2. Informative References 364 [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", 365 work-in-progress, draft-ietf-pim-anycast-rp-00.txt, 366 November 2003. 368 [BGMP] Thaler, D., "Border Gateway Multicast Protocol (BGMP)", 369 work-in-progress, draft-ietf-bgmp-spec-06.txt, 370 January 2004. 372 [BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for 373 PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm- 374 bsr-03.txt, February 2003. 376 [CGMP] Cisco, "Cisco Group Management Protocol", e.g. 377 http://www.cisco.com/en/US/tech/tk648/tk363/tk105/ 378 tech_protocol_home.html 380 [GARP] Tobagi, F., et al, "Study of IEEE 802.1p GARP/GMRP Timer 381 Values", (for introduction to GARP/GMRP, see section 2), 382 Sep 1997. 384 [MLDSNOOP] Christensen, M., Solensky, F., "IGMP and MLD snooping 385 switches", work-in-progress, draft-ietf-magma- 386 snoop-10.txt, October 2003. 388 [MULTIGAP] Meyer, D., Nickless, B., "Internet Multicast Gap 389 Analysis [...]", work-in-progress, 390 draft-ietf-mboned-iesg-gap-analysis-00.txt, July 2002. 392 [PIMSO] Bhattacharyya, S. et al, "Deployment of PIM-SO at Sprint 393 (PIM-SO)", work-in-progress, 394 draft-bhattach-diot-pimso-00.txt (expired), March 2000. 396 [SSMSNOOP] Thaler, D., "Operational Problems with IGMP snooping 397 switches", presentation in MAGMA WG at IETF56, 398 http://www.ietf.org/proceedings/03mar/148.htm, 399 March 2003. 401 Author's Address 403 Pekka Savola 404 CSC/FUNET 405 Espoo, Finland 406 EMail: psavola@funet.fi 408 Intellectual Property Statement 410 The IETF takes no position regarding the validity or scope of any 411 intellectual property or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; neither does it represent that it 415 has made any effort to identify any such rights. Information on the 416 IETF's procedures with respect to rights in standards-track and 417 standards-related documentation can be found in BCP-11. Copies of 418 claims of rights made available for publication and any assurances of 419 licenses to be made available, or the result of an attempt made to 420 obtain a general license or permission for the use of such 421 proprietary rights by implementors or users of this specification can 422 be obtained from the IETF Secretariat. 424 The IETF invites any interested party to bring to its attention any 425 copyrights, patents or patent applications, or other proprietary 426 rights which may cover technology that may be required to practice 427 this standard. Please address the information to the IETF Executive 428 Director. 430 Full Copyright Statement 432 Copyright (C) The Internet Society (2004). All Rights Reserved. 434 This document and translations of it may be copied and furnished to 435 others, and derivative works that comment on or otherwise explain it 436 or assist in its implementation may be prepared, copied, published 437 and distributed, in whole or in part, without restriction of any 438 kind, provided that the above copyright notice and this paragraph are 439 included on all such copies and derivative works. However, this 440 document itself may not be modified in any way, such as by removing 441 the copyright notice or references to the Internet Society or other 442 Internet organizations, except as needed for the purpose of 443 developing Internet standards in which case the procedures for 444 copyrights defined in the Internet Standards process must be 445 followed, or as required to translate it into languages other than 446 English. 448 The limited permissions granted above are perpetual and will not be 449 revoked by the Internet Society or its successors or assignees. 451 This document and the information contained herein is provided on an 452 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 453 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 454 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 455 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 456 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 458 Acknowledgement 460 Funding for the RFC Editor function is currently provided by the 461 Internet Society.