idnits 2.17.1 draft-savola-v6ops-multicast-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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.) ** 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 179: '...a scope boundary MUST also be a a site...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 167 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 7854 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: A later version (-06) exists of draft-ietf-bgmp-spec-03 == Outdated reference: A later version (-12) exists of draft-ietf-magma-snoop-02 == Outdated reference: A later version (-20) exists of draft-ietf-msdp-spec-13 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-05 == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-00 == Outdated reference: A later version (-03) exists of draft-savola-mboned-mcast-rpaddr-00 Summary: 6 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 October 2002 7 IPv6 Multicast Deployment Issues 9 draft-savola-v6ops-multicast-issues-00.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 Abstract 31 There are many issues concerning the deployment and implementation, 32 and to a lesser degree, specification of IPv6 multicast. This memo 33 describes known problems, trying to raise awareness. Currently, 34 global IPv6 interdomain multicast is completely impossible except 35 using SSM: there is no way to convey information about multicast 36 sources between PIM RPs. Site-scoped multicast is also problematic 37 when used alongside to global multicast because of that. A few 38 possible solutions are outlined or referred to. In addition, an 39 issue regarding link-local multicast-blocking Ethernet switches is 40 brought up. Finally, a feature request for MLD snooping switches is 41 noted. 43 Table of Contents 45 1. Introduction ............................................... 2 46 2. Issues with Multiple PIM Domains and Any Source Multicast .. 2 47 2.1. Changing the Multicast Usage Model ..................... 3 48 2.2. Implementing MSDP for IPv6 ............................. 3 49 2.3. Implementing Another Multicast Routing Protocol ........ 4 50 2.4. Embedding the Address of the RP in Multicast Address ... 4 51 2.5. Site-local Group Scoping ............................... 4 52 3. Neighbor Discovery Using Multicast ......................... 5 53 4. MLD Snooping Ethernet Switches ............................. 5 54 5. Security Considerations .................................... 6 55 6. Acknowledgements ........................................... 6 56 7. References ................................................. 6 57 7.1. Normative References ................................... 6 58 7.2. Informative References ................................. 6 59 Author's Address ............................................... 7 61 1. Introduction 63 There are many issues concerning the deployment and implementation, 64 and to a lesser degree, specification of IPv6 multicast. This memo 65 describes known problems, trying to raise awareness. 67 Currently, global IPv6 interdomain multicast is completely impossible 68 except using SSM: there is no way to convey information about 69 multicast sources between PIM RPs. Site-scoped multicast is also 70 problematic when used alongside to global multicast because of that. 71 A few possible solutions are outlined or referred to. These are 72 discussed in section 2. 74 In addition, an issue regarding link-local multicast-blocking 75 Ethernet switches is brought up. Finally, a feature request for MLD 76 snooping switches is noted. These are discussed in sections 3 and 4, 77 respectively. 79 2. Issues with Multiple PIM Domains and Any Source Multicast 81 For both administrative and technical reasons, there must be multiple 82 Protocol-Independent Multicast (PIM) [PIM] domains in the Internet, 83 which means there will be multiple PIM Rendezvous Points (RPs) -- and 84 communication mechanisms between these RPs will become critical. 86 These issues only come up with classical Any Source Multicast; 87 Source-Specific Multicast [SSM] does not require RPs and is not 88 affected, as the multicast "channel" is identified by the combination 89 and can be communicated out-of-band. 91 In IPv4, notification of multicast sources between these PIM RPs is 92 done with Multicast Source Discovery Protocol (MSDP) [MSDP]. Many 93 consider this a sub-optimal, but unfortunately necessary, solution; 94 when it was specified, it was only meant as a "stop-gap" measure. 96 Below, some issues and solutions/work-arounds are described. 98 2.1. Changing the Multicast Usage Model 100 As "Any Source Multicast" -model has been found to be complex and a 101 bit problematic, there may be an incentive to move to SSM for good 102 (at least for most cases). 104 SSM is ideal for "broadcast" -type applications, but can be argued to 105 be a bit lacking in e.g. "videoconference" -type applications (as it 106 may be desirable to have data flow directly between each 107 participant). However, in the latter case, as with telephone 108 teleconferences, it is often very desirable for one party to act as a 109 chair or a "hub". In this case, other participants could send their 110 data using unicast to the hub and hub could retransmit all data using 111 SSM, though. 113 One could argue that the added latency of circulating the data 114 through the hub may be unacceptable; however, at least in the bigger 115 conferences (where usually using multicast really matters) this does 116 not seem like a big problem because there must be some control of the 117 order of speech anyway. 119 In any case, even though SSM would avoid mentioned problems, it is 120 far from being generally implemented, much less deployed, yet. 122 Nonetheless, few seem to realize that SSM is currently the only way 123 to get global interdomain multicast in IPv6. 125 2.2. Implementing MSDP for IPv6 127 One could argue that currently, the easiest stop-gap solution (to a 128 stop-gap solution) would be to specify IPv6 TLV's for MSDP. This 129 would be fairly straightforward, and existing implementations would 130 probably be relatively easily modifiable. 132 There has been some resistance to this, as MSDP was not supposed to 133 last this long in the first place, though. Whether this is a "good" 134 or "bad" decision is a matter of opinion. 136 2.3. Implementing Another Multicast Routing Protocol 138 One possibility might be to specify and/or implement a different 139 multicast routing protocol. In fact, Border Gateway Multicast 140 Protocol (BGMP) [BGMP] has been specified for a few years; however, 141 it seems quite complex and there have been no implementations. 142 Lacking deployment experience and specification analysis, it is 143 difficult to say which problems it might solve (and possibly, which 144 new ones to introduce). 146 In conclusion, looking for a solution in BGMP may not be realistic in 147 this time frame. 149 2.4. Embedding the Address of the RP in Multicast Address 151 One way to work around these problems would be to allocate and assign 152 multicast addresses in such a fashion that the address of the RP 153 could be automatically calculated from the multicast address. 155 At the first glance, this appears to be an impossible problem: the 156 address of the RP, as well as the multicast address, are both 128 157 bits long; in the general case, embedding one in the other is 158 impossible. 160 However, making some assumptions about multicast addressing, this is 161 can be done -- a proposed solution is presented in a different memo 162 [V6RPADDR]. Some minor changes in existing PIM specifications would 163 have to be done to take advantage of this, though (but non-modified 164 implementations would be no worse than today). 166 One should note that MSDP is also used in "Anycast RP" [ANYCASTRP] 167 -technique, for sharing the state information between different RP's 168 in one PIM domain; without further specification, anycast-RP 169 technique could not be used with "embedded RP address" mechanism. 171 2.5. Site-local Group Scoping 173 Site-local groups must be their own PIM domains to prevent site-local 174 data leaking to other sites. A more complex possibility would be to 175 implement something resembling "BSR border" feature which would 176 filter out all site-local components in PIM packets: if this is not 177 done very carefully, site-local information will leak to the global 178 network. This is operationally difficult, and PIM working group has 179 come to consensus that a scope boundary MUST also be a a site 180 boundary for certain critical PIM messages (e.g. C-RP and Bootstrap). 182 Especially if site-local multicast is used (and the site also wants 183 to engage in global multicast), there will be a huge number of 184 domains and communication required between them. This will increase 185 the need for a global multicast solution. 187 3. Neighbor Discovery Using Multicast 189 Neighbor Discovery [NDISC] uses link-local multicast in the most 190 common link-layer media, not broadcast as does ARP with IPv4. This 191 may cause some operational problems with some equipment. 193 The author has seen two brands of managed Ethernet switches that do 194 not forward IPv6 link-layer multicast packets to other ports at all. 195 In essence, native IPv6 is impossible with this equipment. 196 Investigation is still going on whether these issues can be worked 197 around. 199 However, it seems likely this may be a problem with some switches 200 that build multicast forwarding state based on Layer 3 information 201 (and do not support IPv6); state using Layer 2 information would work 202 just fine [MLDSNOOP]. 204 For the deployment of IPv6, it would be important to find out how 205 this can be fixed (e.g. how exactly this breaks specifications) and 206 how one can identify which equipment could case problems like these 207 (and whether there are workarounds). 209 4. MLD Snooping Ethernet Switches 211 Especially if multicast traffic is relatively heavy (e.g. video 212 streaming), it becomes particularly important to have Multicast 213 Listener Discovery (MLD) snooping implemented in some equipment, most 214 importantly Ethernet switches [MLDSNOOP]. 216 In addition, there have been some misunderstandings wrt. which 217 multicast addresses (in particular, link-locals) MLD reports 218 (utilized in the snooping) should be generated for. If all 219 implementations do not generate enough MLD reports, the introduction 220 of MLD snooping could cause them being blocked out. Clarifications 221 and analysis on what MLD snooping switches can reasonably expect 222 would be very important. 224 5. Security Considerations 226 Only deployment/implementation issues are considered, and these do 227 not have any particular security considerations; security 228 considerations for each technology are covered in the respective 229 specification. 231 One fairly obvious issue raised in this memo is that if there is no 232 adminsitrative PIM domain border between site-local multicast 233 domains, the site-local traffic could very easily flow into other 234 sites and the Internet. 236 6. Acknowledgements 238 Early discussions with Stig Venaas, Jerome Durand, Tim Chown et al. 239 led to the writing of this draft. Brian Haberman offered extensive 240 comments along the way. "Itojun" Hagino brought up the need for MLD 241 snooping in a presentation. 243 7. References 245 7.1. Normative References 247 [NDISC] Narten, T., Nordmark, E., Simpson W., "Neighbor Discovery 248 for IP Version 6 (IPv6)", RFC2461, December 1998. 250 7.2. Informative References 252 [ANYCASTRP] Dorian, K. et al, q(Anycast RP mechanism using PIM and 253 MSDP", work-in-progress, draft-ietf-mboned-anycast- 254 rp-08.txt, May 2001. 256 [BGMP] Thaler, D., "Border Gateway Multicast Protocol (BGMP)", 257 work-in-progress, draft-ietf-bgmp-spec-03.txt. June 2002. 259 [MLDSNOOP] Christensen, M., Solensky, F., "IGMP and MLD snooping 260 switches", work-in-progress, draft-ietf-magma- 261 snoop-02.txt, June 2002. 263 [MSDP] Farinacci, D. et al, "Multicast Source Discovery Protocol 264 (MSDP)", work-in-progress, draft-ietf-msdp-spec-13.txt 265 (expired), 2002. 267 [PIM] Fenner, B. et al, "Protocol Independent Multicast - 268 Sparse Mode (PIM-SM): Protocol Specification (Revised)", 269 work-in-progress, draft-ietf-pim-sm-v2-new-05.txt, 270 March 2002. 272 [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", 273 work-in-progress, draft-ietf-ssm-arch-00.txt, 274 November 2001. 276 [V6RPADDR] Savola, P., "Embedding the Address of RP in IPv6 277 Multicast Address", work-in-progress, 278 draft-savola-mboned-mcast-rpaddr-00.txt, October 2002. 280 Author's Address 282 Pekka Savola 283 CSC/FUNET 284 Espoo, Finland 285 EMail: psavola@funet.fi