idnits 2.17.1 draft-ietf-mboned-ipv4-mcast-bcp-01.txt: -(224): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(239): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(415): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(455): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(501): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-ietf-mboned-ipv4-mcast-bcp-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-mboned-ipv4-mcast-bcp-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-mboned-ipv4-mcast-bcp-', but the file name used is 'draft-ietf-mboned-ipv4-mcast-bcp-01' == There are 19 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 6 instances 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: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 2003) is 7618 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CBT' is mentioned on line 319, but not defined ** Obsolete normative reference: RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 966 (Obsoleted by RFC 988) == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-00 ** Obsolete normative reference: RFC 1771 (ref. 'BGPV4') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2858 (ref. 'MBGP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2117 (ref. 'PIM-SM') (Obsoleted by RFC 2362) == Outdated reference: A later version (-20) exists of draft-ietf-msdp-spec-13 ** Downref: Normative reference to an Experimental draft: draft-ietf-msdp-spec (ref. 'MSDP') == Outdated reference: A later version (-03) exists of draft-nickless-ipv4-mcast-unusable-02 -- Possible downref: Normative reference to a draft: ref. 'UNUSABLE' ** Downref: Normative reference to an Informational RFC: RFC 3446 (ref. 'ANYCASTRP') Summary: 10 errors (**), 1 flaw (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft B. Nickless 2 Document: draft-ietf-mboned-ipv4-mcast-bcp- Argonne National 3 01.txt Laboratory 4 Expires: December 2003 June 2003 6 IPv4 Multicast Best Current Practice 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes best current practices for IPv4 multicast 32 deployment, both within and between PIM Domains and Autonomous 33 Systems. 35 Table of Contents 37 Status of this Memo................................................1 38 Abstract...........................................................1 39 Conventions used in this document..................................2 40 Scope..............................................................2 41 Introduction and Terminology.......................................2 42 Packet Forwarding..................................................3 43 Any Source Multicast...............................................3 44 Source Specific Multicast..........................................4 45 Multiprotocol BGP..................................................4 46 PIM Sparse Mode....................................................5 47 Internet Group Management Protocol.................................6 48 Multicast Source Discovery Protocol................................6 49 Model IPv4 Multicast-Capable BGPv4 Configuration...................7 50 Model IPv4 Multicast Inter-domain PIM Sparse Mode Configuration....7 51 Model PIM Sparse Mode Rendezvous Point Location....................8 52 Model MSDP Configuration Between Autonomous Systems................9 53 Advanced Configurations............................................9 54 Security Considerations...........................................10 55 Acknowledgements..................................................10 56 Normative References..............................................10 57 Non-Normative References..........................................11 58 Author's Address..................................................12 60 Overview 62 Current best practice for IPv4 multicast service provision uses four 63 different protocols: Internet Group Management Protcol, Protocol 64 Independent Multicast (Sparse Mode), Border Gateway Protocol with 65 multiprotocol extensions, and the Multicast Source Discovery 66 Protocol. This document outlines how these protocols work together 67 to provide end-to-end IPv4 multicast service. In addition, this 68 document describes best current practices for configuring these 69 protocols, individually and in combination. 71 Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC-2119 [RFC2119]. 77 Scope 79 This document is intended to provide basic information on how IPv4 80 Multicast routing is accomplished. It discusses the IPv4 Multicast 81 Service model based in IGMP; how PIM Sparse Mode is used to route 82 traffic within an Autonomous System; and how the Multiprotocol 83 extensions to BGPv4, PIM Sparse Mode, and the Multicast Source 84 Discovery Protocol are used to route traffic between Autonomous 85 Systems. Pointers to more sophisticated uses of these protocols are 86 provided. 88 Introduction and Terminology 90 IPv4 multicast [MCAST] is an internetwork service that allows IPv4 91 datagrams sent from a source to be delivered to one or more 92 interested receiver(s). That is, a given source sends a packet to 93 the network with a destination address in the 224.0.0.0/4 CIDR 94 [CIDR] range. The network transports this packet to all receivers 95 (replicated where necessary) that have registered their interest in 96 receiving these packets. The set of interested receivers is known 97 as a Host Group [RFC966]. 99 The letter S is used to represent the IPv4 address of a given 100 source. The letter G is used to represent a given IPv4 group 101 address (within the 224/4 CIDR range). A packet, or series of 102 packets, sent by a sender with a given address S to a given Host 103 Group G is represented as (S,G). A set of packets sent to Host 104 Group G by multiple senders is represented as (*,G). 106 Packet Forwarding 108 Routers do multicast packet forwarding. In order to know from where 109 to accept packets, and where to send them (duplicated if necessary), 110 each router maintains forwarding state. This forwarding state might 111 be source specific (S,G) or source-generic/group-specific (*,G). 112 Each element of forwarding state defines an Input Interface (IIF) 113 and a set of Output Interfaces, known as an Output Interface List 114 (OIL). 116 When a packet is received on an IIF, the router performs a Reverse 117 Path Forwarding (RPF) check on that packet. If that RPF check 118 succeeds, the packet is forwarded to the interfaces in the OIL. 120 The forwarding state in each router is a node on a singly rooted 121 tree. In the case of shared trees using (*,G) forwarding state, the 122 root of the tree is the PIM Sparse Mode Rendezvous Point. In the 123 case of source-specific trees using (S,G) forwarding state, the root 124 of the tree is the PIM Designated Router for the source S sending to 125 group G. 127 Any Source Multicast 129 Any Source Multicast (ASM) is the traditional IPv4 multicast [MCAST] 130 model. IPv4 multicast sources send IPv4 datagrams to the network, 131 with the destination address of each IPv4 datagram set to a specific 132 �group� address in the Class D address space (224/4). IPv4 133 multicast receivers register their interest in packets addressed to 134 a group address, and the internetwork delivers packets from all 135 sources in the internetwork to the interested receivers. 137 It is the responsibility of the internetwork to keep track of all 138 the sources transmitting to a particular group (identified by the 139 group address). When a receiver wishes traffic sent to a group the 140 network forwards traffic from all group sources. 142 There is no requirement that a source be a member of the destination 143 Host Group. In terms of [RFC966], IPv4 ASM groups are �open�. 145 IPv4 multicast receivers register their interest in packets sent to 146 group addresses through the Internet Group Management Protocol 147 Version 2 (IGMPv2) [IGMPV2]. IGMPv2 does not have any facility for 148 receivers to specify which sources the receiver wants to receive 149 from. That is, IGMPv2 only allows (*,G) registrations. 151 The Internet Group Management Protocol Version 3 (IGMPv3) [IGMPV3] 152 can also be used in Any Source Multicast mode. 154 Source Specific Multicast 156 Source Specific Multicast (SSM) [SSM] is another IPv4 multicast 157 model. IPv4 multicast sources send IPv4 datagrams to the network, 158 with the destination address of each IPv4 datagram set to a specific 159 �group� address in the Class D address space (224/4). IPv4 160 multicast receivers register their interest in packets from a 161 specific source that have been addressed to a group address, and the 162 internetwork delivers packets from that source to the interested 163 receivers. 165 It is the responsibility of each receiver to specify which sources, 166 sending to which groups, the receiver wishes to receive datagrams 167 from. 169 IPv4 multicast receivers register their interest in packets sent by 170 specific sources to group addresses through IGMPv3. That is, IGMPv3 171 supports (S,G) registrations. 173 Sources that send packets to group addresses in the 232/8 range (the 174 SSM-specific range) can only be received by IGMPv3/SSM speaking 175 receivers and networks. 177 Multiprotocol BGP 179 The topology of inter-domain IPv4 multicast forwarding is determined 180 by BGPv4 [BGPV4] policy, as is IPv4 unicast forwarding. BGP 181 provides reachability information. Reachability information for 182 IPv4 Unicast and IPv4 Multicast prefixes can be advertised 183 separately. (See [MBGP] for details and the definition of Network 184 Layer Reachability Information (NLRI) and Subsequent Address Family 185 Information (SAFI).) The practical definition of reachability is 186 different for IPv4 unicast (NLRI=unicast, SAFI=1) and IPv4 multicast 187 (NLRI=Multicast, SAFI=2). 189 In current practice for BGP unicast advertisements (NLRI=Unicast, 190 SAFI=1), reachability is interpreted to mean that IPv4 datagrams 191 will be forwarded towards their destination host if sent to the 192 NEXT_HOP address in the advertisement. 194 In the case of BGP multicast advertisements (NLRI=Multicast, 195 SAFI=2), reachability is interpreted to mean two things 196 simultaneously: 198 First, IPv4 datagrams can be requested from sources within the 199 advertised prefix range. Such requests are made to the advertised 200 NEXT_HOP by means of the PIM Sparse Mode [PIM-SM] protocol, or 201 (rarely) any other mutually agreed upon protocol that supports (S,G) 202 requests. 204 Second, the MSDP [MSDP] speaker associated with the NEXT_HOP address 205 will provide MSDP Source Active messages from PIM Rendevous Points 206 within the advertised prefix range. 208 These two interpretations of BGP NLRI=Multicast flow from the use of 209 BGP to replace the topology discovery portion of the Distance Vector 210 Multicast Routing Protocol [DVMRP]. DVMRP is a �dense� routing 211 protocol, which means traffic is flooded outwards from the sources 212 to all possible receivers. In this situation, an IPv4 multicast 213 router has to decide which incoming interface may accept IPv4 214 datagrams from a given source (to avoid forwarding loops). When the 215 switch was made to use a �sparse� forwarding model (requiring 216 specific (S,G) requests for traffic to flow) both interpretations of 217 BGP NLRI=Multicast became necessary for interoperability with the 218 DVMRP-based model. 220 Note that while MSDP is not strictly necessary for Autonomous 221 Systems that only support Source Specific Multicast [SSM], MSDP 222 depends on the latter interpretation of BGP NLRI=Multicast to avoid 223 MSDP SA forwarding loops. There is a real danger of causing MSDP SA 224 forwarding �black holes� unless MSDP peerings are set up at the same 225 time as BGP NLRI=Multicast peerings. 227 Some MBGP implementations also support combined multicast and 228 unicast advertisements (SAFI=3). Current practice is to interpret 229 these advertisements to include all three meanings listed above: 230 unicast forwarding, availability of traffic from multicast sources, 231 and MSDP Source Active availability. 233 PIM Sparse Mode 235 The PIM Sparse Mode protocol [PIM-SM] is widely used to create 236 forwarding state from IPv4 multicast sources to interested 237 receivers. 239 The term �PIM Sparse Mode domain� generally refers to the hosts and 240 routers that share a PIM Sparse Mode Rendezvous Point. 242 In current practice, there is generally one PIM Sparse Mode domain 243 per Autonomous System. Some Autonomous Systems choose to have 244 multiple PIM Sparse Mode domains for scalability and reliability 245 reasons. 247 Within a PIM Sparse Mode domain, the standard PIM Sparse Mode 248 mechanisms are used to build shared forwarding trees. Interested 249 IPv4 multicast receivers make their group interest known through the 250 Internet Group Management Protocol, and the associated PIM 251 Designated Router (DR) sends (*,G) PIM Join messages towards the RP 252 to build the appropriate shared forwarding tree. IPv4 multicast 253 sources are registered with the PIM Rendezvous Point (RP). When 254 enough traffic from a given source is flowing down the shared tree, 255 PIM routers will create and join source-specific (S,G) trees rooted 256 at the source. This is known as the SPT Threshold. 258 Best current practice is to configure routers to join the source- 259 rooted tree on the first packet sent down the shared tree. That is, 260 the SPT Threshold should be zero. 262 In the ASM model, PIM Sparse Mode Rendezvous Points have to co- 263 operate in order to discover active sources and set up forwarding 264 trees. MSDP is used to spread the knowledge of active sources 265 within a multicast group. Source-specific (S,G) joins are used to 266 set up forwarding from sources towards the interested receivers. No 267 inter-PIM-domain shared forwarding tree is created. 269 In the SSM model, there is no need for PIM Sparse Mode Rendezvous 270 Points because each receiver explicitly identifies the sources from 271 which it desires traffic. Thus, the local PIM Designated Router 272 that receives an IGMPv3 request for traffic can initiate the PIM- 273 Sparse Mode source-specific (S,G) requests directly towards the 274 source. Packets sent to group addresses within the 232.0.0.0/8 275 range SHOULD NOT be encapsulated into PIM Register messages and 276 forwarded to the PIM Rendezvous Point. 278 Internet Group Management Protocol 280 The Internet Group Management Protocol was designed to be used by 281 hosts to notify the network that the hosts want to receive traffic 282 on an IPv4 multicast group. 284 The IGMP design originally assumed a shared media network like 285 Ethernet. When IEEE 802.1 bridging (layer 2) switches became 286 available, many vendors built in IGMP �snooping� so as to avoid 287 flooding IP multicast traffic to all ports. 289 There are two alternative best current practices for IPv4 multicast 290 deployment in a network that has many IEEE 802 segments. Both 291 practices are intended to constrain unwanted flooding of multicast 292 traffic to segments that have no intended receivers. One is to use 293 nominally IEEE 802.1 bridges enhanced with IGMP snooping. Another 294 is to avoid IEEE 802.1 bridges altogether, in favor of small subnets 295 and multicast-aware IP routers. 297 IGMPv2 [IGMPV2] supports the ASM model. IGMPv3 [IGMPV3] supports 298 the ASM model as well as the SSM model. 300 Some wide area network access servers support IGMP and IPv4 301 Multicast over PPP connections. Host implementations also support 302 the IGMP over PPP connections, even those that use dial-up modems. 303 Such support contributes to the availability and utility of IPv4 304 multicast service, but only when configured by network operators. 306 Multicast Source Discovery Protocol 308 The Multicast Source Discovery Protocol (MSDP) supports the Any 309 Source Multicast model. It SHOULD NOT be used in a Source Specific 310 Multicast context. 312 Current best practice is for Autonomous Systems to ask each other 313 for traffic from specific sources transmitting to specific groups. 314 It follows that inter-AS IP multicast forwarding trees are all 315 source-specific. Thus, when a receiver registers an interest in 316 datagrams addressed to a multicast group G (generally through an 317 IGMPv2 (*,G) join) it is necessary for the associated PIM Sparse 318 Mode Rendezvous Point (or other intra-AS protocol element, such as a 319 Core Based Trees [CBT] Core Router) to arrange (S,G) joins towards 320 each sender. Each inter-AS (S,G) join creates a branch of the 321 forwarding tree towards the sender. 323 The Multicast Source Discovery Protocol [MSDP] is used to 324 communicate the availability of sources between Autonomous Systems. 325 MSDP-speaking PIM Sparse Mode Rendezvous Points (or other designated 326 MSDP speakers with knowledge of all sources within an Autonomous 327 System) flood knowledge of active sources to each other. 329 MSDP-speaking RPs communicate by way of a TCP session. The Source 330 Active messages transmitted over the TCP session contain a packet of 331 data, which the MSDP-speaking RPs can forward down their group- 332 specific shared trees. This is how PIM speakers within a PIM domain 333 learn of the external sources. 335 Generally, with the SPT Threshold set to zero, PIM speakers within 336 the domain will then join the source-rooted distribution tree. 337 Thus, the persistent packet flow may bypass the RP altogether. 339 Model IPv4 Multicast-Capable BGPv4 Configuration 341 IPv4 multicast reachability is communicated between Autonomous 342 Systems by BGPv4 prefix announcements. That is, prefixes are 343 advertised with NLRI=Multicast (SAFI in {2,3}). As outlined above, 344 the semantics of a BGPv4 advertisement of an IPv4 NLRI=Multicast 345 prefix are currently interpreted to mean two things: 347 First, such an advertisement means that the router with the NEXT_HOP 348 address of that advertisement will supply packets from any 349 transmitting source S whose address matches the prefix advertised. 350 In order to fulfill this expectation, any two BGPv4 speakers that 351 communicate NLRI=Multicast advertisements must be able to ask each 352 other for (S,G) traffic. That is, they must have some protocol 353 (most often PIM Sparse Mode) configured between them. 355 Second, such an advertisement means that the router with the 356 NEXT_HOP address of that advertisement will supply MSDP Source 357 Active messages from any (e.g.) PIM Sparse Mode Rendezvous Point 358 whose address matches the prefix advertised. To avoid MSDP �black 359 holes�, Autonomous Systems with BGPv4 speakers that exchange 360 NLRI=Multicast advertisements must also have appropriate MSDP 361 peerings configured. 363 Model IPv4 Multicast Inter-domain PIM Sparse Mode Configuration 365 As outlined above, current practice is that each IPv4 BGPv4 366 NLRI=Multicast capable peering is capable of making (S,G) requests 367 for traffic. Autonomous Systems predominantly use PIM Sparse Mode 368 for this purpose. The rest of this section describes how PIM Sparse 369 Mode is widely configured, but the principles can be applied to any 370 other (S,G) request protocol between Autonomous Systems. 372 The minimum TTL Threshold for traffic crossing an Autonomous System 373 peering is generally set to be 32. This value follows earlier 374 practice [FAQ] that sets inter-institution TTL barriers at 16-32. 375 It also provides a reasonable number of values both above and below 376 the (maximum 255) barrier. 378 The PIM Sparse Mode Adjacency should not make requests for traffic 379 across the peering for sources in these groups: 381 224.0.1.39/32: Cisco�s Rendezvous Point Announcement Protocol 382 224.0.1.40/32: Cisco�s Rendezvous Point Discovery Protocol 383 239.0.0.0/8: Administratively Scoped IPv4 Group Addresses (with 384 possible exceptions) 386 The first two groups are used to determine where PIM Sparse Mode 387 Rendezvous Points can be found within an Autonomous System. The 388 latter group range is defined by RFC 2365 [RFC2365]. RFC 2365 has 389 been generally interpreted to equate �organizations� (see section 390 6.2) with Autonomous Systems. Some Autonomous Systems choose to 391 interpret this differently. 393 Model PIM Sparse Mode Rendezvous Point Location 395 In order to participate in current-practice inter-Autonomous System 396 IPv4 multicast routing, a PIM Sparse Mode Rendezvous Point (or other 397 such MSDP-speaker) should have access to the full BGP NLRI=Multicast 398 reachability table so as to arrange for (S,G) joins to the 399 appropriate external peer networks. This need arises when a (*,G) 400 request comes in from a host. Access to the BGPv4 NLRI=Multicast 401 reachability table is also important so that the (e.g.) PIM Sparse 402 Mode Rendezvous Point will perform MSDP Reverse-Path-Forwarding 403 (RPF) checks correctly. 405 PIM Sparse Mode Rendezvous Points are often located at the border 406 router of an Autonomous System where the BGPv4 NLRI=Multicast 407 reachability table is already maintained. If necessary, an MSDP 408 Mesh Group can be created if there are multiple BGPv4 NLRI=Multicast 409 speakers within an Autonomous System. (See Section 14.3 of [MSDP] 410 as well as [ANYCASTRP].) 412 The IPv4 address of each PIM Sparse Mode Rendezvous Point (or other 413 such MSDP-speaker) must be chosen so that it is within an advertised 414 BGPv4 NLRI=Multicast prefix. The MSDP RPF checks operate on the so- 415 called �RP-Address� within the MSDP Source Active message, not the 416 advertised source S. In the most widely deployed case, the RP- 417 Address is set by the MSDP-speaker to be the PIM Sparse Mode 418 Rendezvous Point address. 420 Model MSDP Configuration Between Autonomous Systems 422 MSDP peerings are configured between Autonomous Systems. These 423 peerings are statically defined. Thus, in practice, such MSDP- 424 speaking (e.g.) PIM Sparse Mode Rendezvous Point(s) must be �tied 425 down� to known addresses and routers for the inter-AS peerings to 426 operate correctly. 428 The so-called �RP-address� in MSDP Source Active messages must be 429 addressed within prefixes announced by BGPv4 NLRI=Multicast 430 advertisements. (Otherwise the RP-Address Reverse Path Forwarding 431 checks done by peer MSDP-speaking Autonomous Systems will fail, and 432 the MSDP Source Active messages will be discarded.) The most common 433 RP-address in MSDP Source Active messages is the PIM Rendezvous 434 Point IPv4 address. 436 In practice, MSDP speakers are configured to not advertise sources 437 to external peers that are operating in certain groups, as outlined 438 in [UNUSABLE]. Also see [FILTERLIST] for more information. Some 439 sites block all groups in 224.0.0.0/24, due to a lack of interdomain 440 groups in that range. 442 MSDP speakers are configured to not accept or advertise sources to 443 or from external peers with Private Internet addresses [RFC1918]. 445 MSDP-speakers are configured, wherever possible, to only advertise 446 sources within prefixes that they are advertising as BGPv4 447 NLRI=Multicast (SAFI in {2,3}) announcements. That is, a non- 448 transit Autonomous System would only advertise sources within the 449 prefixes it advertises to its peers. 451 Based on recent events, MSDP peerings are configured with reasonable 452 rate limits to dampen explosions of MSDP SA advertisements. These 453 explosions can occur when malicious software generates packets 454 addressed to many IPv4 multicast groups in a very short period of 455 time. What �appropriate� means for these rate limits will vary over 456 time with the number of active IPv4 multicast sources in the 457 Internet. To determine an initial approximation for these rate 458 limits, configure MSDP without rate limits initially, and then set 459 the rate limits at some small multiple of the observed steady state 460 rate. Another approach would be to set rate limits based on a small 461 multiple of the current number of active sources in the Internet. 462 The Mantra Project [MANTRA] maintains MSDP statistics, as well as 463 other IPv4 multicast statistics. 465 Advanced Configurations 467 Often an organization may wish to have multiple PIM RPs for 468 scalability reasons. The Anycast-RP [ANYCASTRP] draft outlines one 469 way how this can be accomplished. 471 When an organization has multiple border routers, it makes sense for 472 the organization to move the PIM Rendezvous Point off of the border 473 and to an internal router. Note that the MSDP-speaking PIM RP will 474 need to be a part of the iBGP mesh so as to have BGPv4 475 NLRI=Multicast topology information. 477 Security Considerations 479 Autonomous Systems often configure router filters or firewall rules 480 to discard mis-forwarded IPv4 datagrams. Such rules may explicitly 481 list the IPv4 address ranges that are acceptable for incoming IPv4 482 datagrams. When IPv4 multicast is enabled, these rules need to be 483 updated to disallow incoming IPv4 datagrams with addresses in the 484 239/8 CIDR range, but otherwise to allow incoming IPv4 datagrams 485 with destination addresses in the 224/4 CIDR range. 487 PIM Sparse Mode Rendezvous Points are particularly vulnerable to 488 Denial of Service attacks. As outlined above, it is important to 489 put rate limits on MSDP peerings so as to protect your PIM Sparse 490 Mode Rendezvous Points from explosions in the size of the cached 491 MSDP Source Active table. Other denial of service attacks include 492 sending excessive Register-encapsulated packets towards the 493 Rendezvous Point and flooding the Rendezvous Point with large 494 numbers of (S,G) joins originated as IGMP Group Reports. 496 Acknowledgements 498 Dino Farinacci created the (S,G) notation used throughout this 499 document. 501 Kevin Almeroth, Tony Ballardie, H�vard Eidnes, David Farmer, Leonard 502 Giuliano, John Heasley, Marty Hoag, Milan J, Simon Leinen, Michael 503 Luby, David Meyer, John Meylor, Stephen Sprunk and Dave Thaler 504 provided information, pointed out mistakes and made suggestions for 505 improvement. 507 Marshall Eubanks described the vulnerability of PIM Sparse Mode 508 Rendezvous Points to various denial of service attacks. 510 This work was supported by the Mathematical, Information, and 511 Computational Sciences Division subprogram of the Office of Advanced 512 Scientific Computing Research, U.S. Department of Energy, under 513 Contract W-31-109-Eng-38. 515 Normative References 517 [RFC2119] RFC 2119: Key Words for use in RFCs to Indicate 518 Requirement Levels. S. Bradner. March 1997. 520 [MCAST] RFC 1112: Host extensions for IP multicasting. S.E. Deering. 521 August 1989. 523 [CIDR] RFC 1519: Classless Inter-Domain Routing (CIDR): an Address 524 Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. 525 Varadhan. September 1993. 527 [RFC966] RFC 966: Host Groups: A Multicast Extension to the Internet 528 Protocol. S. E. Deering, D. R. Cheriton. December 1985. 530 [IGMPV2] RFC 2236: Internet Group Management Protocol, Version 2. W. 531 Fenner. November 1997. 533 [IGMPV3] RFC 3376: Internet Group Management Protocol, Version 3. 534 B. Cain, S. Deering, B. Fenner, I Kouvelas, A. Thyagarajan. 535 October 2002. 537 [SSM] draft-ietf-ssm-arch-00.txt: Source-Specific Multicast for IP. 538 H. Holbrook, B. Cain. 21 November 2001. 540 [BGPV4] RFC 1771: A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, 541 T. Li. March 1995. 543 [MBGP] RFC 2858: Multiprotocol Extensions for BGP-4. T. Bates, Y. 544 Rekhter, R. Chandra, D. Katz. June 2000. 546 [PIM-SM] RFC 2117: Protocol Independent Multicast-Sparse Mode (PIM- 547 SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, 548 D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. 549 Sharma, L. Wei. June 1997. 551 [MSDP] draft-ietf-msdp-spec-13.txt: Multicast Source Discovery 552 Protocol (MSDP). D. Meyer (Editor), B. Fenner (Editor). 553 November 2001. 555 [RFC2365] RFC 2365: Administratively Scoped IP Multicast. D. Meyer. 556 July 1998. 558 [UNUSABLE] IPv4 Multicast Unusable Group Addresses. B. Nickless. 559 draft-nickless-ipv4-mcast-unusable-02.txt. June 2003. 561 [RFC1918] RFC 1918: Address Allocation for Private Internets. Y. 562 Rekhter, B. Moskowitz, D. Karrenberk, G. J. de Groot, E. Lear. 563 February 1996. 565 [ANYCASTRP] RFC 3446: Anycast RP mechanism using PIM and MSDP. D. 566 Kim, D. Meyer, H. Kilmer, D. Farinacci. January 2003. 568 Non-Normative References 570 [DVMRP] RFC 1075: Distance Vector Multicast Routing Protocol. D. 571 Waitzman, C. Partridge, S.E. Deering. November 1988. 573 [FAQ] http://netlab.gmu.edu/mbone_installation.htm 575 [FILTERLIST] ftp://ftpeng.cisco.com/ipmulticast/config-notes/msdp- 576 sa-filter.txt 578 [MANTRA] http://www.caida.org/tools/measurement/mantra 580 Author's Address 582 Bill Nickless 583 Argonne National Laboratory 584 9700 South Cass Avenue #221 Phone: +1 630 252 7390 585 Argonne, IL 60439 Email: nickless@mcs.anl.gov