idnits 2.17.1 draft-ietf-mboned-deprecate-interdomain-asm-02.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 (October 22, 2018) is 2013 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: 'RFC3569' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'RFC8085' is defined on line 728, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 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: April 25, 2019 Jisc 6 L. Giuliano 7 Juniper Networks, Inc. 8 T. Eckert 9 Huawei 10 October 22, 2018 12 Deprecating ASM for Interdomain Multicast 13 draft-ietf-mboned-deprecate-interdomain-asm-02 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 April 25, 2019. 51 Copyright Notice 53 Copyright (c) 2018 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 . . . . . . . . . . 8 82 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 83 4.1. Deprecating use of ASM for interdomain multicast . . . . 8 84 4.2. Including network support for IGMPv3 / MLDv2 . . . . . . 9 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 . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 eliminates the most 251 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 issues is one of biggest problem 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 oob mechanism) before the application 268 starts running or applications that utilize some signaling to 269 indicate the source address of the multicast stream (eg, electronic 270 programming guide in IPTV applications). PIM-SSM is therefore very 271 well-suited to applications such as classic linear broadcast TV over 272 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 area of benefits that SSM with 283 PIM-SSM has over ASM. These benefits also apply to intradomain 284 deployment but are even more important in interdomain deployments. 285 See [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 Protocols to automate ASM IP multicast group allocations to 321 application instances where defined in the 1990'ths, but never widely 322 deployed: MADCAP [RFC2730], MASC [RFC2909] and MZAP [RFC2776]. 323 Today, all ASM IP multicast group allocation are based on per- 324 operator, non-standardized and mostly manual assignment practices 325 which adds to the operational overhead of supporting ASM. 327 In SSM, no such IP multicast group management is necessary. Instead, 328 the IP multicast group address simply needs to be assigned locally on 329 a source like a unicast transport protocol port number: No two 330 independent applications on the host must use same IP multicast group 331 number. This does not require any network operator involvement. 333 3.2.3. Intrinsic source-control security 335 SSM is implicitly secure against unauthorized/undesired sources. 336 Receivers only receive packets from the sources they explicitly 337 specify in their IGMP/MLD membreship messages, as opposed to ASM 338 where any host can send traffic to a group address and have it 339 transmitted to all receivers. With PIM-SSM, traffic from sources not 340 requested by any receiver will be discarded by the first-hop router 341 (FHR) of that source, minimizing source attacks against shared 342 network bandwidth and receivers. 344 This benefit is particularily important in interdomain deployments 345 because there are no standardized solutions for ASM control of 346 sources and the most common intradomain operational practices such as 347 Access Control Lists (ACL) on senders FHR are not feasible for 348 interdomain deployments. 350 This topic is expanded upon in [RFC4609]. 352 4. Recommendations 354 4.1. Deprecating use of ASM for interdomain multicast 356 This document recommends that the use of ASM is deprecated for 357 interdomain multicast, and thus implicitly, that hosts and routers 358 that support such interdomain applications fully support SSM and its 359 associated protocols. Best current practices for deploying 360 interdomain multicast using SSM are documented in [RFC8313]. 362 The recommendation applies to the use of ASM between domains where 363 either MSDP (IPv4) or Embedded-RP (IPv6) is used. 365 An interdomain use of ASM multicast in the context of this document 366 is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers 367 operated by two or more separate administrative entities (domains, 368 organisations). 370 The more inclusive interpretation of this recommendation is that it 371 also extends to the case where PIM may only be operated in a single 372 operator domain, but where user hosts or non-PIM network edge devices 373 are under different operator control. A typical example of this case 374 is an SP providing IPTV (single operator domain for PIM) to 375 subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 376 hosts (computer, tablets, set-top boxes). 378 4.2. Including network support for IGMPv3 / MLDv2 380 This document recommends that all hosts, router platforms and 381 security appliances supporting multicast support IGMPv3 [RFC3376] and 382 MLDv2 [RFC3810] (based on the version IP they intend to support). 383 The updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] 384 states that MLDv2 support is a MUST in all implementations. Such 385 support is already widespread in common host and router platforms. 387 Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. 389 Multicast snooping is often used limit the flooding of multicast 390 traffic in a layer 2 network. With snooping, a L2 switch will 391 monitor IGMP/MLD messages and only forward multicast traffic out host 392 ports that have interested receivers connected. Such snooping 393 capability should therefore support IGMPv3 and MLDv2. There is 394 further discussion in [RFC4541]. 396 4.3. Building application support for SSM 398 The recommendation to use SSM for interdomain multicast means that 399 applications should properly trigger the sending of IGMPv3/MLDv2 400 messages. It should be noted, however, there is a wide range of 401 applications today that only support ASM. In many cases this is due 402 to application developers being unaware of the operational concerns 403 of networks. This document serves to provide clear direction for 404 application developers to support SSM. 406 It is often thought that ASM is required for multicast applications 407 where there are multiple sources. However, RFC 4607 also describes 408 how SSM can be used instead of PIM-SM for multi-party applications: 410 "SSM can be used to build multi-source applications where all 411 participants' identities are not known in advance, but the multi- 412 source "rendezvous" functionality does not occur in the network 413 layer in this case. Just like in an application that uses unicast 414 as the underlying transport, this functionality can be implemented 415 by the application or by an application-layer library." 417 Some useful considerations for multicast applications can be found in 418 [RFC3170]. 420 4.4. Developing application guidance: SSM, ASM, service discovery 422 Applications with many-to-many communication patterns can create more 423 (S,G) state than feasible for networks, whether the source discovery 424 is done by ASM with PIM-SM or at the application level and SSM/PIM- 425 SM. These applications are not best supported by neithre SSM/PIM-SSM 426 nor ASM/PIM-SM. 428 Instead, these applications are better served by routing protocols 429 that do not create (S,G) such as Bidir-PIM. As of today, 430 Unfortunately, many applications simply use ASM for service 431 discovery, for example by clients sending IP multicast packets to 432 elicit unicast replies from server(s). Deploying any form of IP 433 multicast solely in support of such service discovery is in general 434 not recommended (complexity, control, ...) but instead dedicated 435 service discovery via DNS [RFC6763] 437 Best practices should be developed to explain when to use SSM in 438 application, when ASM without (S,G) state in the network is better, 439 or when dedicated service-discovery mechanisms should be used. 441 4.5. Preferring SSM applications intradomain 443 If feasible, it is recommended for applications to use SSM even if 444 they are initially only meant to be used in intradomain environments 445 supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing 446 intradomain PIM-SM networks are automatically compatible with SSM 447 applications. Thus, SSM applications can operate alongside existing 448 ASM applications. SSM's benefits of simplified address management 449 and significantly reduced operational complexity apply equally to 450 intradomain use. 452 However, for some applications it may be prohibitively difficult to 453 add support for source discovery, so intradomain ASM may still be 454 appropriate. 456 4.6. Documenting an ASM/SSM protocol mapping mechanism 458 In the case of existing ASM applications that cannot readily be 459 ported to SSM, it may be possible to use some form of protocol 460 mapping, i.e., to have a mechanism to translate a (*,G) join or leave 461 to a (S,G) join or leave, for a specific source, S. The general 462 challenge in performing such mapping is determining where the 463 configured source address, S, comes from. 465 There are existing vendor-specific mechanisms deployed that achieve 466 this function, but none are documented in IETF documents. This may 467 be a useful area for the IETF to work on as an interim transition 468 mechanism. However, these mechanisms would introduce additional 469 administrative burdens, along with the need for some form of address 470 management, neither of which are required in SSM. Hence, this should 471 not be considered a a long-term solution. 473 4.7. Not filtering ASM addressing between domains 475 A key benefit of SSM is that the receiver specifies the source-group 476 tuple when signaling interest in a multicast stream. Hence, the 477 group address need not be globally unique, so there is no need for 478 multicast address allocation as long the reserved SSM range is used. 480 Despite the deprecation of interdomain ASM, it is recommended that 481 operators should not filter ASM group ranges at domain boundaries, as 482 some form of ASM-SSM mappings may continue to be used for some time. 484 4.8. Not precluding Intradomain ASM 486 The use of ASM within a single multicast domain such as a campus or 487 enterprise is still relatively common today. There are even global 488 enterprise networks that have successfully been using PIM-SM for many 489 years. The operators of such networks most often use Anycast-RP 490 [RFC4610] or MSDP (with IPv4) for RP resilience, at the expense of 491 the extra operational complexity. These existing practices are 492 unaffected by this document. 494 In the past decade, Bidir-PIM too has seen deployments to scale 495 interdomain ASM deployments beyond the capabilities of PIM-SM. This 496 too is unaffected by this document, instead it is encouraged where 497 necessary due to application requirements (see Section 4.4. 499 This document does also not preclude continued use of ASM with 500 multiple PIM-SM domains inside organisations, such as with IPv4 MSDP 501 or IPv6 Embedded-RP. This includes organizations that are 502 federations and have appropriate, non-standardized mechanisms to deal 503 with the interdomain ASM issues explained in Section 3.2. 505 4.9. Evolving PIM deployments for SSM 507 Existing PIM-SM deployments can usually be used to run SSM/PIM-SM 508 applications with no or little changes. In some widely available 509 router implentations of PIM-SM, PIM-SSM is simply enabled by default 510 in the designated SSM address spaces whener PIM-SM is configuring/ 511 enabled. In other implementations, simple configuration options 512 exist to enable it. This allows to easily migrate ASM applications 513 to SSM/PIM-SSM solely through application side development/ 514 configuration work: adding above mentioned source-signaling via 515 IGMPv3/MLDv2 and using SSM addresses. No network actions are 516 required for this transitioning: Unchanged ASM applications can 517 continue to co-exist without issues. 519 When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also 520 result in the desired PIM-SSM (S,G) operations and bypass any RP 521 procedures, but this is not standardized but depends on 522 implementation and may require additional configuration in available 523 products. In general, it is recommended to always use SSM address 524 space for SSM applications. For example, the interaction of IGMPv3/ 525 MLDv2 (S,G) membership reports and Bidir-PIM is undefined and may not 526 result in forwarding of any traffic. 528 Note that this migration recommendations do not include the 529 considerations when or how to evolve those intradomain applications 530 best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM. This may also 531 be important but is outside the scope of this document. 533 5. Future interdomain ASM work 535 Future work may attempt to overcome current limitations of ASM 536 solutions, such as interdomain deployment solutions for Bidir-PIM, or 537 source access control mechaisms for IPv6 PIM-SM with embedded-RP. 538 Such work could modify or amend the recommendations of this document 539 (like any future IETF standards/BCP work). 541 Nevertheless, this document does not believe that any ASM solution, 542 even with such future work, can ever provide the same intrinsic 543 security and network and address management simplicity as SSM (see 544 Section 3.2). Instead, this document believes that future work for 545 general purpose interdomain IP multicast is better spent on the SSM 546 items listed in Section 4. 548 6. Security Considerations 550 This document adds no new security considerations. It instead 551 removes security issues incurred by interdomain ASM with PIM-SM/MSDP 552 such as infrastructure control plane attacks and application and 553 bandwidth/congestion attacks from unauthorised sources sending to ASM 554 multicast groups. RFC 4609 describes the additional security 555 benefits of using SSM instead of ASM. 557 7. IANA Considerations 559 This document makes no request of IANA. 561 Note to RFC Editor: this section may be removed upon publication as 562 an RFC. 564 8. Acknowledgments 566 The authors would like to thank members of the IETF mboned WG for 567 discussions on the content of this document, with specific thanks to 568 the following people for their contributions to the document: Hitoshi 569 Asaeda, Dale Carder, Jake Holland, Albert Manfredi, Mike McBride, Per 570 Nihlen, Greg Shepherd, James Stevens, Stig Venaas, Nils Warnke, and 571 Sandy Zhang. 573 9. Changelog 575 [RFC-Editor: Please remove this section.] 577 02 - Toerless: Attempt to document the issues brought up on the list 578 and discussion by James Stevens re. use of Bidir-PIM intradomain and 579 IGMP/MLD interop issues. 581 - NOTE: Text was not vetted by co-authors, so rev'ed just as 582 discussion basis. 584 - more subsection to highlight content. Added more detailled 585 discussion about downsides of ASM wrt. address management and 586 intrinsic source-control in SSM. Added recommendation to work on 587 guidance when apps are best suited for SSM vs. ASM/Bidir vs. service 588 discovery. Added recommendation how to evolve from PIM-SM to SSM in 589 existing deployments. Added section on possible future interdomain 590 ASM work (and why not to focus on it). 592 01 - Lenny: cleanup of text version, removed redundancies. 594 00 - initial IETF WG version. See draft-acg-mboned-deprecate- 595 interdomain-asm for work leading to this document. 597 10. References 599 10.1. Normative References 601 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 602 RFC 1112, DOI 10.17487/RFC1112, August 1989, 603 . 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, 607 DOI 10.17487/RFC2119, March 1997, 608 . 610 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 611 Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, 612 . 614 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 615 Thyagarajan, "Internet Group Management Protocol, Version 616 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 617 . 619 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 620 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 621 DOI 10.17487/RFC3810, June 2004, 622 . 624 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 625 Point (RP) Address in an IPv6 Multicast Address", 626 RFC 3956, DOI 10.17487/RFC3956, November 2004, 627 . 629 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 630 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 631 2006, . 633 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 634 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 635 . 637 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 638 Independent Multicast (PIM)", RFC 4610, 639 DOI 10.17487/RFC4610, August 2006, 640 . 642 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 643 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 644 DOI 10.17487/RFC5771, March 2010, 645 . 647 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 648 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 649 Multicast - Sparse Mode (PIM-SM): Protocol Specification 650 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 651 2016, . 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 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 660 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 661 DOI 10.17487/RFC2730, December 1999, 662 . 664 [RFC2776] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 665 Zone Announcement Protocol (MZAP)", RFC 2776, 666 DOI 10.17487/RFC2776, February 2000, 667 . 669 [RFC2909] Radoslavov, P., Estrin, D., Govindan, R., Handley, M., 670 Kumar, S., and D. Thaler, "The Multicast Address-Set Claim 671 (MASC) Protocol", RFC 2909, DOI 10.17487/RFC2909, 672 September 2000, . 674 [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: 675 Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, 676 September 2001, . 678 [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific 679 Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 680 2003, . 682 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 683 Discovery Protocol (MSDP)", RFC 3618, 684 DOI 10.17487/RFC3618, October 2003, 685 . 687 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 688 Protocol Specification", RFC 3913, DOI 10.17487/RFC3913, 689 September 2004, . 691 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 692 Independent Multicast - Dense Mode (PIM-DM): Protocol 693 Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, 694 January 2005, . 696 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 697 "Considerations for Internet Group Management Protocol 698 (IGMP) and Multicast Listener Discovery (MLD) Snooping 699 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 700 . 702 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 703 Group Management Protocol Version 3 (IGMPv3) and Multicast 704 Listener Discovery Protocol Version 2 (MLDv2) for Source- 705 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 706 August 2006, . 708 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 709 Independent Multicast - Sparse Mode (PIM-SM) Multicast 710 Routing Security Issues and Enhancements", RFC 4609, 711 DOI 10.17487/RFC4609, October 2006, 712 . 714 [RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source 715 Discovery Protocol (MSDP) Deployment Scenarios", BCP 121, 716 RFC 4611, DOI 10.17487/RFC4611, August 2006, 717 . 719 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 720 "Bidirectional Protocol Independent Multicast (BIDIR- 721 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 722 . 724 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 725 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 726 . 728 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 729 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 730 March 2017, . 732 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 733 Ed., and R. Krishnan, "Use of Multicast across Inter- 734 domain Peering Points", BCP 213, RFC 8313, 735 DOI 10.17487/RFC8313, January 2018, 736 . 738 [I-D.ietf-6man-rfc6434-bis] 739 Chown, T., Loughney, J., and T. Winters, "IPv6 Node 740 Requirements", draft-ietf-6man-rfc6434-bis-09 (work in 741 progress), July 2018. 743 Authors' Addresses 745 Mikael Abrahamsson 746 T-Systems 747 Stockholm 748 Sweden 750 Email: mikael.abrahamsson@t-systems.se 751 Tim Chown 752 Jisc 753 Lumen House, Library Avenue 754 Harwell Oxford, Didcot OX11 0SG 755 United Kingdom 757 Email: tim.chown@jisc.ac.uk 759 Lenny Giuliano 760 Juniper Networks, Inc. 761 2251 Corporate Park Drive 762 Herndon, Virginia 20171 763 United States 765 Email: lenny@juniper.net 767 Toerless Eckert 768 Futurewei Technologies Inc. 769 2330 Central Expy 770 Santa Clara 95050 771 USA 773 Email: tte+ietf@cs.fau.de