idnits 2.17.1 draft-ietf-mboned-deprecate-interdomain-asm-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1060 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned M. Abrahamsson 3 Internet-Draft 4 Intended status: Best Current Practice T. Chown 5 Expires: September 10, 2020 Jisc 6 L. Giuliano 7 Juniper Networks, Inc. 8 T. Eckert 9 Futurewei Technologies Inc. 10 March 9, 2020 12 Deprecating ASM for Interdomain Multicast 13 draft-ietf-mboned-deprecate-interdomain-asm-07 15 Abstract 17 This document recommends deprecation of the use of Any-Source 18 Multicast (ASM) for interdomain multicast. It recommends the use of 19 Source-Specific Multicast (SSM) for interdomain multicast 20 applications and recommends that hosts and routers in these 21 deployments fully support SSM. The recommendations in this document 22 do not preclude the continued use of ASM within a single organisation 23 or domain and are especially easy to adopt in existing intradomain 24 ASM/PIM-SM deployments. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 10, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Multicast service models . . . . . . . . . . . . . . . . 3 63 2.2. ASM routing protocols . . . . . . . . . . . . . . . . . . 4 64 2.2.1. PIM Sparse Mode (PIM-SM) . . . . . . . . . . . . . . 4 65 2.2.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 4 66 2.2.3. Bidir-RP . . . . . . . . . . . . . . . . . . . . . . 5 67 2.3. SSM Routing protocols . . . . . . . . . . . . . . . . . . 5 68 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Observations on ASM and SSM deployments . . . . . . . . . 5 70 3.2. Advantages of SSM for interdomain multicast . . . . . . . 6 71 3.2.1. Reduced network operations complexity . . . . . . . . 7 72 3.2.2. No network-wide IP multicast group-address management 7 73 3.2.3. Intrinsic source-control security . . . . . . . . . . 7 74 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Deprecating use of ASM for interdomain multicast . . . . 8 76 4.2. Including network support for IGMPv3/MLDv2 . . . . . . . 9 77 4.3. Building application support for SSM . . . . . . . . . . 9 78 4.4. Developing application guidance: SSM, ASM, service 79 discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.5. Preferring SSM applications intradomain . . . . . . . . . 10 81 4.6. Documenting an ASM/SSM protocol mapping mechanism . . . . 10 82 4.7. Not filtering ASM addressing between domains . . . . . . 11 83 4.8. Not precluding Intradomain ASM . . . . . . . . . . . . . 11 84 4.9. Evolving PIM deployments for SSM . . . . . . . . . . . . 11 85 5. Future interdomain ASM work . . . . . . . . . . . . . . . . . 12 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 89 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 92 10.2. Informative References . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 IP Multicast has been deployed in various forms, within private 98 networks, the wider Internet, and federated networks such as national 99 or regional research networks. While a number of service models have 100 been published, and in many cases revised over time, there has been 101 no strong recommendation made by the IETF on the appropriateness of 102 those models to certain scenarios, even though vendors and 103 federations have often made such recommendations. 105 This document addresses this gap by making a BCP-level recommendation 106 to deprecate the use of Any-Source Multicast (ASM) for interdomain 107 multicast, leaving Source-Specific Multicast (SSM) as the recommended 108 interdomain mode of multicast. This document further recommends that 109 all hosts and routers which support interdomain multicast 110 applications fully support SSM. 112 This document does not make any statement on the use of ASM within a 113 single domain or organisation, and therefore does not preclude its 114 use. Indeed, there are application contexts for which ASM is 115 currently still widely considered well-suited within a single domain. 117 The main issue in most cases with moving to SSM is application 118 support. Many applications are initially deployed for intradomain 119 use and are later deployed interdomain. Therefore, this document 120 recommends applications support SSM, even when they are initially 121 intended for intradomain use. As explained below, SSM applications 122 are readily compatible with existing intradomain ASM deployments as 123 SSM is merely a subset of ASM. 125 2. Background 127 2.1. Multicast service models 129 Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are 130 the two multicast service models in use today. In ASM, as originally 131 described in [RFC1112], receivers express interest in joining a 132 multicast group address and routers use multicast routing protocols 133 to deliver traffic from the sender(s) to the receivers. If there are 134 multiple senders for a given group, traffic from all senders will be 135 delivered to the receivers. Since receivers specify only the group 136 address, the network, and therefore the multicast routing protocols, 137 are responsible for source discovery. 139 In SSM, by contrast, receivers specify both group and source when 140 expressing interest in joining a multicast stream. Source discovery 141 in SSM is handled by some out-of-band mechanism in the application 142 layer, which drastically simplifies the network and how the multicast 143 routing protocols operate. 145 IANA has reserved specific ranges of IPv4 and IPv6 address space for 146 multicast addressing. Guidelines for IPv4 multicast address 147 assignments can be found in [RFC5771], while guidelines for IPv6 148 multicast address assignments can be found in [RFC2375] and 149 [RFC3307]. The IPv6 multicast address format is described in 150 [RFC4291]. 152 2.2. ASM routing protocols 154 2.2.1. PIM Sparse Mode (PIM-SM) 156 The most commonly deployed ASM routing protocol is Protocol 157 Independent Multicast - Sparse Mode (PIM-SM), as detailed in 158 [RFC7761]. PIM-SM, as the name suggests, was designed to be used in 159 scenarios where the subnets with receivers are sparsely distributed 160 throughout the network. Because receivers do not indicate sender 161 addresses in ASM (but only group addresses), PIM-SM uses the concept 162 of a Rendezvous Point (RP) as a 'meeting point' for sources and 163 receivers, and all routers in a PIM-SM domain are configured to use 164 specific RP(s), either explicitly or through dynamic RP discovery 165 protocols. 167 To enable PIM-SM to work between multiple domains, an interdomain, 168 inter-RP signalling protocol known as Multicast Source Discovery 169 Protocol (MSDP) [RFC3618] is used to allow an RP in one domain to 170 learn the existence of a source in another domain. Deployment 171 scenarios for MSDP are given in [RFC4611]. MSDP floods information 172 about all active sources for all multicast streams to all RPs in all 173 the domains - even if there is no receiver for a given application in 174 a domain. As a result of this key scalability and security issue, 175 along with other deployment challenges with the protocol, MSDP was 176 never extended to support IPv6 and remains an Experimental protocol. 178 At the time of writing, there is no IETF Proposed Standard level 179 interdomain solution for IPv4 ASM multicast because MSDP was the de 180 facto mechanism for the interdomain source discovery problem, and it 181 is Experimental. Other protocol options were investigated at the 182 same time but were never implemented or deployed and are now historic 183 (e.g: [RFC3913]). 185 2.2.2. Embedded-RP 187 Due to the availability of more bits in an IPv6 address than in IPv4, 188 an IPv6-specific mechanism was designed in support of interdomain ASM 189 with PIM-SM leveraging those bits. Embedded-RP [RFC3956] allows 190 routers supporting the protocol to determine the RP for the group 191 without any prior configuration or discovery protocols, simply by 192 observing the unicast RP address that is embedded (included) in the 193 IPv6 multicast group address. Embedded-RP allows PIM-SM operation 194 across any IPv6 network in which there is an end-to-end path of 195 routers supporting this mechanism, including interdomain deployment. 197 2.2.3. Bidir-RP 199 Bidir-PIM [RFC5015] is another protocol to support ASM. There is no 200 standardized option to operate Bidir-PIM interdomain. It is deployed 201 intradomain for applications where many sources send traffic to the 202 same IP multicast groups because unlike PIM-SM it does not create 203 per-source state. Bidir-PIM is one of the important reasons for this 204 document to not deprecate intradomain ASM. 206 2.3. SSM Routing protocols 208 SSM is detailed in [RFC4607]. It mandates the use of PIM-SSM for 209 routing of SSM. PIM-SSM is merely a subset of PIM-SM ([RFC7761]). 211 PIM-SSM expects the sender's source address(es) to be known in 212 advance by receivers through some out-of-band mechanism (typically in 213 the application layer), and thus the receiver's designated router can 214 send a PIM JOIN directly towards the source without needing to use an 215 RP. 217 IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 218 designated as source-specific multicast (SSM) destination addresses 219 and are reserved for use by source-specific applications and 220 protocols. See [RFC4607]. For IPv6, the address prefix ff3x::/32 is 221 reserved for source-specific multicast use. 223 3. Discussion 225 3.1. Observations on ASM and SSM deployments 227 In enterprise and campus scenarios, ASM in the form of PIM-SM is 228 likely the most commonly deployed multicast protocol. The 229 configuration and management of an RP (including RP redundancy) 230 within a single domain is a well understood operational practice. 231 However, if interworking with external PIM domains is needed in IPv4 232 multicast deployments, interdomain MSDP is required to exchange 233 information about sources between domain RPs. Deployment experience 234 has shown MSDP to be a complex and fragile protocol to manage and 235 troubleshoot. Some of these issues include complex Reverse Path 236 Forwarding (RPF) rules, state attack protection, and filtering of 237 undesired sources. 239 PIM-SM is a general purpose protocol that can handle all use cases. 240 In particular, it was designed for cases such as videoconferencing 241 where multiple sources may come and go during a multicast session. 242 But for cases where a single, persistent source for a group is used, 243 and receivers can be configured to know of that source, PIM-SM has 244 unnecessary complexity. Therefore, SSM removes the need for many of 245 the most complex components of PIM-SM. 247 As explained above, MSDP was not extended to support IPv6. Instead, 248 the proposed interdomain ASM solution for PIM-SM with IPv6 is 249 Embedded-RP, which allows the RP address for a multicast group to be 250 embedded in the group address, making RP discovery automatic for all 251 routers on the path between a receiver and a sender. Embedded-RP can 252 support lightweight ad-hoc deployments. However, it relies on a 253 single RP for an entire group that could only be made resilient 254 within one domain. While this approach solves the MSDP issues, it 255 does not solve the problem of unauthorised sources sending traffic to 256 ASM multicast groups; this security issue is one of biggest problems 257 of interdomain multicast. 259 As stated in RFC 4607, SSM is particularly well-suited to 260 dissemination-style applications with one or more senders whose 261 identities are known (by some out-of-band mechanism) before the 262 application starts running or applications that utilize some 263 signaling to indicate the source address of the multicast stream 264 (e.g., electronic programming guide in IPTV applications). PIM-SSM 265 is therefore very well-suited to applications such as classic linear 266 broadcast TV over IP. 268 SSM requires applications, host operating systems and the designated 269 routers connected to receiving hosts to support Internet Group 270 Management Protocol, Version 3 (IGMPv3) [RFC3376] and Multicast 271 Listener Discovery, Version 2 (MLDv2) [RFC3810]. While support for 272 IGMPv3 and MLDv2 has been commonplace in routing platforms for a long 273 time, it has also now become widespread in common operating systems 274 for several years (Windows, MacOS, Linux/Android) and is no longer an 275 impediment to SSM deployment. 277 3.2. Advantages of SSM for interdomain multicast 279 This section describes the three key benefits that SSM with PIM-SSM 280 has over ASM. These benefits also apply to intradomain deployment 281 but are even more important in interdomain deployments. See 282 [RFC4607] for more details. 284 3.2.1. Reduced network operations complexity 286 A significant benefit of SSM is the reduced complexity that comes 287 through eliminating the network-based source discovery required in 288 ASM with PIM-SM. Specifically, SSM eliminates the need for RPs, 289 shared trees, Shortest Path Tree (SPT) switchovers, PIM registers, 290 MSDP, dynamic RP discovery mechanisms (BSR/AutoRP) and data-driven 291 state creation. SSM simply utilizes a small subset of PIM-SM, 292 alongside the integration with IGMPv3/MLDv2, where the source address 293 signaled from the receiver is immediately used to create (S,G) state. 294 Eliminating network-based source discovery for interdomain multicast 295 means the vast majority of the complexity of multicast goes away. 297 This reduced complexity makes SSM radically simpler to manage, 298 troubleshoot and operate, particularly for backbone network 299 operators. This is the main operator motivation for the 300 recommendation to deprecate the use of ASM in interdomain scenarios. 302 Note that this discussion does not apply to Bidir-PIM, and there is 303 (as mentioned above) no standardized interdomain solution for Bidir- 304 PIM. In Bidir-PIM, traffic is forwarded to the RP instead of 305 building state as in PIM-SM. This occurs even in the absence of 306 receivers. Bidir-PIM therefore trades state complexity with 307 unnecessary traffic (potentially a large amount). 309 3.2.2. No network-wide IP multicast group-address management 311 In ASM, IP multicast group addresses need to be assigned to 312 applications and instances thereof, so that two simultaneously active 313 application instances will not share the same group address and 314 receive IP multicast traffic from each other. 316 In SSM, no such IP multicast group management is necessary. Instead, 317 the IP multicast group address simply needs to be assigned locally on 318 a source like a unicast transport protocol port number: the only 319 coordination required is to ensure that different applications 320 running on the same host don't send to the same group address. This 321 does not require any network operator involvement. 323 3.2.3. Intrinsic source-control security 325 SSM is implicitly secure against off-path unauthorized/undesired 326 sources. Receivers only receive packets from the sources they 327 explicitly specify in their IGMPv3/MLDv2 membership messages, as 328 opposed to ASM where any host can send traffic to a group address and 329 have it transmitted to all receivers. With PIM-SSM, traffic from 330 sources not requested by any receiver will be discarded by the first- 331 hop router (FHR) of that source, minimizing source attacks against 332 shared network bandwidth and receivers. 334 This benefit is particularly important in interdomain deployments 335 because there are no standardized solutions for ASM control of 336 sources and the most common intradomain operational practices such as 337 Access Control Lists (ACL) on the sender's FHR are not feasible for 338 interdomain deployments. 340 This topic is expanded upon in [RFC4609]. 342 4. Recommendations 344 This section provides recommendations for a variety of stakeholders 345 in SSM deployment, including vendors, operators and application 346 developers, and also suggests further work that could be undertaken 347 within the IETF. 349 4.1. Deprecating use of ASM for interdomain multicast 351 This document recommends that the use of ASM be deprecated for 352 interdomain multicast, and thus implicitly, that hosts and routers 353 that support such interdomain applications fully support SSM and its 354 associated protocols. Best current practices for deploying 355 interdomain multicast using SSM are documented in [RFC8313]. 357 The recommendation applies to the use of ASM between domains where 358 either MSDP (IPv4) or Embedded-RP (IPv6) is used. 360 An interdomain use of ASM multicast in the context of this document 361 is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers 362 operated by two or more separate administrative entities. 364 The focus of this document is deprecation of inter-domain ASM 365 multicast, and while encouraging the use of SSM within domains, it 366 leaves operators free to choose to use ASM within their own domains. 367 A more inclusive interpretation of this recommendation is that it 368 also extends to deprecating use of ASM in the case where PIM is 369 operated in a single operator domain, but where user hosts or non-PIM 370 network edge devices are under different operator control. A typical 371 example of this case is a service provider offering IPTV (single 372 operator domain for PIM) to subscribers operating an IGMP proxy home 373 gateway and IGMPv3/MLDv2 hosts (computer, tablets, set-top boxes). 375 4.2. Including network support for IGMPv3/MLDv2 377 This document recommends that all hosts, router platforms and 378 security appliances used for deploying multicast support the 379 components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to 380 support SSM (i.e., explicitly sending source-specific reports). The 381 updated IPv6 Node Requirements RFC [RFC8504] states that MLDv2 must 382 be supported in all implementations. Such support is already 383 widespread in common host and router platforms. 385 Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. 387 Multicast snooping is often used to limit the flooding of multicast 388 traffic in a layer 2 network. With snooping, a L2 switch will 389 monitor IGMP/MLD messages and only forward multicast traffic out on 390 host ports that have interested receivers connected. Such snooping 391 capability should therefore support IGMPv3 and MLDv2. There is 392 further discussion in [RFC4541]. 394 4.3. Building application support for SSM 396 The recommendation to use SSM for interdomain multicast means that 397 applications should properly trigger the sending of IGMPv3/MLDv2 398 source-specific report messages. It should be noted, however, there 399 is a wide range of applications today that only support ASM. In many 400 cases this is due to application developers being unaware of the 401 operational concerns of networks, and the implications of using ASM 402 versus using SSM. This document serves to provide clear direction 403 for application developers who might currently only consider using 404 ASM to instead support SSM, which only requires relatively minor 405 changes for many applications, particularly those with single 406 sources. 408 It is often thought that ASM is required for multicast applications 409 where there are multiple sources. However, RFC 4607 also describes 410 how SSM can be used instead of PIM-SM for multi-party applications: 412 "SSM can be used to build multi-source applications where all 413 participants' identities are not known in advance, but the multi- 414 source "rendezvous" functionality does not occur in the network 415 layer in this case. Just like in an application that uses unicast 416 as the underlying transport, this functionality can be implemented 417 by the application or by an application-layer library." 419 Some useful considerations for multicast applications can be found in 420 [RFC3170]. 422 4.4. Developing application guidance: SSM, ASM, service discovery 424 Applications with many-to-many communication patterns can create more 425 (S,G) state than is feasible for networks to manage, whether the 426 source discovery is done by ASM with PIM-SM or at the application 427 level and SSM/PIM-SM. These applications are not best supported by 428 either SSM/PIM-SSM or ASM/PIM-SM. 430 Instead, these applications are better served by routing protocols 431 that do not create (S,G), such as Bidir-PIM. Unfortunately, today 432 many applications use ASM solely for service discovery. One example 433 is where clients send IP multicast packets to elicit unicast replies 434 from server(s). Deploying any form of IP multicast solely in support 435 of such service discovery is in general not recommended. Dedicated 436 service discovery via DNS-SD [RFC6763] should be used for this 437 instead. 439 This document describes best practices to explain when to use SSM in 440 applications, e.g, when ASM without (S,G) state in the network is 441 better, or when dedicated service-discovery mechanisms should be 442 used, but specifying these practices is outside the scope of this 443 document. Further work on this subject may be expected within the 444 IETF. 446 4.5. Preferring SSM applications intradomain 448 If feasible, it is recommended for applications to use SSM even if 449 they are initially only meant to be used in intradomain environments 450 supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing 451 intradomain PIM-SM networks are automatically compatible with SSM 452 applications. Thus, SSM applications can operate alongside existing 453 ASM applications. SSM's benefits of simplified address management 454 and significantly reduced operational complexity apply equally to 455 intradomain use. 457 However, for some applications it may be prohibitively difficult to 458 add support for source discovery, so intradomain ASM may still be 459 appropriate. 461 4.6. Documenting an ASM/SSM protocol mapping mechanism 463 In the case of existing ASM applications that cannot readily be 464 ported to SSM, it may be possible to use some form of protocol 465 mapping, i.e., to have a mechanism to translate a (*,G) join or leave 466 to a (S,G) join or leave for a specific source S. The general 467 challenge in performing such mapping is determining where the 468 configured source address, S, comes from. 470 There are existing vendor-specific mechanisms deployed that achieve 471 this function, but none are documented in IETF documents. This may 472 be a useful area for the IETF to work on as an interim transition 473 mechanism. However, these mechanisms would introduce additional 474 administrative burdens, along with the need for some form of address 475 management, neither of which are required in SSM. Hence, this should 476 not be considered a long-term solution. 478 4.7. Not filtering ASM addressing between domains 480 A key benefit of SSM is that the receiver specifies the source-group 481 tuple when signaling interest in a multicast stream. Hence, the 482 group address need not be globally unique, so there is no need for 483 multicast address allocation as long the reserved SSM range is used. 485 Despite the deprecation of interdomain ASM, it is recommended that 486 operators should not filter ASM group ranges at domain boundaries, as 487 some form of ASM-SSM mappings may continue to be used for some time. 489 4.8. Not precluding Intradomain ASM 491 The use of ASM within a single multicast domain such as a campus or 492 enterprise is still relatively common today. There are even global 493 enterprise networks that have successfully been using PIM-SM for many 494 years. The operators of such networks most often use Anycast-RP 495 [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of 496 the extra operational complexity. These existing practices are 497 unaffected by this document. 499 In the past decade, some Bidir-PIM deployments have scaled 500 interdomain ASM deployments beyond the capabilities of PIM-SM. This 501 too is unaffected by this document, instead it is encouraged where 502 necessary due to application requirements (see Section 4.4). 504 This document also does not preclude continued use of ASM with 505 multiple PIM-SM domains inside organisations, such as with IPv4 MSDP 506 or IPv6 Embedded-RP. This includes organizations that are 507 federations and have appropriate, non-standardized mechanisms to deal 508 with the interdomain ASM issues explained in Section 3.2. 510 4.9. Evolving PIM deployments for SSM 512 Existing PIM-SM deployments can usually be used to run SSM 513 applications with little to no changes. In some widely available 514 router implementations of PIM-SM, PIM-SSM is simply enabled by 515 default in the designated SSM address spaces whenever PIM-SM is 516 enabled. In other implementations, simple configuration options 517 exist to enable it. This allows migration of ASM applications to 518 SSM/PIM-SSM solely through application-side development to handle 519 source-signaling via IGMPv3/MLDv2 and using SSM addresses. No 520 network actions are required for this transition; unchanged ASM 521 applications can continue to co-exist without issues. 523 When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also 524 result in the desired PIM-SSM (S,G) operations and bypass any RP 525 procedures. This is not standardized but depends on implementation 526 and may require additional configuration in available products. In 527 general, it is recommended to always use SSM address space for SSM 528 applications. For example, the interaction of IGMPv3/MLDv2 (S,G) 529 membership reports and Bidir-PIM is undefined and may not result in 530 forwarding of any traffic. 532 Note that these migration recommendations do not include 533 considerations on when or how to evolve those intradomain 534 applications best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM. 535 This may also be important but is outside the scope of this document. 537 5. Future interdomain ASM work 539 Future work may attempt to overcome current limitations of ASM 540 solutions, such as interdomain deployment solutions for Bidir-PIM, or 541 source access control mechanisms for IPv6 PIM-SM with embedded-RP. 542 Such work could modify or amend the recommendations of this document 543 (like any future IETF standards/BCP work). 545 Nevertheless, it is very unlikely that any ASM solution, even with 546 such future work, can ever provide the same intrinsic security and 547 network and address management simplicity as SSM (see Section 3.2). 548 Accordingly, this document recommends that future work for general- 549 purpose interdomain IP multicast focus on SSM items listed in 550 Section 4. 552 6. Security Considerations 554 This document adds no new security considerations. It instead 555 removes security issues incurred by interdomain ASM with PIM-SM/MSDP 556 such as infrastructure control plane attacks and application and 557 bandwidth/congestion attacks from unauthorised sources sending to ASM 558 multicast groups. RFC 4609 describes the additional security 559 benefits of using SSM instead of ASM. 561 7. IANA Considerations 563 This document makes no request of IANA. 565 Note to RFC Editor: this section may be removed upon publication as 566 an RFC. 568 8. Acknowledgments 570 The authors would like to thank members of the IETF mboned WG for 571 discussions on the content of this document, with specific thanks to 572 the following people for their contributions to the document: Hitoshi 573 Asaeda, Dale Carder, Jake Holland, Albert Manfredi, Mike McBride, Per 574 Nihlen, Greg Shepherd, James Stevens, Stig Venaas, Nils Warnke, and 575 Sandy Zhang. 577 9. Changelog 579 [RFC-Editor: Please remove this section.] 581 02 - Toerless: Attempt to document the issues brought up on the list 582 and discussion by James Stevens re. use of Bidir-PIM intradomain and 583 IGMP/MLD interop issues. 585 - NOTE: Text was not vetted by co-authors, so rev'ed just as 586 discussion basis. 588 - more subsection to highlight content. Added more detailled 589 discussion about downsides of ASM wrt. address management and 590 intrinsic source-control in SSM. Added recommendation to work on 591 guidance when apps are best suited for SSM vs. ASM/Bidir vs. service 592 discovery. Added recommendation how to evolve from PIM-SM to SSM in 593 existing deployments. Added section on possible future interdomain 594 ASM work (and why not to focus on it). 596 01 - Lenny: cleanup of text version, removed redundancies. 598 00 - initial IETF WG version. See draft-acg-mboned-deprecate- 599 interdomain-asm for work leading to this document. 601 10. References 603 10.1. Normative References 605 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 606 RFC 1112, DOI 10.17487/RFC1112, August 1989, 607 . 609 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 610 Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, 611 . 613 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 614 Thyagarajan, "Internet Group Management Protocol, Version 615 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 616 . 618 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 619 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 620 DOI 10.17487/RFC3810, June 2004, 621 . 623 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 624 Point (RP) Address in an IPv6 Multicast Address", 625 RFC 3956, DOI 10.17487/RFC3956, November 2004, 626 . 628 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 629 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 630 2006, . 632 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 633 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 634 . 636 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 637 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 638 DOI 10.17487/RFC5771, March 2010, 639 . 641 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 642 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 643 Multicast - Sparse Mode (PIM-SM): Protocol Specification 644 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 645 2016, . 647 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 648 Ed., and R. Krishnan, "Use of Multicast across Inter- 649 domain Peering Points", BCP 213, RFC 8313, 650 DOI 10.17487/RFC8313, January 2018, 651 . 653 10.2. Informative References 655 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 656 Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, 657 . 659 [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: 660 Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, 661 September 2001, . 663 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 664 Discovery Protocol (MSDP)", RFC 3618, 665 DOI 10.17487/RFC3618, October 2003, 666 . 668 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 669 Protocol Specification", RFC 3913, DOI 10.17487/RFC3913, 670 September 2004, . 672 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 673 "Considerations for Internet Group Management Protocol 674 (IGMP) and Multicast Listener Discovery (MLD) Snooping 675 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 676 . 678 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 679 Group Management Protocol Version 3 (IGMPv3) and Multicast 680 Listener Discovery Protocol Version 2 (MLDv2) for Source- 681 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 682 August 2006, . 684 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 685 Independent Multicast - Sparse Mode (PIM-SM) Multicast 686 Routing Security Issues and Enhancements", RFC 4609, 687 DOI 10.17487/RFC4609, October 2006, 688 . 690 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 691 Independent Multicast (PIM)", RFC 4610, 692 DOI 10.17487/RFC4610, August 2006, 693 . 695 [RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source 696 Discovery Protocol (MSDP) Deployment Scenarios", BCP 121, 697 RFC 4611, DOI 10.17487/RFC4611, August 2006, 698 . 700 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 701 "Bidirectional Protocol Independent Multicast (BIDIR- 702 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 703 . 705 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 706 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 707 . 709 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 710 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 711 January 2019, . 713 Authors' Addresses 715 Mikael Abrahamsson 717 Stockholm 718 Sweden 720 Email: swmike@swm.pp.se 722 Tim Chown 723 Jisc 724 Lumen House, Library Avenue 725 Harwell Oxford, Didcot OX11 0SG 726 United Kingdom 728 Email: tim.chown@jisc.ac.uk 730 Lenny Giuliano 731 Juniper Networks, Inc. 732 2251 Corporate Park Drive 733 Herndon, Virginia 20171 734 United States 736 Email: lenny@juniper.net 738 Toerless Eckert 739 Futurewei Technologies Inc. 740 2330 Central Expy 741 Santa Clara 95050 742 USA 744 Email: tte+ietf@cs.fau.de