idnits 2.17.1 draft-ietf-mboned-deprecate-interdomain-asm-03.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 (February 11, 2019) is 1898 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) == Unused Reference: 'RFC2730' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC2776' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC2909' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC3569' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC8085' is defined on line 721, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned M. Abrahamsson 3 Internet-Draft T-Systems 4 Intended status: Best Current Practice T. Chown 5 Expires: August 15, 2019 Jisc 6 L. Giuliano 7 Juniper Networks, Inc. 8 T. Eckert 9 Huawei 10 February 11, 2019 12 Deprecating ASM for Interdomain Multicast 13 draft-ietf-mboned-deprecate-interdomain-asm-03 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 that hosts and routers in these deployments fully 21 support SSM. The recommendations in this document do not preclude 22 the continued use of ASM within a single organisation or domain and 23 are especially easy to adopt in existing intradomain ASM/PIM-SM 24 deployments. 26 Requirements Language and Terminology 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in "Key words for use in 31 RFCs to Indicate Requirement Levels" [RFC2119]. 33 The term IP and IP multicast are used to refer to both IPv4 and IPv6. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 15, 2019. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.1. Multicast service models . . . . . . . . . . . . . . . . 3 71 2.2. ASM routing protocols . . . . . . . . . . . . . . . . . . 4 72 2.2.1. PIM Sparse Mode (PIM-SM) . . . . . . . . . . . . . . 4 73 2.2.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 5 74 2.2.3. Bidir-RP . . . . . . . . . . . . . . . . . . . . . . 5 75 2.3. SSM Routing protocols . . . . . . . . . . . . . . . . . . 5 76 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.1. Observations on ASM and SSM deployments . . . . . . . . . 5 78 3.2. Advantages of SSM for interdomain multicast . . . . . . . 6 79 3.2.1. Reduced network operations complexity . . . . . . . . 7 80 3.2.2. No network wide IP multicast group-address management 7 81 3.2.3. Intrinsic source-control security . . . . . . . . . . 7 82 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 83 4.1. Deprecating use of ASM for interdomain multicast . . . . 8 84 4.2. Including network support for IGMPv3 / MLDv2 . . . . . . 8 85 4.3. Building application support for SSM . . . . . . . . . . 9 86 4.4. Developing application guidance: SSM, ASM, service 87 discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 88 4.5. Preferring SSM applications intradomain . . . . . . . . . 10 89 4.6. Documenting an ASM/SSM protocol mapping mechanism . . . . 10 90 4.7. Not filtering ASM addressing between domains . . . . . . 10 91 4.8. Not precluding Intradomain ASM . . . . . . . . . . . . . 11 92 4.9. Evolving PIM deployments for SSM . . . . . . . . . . . . 11 93 5. Future interdomain ASM work . . . . . . . . . . . . . . . . . 12 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 96 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 97 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 100 10.2. Informative References . . . . . . . . . . . . . . . . . 14 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 103 1. Introduction 105 IP Multicast has been deployed in various forms, within private 106 networks, the wider Internet, and federated networks such as national 107 or regional research networks. While a number of service models have 108 been published, and in many cases revised over time, there has been 109 no strong recommendation made by the IETF on the appropriateness of 110 those models to certain scenarios, even though vendors and 111 federations have often made such recommendations. 113 This document addresses this gap by making a BCP-level recommendation 114 to deprecate the use of ASM for interdomain multicast, leaving SSM as 115 the recommended interdomain mode of multicast. This recommendation 116 thus also implicitly states that all hosts and routers that are 117 expected to support interdomain multicast applications fully support 118 SSM. 120 This document does not make any statement on the use of ASM within a 121 single domain or organisation, and therefore does not preclude its 122 use. Indeed, there are application contexts for which ASM is 123 currently still widely considered well-suited within a single domain. 125 The main issue in most cases with moving to SSM is application 126 support. Many applications are initially deployed for intradomain 127 use and are later deployed interdomain. Therefore, this document 128 recommends applications support SSM, even when they are initially 129 intended for intradomain use. As explained below, SSM applications 130 are readily compatible with existing intradomain ASM deployments as 131 SSM is merely a subset of ASM. 133 2. Background 135 2.1. Multicast service models 137 Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are 138 the two multicast service models in use today. In ASM, as originally 139 described in [RFC1112], receivers express interest in joining a 140 multicast group address and routers use multicast routing protocols 141 to deliver traffic from the sender(s) to the receivers. If there are 142 multiple senders for a given group, traffic from all senders will be 143 delivered to the receiver. Since receivers specify only the group 144 address, the network, and therefore the multicast routing protocols, 145 are responsible for source discovery. 147 In SSM, by contrast, receivers specify both group and source when 148 expressing interest in joining a multicast stream. Source discovery 149 in SSM is handled by some out-of-band mechanism (ie, the application 150 layer), which drastically simplifies the network and how the 151 multicast routing protocols operate. 153 IANA has reserved specific ranges of IPv4 and IPv6 address space for 154 multicast addressing. Guidelines for IPv4 multicast address 155 assignments can be found in [RFC5771], while guidelines for IPv6 156 multicast address assignments can be found in [RFC2375] and 157 [RFC3307]. The IPv6 multicast address format is described in 158 [RFC4291]. 160 2.2. ASM routing protocols 162 2.2.1. PIM Sparse Mode (PIM-SM) 164 The most commonly deployed ASM routing protocol is Protocol 165 Independent Multicast - Sparse Mode (PIM-SM), as detailed in 166 [RFC7761]. PIM-SM, as the name suggests, was designed to be used in 167 scenarios where the subnets with receivers are sparsely distributed 168 throughout the network. Because receivers do not indicate sender 169 addresses in ASM (but only group addresses), PIM-SM uses the concept 170 of a Rendezvous Point (RP) as a 'meeting point' for sources and 171 receivers, and all routers in a PIM-SM domain are configured to use 172 specific RP(s), either explicitly or through dynamic RP discovery 173 protocols. 175 To enable PIM-SM to work between multiple domains, an interdomain, 176 inter-RP signalling protocol known as Multicast Source Discovery 177 Protocol (MSDP) [RFC3618] is used to allow an RP in one domain to 178 learn the existence of a source in another domain. Deployment 179 scenarios for MSDP are given in [RFC4611]. MSDP floods information 180 about all active sources for all multicast streams to all RPs in all 181 the domains - even if there is no receiver for a given application in 182 a domain. As a result of this key scalability and security issue, 183 along with other deployment challenges with the protocol, MSDP was 184 never extended to support IPv6 and remains an Experimental protocol. 186 To this day, there is no IETF Proposed Standard level interdomain 187 solution for IPv4 ASM multicast because MSDP was the "best" component 188 for the interdomain source discovery problem, and it is Experimental. 189 Other protocol options where investigated at the same time but were 190 never implemented or deployed and are now historic (e.g: [RFC3913]). 192 2.2.2. Embedded-RP 194 Due to the availability of more bits in an IPv6 address than in IPv4, 195 an IPv6-specific mechanism was designed in support of interdomain ASM 196 with PIM-SM leveraging those bits. Embedded-RP [RFC3956] allows 197 routers supporting the protocol to determine the RP for the group 198 without any prior configuration or discovery protocols, simply by 199 observing the unicast RP address that is embedded (included) in the 200 IPv6 multicast group address. Embedded-RP allows PIM-SM operation 201 across any IPv6 network in which there is an end-to-end path of 202 routers supporting this mechanism, including interdomain deployment. 204 2.2.3. Bidir-RP 206 Bidir-PIM [RFC5015] is another protocol to support ASM. There is no 207 standardized option to operate Bidir-PIM interdomain. It is deployed 208 intradomain for applications where many sources may want to sent 209 traffic to the same IP multicast groups because unlike PIM-SM it does 210 not create per-source state. Bidir-PIM is one of the important 211 reasons for this document to not deprecate intradomain ASM. 213 2.3. SSM Routing protocols 215 SSM is detailed in [RFC4607]. It mandates the use of PIM-SSM for 216 routing of SSM. PIM-SSM as it merely a subset of PIM-SM ([RFC7761]). 218 PIM-SSM expects that the sender's source address(es) is known in 219 advance by receivers through some out-of-band mechanism (typically in 220 the application layer), and thus the receiver's designated router can 221 send a PIM JOIN directly towards the source without needing to use an 222 RP. 224 IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 225 designated as source-specific multicast (SSM) destination addresses 226 and are reserved for use by source-specific applications and 227 protocols. See [RFC4607]. For IPv6, the address prefix FF3x::/32 is 228 reserved for source-specific multicast use. 230 3. Discussion 232 3.1. Observations on ASM and SSM deployments 234 In enterprise and campus scenarios, ASM in the form of PIM-SM is 235 likely the most commonly deployed multicast protocol. The 236 configuration and management of an RP (including RP redundancy) 237 within a single domain is a well understood operational practice. 238 However, if interworking with external PIM domains is needed in IPv4 239 multicast deployments, interdomain MSDP is required to exchange 240 information about sources between domain RPs. Deployment experience 241 has shown MSDP to be a complex and fragile protocol to manage and 242 troubleshoot (complex flooding RPF rules, state attack protection, 243 filtering of undesired sources, ...). 245 PIM-SM is a general purpose protocol that can handle all use cases. 246 In particular, it was designed for cases such as videoconferencing 247 where multiple sources may come and go during a multicast session. 248 But for cases where a single, persistent source for a group is used, 249 and receivers can be configured to know of that source, PIM-SM has 250 unnecessary complexity. Therefore, SSM removes the need for many of 251 the most complex components of PIM-SM. 253 As explained above, MSDP was not extended to support IPv6. Instead, 254 the proposed interdomain ASM solution for PIM-SM with IPv6 is 255 Embedded-RP, which allows the RP address for a multicast group to be 256 embedded in the group address, making RP discovery automatic for all 257 routers on the path between a receiver and a sender. Embedded-RP can 258 support lightweight ad-hoc deployments. However, it relies on a 259 single RP for an entire group that could only be made resilient 260 within one domain. While this approach solves the MSDP issues, it 261 does not solve the problem of unauthorised sources sending traffic to 262 ASM multicast groups; this security issue is one of biggest problems 263 of interdomain multicast. 265 As stated in RFC 4607, SSM is particularly well-suited to 266 dissemination-style applications with one or more senders whose 267 identities are known (by some out-of-band mechanism) before the 268 application starts running or applications that utilize some 269 signaling to indicate the source address of the multicast stream 270 (e.g., electronic programming guide in IPTV applications). PIM-SSM 271 is therefore very well-suited to applications such as classic linear 272 broadcast TV over IP. 274 SSM requires applications, host operating systems and the designated 275 routers connected to receiving hosts to support IGMPv3 [RFC3376] and 276 MLDv2 [RFC3810]. Support for IGMPv3 and MLDv2 has become widespread 277 in common OSes for several years (Windows, MacOS, Linux/Android) and 278 is no longer an impediment to SSM deployment. 280 3.2. Advantages of SSM for interdomain multicast 282 This section describes the three key benefits that SSM with PIM-SSM 283 has over ASM. These benefits also apply to intradomain deployment 284 but are even more important in interdomain deployments. See 285 [RFC4607] for more details. 287 3.2.1. Reduced network operations complexity 289 A significant benefit of SSM is the reduced complexity that comes 290 through eliminating the network-based source discovery required in 291 ASM with PIM-SM. Specifically, SSM eliminates the need for RPs, 292 shared trees, Shortest Path Tree (SPT) switchovers, PIM registers, 293 MSDP, dynamic RP discovery mechanisms (BSR/AutoRP) and data-driven 294 state creation. SSM simply utilizes a small subset of PIM-SM, 295 alongside the integration with IGMPv3 / MLDv2, where the source 296 address signaled from the receiver is immediately used to create 297 (S,G) state. Eliminating network-based source discovery for 298 interdomain multicast means the vast majority of the complexity of 299 multicast goes away. 301 This reduced complexity makes SSM radically simpler to manage, 302 troubleshoot and operate, particularly for backbone network 303 operators. This is the main operator motivation for the 304 recommendation to deprecate the use of ASM in interdomain scenarios. 306 Note that this discussion does not apply to Bidir-PIM, and there is 307 (as mentioned above) no standardized interdomain solution for Bidir- 308 PIM. In Bidir-PIM, traffic is forwarded to an RPs instead o building 309 state as in PIM-SM. Even in the absence of receivers. Bidir-PIM 310 therefore trades state complexity with (potentially large amounts) of 311 unnecessary traffic. 313 3.2.2. No network wide IP multicast group-address management 315 In ASM, IP multicast group addresses need to be assigned to 316 applications and instances thereof, so that two simultaneously active 317 application instances will not share the same group address and 318 receive each others IP multicast traffic. 320 In SSM, no such IP multicast group management is necessary. Instead, 321 the IP multicast group address simply needs to be assigned locally on 322 a source like a unicast transport protocol port number: No two 323 independent applications on the host must use same IP multicast group 324 number. This does not require any network operator involvement. 326 3.2.3. Intrinsic source-control security 328 SSM is implicitly secure against unauthorized/undesired sources. 329 Receivers only receive packets from the sources they explicitly 330 specify in their IGMP/MLD membership messages, as opposed to ASM 331 where any host can send traffic to a group address and have it 332 transmitted to all receivers. With PIM-SSM, traffic from sources not 333 requested by any receiver will be discarded by the first-hop router 334 (FHR) of that source, minimizing source attacks against shared 335 network bandwidth and receivers. 337 This benefit is particularily important in interdomain deployments 338 because there are no standardized solutions for ASM control of 339 sources and the most common intradomain operational practices such as 340 Access Control Lists (ACL) on the sender's FHR are not feasible for 341 interdomain deployments. 343 This topic is expanded upon in [RFC4609]. 345 4. Recommendations 347 4.1. Deprecating use of ASM for interdomain multicast 349 This document recommends that the use of ASM is deprecated for 350 interdomain multicast, and thus implicitly, that hosts and routers 351 that support such interdomain applications fully support SSM and its 352 associated protocols. Best current practices for deploying 353 interdomain multicast using SSM are documented in [RFC8313]. 355 The recommendation applies to the use of ASM between domains where 356 either MSDP (IPv4) or Embedded-RP (IPv6) is used. 358 An interdomain use of ASM multicast in the context of this document 359 is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers 360 operated by two or more separate administrative entities (domains, 361 organisations). 363 The more inclusive interpretation of this recommendation is that it 364 also extends to the case where PIM may only be operated in a single 365 operator domain, but where user hosts or non-PIM network edge devices 366 are under different operator control. A typical example of this case 367 is an SP providing IPTV (single operator domain for PIM) to 368 subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 369 hosts (computer, tablets, set-top boxes). 371 4.2. Including network support for IGMPv3 / MLDv2 373 This document recommends that all hosts, router platforms and 374 security appliances used for deploying multicast support the 375 components of IGMPv3 [RFC3376] and MLDv2 [RFC3810] necessary to 376 support SSM (i.e., explicitly sending source-specific reports). The 377 updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states 378 that MLDv2 support is a MUST in all implementations. Such support is 379 already widespread in common host and router platforms. 381 Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. 383 Multicast snooping is often used to limit the flooding of multicast 384 traffic in a layer 2 network. With snooping, a L2 switch will 385 monitor IGMP/MLD messages and only forward multicast traffic out on 386 host ports that have interested receivers connected. Such snooping 387 capability should therefore support IGMPv3 and MLDv2. There is 388 further discussion in [RFC4541]. 390 4.3. Building application support for SSM 392 The recommendation to use SSM for interdomain multicast means that 393 applications should properly trigger the sending of IGMPv3/MLDv2 394 source-specific report messages. It should be noted, however, there 395 is a wide range of applications today that only support ASM. In many 396 cases this is due to application developers being unaware of the 397 operational concerns of networks. This document serves to provide 398 clear direction for application developers to support SSM. 400 It is often thought that ASM is required for multicast applications 401 where there are multiple sources. However, RFC 4607 also describes 402 how SSM can be used instead of PIM-SM for multi-party applications: 404 "SSM can be used to build multi-source applications where all 405 participants' identities are not known in advance, but the multi- 406 source "rendezvous" functionality does not occur in the network 407 layer in this case. Just like in an application that uses unicast 408 as the underlying transport, this functionality can be implemented 409 by the application or by an application-layer library." 411 Some useful considerations for multicast applications can be found in 412 [RFC3170]. 414 4.4. Developing application guidance: SSM, ASM, service discovery 416 Applications with many-to-many communication patterns can create more 417 (S,G) state than feasible for networks, whether the source discovery 418 is done by ASM with PIM-SM or at the application level and SSM/PIM- 419 SM. These applications are not best supported by either SSM/PIM-SSM 420 or ASM/PIM-SM. 422 Instead, these applications are better served by routing protocols 423 that do not create (S,G) such as Bidir-PIM. As of today, 424 Unfortunately, many applications simply use ASM for service 425 discovery, for example by clients sending IP multicast packets to 426 elicit unicast replies from server(s). Deploying any form of IP 427 multicast solely in support of such service discovery is in general 428 not recommended (complexity, control, ...) but instead dedicated 429 service discovery via DNS [RFC6763] 430 Best practices should be developed to explain when to use SSM in 431 applications, when ASM without (S,G) state in the network is better, 432 or when dedicated service-discovery mechanisms should be used. 434 4.5. Preferring SSM applications intradomain 436 If feasible, it is recommended for applications to use SSM even if 437 they are initially only meant to be used in intradomain environments 438 supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing 439 intradomain PIM-SM networks are automatically compatible with SSM 440 applications. Thus, SSM applications can operate alongside existing 441 ASM applications. SSM's benefits of simplified address management 442 and significantly reduced operational complexity apply equally to 443 intradomain use. 445 However, for some applications it may be prohibitively difficult to 446 add support for source discovery, so intradomain ASM may still be 447 appropriate. 449 4.6. Documenting an ASM/SSM protocol mapping mechanism 451 In the case of existing ASM applications that cannot readily be 452 ported to SSM, it may be possible to use some form of protocol 453 mapping, i.e., to have a mechanism to translate a (*,G) join or leave 454 to a (S,G) join or leave, for a specific source, S. The general 455 challenge in performing such mapping is determining where the 456 configured source address, S, comes from. 458 There are existing vendor-specific mechanisms deployed that achieve 459 this function, but none are documented in IETF documents. This may 460 be a useful area for the IETF to work on as an interim transition 461 mechanism. However, these mechanisms would introduce additional 462 administrative burdens, along with the need for some form of address 463 management, neither of which are required in SSM. Hence, this should 464 not be considered a long-term solution. 466 4.7. Not filtering ASM addressing between domains 468 A key benefit of SSM is that the receiver specifies the source-group 469 tuple when signaling interest in a multicast stream. Hence, the 470 group address need not be globally unique, so there is no need for 471 multicast address allocation as long the reserved SSM range is used. 473 Despite the deprecation of interdomain ASM, it is recommended that 474 operators should not filter ASM group ranges at domain boundaries, as 475 some form of ASM-SSM mappings may continue to be used for some time. 477 4.8. Not precluding Intradomain ASM 479 The use of ASM within a single multicast domain such as a campus or 480 enterprise is still relatively common today. There are even global 481 enterprise networks that have successfully been using PIM-SM for many 482 years. The operators of such networks most often use Anycast-RP 483 [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of 484 the extra operational complexity. These existing practices are 485 unaffected by this document. 487 In the past decade, Bidir-PIM too has seen deployments to scale 488 interdomain ASM deployments beyond the capabilities of PIM-SM. This 489 too is unaffected by this document, instead it is encouraged where 490 necessary due to application requirements (see Section 4.4. 492 This document does also not preclude continued use of ASM with 493 multiple PIM-SM domains inside organisations, such as with IPv4 MSDP 494 or IPv6 Embedded-RP. This includes organizations that are 495 federations and have appropriate, non-standardized mechanisms to deal 496 with the interdomain ASM issues explained in Section 3.2. 498 4.9. Evolving PIM deployments for SSM 500 Existing PIM-SM deployments can usually be used to run SSM/PIM-SM 501 applications with no or little changes. In some widely available 502 router implentations of PIM-SM, PIM-SSM is simply enabled by default 503 in the designated SSM address spaces whener PIM-SM is configuring/ 504 enabled. In other implementations, simple configuration options 505 exist to enable it. This allows to easily migrate ASM applications 506 to SSM/PIM-SSM solely through application side development/ 507 configuration work: adding above mentioned source-signaling via 508 IGMPv3/MLDv2 and using SSM addresses. No network actions are 509 required for this transitioning: Unchanged ASM applications can 510 continue to co-exist without issues. 512 When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also 513 result in the desired PIM-SSM (S,G) operations and bypass any RP 514 procedures, but this is not standardized but depends on 515 implementation and may require additional configuration in available 516 products. In general, it is recommended to always use SSM address 517 space for SSM applications. For example, the interaction of IGMPv3/ 518 MLDv2 (S,G) membership reports and Bidir-PIM is undefined and may not 519 result in forwarding of any traffic. 521 Note that these migration recommendations do not include the 522 considerations when or how to evolve those intradomain applications 523 best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM. This may also 524 be important but is outside the scope of this document. 526 5. Future interdomain ASM work 528 Future work may attempt to overcome current limitations of ASM 529 solutions, such as interdomain deployment solutions for Bidir-PIM, or 530 source access control mechaisms for IPv6 PIM-SM with embedded-RP. 531 Such work could modify or amend the recommendations of this document 532 (like any future IETF standards/BCP work). 534 Nevertheless, this document does not believe that any ASM solution, 535 even with such future work, can ever provide the same intrinsic 536 security and network and address management simplicity as SSM (see 537 Section 3.2). Instead, this document believes that future work for 538 general purpose interdomain IP multicast is better spent on the SSM 539 items listed in Section 4. 541 6. Security Considerations 543 This document adds no new security considerations. It instead 544 removes security issues incurred by interdomain ASM with PIM-SM/MSDP 545 such as infrastructure control plane attacks and application and 546 bandwidth/congestion attacks from unauthorised sources sending to ASM 547 multicast groups. RFC 4609 describes the additional security 548 benefits of using SSM instead of ASM. 550 7. IANA Considerations 552 This document makes no request of IANA. 554 Note to RFC Editor: this section may be removed upon publication as 555 an RFC. 557 8. Acknowledgments 559 The authors would like to thank members of the IETF mboned WG for 560 discussions on the content of this document, with specific thanks to 561 the following people for their contributions to the document: Hitoshi 562 Asaeda, Dale Carder, Jake Holland, Albert Manfredi, Mike McBride, Per 563 Nihlen, Greg Shepherd, James Stevens, Stig Venaas, Nils Warnke, and 564 Sandy Zhang. 566 9. Changelog 568 [RFC-Editor: Please remove this section.] 570 02 - Toerless: Attempt to document the issues brought up on the list 571 and discussion by James Stevens re. use of Bidir-PIM intradomain and 572 IGMP/MLD interop issues. 574 - NOTE: Text was not vetted by co-authors, so rev'ed just as 575 discussion basis. 577 - more subsection to highlight content. Added more detailled 578 discussion about downsides of ASM wrt. address management and 579 intrinsic source-control in SSM. Added recommendation to work on 580 guidance when apps are best suited for SSM vs. ASM/Bidir vs. service 581 discovery. Added recommendation how to evolve from PIM-SM to SSM in 582 existing deployments. Added section on possible future interdomain 583 ASM work (and why not to focus on it). 585 01 - Lenny: cleanup of text version, removed redundancies. 587 00 - initial IETF WG version. See draft-acg-mboned-deprecate- 588 interdomain-asm for work leading to this document. 590 10. References 592 10.1. Normative References 594 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 595 RFC 1112, DOI 10.17487/RFC1112, August 1989, 596 . 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, 600 DOI 10.17487/RFC2119, March 1997, 601 . 603 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 604 Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, 605 . 607 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 608 Thyagarajan, "Internet Group Management Protocol, Version 609 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 610 . 612 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 613 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 614 DOI 10.17487/RFC3810, June 2004, 615 . 617 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 618 Point (RP) Address in an IPv6 Multicast Address", 619 RFC 3956, DOI 10.17487/RFC3956, November 2004, 620 . 622 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 623 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 624 2006, . 626 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 627 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 628 . 630 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 631 Independent Multicast (PIM)", RFC 4610, 632 DOI 10.17487/RFC4610, August 2006, 633 . 635 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 636 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 637 DOI 10.17487/RFC5771, March 2010, 638 . 640 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 641 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 642 Multicast - Sparse Mode (PIM-SM): Protocol Specification 643 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 644 2016, . 646 10.2. Informative References 648 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 649 Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, 650 . 652 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 653 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 654 DOI 10.17487/RFC2730, December 1999, 655 . 657 [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 658 Zone Announcement Protocol (MZAP)", RFC 2776, 659 DOI 10.17487/RFC2776, February 2000, 660 . 662 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 663 Kumar, S., and D. Thaler, "The Multicast Address-Set Claim 664 (MASC) Protocol", RFC 2909, DOI 10.17487/RFC2909, 665 September 2000, . 667 [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: 668 Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, 669 September 2001, . 671 [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific 672 Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 673 2003, . 675 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 676 Discovery Protocol (MSDP)", RFC 3618, 677 DOI 10.17487/RFC3618, October 2003, 678 . 680 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 681 Protocol Specification", RFC 3913, DOI 10.17487/RFC3913, 682 September 2004, . 684 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 685 Independent Multicast - Dense Mode (PIM-DM): Protocol 686 Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, 687 January 2005, . 689 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 690 "Considerations for Internet Group Management Protocol 691 (IGMP) and Multicast Listener Discovery (MLD) Snooping 692 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 693 . 695 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 696 Group Management Protocol Version 3 (IGMPv3) and Multicast 697 Listener Discovery Protocol Version 2 (MLDv2) for Source- 698 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 699 August 2006, . 701 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 702 Independent Multicast - Sparse Mode (PIM-SM) Multicast 703 Routing Security Issues and Enhancements", RFC 4609, 704 DOI 10.17487/RFC4609, October 2006, 705 . 707 [RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source 708 Discovery Protocol (MSDP) Deployment Scenarios", BCP 121, 709 RFC 4611, DOI 10.17487/RFC4611, August 2006, 710 . 712 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 713 "Bidirectional Protocol Independent Multicast (BIDIR- 714 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 715 . 717 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 718 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 719 . 721 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 722 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 723 March 2017, . 725 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 726 Ed., and R. Krishnan, "Use of Multicast across Inter- 727 domain Peering Points", BCP 213, RFC 8313, 728 DOI 10.17487/RFC8313, January 2018, 729 . 731 [I-D.ietf-6man-rfc6434-bis] 732 Chown, T., Loughney, J., and T. Winters, "IPv6 Node 733 Requirements", draft-ietf-6man-rfc6434-bis-09 (work in 734 progress), July 2018. 736 Authors' Addresses 738 Mikael Abrahamsson 739 T-Systems 740 Stockholm 741 Sweden 743 Email: mikael.abrahamsson@t-systems.se 745 Tim Chown 746 Jisc 747 Lumen House, Library Avenue 748 Harwell Oxford, Didcot OX11 0SG 749 United Kingdom 751 Email: tim.chown@jisc.ac.uk 753 Lenny Giuliano 754 Juniper Networks, Inc. 755 2251 Corporate Park Drive 756 Herndon, Virginia 20171 757 United States 759 Email: lenny@juniper.net 760 Toerless Eckert 761 Futurewei Technologies Inc. 762 2330 Central Expy 763 Santa Clara 95050 764 USA 766 Email: tte+ietf@cs.fau.de