idnits 2.17.1 draft-ietf-mboned-deprecate-interdomain-asm-01.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 1985 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: 'RFC3973' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'RFC8085' is defined on line 547, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 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-01 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 these existing intradomain ASM 24 deployments. 26 Requirements Language 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 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 25, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Multicast routing protocols . . . . . . . . . . . . . . . . . 3 69 2.1. ASM routing protocols . . . . . . . . . . . . . . . . . . 4 70 2.2. SSM Routing protocols . . . . . . . . . . . . . . . . . . 4 71 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Observations on ASM and SSM deployments . . . . . . . . . 5 73 3.2. Advantages of SSM for interdomain multicast . . . . . . . 6 74 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Deprecating use of ASM for interdomain multicast . . . . 7 76 4.2. Including network support for IGMPv3 / MLDv2 . . . . . . 7 77 4.3. Building application support for SSM . . . . . . . . . . 8 78 4.4. Preferring SSM applications intradomain . . . . . . . . . 8 79 4.5. Documenting an ASM/SSM protocol mapping mechanism . . . . 8 80 4.6. Not filtering ASM addressing between domains . . . . . . 9 81 4.7. Not precluding Intradomain ASM . . . . . . . . . . . . . 9 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 8.2. Informative References . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 IP Multicast has been deployed in various forms, within private 93 networks, the wider Internet, and federated networks such as national 94 or regional research networks. While a number of service models have 95 been published, and in many cases revised over time, there has been 96 no strong recommendation made by the IETF on the appropriateness of 97 those models to certain scenarios, even though vendors and 98 federations have often made such recommendations. 100 This document addresses this gap by making a BCP-level recommendation 101 to deprecate the use of ASM for interdomain multicast, leaving SSM as 102 the recommended interdomain mode of multicast. This recommendation 103 thus also implicitly states that all hosts and routers that are 104 expected to support interdomain multicast applications fully support 105 SSM. 107 This document does not make any statement on the use of ASM within a 108 single domain or organisation, and therefore does not preclude its 109 use. Indeed, there are application contexts for which ASM is 110 currently still widely considered well-suited within a single domain. 112 The main issue in most cases with moving to SSM is application 113 support. Many applications are initially deployed for intradomain 114 use and are later deployed interdomain. Therefore, this document 115 recommends applications support SSM, even when they are initially 116 intended for intradomain use. As explained below, SSM applications 117 are readily compatible with existing intradomain ASM deployments as 118 SSM is merely a subset of ASM. 120 2. Multicast routing protocols 122 Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) are 123 the two multicast service models in use today. In ASM, as originally 124 described in [RFC1112], receivers express interest in joining a 125 multicast group address and routers use multicast routing protocols 126 to deliver traffic from the sender(s) to the receivers. If there are 127 multiple senders for a given group, traffic from all senders will be 128 delivered to the receiver. Since receivers specify only the group 129 address, the network, and therefore the multicast routing protocols, 130 are responsible for source discovery. In SSM, by contrast, receivers 131 specify both group and source when expressing interest in joining a 132 multicast stream. Source discovery in SSM is handled by some out-of- 133 band mechanism (ie, the application layer), which drastically 134 simplifies the network and how the multicast routing protocols 135 operate. 137 IANA has reserved specific ranges of IPv4 and IPv6 address space for 138 multicast addressing. Guidelines for IPv4 multicast address 139 assignments can be found in [RFC5771], while guidelines for IPv6 140 multicast address assignments can be found in [RFC2375] and 141 [RFC3307]. The IPv6 multicast address format is described in 142 [RFC4291]. 144 2.1. ASM routing protocols 146 The most commonly deployed ASM routing protocol is Protocol 147 Independent Multicast - Sparse Mode, or PIM-SM, as detailed in 148 [RFC7761]. PIM-SM, as the name suggests, was designed to be used in 149 scenarios where the subnets with receivers are sparsely distributed 150 throughout the network. Because it does not know sender addresses in 151 advance, PIM-SM uses the concept of a Rendezvous Point (RP) as a 152 'meeting point' for sources and receivers, and all routers in a PIM- 153 SM domain are configured to use specific RP(s), either explicitly or 154 through dynamic RP discovery protocols. 156 To enable PIM-SM to work between multiple domains, an inter-RP 157 signalling protocol known as Multicast Source Discovery Protocol 158 (MSDP) [RFC3618] is used to allow an RP in one domain to learn the 159 existence of a source in another domain. Deployment scenarios for 160 MSDP are given in [RFC4611]. MSDP floods information about all 161 active sources for all multicast streams to all RPs in all the 162 domains - even if there is no receiver for a given application in a 163 domain. As a result of this key scalability and security issue, 164 along with other deployment challenges with the protocol, MSDP was 165 never extended to support IPv6 and remains an Experimental protocol. 167 To this day, there is no IETF Proposed Standard level interdomain 168 solution for IPv4 ASM multicast because MSDP was the "best" component 169 for the interdomain source discovery problem, and it is Experimental. 170 Other protocol options where investigated at the same time but were 171 never implemented or deployed and are now historic (e.g: [RFC3913]). 173 Due to the availability of more bits in an IPv6 address than in IPv4, 174 an IPv6-specific mechanism was able to be designed in support of 175 interdomain ASM with PIM-SM. Embedded-RP [RFC3956] allows routers 176 supporting the protocol to determine the RP for the group without any 177 prior configuration or discovery protocols, simply by observing the 178 unicast RP address that is embedded (included) in the IPv6 multicast 179 group address. Embedded-RP allows PIM-SM operation across any IPv6 180 network in which there is an end-to-end path of routers supporting 181 the mechanism. 183 2.2. SSM Routing protocols 185 SSM is detailed in [RFC4607]. Note that there is no separate 186 document for PIM-SSM as it merely leverages a subset of [RFC7761]. 188 PIM-SSM expects that the sender's source address(es) is known in 189 advance by receivers by some out-of-band mechanism (typically in the 190 application layer), and thus the receiver's designated router can 191 send a PIM JOIN directly towards the source without needing to use an 192 RP. 194 IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 195 designated as source-specific multicast (SSM) destination addresses 196 and are reserved for use by source-specific applications and 197 protocols. See [RFC4607]. For IPv6, the address prefix FF3x::/32 is 198 reserved for source-specific multicast use. 200 3. Discussion 202 3.1. Observations on ASM and SSM deployments 204 In enterprise and campus scenarios, ASM in the form of PIM-SM is 205 likely the most commonly deployed multicast protocol. The 206 configuration and management of an RP (including RP redundancy) 207 within a single domain is a well understood operational practice. 208 However, if interworking with external PIM domains is needed in IPv4 209 multicast deployments, interdomain MSDP is required to exchange 210 information about sources between domain RPs. Deployment experience 211 has shown MSDP to be a complex and fragile protocol to manage and 212 troubleshoot (complex flooding RPF rules, state attack protection, 213 filtering of undesired sources, ...). 215 PIM-SM is a general purpose protocol that can handle all use cases. 216 In particular, it was designed for cases such as videoconferencing 217 where multiple sources may come and go during a multicast session. 218 But for cases where a single, persistent source for a group is used, 219 and receivers can be configured to know of that source, PIM-SM has 220 unnecessary complexity. Therefore, SSM eliminates the most 221 components of PIM-SM. 223 As explained above, MSDP was not extended to support to IPv6. 224 Instead, the proposed interdomain ASM solution for PIM-SM with IPv6 225 is Embedded-RP, which allows the RP address for a multicast group to 226 be embedded in the group address, making RP discovery automatic for 227 all routers on the path between a receiver and a sender. Embedded-RP 228 can support lightweight ad-hoc deployments. However, it relies on a 229 single RP for an entire group that could only be made resilient 230 within one domain. While this approach solves the MSDP issues, it 231 does not solve the problem of unauthorised sources sending traffic to 232 ASM multicast groups; this security issues is one of biggest problem 233 of interdomain multicast. 235 As stated in RFC 4607, SSM is particularly well-suited to 236 dissemination-style applications with one or more senders whose 237 identities are known (by some oob mechanism) before the application 238 starts running or applications that utilize some signaling to 239 indicate the source address of the multicast stream (eg, electronic 240 programming guide in IPTV applications). PIM-SSM is therefore very 241 well-suited to applications such as classic linear broadcast TV over 242 IP. 244 SSM requires applications, host operating systems and the designated 245 routers connected to receiving hosts to support IGMPv3 [RFC3376] and 246 MLDv2 [RFC3810]. Support for IGMPv3 and MLDv2 has become widespread 247 in common OSes for several years (Windows, MacOS, Linux/Android) and 248 is no longer an impediment to SSM deployment. 250 3.2. Advantages of SSM for interdomain multicast 252 A significant benefit of SSM is the reduced complexity that comes 253 through eliminating the network-based source discovery required in 254 ASM. Specifically, SSM eliminates the need for RPs, shared trees, 255 Shortest Path Tree (SPT) switchovers, PIM registers, MSDP, dynamic RP 256 discovery mechanisms (BSR/AutoRP) and data-driven state creation. 257 SSM simply utilizes a small subset of PIM-SM, alongside the 258 integration with IGMPv3 / MLDv2, where the source address signaled 259 from the receiver is immediately used to create (S,G) state. 260 Eliminating network-based source discovery for interdomain multicast 261 means the vast majority of the complexity of multicast goes away. 263 This reduced complexity makes SSM radically simpler to manage, 264 troubleshoot and operate, particularly for backbone network 265 operators. This is the main motivation for the recommendation to 266 deprecate the use of ASM in interdomain scenarios. Note that SSM 267 operation is standardised in PIM-SM (RFC7761); there is no separate 268 specification for PIM-SSM. 270 RFC 4607 details many benefits of SSM, including: 272 "Elimination of cross-delivery of traffic when two sources 273 simultaneously use the same source-specific destination address; 275 Avoidance of the need for inter-host coordination when choosing 276 source-specific addresses, as a consequence of the above; 278 Avoidance of many of the router protocols and algorithms that are 279 needed to provide the ASM service model." 281 Further discussion can also be found in [RFC3569]. 283 SSM is considered more secure in that it inherently supports access 284 control. That is, receivers only get packets from the sources they 285 explicitly specify, as opposed to ASM where any host can send traffic 286 to a group address and have it transmitted to all receivers. This 287 topic is expanded upon in [RFC4609]. 289 4. Recommendations 291 4.1. Deprecating use of ASM for interdomain multicast 293 This document recommends that the use of ASM is deprecated for 294 interdomain multicast, and thus implicitly, that hosts and routers 295 that support such interdomain applications fully support SSM and its 296 associated protocols. Best current practices for deploying 297 interdomain multicast using SSM are documented in [RFC8313]. 299 The recommendation applies to the use of ASM between domains where 300 either MSDP (IPv4) or Embedded-RP (IPv6) is used. 302 An interdomain use of ASM multicast in the context of this document 303 is one where PIM-SM with RPs/MSDP/Embedded-RP is run on routers 304 operated by two or more separate administrative entities (domains, 305 organisations). 307 The more inclusive interpretation of this recommendation is that it 308 also extends to the case where PIM may only be operated in a single 309 operator domain, but where user hosts or non-PIM network edge devices 310 are under different operator control. A typical example of this case 311 is an SP providing IPTV (single operator domain for PIM) to 312 subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 313 hosts (computer, tablets, set-top boxes). 315 4.2. Including network support for IGMPv3 / MLDv2 317 This document recommends that all hosts, router platforms and 318 security appliances supporting multicast support IGMPv3 [RFC3376] and 319 MLDv2 [RFC3810] (based on the version IP they intend to support). 320 The updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] 321 states that MLDv2 support is a MUST in all implementations. Such 322 support is already widespread in common host and router platforms. 324 Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. 326 Multicast snooping is often used limit the flooding of multicast 327 traffic in a layer 2 network. With snooping, a L2 switch will 328 monitor IGMP/MLD messages and only forward multicast traffic out host 329 ports that have interested receivers connected. Such snooping 330 capability should therefore support IGMPv3 and MLDv2. There is 331 further discussion in [RFC4541]. 333 4.3. Building application support for SSM 335 The recommendation to use SSM for interdomain multicast means that 336 applications should properly trigger the sending of IGMPv3/MLDv2 337 messages. It should be noted, however, there is a wide range of 338 applications today that only support ASM. In many cases this is due 339 to application developers being unaware of the operational concerns 340 of networks. This document serves to provide clear direction for 341 application developers to support SSM. 343 It is often thought that ASM is required for multicast applications 344 where there are multiple sources. However, RFC 4607 also describes 345 how SSM can be used instead of PIM-SM for multi-party applications: 347 "SSM can be used to build multi-source applications where all 348 participants' identities are not known in advance, but the multi- 349 source "rendezvous" functionality does not occur in the network 350 layer in this case. Just like in an application that uses unicast 351 as the underlying transport, this functionality can be implemented 352 by the application or by an application-layer library." 354 Some useful considerations for multicast applications can be found in 355 [RFC3170]. 357 4.4. Preferring SSM applications intradomain 359 If feasible, it is recommended for applications to use SSM even if 360 they are initially only meant to be used in intradomain environments 361 supporting ASM. Because PIM-SSM is a subset of PIM-SM, existing 362 intradomain PIM-SM networks are automatically compatible with SSM 363 applications. Thus, SSM applications can operate alongside existing 364 ASM applications. SSM's benefits of simplified address management 365 and significantly reduced operational complexity apply equally to 366 intradomain use. 368 However, for some applications it may be prohibitively difficult to 369 add support for source discovery, so intradomain ASM may still be 370 appropriate. 372 4.5. Documenting an ASM/SSM protocol mapping mechanism 374 In the case of existing ASM applications that cannot readily be 375 ported to SSM, it may be possible to use some form of protocol 376 mapping, i.e., to have a mechanism to translate a (*,G) join or leave 377 to a (S,G) join or leave, for a specific source, S. The general 378 challenge in performing such mapping is determining where the 379 configured source address, S, comes from. 381 There are existing vendor-specific mechanisms deployed that achieve 382 this function, but none are documented in IETF documents. This may 383 be a useful area for the IETF to work on as an interim transition 384 mechanism. However, these mechanisms would introduce additional 385 administrative burdens, along with the need for some form of address 386 management, neither of which are required in SSM. Hence, this should 387 not be considered a a long-term solution. 389 4.6. Not filtering ASM addressing between domains 391 A key benefit of SSM is that the receiver specifies the source-group 392 tuple when signaling interest in a multicast stream. Hence, the 393 group address need not be globally unique, so there is no need for 394 multicast address allocation as long the reserved SSM range is used. 396 Despite the deprecation of interdomain ASM, it is recommended that 397 operators should not filter ASM group ranges at domain boundaries, as 398 some form of ASM-SSM mappings may continue to be used for some time. 400 4.7. Not precluding Intradomain ASM 402 The use of ASM within a single multicast domain such as a campus or 403 enterprise is still relatively common today. There are even global 404 enterprise networks that have successfully been using PIM-SM for many 405 years. The operators of such networks most often use Anycast-RP 406 [RFC4610] or MSDP for RP resilience, at the expense of the extra 407 operational complexity. These existing practices are unaffected by 408 this document. 410 This document does not preclude continued use of ASM in the 411 intradomain scenario. If an organisation chooses to operate multiple 412 multicast domains within its own administrative borders, it may then 413 use MSDP or Embedded-RP internally within its own network. 415 5. Security Considerations 417 This document adds no new security considerations. It instead 418 removes security issues incurred by interdomain ASM with PIM-SM/MSDP 419 such as infrastructure control plane attacks and application and 420 bandwidth/congestion attacks from unauthorised sources sending to ASM 421 multicast groups. RFC 4609 describes the additional security 422 benefits of using SSM instead of ASM. 424 6. IANA Considerations 426 This document makes no request of IANA. 428 Note to RFC Editor: this section may be removed upon publication as 429 an RFC. 431 7. Acknowledgments 433 The authors would like to thank members of the IETF mboned WG for 434 discussions on the content of this document, with specific thanks to 435 the following people for their contributions to the document: Hitoshi 436 Asaeda, Dale Carder, Jake Holland, Albert Manfredi, Mike McBride, Per 437 Nihlen, Greg Shepherd, James Stevens, Stig Venaas, Nils Warnke, and 438 Sandy Zhang. 440 8. References 442 8.1. Normative References 444 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 445 RFC 1112, DOI 10.17487/RFC1112, August 1989, 446 . 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, 450 DOI 10.17487/RFC2119, March 1997, 451 . 453 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 454 Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, 455 . 457 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 458 Thyagarajan, "Internet Group Management Protocol, Version 459 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 460 . 462 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 463 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 464 DOI 10.17487/RFC3810, June 2004, 465 . 467 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 468 Point (RP) Address in an IPv6 Multicast Address", 469 RFC 3956, DOI 10.17487/RFC3956, November 2004, 470 . 472 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 473 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 474 2006, . 476 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 477 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 478 . 480 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 481 Independent Multicast (PIM)", RFC 4610, 482 DOI 10.17487/RFC4610, August 2006, 483 . 485 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 486 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 487 DOI 10.17487/RFC5771, March 2010, 488 . 490 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 491 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 492 Multicast - Sparse Mode (PIM-SM): Protocol Specification 493 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 494 2016, . 496 8.2. Informative References 498 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 499 Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, 500 . 502 [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: 503 Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, 504 September 2001, . 506 [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific 507 Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 508 2003, . 510 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 511 Discovery Protocol (MSDP)", RFC 3618, 512 DOI 10.17487/RFC3618, October 2003, 513 . 515 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 516 Protocol Specification", RFC 3913, DOI 10.17487/RFC3913, 517 September 2004, . 519 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 520 Independent Multicast - Dense Mode (PIM-DM): Protocol 521 Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, 522 January 2005, . 524 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 525 "Considerations for Internet Group Management Protocol 526 (IGMP) and Multicast Listener Discovery (MLD) Snooping 527 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 528 . 530 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 531 Group Management Protocol Version 3 (IGMPv3) and Multicast 532 Listener Discovery Protocol Version 2 (MLDv2) for Source- 533 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 534 August 2006, . 536 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 537 Independent Multicast - Sparse Mode (PIM-SM) Multicast 538 Routing Security Issues and Enhancements", RFC 4609, 539 DOI 10.17487/RFC4609, October 2006, 540 . 542 [RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source 543 Discovery Protocol (MSDP) Deployment Scenarios", BCP 121, 544 RFC 4611, DOI 10.17487/RFC4611, August 2006, 545 . 547 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 548 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 549 March 2017, . 551 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 552 Ed., and R. Krishnan, "Use of Multicast across Inter- 553 domain Peering Points", BCP 213, RFC 8313, 554 DOI 10.17487/RFC8313, January 2018, 555 . 557 [I-D.ietf-6man-rfc6434-bis] 558 Chown, T., Loughney, J., and T. Winters, "IPv6 Node 559 Requirements", draft-ietf-6man-rfc6434-bis-09 (work in 560 progress), July 2018. 562 Authors' Addresses 564 Mikael Abrahamsson 565 T-Systems 566 Stockholm 567 Sweden 569 Email: mikael.abrahamsson@t-systems.se 570 Tim Chown 571 Jisc 572 Lumen House, Library Avenue 573 Harwell Oxford, Didcot OX11 0SG 574 United Kingdom 576 Email: tim.chown@jisc.ac.uk 578 Lenny Giuliano 579 Juniper Networks, Inc. 580 2251 Corporate Park Drive 581 Herndon, Virginia 20171 582 United States 584 Email: lenny@juniper.net 586 Toerless Eckert 587 Futurewei Technologies Inc. 588 2330 Central Expy 589 Santa Clara 95050 590 USA 592 Email: tte+ietf@cs.fau.de