idnits 2.17.00 (12 Aug 2021) /tmp/idnits33389/draft-savola-v6ops-multicast-issues-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. == 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 195: '...a scope boundary MUST also be a a site...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 175 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 (November 2002) is 7127 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 2461 (ref. 'NDISC') (Obsoleted by RFC 4861) == Outdated reference: draft-ietf-mboned-anycast-rp has been published as RFC 3446 == Outdated reference: draft-ietf-bgmp-spec has been published as RFC 3913 == Outdated reference: draft-ietf-magma-snoop has been published as RFC 4541 == 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: A later version (-04) exists of draft-bhattach-diot-pimso-00 == Outdated reference: draft-ietf-ssm-arch has been published as RFC 4607 == Outdated reference: A later version (-03) exists of draft-savola-mboned-mcast-rpaddr-00 Summary: 5 errors (**), 0 flaws (~~), 11 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: May 2003 5 November 2002 7 IPv6 Multicast Deployment Issues 9 draft-savola-v6ops-multicast-issues-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 There are many issues concerning the deployment and implementation, 35 and to a lesser degree, specification of IPv6 multicast. This memo 36 describes known problems, trying to raise awareness. Currently, 37 global IPv6 interdomain multicast is completely impossible except 38 using SSM: there is no way to convey information about multicast 39 sources between PIM RPs. Site-scoped multicast is also problematic 40 when used alongside to global multicast because of that. A few 41 possible solutions are outlined or referred to. In addition, an 42 issue regarding link-local multicast-blocking Ethernet switches is 43 brought up. Finally, a feature request for MLD snooping switches is 44 noted. 46 Table of Contents 48 1. Introduction ............................................... 2 49 2. Issues with Multiple PIM Domains and Any Source Multicast .. 3 50 2.1. Changing the Multicast Usage Model ..................... 3 51 2.2. Implementing MSDP for IPv6 ............................. 4 52 2.3. Implementing Another Multicast Routing Protocol ........ 4 53 2.4. Embedding the Address of the RP in Multicast Address ... 4 54 2.5. Site-local Group Scoping ............................... 5 55 3. Neighbor Discovery Using Multicast ......................... 5 56 4. MLD Snooping Ethernet Switches ............................. 6 57 5. Security Considerations .................................... 6 58 6. Acknowledgements ........................................... 6 59 7. References ................................................. 7 60 7.1. Normative References ................................... 7 61 7.2. Informative References ................................. 7 62 Author's Address ............................................... 8 64 1. Introduction 66 There are many issues concerning the deployment and implementation, 67 and to a lesser degree, specification of IPv6 multicast. This memo 68 describes known problems, trying to raise awareness. 70 Currently, global IPv6 interdomain multicast is completely impossible 71 except using SSM: there is no way to convey information about 72 multicast sources between PIM RPs. Site-scoped multicast is also 73 problematic when used alongside to global multicast because of that. 74 A few possible solutions are outlined or referred to. These are 75 discussed in section 2. 77 In addition, an issue regarding link-local multicast -blocking 78 Ethernet switches is brought up. Finally, a feature request for MLD 79 snooping switches is noted. These are discussed in sections 3 and 4, 80 respectively. 82 [MULTIGAP] analyses the more generic set of issues with multicast; 83 this memo focuses on critical issues regarding IPv6. 85 2. Issues with Multiple PIM Domains and Any Source Multicast 87 For both administrative and technical reasons, there must be multiple 88 Protocol-Independent Multicast (PIM) [PIM] domains in the Internet, 89 which means there will be multiple PIM Rendezvous Points (RPs) -- and 90 communication mechanisms between these RPs will become critical. 92 These issues only come up with classical Any Source Multicast; 93 Source-Specific Multicast [SSM] does not require RPs and is not 94 affected, as the multicast "channel" is identified by the combination 95 and can be communicated out-of-band. 97 In IPv4, notification of multicast sources between these PIM RPs is 98 done with Multicast Source Discovery Protocol (MSDP) [MSDP]. Many 99 consider this a sub-optimal, but unfortunately necessary, solution; 100 when it was specified, it was only meant as a "stop-gap" measure. 102 Below, some issues and solutions/work-arounds are described. 104 2.1. Changing the Multicast Usage Model 106 As "Any Source Multicast" -model has been found to be complex and a 107 bit problematic, there may be an incentive to move to SSM for good 108 (at least for most cases). Below two paragraphs are adapted from 109 [PIMSO]: 111 The most serious criticism of the SSM architecture is that it does 112 not support shared trees which may be useful for supporting many-to- 113 many applications. In the short-term this is not a serious concern 114 since the multicast application space is likely to be dominated by 115 one-to-many applications. Some other classes of multicast 116 applications that are likely to emerge in the future are few-to-few 117 (e.g. private chat rooms, whiteboards), few-to-many (e.g., video 118 conferencing, distance learning) and many-to-many (e.g., large chat 119 rooms, multi-user games). The first two classes can be easily handled 120 using a few one-to-many source-based trees. 122 The issue of many-to-many multicasting service on top of a SSM 123 architecture is an open issue at this point. However, some feel that 124 even many-to-many applications should be handled with multiple one- 125 to-many instead of shared trees. 127 In any case, even though SSM would avoid mentioned problems, it is 128 far from being generally implemented, much less deployed, yet. 130 Nonetheless, few seem to realize that SSM is currently the only way 131 to get global interdomain multicast in IPv6. 133 2.2. Implementing MSDP for IPv6 135 One could argue that currently, the easiest stop-gap solution (to a 136 stop-gap solution) would be to specify IPv6 TLV's for MSDP. This 137 would be fairly straightforward, and existing implementations would 138 probably be relatively easily modifiable. 140 There has been some resistance to this, as MSDP was not supposed to 141 last this long in the first place, though. Whether this is a "good" 142 or "bad" decision is a matter of opinion. 144 2.3. Implementing Another Multicast Routing Protocol 146 One possibility might be to specify and/or implement a different 147 multicast routing protocol. In fact, Border Gateway Multicast 148 Protocol (BGMP) [BGMP] has been specified for a few years; however, 149 it seems quite complex and there have been no implementations. 150 Lacking deployment experience and specification analysis, it is 151 difficult to say which problems it might solve (and possibly, which 152 new ones to introduce). 154 In conclusion, looking for a solution in BGMP may not be realistic in 155 this time frame. 157 2.4. Embedding the Address of the RP in Multicast Address 159 One way to work around these problems would be to allocate and assign 160 multicast addresses in such a fashion that the address of the RP 161 could be automatically calculated from the multicast address. 163 At the first glance, this appears to be an impossible problem: the 164 address of the RP, as well as the multicast address, are both 128 165 bits long; in the general case, embedding one in the other is 166 impossible. 168 However, making some assumptions about multicast addressing, this is 169 can be done -- a proposed solution is presented in a different memo 170 [V6RPADDR]. Some minor changes in existing PIM specifications would 171 have to be done to take advantage of this, though (but non-modified 172 implementations would be no worse than today). 174 One should note that MSDP is also used in "Anycast RP" [ANYCASTRP] 175 -technique, for sharing the state information between different RP's 176 in one PIM domain; without further specification, anycast-RP 177 technique could not be used with "embedded RP address" mechanism. 179 However, a "cold failover" variant of anycast-RP (for redundancy 180 only) would still be possible. In this mechanism, multiple routers 181 would be configured with the RP address, but only one would be active 182 at the time: if the RP goes down, another takes its place. The 183 multicast state stored in the RP would be lost, though, unless it is 184 copied by some out-of-band mechanism (e.g. placing the backup RP 185 absolutely on-the-path and have it snoop all the relevant packets). 187 2.5. Site-local Group Scoping 189 Site-local groups must be their own PIM domains to prevent site-local 190 data leaking to other sites. A more complex possibility would be to 191 implement something resembling "BSR border" feature which would 192 filter out all site-local components in PIM packets: if this is not 193 done very carefully, site-local information will leak to the global 194 network. This is operationally difficult, and PIM working group has 195 come to consensus that a scope boundary MUST also be a a site 196 boundary for certain critical PIM messages (e.g. C-RP and Bootstrap). 198 Especially if site-local multicast is used (and the site also wants 199 to engage in global multicast), there will be a huge number of 200 domains and communication required between them. This will increase 201 the need for a global multicast solution. 203 3. Neighbor Discovery Using Multicast 205 Neighbor Discovery [NDISC] uses link-local multicast in the most 206 common link-layer media, not broadcast as does ARP with IPv4. This 207 may cause some operational problems with some equipment. 209 The author has seen one brand of managed Ethernet switches, and heard 210 reports of a few unmanaged switches, that do not forward IPv6 link- 211 layer multicast packets to other ports at all. In essence, native 212 IPv6 is impossible with this equipment. Investigation is still going 213 on whether these issues can be worked around. 215 However, it seems likely this may be a problem with some switches 216 that build multicast forwarding state based on Layer 3 information 217 (and do not support IPv6); state using Layer 2 information would work 218 just fine [MLDSNOOP]. 220 For the deployment of IPv6, it would be important to find out how 221 this can be fixed (e.g. how exactly this breaks specifications) and 222 how one can identify which equipment could case problems like these 223 (and whether there are workarounds). 225 One workaround might be to implement a toggle in the nodes that would 226 use link-layer broadcast instead of multicast as a fallback solution. 227 However, this would have to be used in all the systems in the same 228 segment one wishes to communicate with. 230 4. MLD Snooping Ethernet Switches 232 Especially if multicast traffic is relatively heavy (e.g. video 233 streaming), it becomes particularly important to have some feature 234 like Multicast Listener Discovery (MLD) snooping implemented in some 235 equipment, most importantly Ethernet switches [MLDSNOOP]. 237 In addition, there have been some misunderstandings wrt. which 238 multicast addresses (in particular, link-locals) MLD reports 239 (utilized in the snooping) should be generated for. If all 240 implementations do not generate enough MLD reports, the introduction 241 of MLD snooping could cause them being blocked out. Clarifications 242 and analysis on what MLD snooping switches can reasonably expect 243 would be very important. 245 One could also argue that MLD snooping might make the devices too 246 complex, requiring the processing of datagrams above the link-layer, 247 and should be discouraged [MULTIGAP]: the whole idea of L2-only 248 devices having be able to peek into L3 datagrams seems like a severe 249 layering violation -- and often the devices aren't upgradeable in any 250 way. Better mechanisms could be having routers tell switches which 251 multicasts to forward where (e.g. [CGMP]) or by using some other 252 mechanisms [GARP]. 254 5. Security Considerations 256 Only deployment/implementation issues are considered, and these do 257 not have any particular security considerations; security 258 considerations for each technology are covered in the respective 259 specification. 261 One fairly obvious issue raised in this memo is that if there is no 262 adminsitrative PIM domain border between site-local multicast 263 domains, the site-local traffic could very easily flow into other 264 sites and the Internet. 266 6. Acknowledgements 268 Early discussions with Stig Venaas, Jerome Durand, Tim Chown et al. 269 led to the writing of this draft. Brian Haberman offered extensive 270 comments along the way. "Itojun" Hagino brought up the need for MLD 271 snooping in a presentation. Bill Nickless pointed out issues in the 272 gap analysis and provided a pointer to GARP/GMRP; H…vard Eidnes made 273 a case for a protocol like CGMP. Leonard Giuliano pointed out a more 274 complete analysis of SSM with different kind of applications. 276 7. References 278 7.1. Normative References 280 [NDISC] Narten, T., Nordmark, E., Simpson W., "Neighbor Discovery 281 for IP Version 6 (IPv6)", RFC2461, December 1998. 283 7.2. Informative References 285 [ANYCASTRP] Dorian, K. et al, q(Anycast RP mechanism using PIM and 286 MSDP", work-in-progress, draft-ietf-mboned-anycast- 287 rp-08.txt, May 2001. 289 [BGMP] Thaler, D., "Border Gateway Multicast Protocol (BGMP)", 290 work-in-progress, draft-ietf-bgmp-spec-03.txt. June 2002. 292 [CGMP] Cisco, "Cisco Group Management Protocol", e.g. 293 http://www.cisco.com/en/US/tech/tk648/tk363/tk105/ 294 tech_protocol_home.html 296 [GARP] Tobagi, F., et al, "Study of IEEE 802.1p GARP/GMRP Timer 297 Values", (for introduction to GARP/GMRP, see section 2), 298 Sep 1997. 300 [MLDSNOOP] Christensen, M., Solensky, F., "IGMP and MLD snooping 301 switches", work-in-progress, draft-ietf-magma- 302 snoop-02.txt, June 2002. 304 [MSDP] Farinacci, D. et al, "Multicast Source Discovery Protocol 305 (MSDP)", work-in-progress, draft-ietf-msdp-spec-13.txt 306 (expired), 2002. 308 [MULTIGAP] Meyer, D., Nickless, B., "Internet Multicast Gap 309 Analysis [...]", work-in-progress, 310 draft-ietf-mboned-iesg-gap-analysis-00.txt, July 2002. 312 [PIM] Fenner, B. et al, "Protocol Independent Multicast - 313 Sparse Mode (PIM-SM): Protocol Specification (Revised)", 314 work-in-progress, draft-ietf-pim-sm-v2-new-05.txt, 315 March 2002. 317 [PIMSO] Bhattacharyya, S. et al, "Deployment of PIM-SO at Sprint 318 (PIM-SO)", work-in-progress, 319 draft-bhattach-diot-pimso-00.txt (expired), March 2000. 321 [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", 322 work-in-progress, draft-ietf-ssm-arch-00.txt, 323 November 2001. 325 [V6RPADDR] Savola, P., Haberman, B., "Embedding the Address of RP 326 in IPv6 Multicast Address", work-in-progress, 327 draft-savola-mboned-mcast-rpaddr-00.txt, October 2002. 329 Author's Address 331 Pekka Savola 332 CSC/FUNET 333 Espoo, Finland 334 EMail: psavola@funet.fi