idnits 2.17.1 draft-nickless-ipv4-mcast-bcp-01.txt: -(164): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(178): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(193): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(339): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(392): 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: ---------------------------------------------------------------------------- == There are 23 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 15 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: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2001) is 8412 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 255, but not defined ** Obsolete normative reference: RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) == Outdated reference: A later version (-03) exists of draft-holbrook-ssm-arch-02 -- Possible downref: Normative reference to a draft: ref. 'SSM' == Outdated reference: A later version (-10) exists of draft-ietf-idmr-igmp-v3-07 ** 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-07 ** Downref: Normative reference to an Experimental draft: draft-ietf-msdp-spec (ref. 'MSDP') ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. 'DVMRP') -- Possible downref: Non-RFC (?) normative reference: ref. 'FAQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'MANTRA' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft B. Nickless 2 Document: draft-nickless-ipv4-mcast-bcp-01.txt Argonne National 3 Laboratory 4 Expires: October 2001 April 2001 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 Introduction and Terminology.......................................2 41 Any Source Multicast...............................................3 42 Source Specific Multicast..........................................3 43 Multiprotocol BGP..................................................4 44 PIM Sparse Mode....................................................5 45 Internet Group Management Protocol.................................5 46 Multicast Source Discovery Protocol................................6 47 Model IPv4 Multicast-Capable BGPv4 Configuration...................6 48 Model IPv4 Multicast Inter-domain PIM Sparse Mode Configuration....7 49 Model PIM Sparse Mode Rendezvous Point Location....................7 50 Model MSDP Configuration Between Autonomous Systems................8 51 Acknowledgements...................................................9 52 Security Considerations............................................9 53 References.........................................................9 54 Author's Address..................................................11 56 Overview 58 Current best practice for IPv4 multicast service provision uses four 59 different protocols: Internet Group Management Protcol, Protocol 60 Independent Multicast (Sparse Mode), Border Gateway Protocol with 61 multiprotocol extensions, and the Multicast Source Discovery 62 Protocol. This document outlines how these protocols work together 63 to provide end-to-end IPv4 multicast service. In addition, this 64 document describes best current practices for configuring these 65 protocols, individually and in combination. 67 Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 71 this document are to be interpreted as described in RFC-2119 72 [RFC2119]. 74 Introduction and Terminology 76 IPv4 multicast [MCAST] is an internetwork service that allows IPv4 77 datagrams sent from a source to be delivered to more than one 78 interested receiver. That is, a given source sends a packet the 79 network with a destination address 224/4 CIDR [CIDR] range. The 80 network transports this packet to all receivers (replicated where 81 necessary) that have registered their interest in receiving these 82 packets. 84 The letter S is used to represent the IPv4 address of a given 85 source. The letter G is used to represent a given IPv4 group 86 address (within the 224/4 CIDR range). A packet, or series of 87 packets, sent by a sender with a given address S to a given group G 88 is represented as (S,G). A set of packets sent to group G by 89 multiple senders is represented as (*,G). 91 Any Source Multicast 93 Any Source Multicast (ASM) is the traditional IPv4 multicast [MCAST] 94 model. IPv4 multicast sources send IPv4 datagrams to the network, 95 with the destination address of each IPv4 datagram set to a specific 96 �group� address in the Class D address space (224/4). IPv4 97 multicast receivers register their interest in packets addressed to 98 a group address, and the internetwork delivers packets from all 99 sources in the internetwork to the interested receivers. 101 It is the responsibility of the internetwork to keep track of all 102 the sources transmitting to a particular group, so that when a 103 receiver wishes traffic sent to that group the network can forward 104 traffic from all group sources. 106 IPv4 multicast receivers register their interest in packets sent to 107 group addresses through the Internet Group Management Protocol 108 Version 2 (IGMPv2) [IGMPV2]. IGMPv2 does not have any facility for 109 receivers to specify which sources the receiver wants to receive 110 from. That is, IGMPv2 only allows (*,G) registrations. 112 Source Specific Multicast 114 Source Specific Multicast (SSM) [SSM] is another IPv4 multicast 115 model. IPv4 multicast sources send IPv4 datagrams to the network, 116 with the destination address of each IPv4 datagram set to a specific 117 �group� address in the Class D address space (224/4). IPv4 118 multicast receivers register their interest in packets from a 119 specific source that have been addressed to a group address, and the 120 internetwork delivers packets from that source to the interested 121 receivers. 123 It is the responsibility of each receiver to specify which sources, 124 sending to which groups, the receiver wishes to receive datagrams 125 from. 127 IPv4 multicast receivers register their interest in packets sent by 128 specific sources to group addresses through the Internet Group 129 Management Protocol Version 3 (IGMPv3) [IGMPV3]. That is, IGMPv3 130 supports (S,G) registrations. 132 Multiprotocol BGP 134 The topology of inter-domain IPv4 multicast forwarding is determined 135 by BGPv4 [BGPV4] policy, as is IPv4 unicast forwarding. BGP 136 provides reachability information. Reachability information for 137 IPv4 Unicast and IPv4 Multicast prefixes can be advertised 138 separately. (See [MBGP] for details and the definition of Network 139 Layer Reachability Information (NLRI) and Subsequent Address Family 140 Information (SAFI).) The practical definition of reachability is 141 different for IPv4 unicast (NLRI=unicast, SAFI=1) and IPv4 multicast 142 (NLRI=Multicast, SAFI=2). 144 In current practice for BGP unicast advertisements (NLRI=Unicast, 145 SAFI=1), reachability is interpreted to mean that IPv4 datagrams 146 will be forwarded towards their destination host if sent to the 147 NEXT_HOP address in the advertisement. 149 In the case of BGP multicast advertisements (NLRI=Multicast, 150 SAFI=2), reachability is interpreted to mean two things: 152 First, IPv4 datagrams can be requested from sources within the 153 advertised prefix range. Such requests are made to the advertised 154 NEXT_HOP by means of the PIM Sparse Mode [PIM-SM] protocol, or 155 (rarely) any other mutually agreed upon protocol that supports (S,G) 156 requests. 158 Second, the MSDP [MSDP] speaker with the NEXT_HOP address will 159 provide MSDP Source Active messages from PIM Rendevous Points within 160 the advertised prefix range. 162 These two interpretations of BGP NLRI=Multicast flow from the 163 original use of BGP to control Distance Vector Multicast Routing 164 Protocol [DVMRP]. DVMRP is a �dense� routing protocol, which means 165 traffic is flooded outwards from the sources to all possible 166 receivers. In this situation, an IPv4 multicast router has to 167 decide which incoming interface may accept IPv4 datagrams from a 168 given source (to avoid forwarding loops). When the switch was made 169 to use a �sparse� forwarding model (requiring specific (S,G) 170 requests for traffic to flow) both interpretations of BGP 171 NLRI=Multicast became necessary for interoperability with the DVMRP- 172 based model. 174 Note that while MSDP is not strictly necessary for Autonomous 175 Systems that only support Source Specific Multicast [SSM], MSDP 176 depends on the latter interpretation of BGP NLRI=Multicast to avoid 177 MSDP SA forwarding loops. There is a real danger of causing MSDP SA 178 forwarding �black holes� unless MSDP peerings are set up at the same 179 time as BGP NLRI=Multicast peerings. 181 MBGP also supports combined multicast and unicast advertisements 182 (SAFI=3). Current practice is to interpret these advertisements to 183 include all three meanings listed above: unicast forwarding, 184 availability of traffic from multicast sources, and MSDP Source 185 Active availability. 187 PIM Sparse Mode 189 The PIM Sparse Mode protocol [PIM-SM] is widely used to create 190 forwarding state from IPv4 multicast sources to interested 191 receivers. 193 The term �PIM Sparse Mode domain� generally refers to the hosts and 194 routers that share a PIM Sparse Mode Rendezvous Point. 196 In current practice, there is generally one PIM Sparse Mode domain 197 per Autonomous System. Some Autonomous Systems choose to have 198 multiple PIM Sparse Mode domains for scalability reasons. 200 Within a PIM Sparse Mode domain, the standard PIM Sparse Mode 201 mechanisms are used to build shared forwarding trees and source 202 specific trees from IPv4 multicast sources to interested receivers. 203 IPv4 multicast sources are registered with the PIM Rendezvous Point 204 (RP). Interested IPv4 multicast receivers make their group interest 205 known through the Internet Group Management Protocol, and the 206 associated PIM Designated Router (DR) sends PIM Join messages 207 towards the RP to build the appropriate forwarding trees. 209 In the ASM model, PIM Sparse Mode Rendezvous Points have to co- 210 operate in order to discover active sources and set up forwarding 211 trees. MSDP is used to spread the knowledge of active sources 212 within a multicast group. Source-specific (S,G) joins are used to 213 set up forwarding from sources towards the interested receivers. No 214 inter-PIM-domain shared forwarding tree is created. 216 In the SSM model, there is no need for PIM Sparse Mode Rendezvous 217 Points because each receiver explicitly identifies the sources from 218 which it desires traffic. Thus, the local PIM Designated Router 219 that receives an IGMPv3 request for traffic can initiate the PIM- 220 Sparse Mode source-specific (S,G) requests directly towards the 221 source. 223 Internet Group Management Protocol 225 The Internet Group Management Protocol was designed to be used by 226 hosts to notify the network that the hosts want to receive traffic 227 on an IPv4 multicast group. 229 The IGMP design originally assumed a shared media network like 230 Ethernet. When layer 2 switches became available, many vendors 231 built in IGMP �snooping� so as to avoid flooding IP multicast 232 traffic to all ports in a Virtual Local Area Network (VLAN). The 233 best current practice for IPv4 multicast deployment in a switched 234 Local Area Network context is to use IGMP snooping to avoid 235 unnecessary IPv4 multicast flooding. 237 IGMPv2 [IGMPV2] supports the ASM model. IGMPv3 [IGMPV3] supports 238 the ASM model as well as the SSM model. 240 Some wide area network access servers support IGMP and IPv4 241 Multicast over PPP connections. Host implementations also support 242 the IGMP over PPP connections, even those that use dial-up modems. 243 Such support contributes to the availability and utility of IPv4 244 multicast service, but only when configured by network operators. 246 Multicast Source Discovery Protocol 248 Current best practice is for Autonomous Systems to ask each other 249 for traffic from specific sources transmitting to specific groups. 250 It follows that inter-AS IP multicast forwarding trees are all 251 source-specific. Thus, when a receiver registers an interest in 252 datagrams addressed to a multicast group G (generally through an 253 IGMPv2 (*,G) join) it is necessary for the associated PIM Sparse 254 Mode Rendezvous Point (or other intra-AS protocol element, such as a 255 Core Based Trees [CBT] Core Router) to arrange (S,G) joins towards 256 each sender. Each inter-AS (S,G) join creates a branch of the 257 forwarding tree towards the sender. 259 The Multicast Source Discovery Protocol [MSDP] is used to 260 communicate the availability of sources between Autonomous Systems. 261 MSDP-speaking PIM Sparse Mode Rendezvous Points (or other designated 262 MSDP speakers with knowledge of all sources within an Autonomous 263 System) flood knowledge of active sources to each other. 265 Model IPv4 Multicast-Capable BGPv4 Configuration 267 IPv4 multicast reachability is communicated between Autonomous 268 Systems by BGPv4 prefix announcements. That is, prefixes are 269 advertised with NLRI=Multicast (SAFI in {2,3}). As outlined above, 270 the semantics of a BGPv4 advertisement of an IPv4 NLRI=Multicast 271 prefix are currently interpreted to mean two things: 273 First, such an advertisement means that the router with the NEXT_HOP 274 address of that advertisement will supply packets from any 275 transmitting source S whose address matches the prefix advertised. 276 In order to fulfill this expectation, any two BGPv4 speakers that 277 communicate NLRI=Multicast advertisements must be able to ask each 278 other for (S,G) traffic. That is, they must have some protocol 279 (most often PIM Sparse Mode) configured between them. 281 Second, such an advertisement means that the router with the 282 NEXT_HOP address of that advertisement will supply MSDP Source 283 Active messages from any (e.g.) PIM Sparse Mode Rendezvous Point 284 whose address matches the prefix advertised. To avoid MSDP �black 285 holes�, Autonomous Systems with BGPv4 speakers that exchange 286 NLRI=Multicast advertisements must also have appropriate MSDP 287 peerings configured. 289 Model IPv4 Multicast Inter-domain PIM Sparse Mode Configuration 291 As outlined above, current practice is that each IPv4 BGPv4 292 NLRI=Multicast capable peering is capable of making (S,G) requests 293 for traffic. Autonomous Systems predominantly use PIM Sparse Mode 294 for this purpose. Whether PIM Sparse Mode is used or not, these 295 peerings/adjacencies are configured in the following ways: 297 The minimum TTL Threshold for traffic crossing an Autonomous System 298 peering is generally set to be 32. This value follows earlier 299 practice [FAQ] that sets inter-institution TTL barriers at 16-32. 300 It also provides a reasonable number of values both above and below 301 the (maximum 255) barrier. 303 The PIM Sparse Mode Adjacency (or other inter-domain (S,G) request 304 mechanism) should not make requests for traffic across the peering 305 for sources in these groups: 307 224.0.1.39/32: Cisco�s Rendezvous Point Announcement Protocol 308 224.0.1.40/32: Cisco�s Rendezvous Point Discovery Protocol 309 239.0.0.0/8: Administratively Scoped IPv4 Group Addresses 311 The first two groups are used to determine where PIM Sparse Mode 312 Rendezvous Points can be found within an Autonomous System. The 313 latter group range is defined by RFC 2365 [RFC2365]. RFC 2365 has 314 been generally interpreted to equate �organizations� (see section 315 6.2) with Autonomous Systems. Some Autonomous Systems choose to 316 interpret this differently. 318 Model PIM Sparse Mode Rendezvous Point Location 320 In order to participate in current-practice inter-Autonomous System 321 IPv4 multicast routing, a PIM Sparse Mode Rendezvous Point (or other 322 such MSDP-speaker) should have access to the full BGP NLRI=Multicast 323 reachability table so as to arrange for (S,G) joins to the 324 appropriate external peer networks. This need arises when a (*,G) 325 request comes in from a host. Access to the BGPv4 NLRI=Multicast 326 reachability table is also important so that the (e.g.) PIM Sparse 327 Mode Rendezvous Point will perform MSDP Reverse-Path-Forwarding 328 (RPF) checks correctly. 330 PIM Sparse Mode Rendezvous Points are often located at the border 331 router of an Autonomous System where the BGPv4 NLRI=Multicast 332 reachability table is already maintained. If necessary, an MSDP 333 Mesh Group can be created if there are multiple BGPv4 NLRI=Multicast 334 speakers within an Autonomous System. (See Section 14.3 of [MSDP].) 336 The IPv4 address of each PIM Sparse Mode Rendezvous Point (or other 337 such MSDP-speaker) must be chosen so that it is within an advertised 338 BGPv4 NLRI=Multicast prefix. The MSDP RPF checks operate on the so- 339 called �RP-Address� within the MSDP Source Active message, not the 340 advertised source S. In the most widely deployed case, the RP- 341 Address is set by the MSDP-speaker to be the PIM Sparse Mode 342 Rendezvous Point address. 344 Model MSDP Configuration Between Autonomous Systems 346 MSDP peerings are configured between Autonomous Systems. These 347 peerings are statically defined. Thus, in practice, such MSDP- 348 speaking (e.g.) PIM Sparse Mode Rendezvous Point(s) must be �tied 349 down� to known addresses and routers for the inter-AS peerings to 350 operate correctly. 352 The so-called �RP-address� in MSDP Source Active messages must be 353 addressed within prefixes announced by BGPv4 NLRI=Multicast 354 advertisements. (Otherwise the RP-Address Reverse Path Forwarding 355 checks done by peer MSDP-speaking Autonomous Systems will fail, and 356 the MSDP Source Active messages will be discarded.) The most common 357 RP-address in MSDP Source Active messages is the PIM Rendezvous 358 Point IPv4 address. 360 In practice, MSDP speakers are configured to not advertise sources 361 to external peers from the following groups. MSDP speakers are also 362 configured to not accept source advertisements from external peers 363 within the following groups: 365 224.0.1.2/32: SGI �Dogfight� game 366 224.0.1.3/32: RWHOD 367 224.0.1.22/32: SVRLOC 368 224.0.1.24/32: MICROSOFT-DS 369 224.0.1.35/32: SVRLOC-DA 370 224.0.1.39/32: Cisco�s Rendezvous Point Announcement Protocol 371 224.0.1.40/32: Cisco�s Rendezvous Point Discovery Protocol 372 224.0.1.60/32: HP�s Device Discovery Protocol 373 224.0.2.2/32: Sun�s Remote Procedure Call Protocol 374 229.55.150.208/32: Norton �Ghost� disk duplication software 375 232.0.0.0/8: Source-Specific Multicast 376 239.0.0.0/8: Administratively Scoped IPv4 Group Addresses 377 (with possible specific exceptions) 379 MSDP speakers are configured to not accept or advertise sources to 380 or from external peers with Private Internet addresses [RFC1918]. 382 MSDP-speakers are configured, wherever possible, to only advertise 383 sources within prefixes that they are advertising as BGPv4 384 NLRI=Multicast (SAFI in {2,3}) announcements. That is, a non- 385 transit Autonomous System would only advertise sources within the 386 prefixes it advertises to its peers. 388 Based on recent events, MSDP peerings are configured with reasonable 389 rate limits to dampen explosions of MSDP SA advertisements. These 390 explosions can occur when malicious software generates packets 391 addressed to many IPv4 multicast groups in a very short period of 392 time. What �appropriate� means for these rate limits will vary over 393 time with the number of active IPv4 multicast sources in the 394 Internet. To determine an initial approximation for these rate 395 limits, configure MSDP without rate limits initially, and then set 396 the rate limits at some small multiple of the observed steady state 397 rate. Another approach would be to set rate limits based on a small 398 multiple of the current number of active sources in the Internet. 399 The Mantra Project [MANTRA] maintains MSDP statistics, as well as 400 other IPv4 multicast statistics. 402 Security Considerations 404 Autonomous Systems often configure router filters or firewall rules 405 to discard mis-forwarded IPv4 datagrams. Such rules may explicitly 406 list the IPv4 address ranges that are acceptable for incoming IPv4 407 datagrams. When IPv4 multicast is enabled, these rules need to be 408 updated to disallow incoming IPv4 datagrams with addresses in the 409 239/8 CIDR range, and to allow incoming IPv4 datagrams with 410 destination addresses in the 224/4 CIDR range. 412 PIM Sparse Mode Rendezvous Points are particularly vulnerable to 413 Denial of Service attacks. As outlined above, it is important to 414 put rate limits on MSDP peerings so as to protect your PIM Sparse 415 Mode Rendezvous Points from explosions in the size of the cached 416 MSDP Source Active table. Other denial of service attacks include 417 sending excessive Register-encapsulated packets towards the 418 Rendezvous Point and flooding the Rendezvous Point with large 419 numbers of IGMP joins. 421 Acknowledgements 423 Dino Farinacci created the (S,G) notation used throughout this 424 document. 426 Marty Hoag, Simon Leinen, David Meyer, and Dave Thaler pointed out 427 mistakes and made suggestions for improvement. 429 Marshall Eubanks described the vulnerability of PIM Sparse Mode 430 Rendezvous Points to various denial of service attacks. 432 This work was supported by the Mathematical, Information, and 433 Computational Sciences Division subprogram of the Office of Advanced 434 Scientific Computing Research, U.S. Department of Energy, under 435 Contract W-31-109-Eng-38. 437 References 439 [RFC2119] RFC 2119: Key Words for use in RFCs to Indicate 440 Requirement Levels. S. Bradner. March 1997. 442 [MCAST] RFC 1112: Host extensions for IP multicasting. S.E. Deering. 443 Aug-01-1989. 445 [CIDR] RFC 1519: Classless Inter-Domain Routing (CIDR): an Address 446 Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. 447 Varadhan. September 1993. 449 [IGMPV2] RFC 2232: Internet Group Management Protocol, Version 2. W. 450 Fenner. November 1997. 452 [SSM] draft-holbrook-ssm-arch-02.txt: Source-Specific Multicast for 453 IP. H. Holbrook, B. Cain. 1 March 2001. 455 [IGMPV3] draft-ietf-idmr-igmp-v3-07.txt: Internet Group Management 456 Protocol, Version 3. B. Cain, S. Deering, B. Fenner, I Kouvelas, 457 A. Thyagarajan. March 2001. 459 [BGPV4] RFC 1771: A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, 460 T. Li. March 1995. 462 [MBGP] RFC 2858: Multiprotocol Extensions for BGP-4. T. Bates, Y. 463 Rekhter, R. Chandra, D. Katz. June 2000. 465 [PIM-SM] RFC 2117: Protocol Independent Multicast-Sparse Mode (PIM- 466 SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, 467 D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. 468 Sharma, L. Wei. June 1997. 470 [MSDP] draft-ietf-msdp-spec-07.txt: Multicast Source Discovery 471 Protocol (MSDP). D. Meyer (Editor). March 2001. 473 [DVMRP] RFC 1075: Distance Vector Multicast Routing Protocol. D. 474 Waitzman, C. Partridge, S.E. Deering. November 1988. 476 [FAQ] http://netlab.gmu.edu/mbone_installation.htm 478 [RFC2365] RFC 2365: Administratively Scoped IP Multicast. D. Meyer. 479 July 1998. 481 [RFC1918] RFC 1918: Address Allocation for Private Internets. Y. 482 Rekhter, B. Moskowitz, D. Karrenberk, G. J. de Groot, E. Lear. 483 February 1996. 485 [MANTRA] http://www.caida.org/tools/measurement/mantra 486 Author's Address 488 Bill Nickless 489 Argonne National Laboratory 490 9700 South Cass Avenue #221 Phone: +1 630 252 7390 491 Argonne, IL 60439 Email: nickless@mcs.anl.gov