idnits 2.17.1 draft-acg-mboned-multicast-models-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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 164: '... 32-bit ASN MAY apply for space in A...' RFC 2119 keyword, line 437: '... support is a MUST in all implementa...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2370 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) ** Downref: Normative reference to an Informational RFC: RFC 2375 ** Downref: Normative reference to an Informational RFC: RFC 3170 ** Downref: Normative reference to an Informational RFC: RFC 3569 ** Downref: Normative reference to an Experimental RFC: RFC 3618 ** Downref: Normative reference to an Experimental RFC: RFC 3973 == Outdated reference: A later version (-14) exists of draft-ietf-mboned-interdomain-peering-bcp-13 == Outdated reference: A later version (-09) exists of draft-ietf-6man-rfc6434-bis-02 Summary: 6 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: May 3, 2018 Jisc 6 L. Giuliano 7 Juniper Networks, Inc. 8 October 30, 2017 10 Deprecating ASM for Interdomain Multicast 11 draft-acg-mboned-multicast-models-02 13 Abstract 15 This document provides a high-level overview of more commonly used 16 multicast service models, principally the Any-Source Multicast (ASM) 17 and Source-Specific Multicast (SSM) models, and discusses the 18 applicability of the models to certain scenarios. As a result, this 19 document recommends that ASM is not used for interdomain scenarios, 20 and the use of SSM is strongly recommended for all multicast 21 scenarios. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 3, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Multicast service models . . . . . . . . . . . . . . . . . . 3 59 3. Multicast building blocks . . . . . . . . . . . . . . . . . . 4 60 3.1. Multicast addressing . . . . . . . . . . . . . . . . . . 4 61 3.2. Host signalling . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Multicast snooping . . . . . . . . . . . . . . . . . . . 5 63 4. ASM service model protocols . . . . . . . . . . . . . . . . . 5 64 4.1. Protocol Independent Multicast, Dense Mode (PIM-DM) . . . 5 65 4.2. Protocol Independent Multicast, Sparse Mode (PIM-SM) . . 5 66 4.2.1. Interdomain PIM-SM, and MSDP . . . . . . . . . . . . 6 67 4.3. Bidirectional PIM (PIM-BIDIR) . . . . . . . . . . . . . . 6 68 4.4. IPv6 PIM-SM with Embedded RP . . . . . . . . . . . . . . 6 69 5. SSM service model protocols . . . . . . . . . . . . . . . . . 7 70 5.1. Source Specific Multicast (PIM-SSM) . . . . . . . . . . . 7 71 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. ASM Deployment . . . . . . . . . . . . . . . . . . . . . 7 73 6.2. SSM Deployment . . . . . . . . . . . . . . . . . . . . . 8 74 7. Recommendations on ASM and SSM deployment . . . . . . . . . . 8 75 7.1. Rationale - advantages of SSM . . . . . . . . . . . . . . 8 76 7.2. On deprecating interdomain ASM . . . . . . . . . . . . . 9 77 7.3. Intradomain ASM . . . . . . . . . . . . . . . . . . . . . 9 78 7.4. IGMPv3/MLDv2 support . . . . . . . . . . . . . . . . . . 10 79 7.5. Multicast addressing considerations . . . . . . . . . . . 10 80 7.6. Application considerations . . . . . . . . . . . . . . . 10 81 7.7. ASM/SSM transition - protocol mapping . . . . . . . . . . 11 82 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 88 12.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 IP Multicast has been deployed in various forms, both within private 94 networks and on the wider Internet. While a number of service models 95 have been published individually, and in many cases revised over 96 time, there has been no strong recommendation made on the 97 appropriateness of the models to certain scenarios. This document 98 aims to fill that gap, and includes a BCP-level recommendation to 99 both deprecate the use of interdomain ASM and to promote the use of 100 SSM for all multicast scenarios. 102 2. Multicast service models 104 The general IP multicast service model [RFC1112] is that senders send 105 to a multicast IP group address, receivers express an interest in 106 traffic sent to a given multicast address, and that routers figure 107 out how to deliver traffic from the senders to the receivers. 109 The benefit of IP multicast is that it enables delivery of content 110 such that any multicast packet sent from a source to a given 111 multicast group address appears once and only once on any path 112 between a sender and an interested receiver that has joined that 113 multicast group. The principal advantage, in terms of bandwidth 114 conservation will lie with the sender, i.e., at the head end. 116 A reserved range of IP multicast group addresses (for either IPv4 or 117 IPv6) is used for multicast group communication, as described in 118 Section 3.1. 120 Two high-level flavours of this service model have evolved over time. 121 In Any-Source Multicast (ASM), any number of sources may transmit 122 multicast packets, and those sources may come and go over the course 123 of a multicast session without being known a priori. In ASM, 124 receivers express interest only in a given multicast group address. 125 In contrast, with Source-Specific Multicast (SSM) the specific 126 source(s) that may send traffic to the group are known in advance. 127 In SSM, receivers express interest both in a given multicast address 128 and specific associated source address(es). 130 Senders transmit multicast packets without knowing where receivers 131 are, or how many there are. Receivers are able to signal to on-link 132 routers their desire to receive multicast content sent to a given 133 multicast group, and in the case of SSM from a specific sender IP 134 address. They may discover the group (and sender IP) information in 135 a number of different ways. They are also able to signal their 136 desire to no longer receive multicast traffic for a given group (and 137 sender IP). 139 Multicast routing protocols are used to establish the multicast 140 forwarding paths (tree) between a sender and a set of receivers. 141 Each router would typically maintain multicast forwarding state for a 142 given group (and potentially sender IP), such that it knows on which 143 interfaces to forward (and where necessary replicate) multicast 144 packets. 146 Multicast packet forwarding is generally not considered a reliable 147 service. It is typically unidirectional, but a bidirectional 148 multicast delivery mechanism also exists. 150 3. Multicast building blocks 152 In this section we describe general multicast building blocks that 153 are applicable to both ASM and SSM deployment. 155 3.1. Multicast addressing 157 IANA has reserved specific ranges of IPv4 and IPv6 address space for 158 multicast addressing. 160 Guidelines for IPv4 multicast address assignments can be found in 161 [RFC5771]. IPv4 has no explicit multicast address format; a specific 162 portion of the overall IPv4 address space is reserved for multicast 163 use (224.0.0.0/4). As per Section 9 of RFC5771, domains with a 164 32-bit ASN MAY apply for space in AD-HOC Block III, or instead 165 consider using IPv6 multicast addresses. 167 Guidelines for IPv6 multicast address assignments can be found in 168 [RFC2375] and [RFC3307]. The IPv6 multicast address format is 169 described in [RFC4291]. An IPv6 multicast group address will lie 170 within ff00::/8. 172 3.2. Host signalling 174 A host wishing to signal interest in receiving (or no longer 175 receiving) multicast to a given multicast group (and potentially from 176 a specific sender IP) may do so by sending a packet using one of the 177 protocols described below on an appropriate interface. 179 For IPv4, a host may use Internet Group Management Protocol Version 2 180 (IGMPv2) [RFC2236] to signal interest in a given group. IGMPv3 181 [RFC3376] has the added capability of specifying interest in 182 receiving multicast packets from specific sources. 184 For IPv6, a host may use Multicast Listener Discovery Protocol (MLD) 185 [RFC2710] to signal interest in a given group. MLDv2 [RFC3810] has 186 the added capability of specifying interest in receiving multicast 187 packets from specific sources. 189 Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. 191 3.3. Multicast snooping 193 In some cases, it is desirable to limit the propagation of multicast 194 messages in a layer 2 network, typically through a layer 2 switch 195 device. In such cases multicast snooping can be used, by which the 196 switch device observes the IGMP/MLD traffic passing through it, and 197 then attempts to make intelligent decisions on which physical ports 198 to forward multicast. Typically, ports that have not expressed an 199 interest in receiving multicast for a given group would not have 200 traffic for that group forwarded through them. There is further 201 discussion in [RFC4541]. 203 4. ASM service model protocols 205 4.1. Protocol Independent Multicast, Dense Mode (PIM-DM) 207 PIM-DM is detailed in [RFC3973]. It operates by flooding multicast 208 messages to all routers within the network in which it is configured. 209 This ensures multicast data packets reach all interested receivers 210 behind edge routers. Prune messages are used by routers to tell 211 upstream routers to (temporarily) stop forwarding multicast for 212 groups for which they have no known receivers. 214 PIM-DM remains an Experimental protocol since its publication in 215 2005. 217 4.2. Protocol Independent Multicast, Sparse Mode (PIM-SM) 219 The most recent revision of PIM-SM is detailed in [RFC7761]. PIM-SM 220 is, as the name suggests, was designed to be used in scenarios where 221 the subnets with receivers are sparsely distributed throughout the 222 network. PIM-SM supports any number of senders for a given multicast 223 group, which do not need to be known in advance, and which may come 224 and go through the session. PIM-SM does not use a flooding phase, 225 making it more scalable and efficient than PIM-DM, but this means 226 PIM-SM needs a mechanism to construct the multicast forwarding tree 227 (and associated forwarding tables in the routers) without flooding 228 the whole network. 230 To achieve this, PIM-SM introduces the concept of a Rendezvous Point 231 (RP) for a PIM domain. All routers in a PIM-SM domain are then 232 configured to use specific RP(s). Such configuration may be 233 performed by a variety of methods, including Anycast-RP [RFC4610]. 235 A sending host's Designated Router encapsulates multicast packets to 236 the RP, and a receiving host's Designated Router can forward PIM JOIN 237 messages to the RP, in so doing forming what is known as the 238 Rendezvous Point Tree (RPT). Optimisation of the tree may then 239 happen once the receiving host's router is aware of the sender's IP, 240 and a source-specific JOIN message may be sent towards it, in so 241 doing forming the Shortest Path Tree (SPT). Unnecessary RPT paths 242 are removed after the SPT is established. 244 4.2.1. Interdomain PIM-SM, and MSDP 246 PIM-SM can in principle operate over any network in which the 247 cooperating routers are configured with RPs. But in general, PIM-SM 248 for a given domain will use an RP configured for that domain. There 249 is thus a challenge in enabling PIM-SM to work between multiple 250 domains, i.e. to allow an RP in one domain to learn the existence of 251 a source in another domain, such that a receiver's router in one 252 domain can know to forward a PIM JOIN towards a source's Designated 253 Router in another domain. The solution to this problem is to use an 254 inter-RP signalling protocol known as Multicast Source Discovery 255 Protocol (MSDP). [RFC3618]. 257 Deployment scenarios for MSDP are given in [RFC4611]. MSDP remains 258 an Experimental protocol since its publication in 2003. MSDP was not 259 replicated for IPv6. 261 4.3. Bidirectional PIM (PIM-BIDIR) 263 PIM-BIDIR is detailed in [RFC5015]. In contrast to PIM-SM, it can 264 establish bi-directional multicast forwarding trees between multicast 265 sources and receivers. 267 4.4. IPv6 PIM-SM with Embedded RP 269 Within a single PIM domain, PIM-SM for IPv6 works largely the same as 270 it does for IPv4. However, the size of the IPv6 address (128 bits) 271 allows a different mechanism for multicast routers to determine the 272 RP for a given multicast group address. Embedded-RP [RFC3956] 273 specifies a method to embed the unicast RP IP address in an IPv6 274 multicast group address, allowing routers supporting the protocol to 275 determine the RP for the group without any prior configuration, 276 simply by observing the RP address that is embedded (included) in the 277 group address. 279 Embedded-RP allows PIM-SM operation across any IPv6 network in which 280 there is an end-to-end path of routers supporting the protocol. By 281 embedding the RP address in this way, multicast for a given group can 282 operate interdomain without the need for an explicit source discovery 283 protocol (i.e. without MSDP for IPv6). It would generally be 284 desirable that the RP would be located close to the sender(s) in the 285 group. 287 5. SSM service model protocols 289 5.1. Source Specific Multicast (PIM-SSM) 291 PIM-SSM is detailed in [RFC4607]. In contrast to PIM-SM, PIM-SSM 292 benefits from assuming that source(s) are known about in advance, 293 i.e. the source IP address is known (by some out of band mechanism), 294 and thus the receiver's router can send a PIM JOIN directly towards 295 the sender, without needing to use an RP. 297 IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 298 designated as source-specific multicast (SSM) destination addresses 299 and are reserved for use by source-specific applications and 300 protocols. For IPv6, the address prefix FF3x::/32 is reserved for 301 source-specific multicast use. 303 6. Discussion 305 In this section we discuss the applicability of the ASM and SSM 306 models described above, and their associated protocols, to a range of 307 deployment scenarios. 309 6.1. ASM Deployment 311 PIM-DM remains an Experimental protocol, that appears to be rarely 312 used in campus or enterprise environments. 314 In enterprise and campus scenarios, PIM-SM is in relatively common 315 use. The configuration and management of an RP within a single 316 domain is not onerous. However, if interworking with external PIM 317 domains in IPv4 multicast deployments is needed, MSDP is required to 318 exchange information between domain RPs about sources. MSDP remains 319 an Experimental protocol, and can be a complex and fragile protocol 320 to administer and troubleshoot. MSDP is also specific to IPv4; it 321 was not carried forward to IPv6, in no small part due to the 322 complexity of operation and troubleshooting. 324 PIM-SM is a general purpose protocol that can handle all use cases. 325 In particular, it was designed for cases where one or more sources 326 may came and go during a multicast session. For cases where a 327 single, persistent source is used, and receivers can be configured to 328 know of that source, PIM-SM has unnecessary complexity. 330 As stated above, MSDP was not taken forward to IPv6. Instead, IPv6 331 has Embedded-RP, which allows the RP address for a multicast group to 332 be embedded in the group address, making RP discovery automatic, if 333 all routers on the path between a receiver and a sender support the 334 protocol. Embedded-RP can support lightweight ad-hoc deployments. 336 However, it does rely on a single RP for an entire group. Embedded- 337 RP was run successfully between European and US academic networks 338 during the 6NET project in 2004/05. Its usage generally remains 339 constrained to academic networks. 341 BIDIR-PIM is designed, as the name suggests, for bidirectional use 342 cases. 344 6.2. SSM Deployment 346 As stated in RFC4607, SSM is particularly well-suited to 347 dissemination-style applications with one or more senders whose 348 identities are known (by some mechanism) before the application 349 starts running. PIM-SSM is therefore very well-suited to 350 applications such as classic linear broadcast TV over IP. 352 SSM requires hosts using it and (edge) routers with SSM receivers 353 support the new(er) IGMPv3 and MLDv2 protocols. While delayed 354 delivery of support in some OSes has meant that adoption of SSM has 355 also been slower than might have been expected, or hoped, support for 356 SSM is now widespread in common OSes. 358 7. Recommendations on ASM and SSM deployment 360 This document recommends that the use of interdomain ASM is 361 deprecated, i.e., only SSM is to be used for interdomain multicast. 362 Further, it also strongly recommends the use of SSM for all multicast 363 scenarios, be they run inter or intradomain. 365 7.1. Rationale - advantages of SSM 367 A significant benefit of SSM is its reduced complexity through 368 eliminating the network-based source discovery required in ASM. This 369 means there are no RPs, shared trees, SPT switchover, PIM registers, 370 MSDP or data-driven state creation elements to support. SSM is 371 really just a small subset of PIM-SM, plus IGMPv3. 373 This reduced complexity makes SSM radically simpler to manage, 374 troubleshoot and operate, particularly for network backbone 375 operators; this is the main motivation for the recommendation to 376 deprecate the use of ASM in interdomain scenarios. Interdomain ASM 377 is widely viewed as complicated and fragile. By eliminating network- 378 based source discovery for interdomain multicast, the vast majority 379 of the complexity issues go away. 381 RFC 4607 includes details benefits of SSM, for example: 383 "Elimination of cross-delivery of traffic when two sources 384 simultaneously use the same source-specific destination address; 386 Avoidance of the need for inter-host coordination when choosing 387 source-specific addresses, as a consequence of the above; 389 Avoidance of many of the router protocols and algorithms that are 390 needed to provide the ASM service model." 392 Further discussion can also be found in [RFC3569]. 394 SSM is considered more secure in that it supports access control, 395 i.e. you only get packets from the sources you explicitly ask for, as 396 opposed to ASM where anyone can decide to send traffic to a PIM-SM 397 group address. This topic is expanded upon in [RFC4609]. 399 7.2. On deprecating interdomain ASM 401 The recommendation to deprecate the use of interdomain ASM applies to 402 the use of ASM between domains, where either MSDP (IPv4) or Embedded- 403 RP (IPv6) is required for sharing knowledge of remote sources. 405 If an organisation, or AS, wishes to use multiple multicast domains 406 within its own network border, that is a choice for that organisation 407 to make, and it may then use MSDP or Embedded-RP internally within 408 its own network. 410 MSDP is an Experimental level standard; this document does not 411 propose making it Historic, given there may be such residual intra- 412 organisation use cases. 414 By implication, it is thus strongly recommended that SSM be the 415 multicast protocol of choice for interdomain multicast. Best current 416 practices for deploying interdomain multicast using SSM are 417 documented in [I-D.ietf-mboned-interdomain-peering-bcp]. 419 7.3. Intradomain ASM 421 The use of ASM within a single multicast domain, such as an 422 enterprise or campus, with an RP for the site, is relatively common 423 today. The site may also choose to use Anycast-RP or MSDP for RP 424 resilience, at the expense of the extra complexity in managing that 425 configuration. Regardless, this document does not preclude continued 426 use of ASM in the intradomain scenario. 428 However, it is strongly recommended that sites using ASM internally 429 conduct an audit of the multicast applications used, and begin 430 planning a migration to using SSM instead wherever possible. 432 7.4. IGMPv3/MLDv2 support 434 This document recommends that all host and router platforms 435 supporting multicast also support IGMPv3 and MLDv2. The updated IPv6 436 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states that MLDv2 437 support is a MUST in all implementations. Such support is already 438 widespread in common host and router platforms. 440 7.5. Multicast addressing considerations 442 A key benefit of SSM is that the multicast application does not need 443 to be allocated a specific multicast group by the network, rather as 444 SSM is inherently source-specific, it can use any group address, G, 445 in the reserved range of IPv4 or IPv6 SSM addresses for its own 446 source address, S. 448 In principle, if interdomain ASM is deprecated, backbone operators 449 could begin filtering the ranges of group addresses used by ASM. In 450 practice, this is not recommended given there will be a transition 451 period from ASM to SSM, as discussed in Section 7.7, where some form 452 of ASM-SSM mappings may be used, and filtering may preclude such 453 operations. 455 7.6. Application considerations 457 There will be a wide range of applications today that only support 458 ASM, whether as software packages, or code embedded in devices such 459 as set top boxes. 461 The strong recommendation in this document for use of SSM means that 462 applications should instead use SSM, should operate correctly in an 463 SSM environment, and thus trigger IGMPv3/MLDv2 messages to signal use 464 of SSM. 466 It is often thought that ASM is required for multicast applications 467 where there are multiple sources. However, RFC4607 also describes 468 how SSM can be used instead of PIM-SM for multi-party applications: 470 "SSM can be used to build multi-source applications where all 471 participants' identities are not known in advance, but the multi- 472 source "rendezvous" functionality does not occur in the network 473 layer in this case. Just like in an application that uses unicast 474 as the underlying transport, this functionality can be implemented 475 by the application or by an application-layer library." 477 Thus, in theory, it should be possible to port ASM-only applications 478 to be able to run using SSM, if an appropriate out-of-band mechanism 479 can be chosen to convey the participant source addresses. 481 Given all common OSes support SSM, it is then down to the programming 482 language and APIs used as to whether the necessary SSM APIs are 483 available. SSM support is generally quite ubiquitous, with the 484 current exception of websockets used in web-browser based 485 applications. 487 It is desirable that applications also support appropriate congestion 488 control, as described in [RFC8085], with appropriate codecs, to 489 achieve the necessary rate adaption. 491 It is recommended that application developers choosing to use 492 multicast, develop and engineer their applications to use SSM rather 493 than ASM. 495 Some useful considerations for multicast applications can still be 496 found in the relatively old [RFC3170]. 498 7.7. ASM/SSM transition - protocol mapping 500 In the case of existing ASM applications that cannot readily be 501 ported to SSM, it may be possible to use some form of protocol 502 mapping, i.e., to have a mechanism to translate a (*,G) join or leave 503 to a (S,G) join or leave, for a specific source, S. The general 504 challenge in performing such mapping is determining where the 505 configured source address, S, comes from. 507 There are some existing vendor-specific mechanisms to achieve this 508 function, but none are documented in IETF standards. This may be an 509 area for the IETF to work on, but it should be noted that any such 510 effort would only be an interim transition mechanism, and such 511 mappings do not remove the requirement for applications to be 512 allocated ASM group addresses for the communications. 514 It is generally considered better to work towards using SSM, and thus 515 pushing the source discovery problem from the network to the 516 application. 518 8. Conclusions 520 This document recommends that the use of interdomain ASM is 521 deprecated. It also recommends the use of SSM for all multicast 522 scenarios. Specific implications and considerations for the 523 recommendation are discussed. 525 9. Security Considerations 527 This document adds no new security considerations. RFC4609 describes 528 the additional security benefits of using SSM instead of ASM. 530 10. IANA Considerations 532 This document currently makes no request of IANA. 534 Note to RFC Editor: this section may be removed upon publication as 535 an RFC. 537 11. Acknowledgments 539 The authors would like to thank the following people for their 540 contributions to the document: Hitoshi Asaeda, Dale Carder, Toerless 541 Eckert, Jake Holland, Mike McBride, Per Nihlen, Greg Shepherd, Stig 542 Venaas, Nils Warnke, and Sandy Zhang. 544 12. References 546 12.1. Normative References 548 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 549 RFC 1112, DOI 10.17487/RFC1112, August 1989, 550 . 552 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 553 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 554 . 556 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 557 Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, 558 . 560 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 561 Listener Discovery (MLD) for IPv6", RFC 2710, 562 DOI 10.17487/RFC2710, October 1999, 563 . 565 [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: 566 Challenges and Solutions", RFC 3170, DOI 10.17487/RFC3170, 567 September 2001, . 569 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 570 Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, 571 . 573 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 574 Thyagarajan, "Internet Group Management Protocol, Version 575 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 576 . 578 [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific 579 Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 580 2003, . 582 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 583 Discovery Protocol (MSDP)", RFC 3618, 584 DOI 10.17487/RFC3618, October 2003, 585 . 587 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 588 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 589 DOI 10.17487/RFC3810, June 2004, 590 . 592 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 593 Point (RP) Address in an IPv6 Multicast Address", 594 RFC 3956, DOI 10.17487/RFC3956, November 2004, 595 . 597 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 598 Independent Multicast - Dense Mode (PIM-DM): Protocol 599 Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, 600 January 2005, . 602 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 603 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 604 2006, . 606 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 607 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 608 . 610 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 611 Independent Multicast (PIM)", RFC 4610, 612 DOI 10.17487/RFC4610, August 2006, 613 . 615 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 616 "Bidirectional Protocol Independent Multicast (BIDIR- 617 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 618 . 620 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 621 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 622 DOI 10.17487/RFC5771, March 2010, 623 . 625 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 626 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 627 Multicast - Sparse Mode (PIM-SM): Protocol Specification 628 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 629 2016, . 631 12.2. Informative References 633 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 634 "Considerations for Internet Group Management Protocol 635 (IGMP) and Multicast Listener Discovery (MLD) Snooping 636 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 637 . 639 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 640 Group Management Protocol Version 3 (IGMPv3) and Multicast 641 Listener Discovery Protocol Version 2 (MLDv2) for Source- 642 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 643 August 2006, . 645 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 646 Independent Multicast - Sparse Mode (PIM-SM) Multicast 647 Routing Security Issues and Enhancements", RFC 4609, 648 DOI 10.17487/RFC4609, October 2006, 649 . 651 [RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source 652 Discovery Protocol (MSDP) Deployment Scenarios", BCP 121, 653 RFC 4611, DOI 10.17487/RFC4611, August 2006, 654 . 656 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 657 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 658 March 2017, . 660 [I-D.ietf-mboned-interdomain-peering-bcp] 661 Tarapore, P., Sayko, R., Shepherd, G., Eckert, T., and R. 662 Krishnan, "Use of Multicast Across Inter-Domain Peering 663 Points", draft-ietf-mboned-interdomain-peering-bcp-13 664 (work in progress), October 2017. 666 [I-D.ietf-6man-rfc6434-bis] 667 Chown, T., Loughney, J., and T. Winters, "IPv6 Node 668 Requirements", draft-ietf-6man-rfc6434-bis-02 (work in 669 progress), October 2017. 671 Authors' Addresses 673 Mikael Abrahamsson 674 T-Systems 675 Stockholm 676 Sweden 678 Email: mikael.abrahamsson@t-systems.se 680 Tim Chown 681 Jisc 682 Lumen House, Library Avenue 683 Harwell Oxford, Didcot OX11 0SG 684 United Kingdom 686 Email: tim.chown@jisc.ac.uk 688 Lenny Giuliano 689 Juniper Networks, Inc. 690 2251 Corporate Park Drive 691 Hemdon, Virginia 20171 692 United States 694 Email: lenny@juniper.net