Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: August 2004 February 2004 IPv6 Multicast Deployment Issues draft-savola-v6ops-multicast-issues-03.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract There are many issues concerning the deployment and implementation, and to a lesser degree, specification of IPv6 multicast. This memo describes known problems, trying to raise awareness. Currently, global IPv6 interdomain multicast is impossible except using SSM: there is no way to convey information about multicast sources between PIM-SM RPs; the situation is analyzed, and a technique called Embedded RP is offered as a solution. The deploability of SSM and Embedded RP is also considered. In addition, an issue regarding link-local multicast-blocking Ethernet switches is brought up. Finally, the requirement for functionality like MLD snooping is noted. Savola [Expires August 2004] [Page 1] Internet Draft draft-savola-v6ops-multicast-issues-03.txt February 2004 Table of Contents 1. Introduction ............................................... 2 2. Issues with Multiple PIM Domains and Any Source Multicast .. 3 2.1. Changing the Multicast Usage Model ..................... 3 2.2. Implementing MSDP for IPv6 Interdomain Multicast ....... 4 2.3. Implementing Another Multicast Routing Protocol ........ 4 2.4. Embedding the RP Address in an IPv6 Multicast Address .. 4 2.5. Site-local Group Scoping ............................... 5 3. Issues with SSM and Embedded RP ............................ 5 3.1. SSM Deployment ......................................... 5 3.2. RP Failover with Embedded RP .......................... 6 4. Neighbor Discovery Using Multicast ......................... 6 5. Functionality Like MLD Snooping ............................ 7 6. Security Considerations .................................... 7 7. Acknowledgements ........................................... 8 8. References ................................................. 8 8.1. Normative References ................................... 8 8.2. Informative References ................................. 8 Author's Address ............................................... 9 Intellectual Property Statement ................................ 9 Full Copyright Statement ....................................... 10 1. Introduction There are many issues concerning the deployment and implementation, and to a lesser degree, specification of IPv6 multicast. This memo describes known problems, trying to raise awareness. Currently, global IPv6 interdomain multicast is impossible except using SSM: there is no way to convey information about multicast sources between PIM-SM RPs; site-scoped multicast problematic. A few possible solutions, such as Embedded RP [EMBEDRP] are outlined or referred to. These are discussed in section 2. Deployment issues with both SSM and Embedded RP are discussed separately in section 3. In addition, an issue regarding link-local multicast -blocking Ethernet switches is brought up. Finally, the requirement for functionality like MLD snooping is noted. These are discussed in sections 4 and 5, respectively. [MULTIGAP] analyses the more generic set of issues with multicast; this memo focuses on critical issues regarding IPv6. Savola [Expires August 2004] [Page 2] Internet Draft draft-savola-v6ops-multicast-issues-03.txt February 2004 2. Issues with Multiple PIM Domains and Any Source Multicast For both administrative and technical reasons, there must be multiple Protocol-Independent Multicast - Sparse Mode (PIM-SM) [PIM-SM] domains in the Internet, which means there will be multiple PIM-SM Rendezvous Points (RPs) -- and communication mechanisms between these RPs will become critical. These issues only come up with classical Any Source Multicast; Source-Specific Multicast [SSM] does not require RPs and is not affected, as the multicast "channel" is identified by the combination and can be communicated out-of-band. In IPv4, notification of multicast sources between these PIM RPs is done with Multicast Source Discovery Protocol (MSDP) [MSDP]. Many consider this a sub-optimal, but unfortunately necessary, solution; when it was specified, it was only meant as a "stop-gap" measure. Below, some issues and solutions or work-arounds are described. 2.1. Changing the Multicast Usage Model As "Any Source Multicast" -model has been found to be complex and a bit problematic, there may be an incentive to move to SSM for good (at least for most cases). Below two paragraphs are adapted from [PIMSO]: The most serious criticism of the SSM architecture is that it does not support shared trees which may be useful for supporting many-to- many applications. In the short-term this is not a serious concern since the multicast application space is likely to be dominated by one-to-many applications. Some other classes of multicast applications that are likely to emerge in the future are few-to-few (e.g. private chat rooms, whiteboards), few-to-many (e.g., video conferencing, distance learning) and many-to-many (e.g., large chat rooms, multi-user games). The first two classes can be easily handled using a few one-to-many source-based trees. The issue of many-to-many multicasting service on top of a SSM architecture is an open issue at this point. However, some feel that even many-to-many applications should be handled with multiple one- to-many instead of shared trees. In any case, even though SSM would avoid mentioned problems, it is far from being generally implemented, much less deployed, yet. Savola [Expires August 2004] [Page 3] Internet Draft draft-savola-v6ops-multicast-issues-03.txt February 2004 2.2. Implementing MSDP for IPv6 Interdomain Multicast One could argue that currently, the easiest stop-gap solution (to a stop-gap solution) would be to specify IPv6 TLV's for MSDP. This would be fairly straightforward, and existing implementations would probably be relatively easily modifiable. There has been some resistance to this, as MSDP was not supposed to last this long in the first place. 2.3. Implementing Another Multicast Routing Protocol One possibility might be to specify and/or implement a different multicast routing protocol. In fact, Border Gateway Multicast Protocol (BGMP) [BGMP] has been specified for a few years; however, it seems quite complex and there have been no implementations. Lacking deployment experience and specification analysis, it is difficult to say which problems it might solve (and possibly, which new ones to introduce). In conclusion, looking for a solution in BGMP may not be realistic in this time frame. 2.4. Embedding the RP Address in an IPv6 Multicast Address One way to work around these problems would be to allocate and assign multicast addresses in such a fashion that the address of the RP could be automatically calculated from the multicast address. At the first glance, this appears to be an impossible problem: the address of the RP, as well as the multicast address, are both 128 bits long; in the general case, embedding one in the other is impossible. However, making some assumptions about multicast addressing, this is can be done -- a proposed solution is presented in a different memo [EMBEDRP]. Additionally, this requires a PIM-SM implementation of the Embedded RP group-to-RP mapping mechanism which takes this encoding to the account. One should note that MSDP is also used in "Anycast RP" [ANYCASTRP] -technique, for sharing the state information between different RP's in one PIM domain; unless other proposals, such as [ANYPIMRP], are deployed, or MSDP for IPv6 implemented, Anycast-RP technique cannot be used. However, a "cold failover" variant of anycast-RP (for long-term redundancy only) would still be possible. In this mechanism, multiple Savola [Expires August 2004] [Page 4] Internet Draft draft-savola-v6ops-multicast-issues-03.txt February 2004 routers would be configured with the RP address, but only one would be active at the time: if the RP goes down, another takes its place. The multicast state stored in the RP would be lost, though, unless it is copied by some out-of-band mechanism (e.g. placing the backup RP absolutely on-the-path and have it snoop all the relevant packets). 2.5. Site-local Group Scoping Site-local groups must be their own PIM domains to prevent site-local data leaking to other sites. A more complex possibility would be to implement something resembling "BSR border" feature which would filter out all site-local components in PIM packets: if this is not done very carefully, site-local information will leak to the global network. This is operationally difficult, and PIM working group has come to consensus that a scope boundary MUST also be a a site boundary for certain critical PIM messages (e.g. C-RP and Bootstrap). Especially if site-local multicast is used (and the site also wants to engage in global multicast), there will be a huge number of domains and communication required between them. This will increase the need for a global multicast solution. 3. Issues with SSM and Embedded RP This section briefly describes some challenges with SSM deployment, and gaps caused by the introduction of Embedded RP. 3.1. SSM Deployment To be deployed, SSM requires changes to routers, MLD-snooping Ethernet switches, host systems, APIs, and the multicast usage models. Introducing SSM support in the routers has been straightforward. IGMP-snooping Ethernet switches have been a more difficult issue, though [SSMSNOOP]; some which perform IGMPv2 snooping discard IGMPv3 reports or queries, or multicast transmissions associated to them. If MLDv1 snooping had been implemented, this would likely have affected that as well. Host systems require MLDv2 support. The situation has become slightly better with respect to MLDv2 support for end systems. The multicast source filtering API specification has also been completed; its deployment is likely roughly equal (or slightly worse) than MLDv2. The API is required for creating SSM applications. Savola [Expires August 2004] [Page 5] Internet Draft draft-savola-v6ops-multicast-issues-03.txt February 2004 Now the most difficult problem, multicast usage models, remains a problem. SSM is an excellent fit for one-to-many distribution topologies, and porting such applications to use SSM would likely be rather simple. However, a significant number of current applications are many-to-many (e.g., conferencing applications) which cannot be converted to SSM without significant effort, including, for example, out-of-band source discovery. For such applications to be usable for IPv6 at least in a short to medium term, Any Source Multicast -like techniques seem to be required. 3.2. RP Failover with Embedded RP Embedded RP provides a means for ASM multicast without inter-domain MSDP. However, to continue providing failover mechanisms for RPs, a form of state sharing, called Anycast-RP, should still be supported. MSDP could still be used for that; an alternative is doing the same in PIM itself [PIMANYRP]. However, one should note that as Embedded RP does not require MSDP peerings between the RPs, it's possible to deploy more RPs in a PIM domain. For example, the scalability and redundancy could be achieved by co-locating RP functionality in the DRs: each major source, which "owns" a group, could have its own DR act as the RP. This has about the same redundancy characteristics as using SSM -- so there may not be an actually very urgent need for Anycast-RP if operational methods to include fate-sharing of the groups is followed. 4. Neighbor Discovery Using Multicast Neighbor Discovery [NDISC] uses link-local multicast in Ethernet media, not broadcast as does ARP with IPv4. This may cause some operational problems with some equipment. The author has seen one brand of managed Ethernet switches, and heard reports of a few unmanaged switches, that do not forward IPv6 link- layer multicast packets to other ports at all. In essence, native IPv6 is impossible with this equipment. Investigation is still going on whether these issues can be worked around. However, it seems likely this may be a problem with some switches that build multicast forwarding state based on Layer 3 information (and do not support IPv6); state using Layer 2 information would work just fine [MLDSNOOP]. For the deployment of IPv6, it would be important to find out how this can be fixed (e.g. how exactly this breaks specifications) and how one can identify which equipment could case problems like these Savola [Expires August 2004] [Page 6] Internet Draft draft-savola-v6ops-multicast-issues-03.txt February 2004 (and whether there are workarounds). One workaround might be to implement a toggle in the nodes that would use link-layer broadcast instead of multicast as a fallback solution. However, this would have to be used in all the systems in the same segment one wishes to communicate with. 5. Functionality Like MLD Snooping On Ethernet, multicast frames are forwarded to every port, even without subscribers (or IPv6 support). Especially if multicast traffic is relatively heavy (e.g. video streaming), it becomes particularly important to have some feature like Multicast Listener Discovery (MLD) snooping implemented in the equipment, most importantly Ethernet switches [MLDSNOOP]. In addition, there have been some misunderstandings wrt. which multicast addresses (in particular, link-locals) MLD reports (utilized in the snooping) should be generated for. If all implementations do not generate enough MLD reports, the introduction of MLD snooping could cause them being blocked out. To clarify, a MLD report MUST be generated for every group except all-nodes (ff02::1 -- which is forwarded to all ports); this also includes all the other link-local groups. Looking at the actual problem from a higher view, it is not clear that MLD snooping is the right long-term solution. It makes the switches complex, requires the processing of datagrams above the link-layer, and should be discouraged [MULTIGAP]: the whole idea of L2-only devices having be able to peek into L3 datagrams seems like a severe layering violation -- and often the devices aren't upgradeable in any way. Better mechanisms could be having routers tell switches which multicasts to forward where (e.g. [CGMP]) or by using some other mechanisms [GARP]. 6. Security Considerations Only deployment/implementation issues are considered, and these do not have any particular security considerations; security considerations for each technology are covered in the respective specifications. One fairly obvious issue raised in this memo is that if there is no adminsitrative PIM domain border between site-local multicast domains, the site-local traffic could very easily flow into other sites and the Internet. Savola [Expires August 2004] [Page 7] Internet Draft draft-savola-v6ops-multicast-issues-03.txt February 2004 7. Acknowledgements Early discussions with Stig Venaas, Jerome Durand, Tim Chown et al. led to the writing of this draft. Brian Haberman offered extensive comments along the way. "Itojun" Hagino brought up the need for MLD snooping in a presentation. Bill Nickless pointed out issues in the gap analysis and provided a pointer to GARP/GMRP; Håvard Eidnes made a case for a protocol like CGMP. Leonard Giuliano pointed out a more complete analysis of SSM with different kind of applications. 8. References 8.1. Normative References [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and MSDP", RFC 3446, January 2003. [EMBEDRP] Savola, P., Haberman, B., "Embedding the RP Address in an IPv6 Multicast Address", work-in-progress, draft-ietf-mboned-embeddedrp-01.txt, Feb 2004. [MSDP] Fenner, B., Meyer, D., "Multicast Source Discovery Protocol", RFC 3618, Oct 2003. [NDISC] Narten, T., Nordmark, E., Simpson W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461, December 1998. [PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", work-in-progress, draft-ietf-pim-sm-v2-new-08.txt, October 2003. [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", work-in-progress, draft-ietf-ssm-arch-04.txt, Oct 2003. 8.2. Informative References [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", work-in-progress, draft-ietf-pim-anycast-rp-00.txt, November 2003. [BGMP] Thaler, D., "Border Gateway Multicast Protocol (BGMP)", work-in-progress, draft-ietf-bgmp-spec-06.txt, January 2004. [BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm- Savola [Expires August 2004] [Page 8] Internet Draft draft-savola-v6ops-multicast-issues-03.txt February 2004 bsr-03.txt, February 2003. [CGMP] Cisco, "Cisco Group Management Protocol", e.g. http://www.cisco.com/en/US/tech/tk648/tk363/tk105/ tech_protocol_home.html [GARP] Tobagi, F., et al, "Study of IEEE 802.1p GARP/GMRP Timer Values", (for introduction to GARP/GMRP, see section 2), Sep 1997. [MLDSNOOP] Christensen, M., Solensky, F., "IGMP and MLD snooping switches", work-in-progress, draft-ietf-magma- snoop-10.txt, October 2003. [MULTIGAP] Meyer, D., Nickless, B., "Internet Multicast Gap Analysis [...]", work-in-progress, draft-ietf-mboned-iesg-gap-analysis-00.txt, July 2002. [PIMSO] Bhattacharyya, S. et al, "Deployment of PIM-SO at Sprint (PIM-SO)", work-in-progress, draft-bhattach-diot-pimso-00.txt (expired), March 2000. [SSMSNOOP] Thaler, D., "Operational Problems with IGMP snooping switches", presentation in MAGMA WG at IETF56, http://www.ietf.org/proceedings/03mar/148.htm, March 2003. Author's Address Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can Savola [Expires August 2004] [Page 9] Internet Draft draft-savola-v6ops-multicast-issues-03.txt February 2004 be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Savola [Expires August 2004] [Page 10]