--- 1/draft-ietf-mboned-deprecate-interdomain-asm-05.txt 2020-01-03 12:13:15.520320128 -0800 +++ 2/draft-ietf-mboned-deprecate-interdomain-asm-06.txt 2020-01-03 12:13:15.556321049 -0800 @@ -1,94 +1,86 @@ Mboned M. Abrahamsson -Internet-Draft T-Systems +Internet-Draft Intended status: Best Current Practice T. Chown -Expires: March 7, 2020 Jisc +Expires: July 6, 2020 Jisc L. Giuliano Juniper Networks, Inc. T. Eckert - Huawei - September 4, 2019 + Futurewei Technologies Inc. + January 3, 2020 Deprecating ASM for Interdomain Multicast - draft-ietf-mboned-deprecate-interdomain-asm-05 + draft-ietf-mboned-deprecate-interdomain-asm-06 Abstract This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast - applications and that hosts and routers in these deployments fully - support SSM. The recommendations in this document do not preclude - the continued use of ASM within a single organisation or domain and - are especially easy to adopt in existing intradomain ASM/PIM-SM - deployments. - -Requirements Language and Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in "Key words for use in - RFCs to Indicate Requirement Levels" [RFC2119]. - - The term IP and IP multicast are used to refer to both IPv4 and IPv6. + applications and recommends that hosts and routers in these + deployments fully support SSM. The recommendations in this document + do not preclude the continued use of ASM within a single organisation + or domain and are especially easy to adopt in existing intradomain + ASM/PIM-SM deployments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on March 7, 2020. + + This Internet-Draft will expire on July 6, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Multicast service models . . . . . . . . . . . . . . . . 3 2.2. ASM routing protocols . . . . . . . . . . . . . . . . . . 4 2.2.1. PIM Sparse Mode (PIM-SM) . . . . . . . . . . . . . . 4 - 2.2.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 5 + 2.2.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 4 2.2.3. Bidir-RP . . . . . . . . . . . . . . . . . . . . . . 5 2.3. SSM Routing protocols . . . . . . . . . . . . . . . . . . 5 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Observations on ASM and SSM deployments . . . . . . . . . 5 3.2. Advantages of SSM for interdomain multicast . . . . . . . 6 3.2.1. Reduced network operations complexity . . . . . . . . 7 3.2.2. No network wide IP multicast group-address management 7 3.2.3. Intrinsic source-control security . . . . . . . . . . 7 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Deprecating use of ASM for interdomain multicast . . . . 8 - 4.2. Including network support for IGMPv3 / MLDv2 . . . . . . 8 + 4.2. Including network support for IGMPv3/MLDv2 . . . . . . . 8 4.3. Building application support for SSM . . . . . . . . . . 9 4.4. Developing application guidance: SSM, ASM, service discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Preferring SSM applications intradomain . . . . . . . . . 10 4.6. Documenting an ASM/SSM protocol mapping mechanism . . . . 10 4.7. Not filtering ASM addressing between domains . . . . . . 10 4.8. Not precluding Intradomain ASM . . . . . . . . . . . . . 11 4.9. Evolving PIM deployments for SSM . . . . . . . . . . . . 11 5. Future interdomain ASM work . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 @@ -104,24 +96,25 @@ IP Multicast has been deployed in various forms, within private networks, the wider Internet, and federated networks such as national or regional research networks. While a number of service models have been published, and in many cases revised over time, there has been no strong recommendation made by the IETF on the appropriateness of those models to certain scenarios, even though vendors and federations have often made such recommendations. This document addresses this gap by making a BCP-level recommendation - to deprecate the use of ASM for interdomain multicast, leaving SSM as - the recommended interdomain mode of multicast. This document further - recommends that all hosts and routers which support interdomain - multicast applications fully support SSM. + to deprecate the use of Any-Source Multicast (ASM) for interdomain + multicast, leaving Source-Specific Multicast (SSM) as the recommended + interdomain mode of multicast. This document further recommends that + all hosts and routers which support interdomain multicast + applications fully support SSM. This document does not make any statement on the use of ASM within a single domain or organisation, and therefore does not preclude its use. Indeed, there are application contexts for which ASM is currently still widely considered well-suited within a single domain. The main issue in most cases with moving to SSM is application support. Many applications are initially deployed for intradomain use and are later deployed interdomain. Therefore, this document recommends applications support SSM, even when they are initially @@ -138,23 +131,23 @@ described in [RFC1112], receivers express interest in joining a multicast group address and routers use multicast routing protocols to deliver traffic from the sender(s) to the receivers. If there are multiple senders for a given group, traffic from all senders will be delivered to the receiver. Since receivers specify only the group address, the network, and therefore the multicast routing protocols, are responsible for source discovery. In SSM, by contrast, receivers specify both group and source when expressing interest in joining a multicast stream. Source discovery - in SSM is handled by some out-of-band mechanism (ie, the application - layer), which drastically simplifies the network and how the - multicast routing protocols operate. + in SSM is handled by some out-of-band mechanism (i.e., the + application layer), which drastically simplifies the network and how + the multicast routing protocols operate. IANA has reserved specific ranges of IPv4 and IPv6 address space for multicast addressing. Guidelines for IPv4 multicast address assignments can be found in [RFC5771], while guidelines for IPv6 multicast address assignments can be found in [RFC2375] and [RFC3307]. The IPv6 multicast address format is described in [RFC4291]. 2.2. ASM routing protocols @@ -217,37 +210,38 @@ PIM-SSM expects that the sender's source address(es) is known in advance by receivers through some out-of-band mechanism (typically in the application layer), and thus the receiver's designated router can send a PIM JOIN directly towards the source without needing to use an RP. IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and - protocols. See [RFC4607]. For IPv6, the address prefix FF3x::/32 is + protocols. See [RFC4607]. For IPv6, the address prefix ff3x::/32 is reserved for source-specific multicast use. 3. Discussion 3.1. Observations on ASM and SSM deployments In enterprise and campus scenarios, ASM in the form of PIM-SM is likely the most commonly deployed multicast protocol. The configuration and management of an RP (including RP redundancy) within a single domain is a well understood operational practice. However, if interworking with external PIM domains is needed in IPv4 multicast deployments, interdomain MSDP is required to exchange information about sources between domain RPs. Deployment experience has shown MSDP to be a complex and fragile protocol to manage and - troubleshoot. Some of these issues include complex flooding RPF - rules, state attack protection, and filtering of undesired sources. + troubleshoot. Some of these issues include complex flooding Reverse + Path Forwarding (RPF) rules, state attack protection, and filtering + of undesired sources. PIM-SM is a general purpose protocol that can handle all use cases. In particular, it was designed for cases such as videoconferencing where multiple sources may come and go during a multicast session. But for cases where a single, persistent source for a group is used, and receivers can be configured to know of that source, PIM-SM has unnecessary complexity. Therefore, SSM removes the need for many of the most complex components of PIM-SM. As explained above, MSDP was not extended to support IPv6. Instead, @@ -265,82 +259,84 @@ As stated in RFC 4607, SSM is particularly well-suited to dissemination-style applications with one or more senders whose identities are known (by some out-of-band mechanism) before the application starts running or applications that utilize some signaling to indicate the source address of the multicast stream (e.g., electronic programming guide in IPTV applications). PIM-SSM is therefore very well-suited to applications such as classic linear broadcast TV over IP. SSM requires applications, host operating systems and the designated - routers connected to receiving hosts to support IGMPv3 [RFC3376] and - MLDv2 [RFC3810]. Support for IGMPv3 and MLDv2 has become widespread - in common OSes for several years (Windows, MacOS, Linux/Android) and - is no longer an impediment to SSM deployment. + routers connected to receiving hosts to support Internet Group + Management Protocol, Version 3 (IGMPv3) [RFC3376] and Multicast + Listener Discovery, Version 2 (MLDv2) [RFC3810]. While support for + IGMPv3 and MLDv2 has been commonplace in routing platforms for a long + time, it has also now become widespread in common operating systems + for several years (Windows, MacOS, Linux/Android) and is no longer an + impediment to SSM deployment. 3.2. Advantages of SSM for interdomain multicast This section describes the three key benefits that SSM with PIM-SSM has over ASM. These benefits also apply to intradomain deployment but are even more important in interdomain deployments. See [RFC4607] for more details. 3.2.1. Reduced network operations complexity A significant benefit of SSM is the reduced complexity that comes through eliminating the network-based source discovery required in ASM with PIM-SM. Specifically, SSM eliminates the need for RPs, shared trees, Shortest Path Tree (SPT) switchovers, PIM registers, MSDP, dynamic RP discovery mechanisms (BSR/AutoRP) and data-driven state creation. SSM simply utilizes a small subset of PIM-SM, - alongside the integration with IGMPv3 / MLDv2, where the source - address signaled from the receiver is immediately used to create - (S,G) state. Eliminating network-based source discovery for - interdomain multicast means the vast majority of the complexity of - multicast goes away. + alongside the integration with IGMPv3/MLDv2, where the source address + signaled from the receiver is immediately used to create (S,G) state. + Eliminating network-based source discovery for interdomain multicast + means the vast majority of the complexity of multicast goes away. This reduced complexity makes SSM radically simpler to manage, troubleshoot and operate, particularly for backbone network operators. This is the main operator motivation for the recommendation to deprecate the use of ASM in interdomain scenarios. Note that this discussion does not apply to Bidir-PIM, and there is (as mentioned above) no standardized interdomain solution for Bidir- PIM. In Bidir-PIM, traffic is forwarded to the RP instead of building state as in PIM-SM. This occurs even in the absence of receivers. Bidir-PIM therefore trades state complexity with unnecessary traffic (potentially a large amount). 3.2.2. No network wide IP multicast group-address management In ASM, IP multicast group addresses need to be assigned to applications and instances thereof, so that two simultaneously active application instances will not share the same group address and - receive each others IP multicast traffic. + receive IP multicast traffic from each other. In SSM, no such IP multicast group management is necessary. Instead, the IP multicast group address simply needs to be assigned locally on a source like a unicast transport protocol port number: the only coordination required is to ensure that different applications running on the same host don't send to the same group address. This does not require any network operator involvement. 3.2.3. Intrinsic source-control security SSM is implicitly secure against off-path unauthorized/undesired sources. Receivers only receive packets from the sources they - explicitly specify in their IGMP/MLD membership messages, as opposed - to ASM where any host can send traffic to a group address and have it - transmitted to all receivers. With PIM-SSM, traffic from sources not - requested by any receiver will be discarded by the first-hop router - (FHR) of that source, minimizing source attacks against shared - network bandwidth and receivers. + explicitly specify in their IGMPv3/MLDv2 membership messages, as + opposed to ASM where any host can send traffic to a group address and + have it transmitted to all receivers. With PIM-SSM, traffic from + sources not requested by any receiver will be discarded by the first- + hop router (FHR) of that source, minimizing source attacks against + shared network bandwidth and receivers. This benefit is particularily important in interdomain deployments because there are no standardized solutions for ASM control of sources and the most common intradomain operational practices such as Access Control Lists (ACL) on the sender's FHR are not feasible for interdomain deployments. This topic is expanded upon in [RFC4609]. 4. Recommendations @@ -354,35 +350,35 @@ interdomain multicast using SSM are documented in [RFC8313]. The recommendation applies to the use of ASM between domains where either MSDP (IPv4) or Embedded-RP (IPv6) is used. An interdomain use of ASM multicast in the context of this document is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers operated by two or more separate administrative entities. The more inclusive interpretation of this recommendation is that it - also extends to the case where PIM may only be operated in a single - operator domain, but where user hosts or non-PIM network edge devices - are under different operator control. A typical example of this case - is a service provider offering IPTV (single operator domain for PIM) - to subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 - hosts (computer, tablets, set-top boxes). + also extends to deprecating use of ASM in the case where PIM is + operated in a single operator domain, but where user hosts or non-PIM + network edge devices are under different operator control. A typical + example of this case is a service provider offering IPTV (single + operator domain for PIM) to subscribers operating an IGMP proxy home + gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-top boxes). 4.2. Including network support for IGMPv3 / MLDv2 This document recommends that all hosts, router platforms and security appliances used for deploying multicast support the components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to support SSM (i.e., explicitly sending source-specific reports). The updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states - that MLDv2 support is a MUST in all implementations. Such support is + that MLDv2 must be supported in all implementations. Such support is already widespread in common host and router platforms. Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. Multicast snooping is often used to limit the flooding of multicast traffic in a layer 2 network. With snooping, a L2 switch will monitor IGMP/MLD messages and only forward multicast traffic out on host ports that have interested receivers connected. Such snooping capability should therefore support IGMPv3 and MLDv2. There is further discussion in [RFC4541]. @@ -407,28 +403,28 @@ layer in this case. Just like in an application that uses unicast as the underlying transport, this functionality can be implemented by the application or by an application-layer library." Some useful considerations for multicast applications can be found in [RFC3170]. 4.4. Developing application guidance: SSM, ASM, service discovery Applications with many-to-many communication patterns can create more - (S,G) state than feasible for networks, whether the source discovery - is done by ASM with PIM-SM or at the application level and SSM/PIM- - SM. These applications are not best supported by either SSM/PIM-SSM - or ASM/PIM-SM. + (S,G) state than is feasible for networks to manage, whether the + source discovery is done by ASM with PIM-SM or at the application + level and SSM/PIM-SM. These applications are not best supported by + either SSM/PIM-SSM or ASM/PIM-SM. Instead, these applications are better served by routing protocols that do not create (S,G), such as Bidir-PIM. Unfortunately, today - many applications simply use ASM for service discovery. One example + many applications use ASM solely for service discovery. One example is where clients send IP multicast packets to elicit unicast replies from server(s). Deploying any form of IP multicast solely in support of such service discovery is in general not recommended. Dedicated service discovery via DNS-SD [RFC6763] should be used for this instead. While the WG discussions had consensus that best practices should be developed to explain when to use SSM in applications, e.g, when ASM without (S,G) state in the network is better, or when dedicated service-discovery mechanisms should be used, it was agreed that @@ -480,21 +476,21 @@ 4.8. Not precluding Intradomain ASM The use of ASM within a single multicast domain such as a campus or enterprise is still relatively common today. There are even global enterprise networks that have successfully been using PIM-SM for many years. The operators of such networks most often use Anycast-RP [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of the extra operational complexity. These existing practices are unaffected by this document. - In the past decade, Bidir-PIM too has seen deployments to scale + In the past decade, some Bidir-PIM deployments have scaled interdomain ASM deployments beyond the capabilities of PIM-SM. This too is unaffected by this document, instead it is encouraged where necessary due to application requirements (see Section 4.4). This document also does not preclude continued use of ASM with multiple PIM-SM domains inside organisations, such as with IPv4 MSDP or IPv6 Embedded-RP. This includes organizations that are federations and have appropriate, non-standardized mechanisms to deal with the interdomain ASM issues explained in Section 3.2. @@ -590,25 +586,20 @@ interdomain-asm for work leading to this document. 10. References 10.1. Normative References [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, . - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, . [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, . [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener @@ -638,20 +629,26 @@ IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, . [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . + [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., + Ed., and R. Krishnan, "Use of Multicast across Inter- + domain Peering Points", BCP 213, RFC 8313, + DOI 10.17487/RFC8313, January 2018, + . + 10.2. Informative References [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, . [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, September 2001, . @@ -689,39 +686,33 @@ [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . - [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., - Ed., and R. Krishnan, "Use of Multicast across Inter- - domain Peering Points", BCP 213, RFC 8313, - DOI 10.17487/RFC8313, January 2018, - . - [I-D.ietf-6man-rfc6434-bis] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", draft-ietf-6man-rfc6434-bis-09 (work in progress), July 2018. Authors' Addresses Mikael Abrahamsson - T-Systems + Stockholm Sweden - Email: mikael.abrahamsson@t-systems.se + Email: swmike@swm.pp.se Tim Chown Jisc Lumen House, Library Avenue Harwell Oxford, Didcot OX11 0SG United Kingdom Email: tim.chown@jisc.ac.uk Lenny Giuliano Juniper Networks, Inc.