idnits 2.17.1 draft-acg-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 (July 2, 2018) is 2125 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) == Outdated reference: A later version (-09) exists of draft-ietf-6man-rfc6434-bis-08 Summary: 0 errors (**), 0 flaws (~~), 3 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: January 3, 2019 Jisc 6 L. Giuliano 7 Juniper Networks, Inc. 8 T. Eckert 9 Huawei 10 July 2, 2018 12 Deprecating ASM for Interdomain Multicast 13 draft-acg-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 that are expected to handle 21 such applications fully support SSM. The recommendations in this 22 document do not preclude the continued use of ASM within a single 23 organisation or domain, and are especially easy to adopt when already 24 using the preferred ASM protocol options there (PIM-SM). 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 January 3, 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 . . . . . . . . . . . . . . . . . . 5 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 . . . . . . 8 77 4.3. Building application support for SSM . . . . . . . . . . 8 78 4.4. Preferring SSM applications intradomain . . . . . . . . . 9 79 4.5. Documenting common practices for SSM support in 80 applications. . . . . . . . . . . . . . . . . . . . . . . 9 81 4.6. Documenting an ASM/SSM protocol mapping mechanism . . . . 10 82 4.7. Not filtering ASM addressing between domains . . . . . . 10 83 4.8. Not precluding Intradomain ASM . . . . . . . . . . . . . 10 84 5. Congestion Control Considerations . . . . . . . . . . . . . . 11 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 9.2. Informative References . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 IP Multicast has been deployed in various forms, within private 96 networks, the wider Internet, and federated networks such as national 97 or regional research networks. While a number of service models have 98 been published, and in many cases revised over time, there has been 99 no strong recommendation made by the IETF on the appropriateness of 100 those models to certain scenarios, even though vendors and 101 federations have often made such recommendations. 103 This document addresses this gap by making a BCP-level recommendation 104 to deprecate the use of ASM for interdomain multicast, leaving SSM as 105 the remaining interdomain mode of multicast. This recommendation 106 thus also implicitly states that all hosts and routers that are 107 expected to support interdomain multicast applications fully support 108 SSM. 110 This document does not make any statement on the use of ASM within a 111 single domain or organisation, and therefore does not preclude its 112 use. Indeed, there are application contexts for which ASM is 113 currently still widely considered well-suited within a single domain. 115 The main issue in most cases with moving to SSM is application 116 support. Many applications will first get used intradomain but only 117 later interdomain. Therefore, this document recommends making 118 applications support SSM, even when they are initially meant to be 119 just used intradomain. As explained below, SSM applications are 120 readily compatible with existing intradomain ASM deployments that 121 follow the current IETF standard protocol recommendations. 123 2. Multicast routing protocols 125 The general IP multicast service model [RFC1112] is that sender(s) 126 send to a multicast group address, receivers express an interest in 127 traffic sent to a given multicast group address, and that routers use 128 multicast routing protocols to determine how to deliver traffic from 129 the sender(s) to the receivers. 131 Two high-level flavours of this service model have evolved over time. 132 In Any-Source Multicast (ASM), any number of sources may transmit 133 multicast packets, and those sources may come and go over the course 134 of a multicast session without being known a priori. In ASM, 135 receivers express interest only in a given multicast group address, 136 and the multicast routing protocol facilitates source discovery at 137 the network layer. ASM is simply the name given to the 1989 RFC1112 138 IP Multicast model when in around 2000 the idea for the alternative 139 SSM model was taking shape: In Source-Specific Multicast (SSM) the 140 specific source(s) that may send traffic to the group are known in 141 advance by the receivers, or may be determined during a session, 142 typically through an out-of-band protocol sitting above the network 143 layer. Thus in SSM, receivers express interest in both a multicast 144 group address and specific associated source address(es). 146 IANA has reserved specific ranges of IPv4 and IPv6 address space for 147 multicast addressing. Guidelines for IPv4 multicast address 148 assignments can be found in [RFC5771], while guidelines for IPv6 149 multicast address assignments can be found in [RFC2375] and 150 [RFC3307]. The IPv6 multicast address format is described in 151 [RFC4291]. 153 2.1. ASM routing protocols 155 The most commonly deployed ASM routing protocol is Protocol 156 Independent Multicast - Sparse Mode, or PIM-SM, as detailed in 157 [RFC7761]. PIM-SM, as the name suggests, was designed to be used in 158 scenarios where the subnets with receivers are sparsely distributed 159 throughout the network. Because it does not know sender addresses in 160 advance, PIM-SM uses the concept of a Rendezvous Point (RP) to 'marry 161 up' senders and receivers, and all routers in a PIM-SM domain are 162 configured to use specific RP(s), either explicitly or through 163 dynamic RP discovery protocols. 165 To enable PIM-SM to work between multiple domains, i.e., to allow an 166 RP in one domain to learn the existence of a source in another 167 domain, an inter-RP signalling protocol known as Multicast Source 168 Discovery Protocol (MSDP) [RFC3618] is used. Deployment scenarios 169 for MSDP are given in [RFC4611]. MSDP has remained an Experimental 170 protocol since its publication in 2003. One core reason for this is 171 the need to flood information about all active sources for all active 172 applications to the RPs in all the domains in an MSDP peering mesh - 173 even if there is no receiver for a given application in a domain. 174 This is the key scalability and security issue with MSDP and also the 175 reason why it was not extended to support IPv6. 177 To this day, there is no IETF Proposed Standard level interdomain 178 solution for IPv4 ASM multicast because MSDP was the "best" component 179 for the interdomain discovery problem, and it stayed Experimental. 180 Other protocol options where investigated at the same time but did 181 achieve at most achieve IETF informational status and are now 182 historic (e.g: [RFC3913]). 184 Due to the availability of more bits in an IPv6 address than in IPv4, 185 an IPv6-specific mechanism was able to be designed in support of 186 interdomain ASM with PIM-SM. Embedded-RP [RFC3956] allows routers 187 supporting the protocol to determine the RP for the group without any 188 prior configuration or discovery protocols, simply by observing the 189 unicast RP address that is embedded (included) in the IPv6 multicast 190 group address. Embedded-RP allows PIM-SM operation across any IPv6 191 network (intradomain but especially interdomain) in which there is an 192 end-to-end path of routers supporting the mechanism. 194 2.2. SSM Routing protocols 196 SSM is detailed in [RFC4607]. It is in effect a subset of PIM-SM 197 where no RP is used. Note that there is no separate document for 198 PIM-SSM, it just leverages a subset of [RFC7761]. 200 PIM-SSM expects that sender source address(es) are known in advance 201 by receivers; i.e., a given source's IP address is known (by some out 202 of band mechanism), and thus the receiver's router can send a PIM 203 JOIN directly towards the sender, without needing to use an RP. 205 IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 206 designated as source-specific multicast (SSM) destination addresses 207 and are reserved for use by source-specific applications and 208 protocols. See [RFC4607]. For IPv6, the address prefix FF3x::/32 is 209 reserved for source-specific multicast use. 211 3. Discussion 213 3.1. Observations on ASM and SSM deployments 215 In enterprise and campus scenarios, ASM in the form of PIM-SM is 216 likely the most commonly deployed multicast protocol and has 217 generally replaced PIM-DM [RFC3973], which is an IETF Experimental 218 category RFC, while PIM-SM is full Internet Standard. The 219 configuration and management of an RP (even with RP redundancy) 220 within a single domain is well understood operational practice. 221 However, if interworking with external PIM domains is needed in IPv4 222 multicast deployments, interdomain MSDP is required to exchange 223 information about sources between domain RPs. The problems with this 224 use of MSDP are as explained above. They are the problems that make 225 MSDP an Experimental protocol, and that make it (in these 226 deployments) a complex and fragile protocol to administer and 227 troubleshoot (flooding RPF rules, state attack protection, undesired 228 source filtering, ...). 230 PIM-SM is a general purpose protocol that can handle all use cases. 231 In particular, it was designed for cases such as videoconferencing 232 where multiple sources may come and go during a multicast session. 233 But for cases where a single, persistent source for a group is used, 234 and receivers can be configured to know of that source, PIM-SM has 235 unnecessary complexity. In these applications it is typically only 236 necessary to extend the configuration or signaling for the IP 237 multicast group to be used with the additional information on the IP 238 multicast source to be used. There are also various techniques to 239 use a single logical "anycast" source address supported by two or 240 more redundant senders to give additional reliability for SSM, and to 241 offer simpler deployment by using that address as a "static"/"well- 242 known" address. 244 As explained above, MSDP was not taken forward to IPv6. Instead, the 245 proposed interdomain ASM solution for PIM-SM with IPv6 is Embedded- 246 RP, which allows the RP address for a multicast group to be embedded 247 in the group address, making RP discovery automatic, if all routers 248 on the path between a receiver and a sender support the protocol. 249 Embedded-RP can support lightweight ad-hoc deployments. However, it 250 relies on a single RP for an entire group that could only be made 251 resilient within one domain. While this approach solves the MSDP 252 issues, it does not solve the problem of unauthorised sources sending 253 traffic to ASM multicast groups; this security issues is one of 254 biggest problem of interdomain multicast. Embedded-RP was run 255 successfully between European and US academic networks during the 256 6NET project in 2004/05. Its usage generally remains constrained to 257 academic networks. 259 As stated in RFC 4607, SSM is particularly well-suited to 260 dissemination-style applications with one or more senders whose 261 identities are known (by some mechanism) before the application 262 starts running - or applications that have some existing signaling 263 indicating multicast groups, where the additional source address can 264 easily be added - for example electronic programming guide signalling 265 in IPTV applications. PIM-SSM is therefore very well-suited to 266 applications such as classic linear broadcast TV over IP. 268 SSM requires applications, host operating systems and their subnet 269 routers using it to support the new(er) IGMPv3 [RFC3376] and MLDv2 270 [RFC3810] protocols. While delayed delivery of support in some OSes 271 has meant that adoption of SSM has been slower than might have been 272 expected, or hoped, and was a historical reason to use ASM rather 273 than SSM, support for IGMPv3 and MLDv2 has become widespread in 274 common OSes for several years (Windows, MacOS, Linux/Android). 276 3.2. Advantages of SSM for interdomain multicast 278 A significant benefit of SSM is its reduced complexity through 279 eliminating the network-based source discovery required in ASM. This 280 means there are no RPs, shared trees, Shortest Path Tree (SPT) 281 switchovers, PIM registers, MSDP, or data-driven state creation 282 elements to support, or any requirement to run dynamic RP discovery 283 and redundancy signaling protocols such as BSR. SSM is really just a 284 small subset of PIM-SM, alongside the integration with IGMPv3 / MLDv2 285 where the source address signaled from the receiver is immediately 286 used to create (S,G) state. Eliminating network-based source 287 discovery for interdomain multicast means the vast majority of the 288 complexity issues go away. 290 This reduced complexity makes SSM radically simpler to manage, 291 troubleshoot and operate, particularly for network backbone 292 operators, and this is the main operator motivation for the 293 recommendation to deprecate the use of ASM in interdomain scenarios. 294 Note that SSM operation is all standardised in PIM-SM (RFC7761). 295 There is no separate specification for PIM-SSM. 297 RFC 4607 details many benefits of SSM, including: 299 "Elimination of cross-delivery of traffic when two sources 300 simultaneously use the same source-specific destination address; 302 Avoidance of the need for inter-host coordination when choosing 303 source-specific addresses, as a consequence of the above; 305 Avoidance of many of the router protocols and algorithms that are 306 needed to provide the ASM service model." 308 Further discussion can also be found in [RFC3569]. 310 SSM is considered more secure in that it supports access control, 311 i.e. you only get packets from the sources you explicitly ask for, as 312 opposed to ASM where anyone can decide to send traffic to a PIM-SM 313 group address. This topic is expanded upon in [RFC4609]. 315 4. Recommendations 317 4.1. Deprecating use of ASM for interdomain multicast 319 This document recommends that the use of ASM is deprecated for 320 interdomain multicast, and thus implicitly that hosts and routers 321 that are expected to support such interdomain applications fully 322 support SSM and its associated protocols. Best current practices for 323 deploying interdomain multicast using SSM are documented in 324 [RFC8313]. 326 The recommendation applies to the use of ASM between domains where 327 either MSDP (IPv4) or Embedded-RP (IPv6) is used for sharing 328 knowledge of remote sources (MSDP) or RPs (Embedded-RP). 330 This document also recommends against the interdomain use of PIM-SM 331 with a (potentially redundant) RP, where multicast tunnels are used 332 between domains. 334 An interdomain use of ASM multicast in the context of this document 335 is primarily one where PIM-SM for ASM, e.g., with RPs/MSDP/Embedded- 336 RP, is run on routers operated by two or more separate operational 337 entities (domains, organisations). 339 The more inclusive interpretation of this recommendation is that it 340 also extends to the case where PIM may only be operated in a single 341 operator domain, but where user hosts or non-PIM network edge devices 342 are under different operator control. A typical example of this case 343 is an SP providing IPTV (single operator domain for PIM) to 344 subscribers operating an IGMP proxy home gateway and IGMPv3/MLDv2 345 hosts (computer, tablets, set-top boxes). 347 While MSDP is an Experimental category IETF standard, this document 348 does not propose making MSDP Historic, given its use may be desirable 349 for intradomain multicast use cases (e.g., RP redundancy 350 intradomain). This may change in future documents should a successor 351 to MSDP for intradomain RP redundancy ([RFC4610]) be defined to add 352 better support for some currently missing operational requirements. 354 4.2. Including network support for IGMPv3 / MLDv2 356 This document recommends that all host and router platforms 357 supporting multicast, and any security appliances that may handle 358 multicast traffic, support IGMPv3 [RFC3376] and MLDv2 [RFC3810] 359 (based on the version IP they intend to support). The updated IPv6 360 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states that MLDv2 361 support is a MUST in all implementations. Such support is already 362 widespread in common host and router platforms. 364 Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. 366 It is sometimes desirable to limit the propagation of multicast 367 messages in a layer 2 network, typically through a layer 2 switch 368 device. In such cases multicast snooping can be used, by which the 369 switch device observes the IGMP/MLD traffic passing through it, and 370 then attempts to make intelligent decisions about on which physical 371 ports it should forward multicast. Typically, ports that have not 372 expressed an interest in receiving multicast for a given group would 373 not have traffic for that group forwarded through them. Such 374 snooping capability should therefore support IGMPv3 and MLDv2. There 375 is further discussion in [RFC4541]. 377 4.3. Building application support for SSM 379 There is a wide range of applications today that only support ASM 380 (mostly for historic reasons), whether as software packages, or code 381 embedded in devices such as set-top boxes. 383 The recommendation to use SSM for interdomain multicast means that 384 applications should use SSM, and operate correctly in an SSM 385 environment, triggering IGMPv3/MLDv2 messages to signal use of SSM. 387 It is often thought that ASM is required for multicast applications 388 where there are multiple sources. However, RFC 4607 also describes 389 how SSM can be used instead of PIM-SM for multi-party applications: 391 "SSM can be used to build multi-source applications where all 392 participants' identities are not known in advance, but the multi- 393 source "rendezvous" functionality does not occur in the network 394 layer in this case. Just like in an application that uses unicast 395 as the underlying transport, this functionality can be implemented 396 by the application or by an application-layer library." 398 Given all common OSes support SSM, it is then down to the programming 399 language and APIs used as to whether the necessary SSM APIs are 400 available. SSM support became first ubiquitous for C/C++/Python, and 401 key exceptions today include websockets used in web-browser based 402 applications (see e.g.: https://github.com/nodejs/node/pull/15735/ 403 files introducing SSM support there in 2017). 405 Some useful considerations for multicast applications can still be 406 found in the relatively old [RFC3170]. 408 4.4. Preferring SSM applications intradomain 410 If feasible, it is recommended to make applications use SSM, even if 411 they are initially only meant to be used in intradomain environments 412 supporting ASM. Because PIM-SSM is a subset of PIM-SM, it should be 413 possible to readily make existing intradomain PIM-SM networks 414 compatible with SSM application receivers, therefore allowing 415 continued use of an existing ASM PIM-SM deployment in a network with 416 no or very little changes. SSM's benefits of simplified address 417 management and significantly reduced operational complexity apply 418 equally to intradomain use. 420 However, for some applications it may be prohibitively difficult to 421 add support for signaling of source IP addresses into the 422 application. 424 4.5. Documenting common practices for SSM support in applications. 426 Currently, there is no good document summarising best current 427 practices to convert ASM applications into SSM applications, or how 428 to most easily support SSM in greenfield application designs. This 429 would be useful guidance for the IETF to work on. 431 4.6. Documenting an ASM/SSM protocol mapping mechanism 433 In the case of existing ASM applications that cannot readily be 434 ported to SSM, it may be possible to use some form of protocol 435 mapping, i.e., to have a mechanism to translate a (*,G) join or leave 436 to a (S,G) join or leave, for a specific source, S. The general 437 challenge in performing such mapping is determining where the 438 configured source address, S, comes from. 440 There are existing vendor-specific mechanisms deployed that achieve 441 this function, but none are documented in IETF documents. This 442 appears to be a useful area for the IETF to work on, but it should be 443 noted that any such effort would only be an interim transition 444 mechanism, and such mappings do not remove the requirement for 445 applications to be allocated ASM group addresses for the 446 communications. 448 The reason why these mechanisms should not be considered a long-term 449 solution is because they introduce network operator management work, 450 and need some form of address management, both of which are not 451 required in SSM. 453 4.7. Not filtering ASM addressing between domains 455 A key benefit of SSM is that a multicast application does not need to 456 be allocated a specific multicast group by the network, rather as SSM 457 is inherently source-specific, it can use any group address, G, in 458 the reserved range of IPv4 or IPv6 SSM addresses for its own source 459 address, S. 461 In principle, if interdomain ASM is deprecated, backbone operators 462 could begin filtering the ranges of group addresses used by ASM. In 463 practice, this is not recommended given there will be a transition 464 period from ASM to SSM, where some form of ASM-SSM mappings may be 465 used, and filtering may preclude such operations. 467 4.8. Not precluding Intradomain ASM 469 The use of ASM within a single multicast domain, such as a campus or 470 enterprise, with an RP for the site, is still relatively common 471 today. There are even global enterprise networks that have 472 successfully been using PIM-SM for many years. The operators of such 473 networks most often use Anycast-RP [RFC4610] or MSDP for RP 474 resilience, at the expense of the extra complexity in managing that 475 configuration. These existing practices are unaffected by this 476 document. 478 This document does not preclude continued use of ASM in the 479 intradomain scenario. If an organisation, or AS, wishes to use 480 multiple multicast domains within its own network border, that is a 481 choice for that organisation to make, and it may then use MSDP or 482 Embedded-RP internally within its own network. 484 5. Congestion Control Considerations 486 Traffic over non-controlled networks, which most interdomain paths 487 are, must support congestion control. This is achievable with rate 488 adaptation, layered codecs, circuit breakers and/or other appropriate 489 mechanisms. See [RFC8085]. 491 6. Security Considerations 493 This document adds no new security considerations. It instead 494 removes security issues incurred by interdomain ASM with PIM-SM/MSDP: 495 infrastructure control plane attacks and application and bandwidth/ 496 congestion attacks from unauthorised sources sending to ASM multicast 497 groups. RFC 4609 describes the additional security benefits of using 498 SSM instead of ASM. 500 7. IANA Considerations 502 This document makes no request of IANA. 504 Note to RFC Editor: this section may be removed upon publication as 505 an RFC. 507 8. Acknowledgments 509 The authors would like to thank members of the IETF mboned WG for 510 discussions on the content of this document, with specific thanks to 511 the following people for their contributions to the document: Hitoshi 512 Asaeda, Dale Carder, Jake Holland, Albert Manfredi, Mike McBride, Per 513 Nihlen, Greg Shepherd, James Stevens, Stig Venaas, Nils Warnke, and 514 Sandy Zhang. 516 9. References 518 9.1. Normative References 520 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 521 RFC 1112, DOI 10.17487/RFC1112, August 1989, 522 . 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, 526 DOI 10.17487/RFC2119, March 1997, 527 . 529 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 530 Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, 531 . 533 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 534 Thyagarajan, "Internet Group Management Protocol, Version 535 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 536 . 538 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 539 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 540 DOI 10.17487/RFC3810, June 2004, 541 . 543 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 544 Point (RP) Address in an IPv6 Multicast Address", 545 RFC 3956, DOI 10.17487/RFC3956, November 2004, 546 . 548 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 549 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 550 2006, . 552 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 553 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 554 . 556 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 557 Independent Multicast (PIM)", RFC 4610, 558 DOI 10.17487/RFC4610, August 2006, 559 . 561 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 562 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 563 DOI 10.17487/RFC5771, March 2010, 564 . 566 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 567 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 568 Multicast - Sparse Mode (PIM-SM): Protocol Specification 569 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 570 2016, . 572 9.2. Informative References 574 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 575 Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, 576 . 578 [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: 579 Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, 580 September 2001, . 582 [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific 583 Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 584 2003, . 586 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 587 Discovery Protocol (MSDP)", RFC 3618, 588 DOI 10.17487/RFC3618, October 2003, 589 . 591 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 592 Protocol Specification", RFC 3913, DOI 10.17487/RFC3913, 593 September 2004, . 595 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 596 Independent Multicast - Dense Mode (PIM-DM): Protocol 597 Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, 598 January 2005, . 600 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 601 "Considerations for Internet Group Management Protocol 602 (IGMP) and Multicast Listener Discovery (MLD) Snooping 603 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 604 . 606 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 607 Group Management Protocol Version 3 (IGMPv3) and Multicast 608 Listener Discovery Protocol Version 2 (MLDv2) for Source- 609 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 610 August 2006, . 612 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 613 Independent Multicast - Sparse Mode (PIM-SM) Multicast 614 Routing Security Issues and Enhancements", RFC 4609, 615 DOI 10.17487/RFC4609, October 2006, 616 . 618 [RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source 619 Discovery Protocol (MSDP) Deployment Scenarios", BCP 121, 620 RFC 4611, DOI 10.17487/RFC4611, August 2006, 621 . 623 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 624 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 625 March 2017, . 627 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 628 Ed., and R. Krishnan, "Use of Multicast across Inter- 629 domain Peering Points", BCP 213, RFC 8313, 630 DOI 10.17487/RFC8313, January 2018, 631 . 633 [I-D.ietf-6man-rfc6434-bis] 634 Chown, T., Loughney, J., and T. Winters, "IPv6 Node 635 Requirements", draft-ietf-6man-rfc6434-bis-08 (work in 636 progress), March 2018. 638 Authors' Addresses 640 Mikael Abrahamsson 641 T-Systems 642 Stockholm 643 Sweden 645 Email: mikael.abrahamsson@t-systems.se 647 Tim Chown 648 Jisc 649 Lumen House, Library Avenue 650 Harwell Oxford, Didcot OX11 0SG 651 United Kingdom 653 Email: tim.chown@jisc.ac.uk 655 Lenny Giuliano 656 Juniper Networks, Inc. 657 2251 Corporate Park Drive 658 Hemdon, Virginia 20171 659 United States 661 Email: lenny@juniper.net 662 Toerless Eckert 663 Futurewei Technologies Inc. 664 2330 Central Expy 665 Santa Clara 95050 666 USA 668 Email: tte+ietf@cs.fau.de