--- 1/draft-ietf-mboned-ipv4-mcast-bcp-00.txt 2006-02-05 00:19:59.000000000 +0100 +++ 2/draft-ietf-mboned-ipv4-mcast-bcp-01.txt 2006-02-05 00:19:59.000000000 +0100 @@ -1,15 +1,15 @@ Internet Draft B. Nickless Document: draft-ietf-mboned-ipv4-mcast-bcp- Argonne National - 00.txt Laboratory - Expires: August 2002 February 2002 + 01.txt Laboratory + Expires: December 2003 June 2003 IPv4 Multicast Best Current Practice Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -35,37 +35,38 @@ Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................2 Scope..............................................................2 Introduction and Terminology.......................................2 Packet Forwarding..................................................3 Any Source Multicast...............................................3 - Source Specific Multicast..........................................3 + Source Specific Multicast..........................................4 Multiprotocol BGP..................................................4 PIM Sparse Mode....................................................5 Internet Group Management Protocol.................................6 Multicast Source Discovery Protocol................................6 - Nickless Informational - Expires August 2002 1 - IPv4 Multicast Best Current Practice February 2002 + Nickless Informational - Expires December 2003 1 + IPv4 Multicast Best Current Practice June 2003 Model IPv4 Multicast-Capable BGPv4 Configuration...................7 Model IPv4 Multicast Inter-domain PIM Sparse Mode Configuration....7 Model PIM Sparse Mode Rendezvous Point Location....................8 - Model MSDP Configuration Between Autonomous Systems................8 + Model MSDP Configuration Between Autonomous Systems................9 Advanced Configurations............................................9 Security Considerations...........................................10 Acknowledgements..................................................10 - References........................................................10 + Normative References..............................................10 + Non-Normative References..........................................11 Author's Address..................................................12 Overview Current best practice for IPv4 multicast service provision uses four different protocols: Internet Group Management Protcol, Protocol Independent Multicast (Sparse Mode), Border Gateway Protocol with multiprotocol extensions, and the Multicast Source Discovery Protocol. This document outlines how these protocols work together to provide end-to-end IPv4 multicast service. In addition, this @@ -90,32 +91,32 @@ provided. Introduction and Terminology IPv4 multicast [MCAST] is an internetwork service that allows IPv4 datagrams sent from a source to be delivered to one or more interested receiver(s). That is, a given source sends a packet to the network with a destination address in the 224.0.0.0/4 CIDR [CIDR] range. The network transports this packet to all receivers (replicated where necessary) that have registered their interest in - receiving these packets. + receiving these packets. The set of interested receivers is known + as a Host Group [RFC966]. + + Nickless Informational - Expires December 2003 2 + IPv4 Multicast Best Current Practice June 2003 The letter S is used to represent the IPv4 address of a given source. The letter G is used to represent a given IPv4 group address (within the 224/4 CIDR range). A packet, or series of - - Nickless Informational - Expires August 2002 2 - IPv4 Multicast Best Current Practice February 2002 - - packets, sent by a sender with a given address S to a given group G - is represented as (S,G). A set of packets sent to group G by - multiple senders is represented as (*,G). + packets, sent by a sender with a given address S to a given Host + Group G is represented as (S,G). A set of packets sent to Host + Group G by multiple senders is represented as (*,G). Packet Forwarding Routers do multicast packet forwarding. In order to know from where to accept packets, and where to send them (duplicated if necessary), each router maintains forwarding state. This forwarding state might be source specific (S,G) or source-generic/group-specific (*,G). Each element of forwarding state defines an Input Interface (IIF) and a set of Output Interfaces, known as an Output Interface List (OIL). @@ -139,53 +140,55 @@ ôgroupö address in the Class D address space (224/4). IPv4 multicast receivers register their interest in packets addressed to a group address, and the internetwork delivers packets from all sources in the internetwork to the interested receivers. It is the responsibility of the internetwork to keep track of all the sources transmitting to a particular group (identified by the group address). When a receiver wishes traffic sent to a group the network forwards traffic from all group sources. + There is no requirement that a source be a member of the destination + Host Group. In terms of [RFC966], IPv4 ASM groups are ôopenö. + IPv4 multicast receivers register their interest in packets sent to group addresses through the Internet Group Management Protocol Version 2 (IGMPv2) [IGMPV2]. IGMPv2 does not have any facility for receivers to specify which sources the receiver wants to receive from. That is, IGMPv2 only allows (*,G) registrations. The Internet Group Management Protocol Version 3 (IGMPv3) [IGMPV3] can also be used in Any Source Multicast mode. + Nickless Informational - Expires December 2003 3 + IPv4 Multicast Best Current Practice June 2003 + Source Specific Multicast Source Specific Multicast (SSM) [SSM] is another IPv4 multicast model. IPv4 multicast sources send IPv4 datagrams to the network, with the destination address of each IPv4 datagram set to a specific - - Nickless Informational - Expires August 2002 3 - IPv4 Multicast Best Current Practice February 2002 - ôgroupö address in the Class D address space (224/4). IPv4 multicast receivers register their interest in packets from a specific source that have been addressed to a group address, and the internetwork delivers packets from that source to the interested receivers. It is the responsibility of each receiver to specify which sources, sending to which groups, the receiver wishes to receive datagrams from. IPv4 multicast receivers register their interest in packets sent by specific sources to group addresses through IGMPv3. That is, IGMPv3 supports (S,G) registrations. - Sources that send packets to group addresses in the 233/8 range (the + Sources that send packets to group addresses in the 232/8 range (the SSM-specific range) can only be received by IGMPv3/SSM speaking receivers and networks. Multiprotocol BGP The topology of inter-domain IPv4 multicast forwarding is determined by BGPv4 [BGPV4] policy, as is IPv4 unicast forwarding. BGP provides reachability information. Reachability information for IPv4 Unicast and IPv4 Multicast prefixes can be advertised separately. (See [MBGP] for details and the definition of Network @@ -193,161 +196,173 @@ Information (SAFI).) The practical definition of reachability is different for IPv4 unicast (NLRI=unicast, SAFI=1) and IPv4 multicast (NLRI=Multicast, SAFI=2). In current practice for BGP unicast advertisements (NLRI=Unicast, SAFI=1), reachability is interpreted to mean that IPv4 datagrams will be forwarded towards their destination host if sent to the NEXT_HOP address in the advertisement. In the case of BGP multicast advertisements (NLRI=Multicast, - SAFI=2), reachability is interpreted to mean two things: + SAFI=2), reachability is interpreted to mean two things + simultaneously: First, IPv4 datagrams can be requested from sources within the advertised prefix range. Such requests are made to the advertised NEXT_HOP by means of the PIM Sparse Mode [PIM-SM] protocol, or (rarely) any other mutually agreed upon protocol that supports (S,G) requests. - Second, the MSDP [MSDP] speaker with the NEXT_HOP address will - provide MSDP Source Active messages from PIM Rendevous Points within - the advertised prefix range. + Second, the MSDP [MSDP] speaker associated with the NEXT_HOP address + will provide MSDP Source Active messages from PIM Rendevous Points + within the advertised prefix range. + + Nickless Informational - Expires December 2003 4 + IPv4 Multicast Best Current Practice June 2003 These two interpretations of BGP NLRI=Multicast flow from the use of BGP to replace the topology discovery portion of the Distance Vector Multicast Routing Protocol [DVMRP]. DVMRP is a ôdenseö routing protocol, which means traffic is flooded outwards from the sources to all possible receivers. In this situation, an IPv4 multicast router has to decide which incoming interface may accept IPv4 - - Nickless Informational - Expires August 2002 4 - IPv4 Multicast Best Current Practice February 2002 - datagrams from a given source (to avoid forwarding loops). When the switch was made to use a ôsparseö forwarding model (requiring specific (S,G) requests for traffic to flow) both interpretations of BGP NLRI=Multicast became necessary for interoperability with the DVMRP-based model. Note that while MSDP is not strictly necessary for Autonomous Systems that only support Source Specific Multicast [SSM], MSDP depends on the latter interpretation of BGP NLRI=Multicast to avoid MSDP SA forwarding loops. There is a real danger of causing MSDP SA forwarding ôblack holesö unless MSDP peerings are set up at the same time as BGP NLRI=Multicast peerings. - MBGP also supports combined multicast and unicast advertisements - (SAFI=3). Current practice is to interpret these advertisements to - include all three meanings listed above: unicast forwarding, - availability of traffic from multicast sources, and MSDP Source - Active availability. + Some MBGP implementations also support combined multicast and + unicast advertisements (SAFI=3). Current practice is to interpret + these advertisements to include all three meanings listed above: + unicast forwarding, availability of traffic from multicast sources, + and MSDP Source Active availability. PIM Sparse Mode The PIM Sparse Mode protocol [PIM-SM] is widely used to create forwarding state from IPv4 multicast sources to interested receivers. The term ôPIM Sparse Mode domainö generally refers to the hosts and routers that share a PIM Sparse Mode Rendezvous Point. In current practice, there is generally one PIM Sparse Mode domain per Autonomous System. Some Autonomous Systems choose to have - multiple PIM Sparse Mode domains for scalability reasons. + multiple PIM Sparse Mode domains for scalability and reliability + reasons. Within a PIM Sparse Mode domain, the standard PIM Sparse Mode mechanisms are used to build shared forwarding trees. Interested IPv4 multicast receivers make their group interest known through the Internet Group Management Protocol, and the associated PIM Designated Router (DR) sends (*,G) PIM Join messages towards the RP to build the appropriate shared forwarding tree. IPv4 multicast sources are registered with the PIM Rendezvous Point (RP). When - enough traffic is flowing down the shared tree, the RP will set the - SPT bit on packets, causing Designated Routers to create and join - source-specific (S,G) trees rooted at the source. + enough traffic from a given source is flowing down the shared tree, + PIM routers will create and join source-specific (S,G) trees rooted + at the source. This is known as the SPT Threshold. - Best current practice is to configure the RP to set the SPT bit on - all packets sent down the shared tree. That is, the SPT Threshold - should be zero. + Best current practice is to configure routers to join the source- + rooted tree on the first packet sent down the shared tree. That is, + the SPT Threshold should be zero. + + Nickless Informational - Expires December 2003 5 + IPv4 Multicast Best Current Practice June 2003 In the ASM model, PIM Sparse Mode Rendezvous Points have to co- operate in order to discover active sources and set up forwarding trees. MSDP is used to spread the knowledge of active sources within a multicast group. Source-specific (S,G) joins are used to set up forwarding from sources towards the interested receivers. No inter-PIM-domain shared forwarding tree is created. - Nickless Informational - Expires August 2002 5 - IPv4 Multicast Best Current Practice February 2002 - In the SSM model, there is no need for PIM Sparse Mode Rendezvous Points because each receiver explicitly identifies the sources from which it desires traffic. Thus, the local PIM Designated Router that receives an IGMPv3 request for traffic can initiate the PIM- Sparse Mode source-specific (S,G) requests directly towards the source. Packets sent to group addresses within the 232.0.0.0/8 range SHOULD NOT be encapsulated into PIM Register messages and forwarded to the PIM Rendezvous Point. Internet Group Management Protocol The Internet Group Management Protocol was designed to be used by hosts to notify the network that the hosts want to receive traffic on an IPv4 multicast group. The IGMP design originally assumed a shared media network like - Ethernet. When layer 2 switches became available, many vendors - built in IGMP ôsnoopingö so as to avoid flooding IP multicast - traffic to all ports. The best current practice for IPv4 multicast - deployment in a switched Local Area Network context is to use IGMP - snooping to avoid unnecessary IPv4 multicast flooding. + Ethernet. When IEEE 802.1 bridging (layer 2) switches became + available, many vendors built in IGMP ôsnoopingö so as to avoid + flooding IP multicast traffic to all ports. + + There are two alternative best current practices for IPv4 multicast + deployment in a network that has many IEEE 802 segments. Both + practices are intended to constrain unwanted flooding of multicast + traffic to segments that have no intended receivers. One is to use + nominally IEEE 802.1 bridges enhanced with IGMP snooping. Another + is to avoid IEEE 802.1 bridges altogether, in favor of small subnets + and multicast-aware IP routers. IGMPv2 [IGMPV2] supports the ASM model. IGMPv3 [IGMPV3] supports the ASM model as well as the SSM model. Some wide area network access servers support IGMP and IPv4 Multicast over PPP connections. Host implementations also support the IGMP over PPP connections, even those that use dial-up modems. Such support contributes to the availability and utility of IPv4 multicast service, but only when configured by network operators. Multicast Source Discovery Protocol The Multicast Source Discovery Protocol (MSDP) supports the Any Source Multicast model. It SHOULD NOT be used in a Source Specific Multicast context. Current best practice is for Autonomous Systems to ask each other for traffic from specific sources transmitting to specific groups. It follows that inter-AS IP multicast forwarding trees are all + + Nickless Informational - Expires December 2003 6 + IPv4 Multicast Best Current Practice June 2003 + source-specific. Thus, when a receiver registers an interest in datagrams addressed to a multicast group G (generally through an IGMPv2 (*,G) join) it is necessary for the associated PIM Sparse Mode Rendezvous Point (or other intra-AS protocol element, such as a Core Based Trees [CBT] Core Router) to arrange (S,G) joins towards each sender. Each inter-AS (S,G) join creates a branch of the forwarding tree towards the sender. The Multicast Source Discovery Protocol [MSDP] is used to communicate the availability of sources between Autonomous Systems. MSDP-speaking PIM Sparse Mode Rendezvous Points (or other designated MSDP speakers with knowledge of all sources within an Autonomous System) flood knowledge of active sources to each other. - Nickless Informational - Expires August 2002 6 - IPv4 Multicast Best Current Practice February 2002 - MSDP-speaking RPs communicate by way of a TCP session. The Source Active messages transmitted over the TCP session contain a packet of data, which the MSDP-speaking RPs can forward down their group- - specific shared trees, with the SPT-bit set. This is how PIM - speakers within a PIM domain learn of the external sources. + specific shared trees. This is how PIM speakers within a PIM domain + learn of the external sources. + + Generally, with the SPT Threshold set to zero, PIM speakers within + the domain will then join the source-rooted distribution tree. + Thus, the persistent packet flow may bypass the RP altogether. Model IPv4 Multicast-Capable BGPv4 Configuration IPv4 multicast reachability is communicated between Autonomous Systems by BGPv4 prefix announcements. That is, prefixes are advertised with NLRI=Multicast (SAFI in {2,3}). As outlined above, the semantics of a BGPv4 advertisement of an IPv4 NLRI=Multicast prefix are currently interpreted to mean two things: First, such an advertisement means that the router with the NEXT_HOP @@ -365,40 +380,41 @@ holesö, Autonomous Systems with BGPv4 speakers that exchange NLRI=Multicast advertisements must also have appropriate MSDP peerings configured. Model IPv4 Multicast Inter-domain PIM Sparse Mode Configuration As outlined above, current practice is that each IPv4 BGPv4 NLRI=Multicast capable peering is capable of making (S,G) requests for traffic. Autonomous Systems predominantly use PIM Sparse Mode for this purpose. The rest of this section describes how PIM Sparse + + Nickless Informational - Expires December 2003 7 + IPv4 Multicast Best Current Practice June 2003 + Mode is widely configured, but the principles can be applied to any other (S,G) request protocol between Autonomous Systems. The minimum TTL Threshold for traffic crossing an Autonomous System peering is generally set to be 32. This value follows earlier practice [FAQ] that sets inter-institution TTL barriers at 16-32. It also provides a reasonable number of values both above and below the (maximum 255) barrier. The PIM Sparse Mode Adjacency should not make requests for traffic across the peering for sources in these groups: 224.0.1.39/32: CiscoÆs Rendezvous Point Announcement Protocol 224.0.1.40/32: CiscoÆs Rendezvous Point Discovery Protocol 239.0.0.0/8: Administratively Scoped IPv4 Group Addresses (with possible exceptions) - Nickless Informational - Expires August 2002 7 - IPv4 Multicast Best Current Practice February 2002 - The first two groups are used to determine where PIM Sparse Mode Rendezvous Points can be found within an Autonomous System. The latter group range is defined by RFC 2365 [RFC2365]. RFC 2365 has been generally interpreted to equate ôorganizationsö (see section 6.2) with Autonomous Systems. Some Autonomous Systems choose to interpret this differently. Model PIM Sparse Mode Rendezvous Point Location In order to participate in current-practice inter-Autonomous System @@ -419,66 +435,44 @@ as well as [ANYCASTRP].) The IPv4 address of each PIM Sparse Mode Rendezvous Point (or other such MSDP-speaker) must be chosen so that it is within an advertised BGPv4 NLRI=Multicast prefix. The MSDP RPF checks operate on the so- called ôRP-Addressö within the MSDP Source Active message, not the advertised source S. In the most widely deployed case, the RP- Address is set by the MSDP-speaker to be the PIM Sparse Mode Rendezvous Point address. + Nickless Informational - Expires December 2003 8 + IPv4 Multicast Best Current Practice June 2003 + Model MSDP Configuration Between Autonomous Systems MSDP peerings are configured between Autonomous Systems. These peerings are statically defined. Thus, in practice, such MSDP- speaking (e.g.) PIM Sparse Mode Rendezvous Point(s) must be ôtied downö to known addresses and routers for the inter-AS peerings to operate correctly. The so-called ôRP-addressö in MSDP Source Active messages must be addressed within prefixes announced by BGPv4 NLRI=Multicast advertisements. (Otherwise the RP-Address Reverse Path Forwarding checks done by peer MSDP-speaking Autonomous Systems will fail, and the MSDP Source Active messages will be discarded.) The most common RP-address in MSDP Source Active messages is the PIM Rendezvous Point IPv4 address. In practice, MSDP speakers are configured to not advertise sources - to external peers from the following groups. MSDP speakers are also - configured to not accept source advertisements from external peers - within the following groups: - - Nickless Informational - Expires August 2002 8 - IPv4 Multicast Best Current Practice February 2002 - - 224.0.1.2/32: SGI ôDogfightö game and related services - 224.0.1.3/32: RWHOD - 224.0.1.8/32: SunÆs NIS+ - 224.0.1.22/32: SVRLOC - 224.0.1.24/32: MICROSOFT-DS - 224.0.1.25/32 - 224.0.1.35/32: SVRLOC-DA - 224.0.1.39/32: CiscoÆs Rendezvous Point Announcement Protocol - 224.0.1.40/32: CiscoÆs Rendezvous Point Discovery Protocol - 224.0.1.60/32: HPÆs Device Discovery Protocol - 224.0.2.1/32: rwho group (BSD) - 224.0.2.2/32: SunÆs Remote Procedure Call Protocol - 225.1.2.3/32: Altiris - 229.55.150.208/32: Norton ôGhostö disk duplication software - 232.0.0.0/8: Source-Specific Multicast - 234.42.42.42/30: ImageCast - 239.0.0.0/8: Administratively Scoped IPv4 Group Addresses - (with possible specific exceptions) - - Also see [FILTERLIST] for more information. Some sites block all - groups in 224.0.0.0/16, due to a lack of interdomain groups in that - range. + to external peers that are operating in certain groups, as outlined + in [UNUSABLE]. Also see [FILTERLIST] for more information. Some + sites block all groups in 224.0.0.0/24, due to a lack of interdomain + groups in that range. MSDP speakers are configured to not accept or advertise sources to or from external peers with Private Internet addresses [RFC1918]. MSDP-speakers are configured, wherever possible, to only advertise sources within prefixes that they are advertising as BGPv4 NLRI=Multicast (SAFI in {2,3}) announcements. That is, a non- transit Autonomous System would only advertise sources within the prefixes it advertises to its peers. @@ -495,26 +489,27 @@ multiple of the current number of active sources in the Internet. The Mantra Project [MANTRA] maintains MSDP statistics, as well as other IPv4 multicast statistics. Advanced Configurations Often an organization may wish to have multiple PIM RPs for scalability reasons. The Anycast-RP [ANYCASTRP] draft outlines one way how this can be accomplished. - Nickless Informational - Expires August 2002 9 - IPv4 Multicast Best Current Practice February 2002 - When an organization has multiple border routers, it makes sense for the organization to move the PIM Rendezvous Point off of the border and to an internal router. Note that the MSDP-speaking PIM RP will + + Nickless Informational - Expires December 2003 9 + IPv4 Multicast Best Current Practice June 2003 + need to be a part of the iBGP mesh so as to have BGPv4 NLRI=Multicast topology information. Security Considerations Autonomous Systems often configure router filters or firewall rules to discard mis-forwarded IPv4 datagrams. Such rules may explicitly list the IPv4 address ranges that are acceptable for incoming IPv4 datagrams. When IPv4 multicast is enabled, these rules need to be updated to disallow incoming IPv4 datagrams with addresses in the @@ -529,95 +524,102 @@ sending excessive Register-encapsulated packets towards the Rendezvous Point and flooding the Rendezvous Point with large numbers of (S,G) joins originated as IGMP Group Reports. Acknowledgements Dino Farinacci created the (S,G) notation used throughout this document. Kevin Almeroth, Tony Ballardie, H…vard Eidnes, David Farmer, Leonard - Giuliano, John Heasley, Marty Hoag, Simon Leinen, Michael Luby, - David Meyer, John Meylor, Stephen Sprunk and Dave Thaler provided - information, pointed out mistakes and made suggestions for + Giuliano, John Heasley, Marty Hoag, Milan J, Simon Leinen, Michael + Luby, David Meyer, John Meylor, Stephen Sprunk and Dave Thaler + provided information, pointed out mistakes and made suggestions for improvement. Marshall Eubanks described the vulnerability of PIM Sparse Mode Rendezvous Points to various denial of service attacks. This work was supported by the Mathematical, Information, and Computational Sciences Division subprogram of the Office of Advanced Scientific Computing Research, U.S. Department of Energy, under Contract W-31-109-Eng-38. -References +Normative References [RFC2119] RFC 2119: Key Words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. [MCAST] RFC 1112: Host extensions for IP multicasting. S.E. Deering. - Aug-01-1989. - - Nickless Informational - Expires August 2002 10 - IPv4 Multicast Best Current Practice February 2002 + August 1989. [CIDR] RFC 1519: Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993. + Nickless Informational - Expires December 2003 10 + IPv4 Multicast Best Current Practice June 2003 + + [RFC966] RFC 966: Host Groups: A Multicast Extension to the Internet + Protocol. S. E. Deering, D. R. Cheriton. December 1985. + [IGMPV2] RFC 2236: Internet Group Management Protocol, Version 2. W. Fenner. November 1997. - [IGMPV3] draft-ietf-idmr-igmp-v3-09.txt: Internet Group Management - Protocol, Version 3. B. Cain, S. Deering, B. Fenner, I Kouvelas, - A. Thyagarajan. January 2002. + [IGMPV3] RFC 3376: Internet Group Management Protocol, Version 3. + B. Cain, S. Deering, B. Fenner, I Kouvelas, A. Thyagarajan. + October 2002. [SSM] draft-ietf-ssm-arch-00.txt: Source-Specific Multicast for IP. H. Holbrook, B. Cain. 21 November 2001. [BGPV4] RFC 1771: A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995. [MBGP] RFC 2858: Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. Chandra, D. Katz. June 2000. [PIM-SM] RFC 2117: Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1997. [MSDP] draft-ietf-msdp-spec-13.txt: Multicast Source Discovery Protocol (MSDP). D. Meyer (Editor), B. Fenner (Editor). November 2001. - [DVMRP] RFC 1075: Distance Vector Multicast Routing Protocol. D. - Waitzman, C. Partridge, S.E. Deering. November 1988. - - [FAQ] http://netlab.gmu.edu/mbone_installation.htm - [RFC2365] RFC 2365: Administratively Scoped IP Multicast. D. Meyer. July 1998. - [FILTERLIST] ftp://ftpeng.cisco.com/ipmulticast/config-notes/msdp- - sa-filter.txt + [UNUSABLE] IPv4 Multicast Unusable Group Addresses. B. Nickless. + draft-nickless-ipv4-mcast-unusable-02.txt. June 2003. [RFC1918] RFC 1918: Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberk, G. J. de Groot, E. Lear. February 1996. - [MANTRA] http://www.caida.org/tools/measurement/mantra + [ANYCASTRP] RFC 3446: Anycast RP mechanism using PIM and MSDP. D. + Kim, D. Meyer, H. Kilmer, D. Farinacci. January 2003. - [ANYCASTRP] Anycast RP mechanism using PIM and MSDP. D. Kim, D. - Meyer, H. Kilmer, D. Farinacci, draft-ietf-mboned-anycast-rp- - 08.txt. May 2001. +Non-Normative References - Nickless Informational - Expires August 2002 11 - IPv4 Multicast Best Current Practice February 2002 + [DVMRP] RFC 1075: Distance Vector Multicast Routing Protocol. D. + Waitzman, C. Partridge, S.E. Deering. November 1988. + + [FAQ] http://netlab.gmu.edu/mbone_installation.htm + + Nickless Informational - Expires December 2003 11 + IPv4 Multicast Best Current Practice June 2003 + + [FILTERLIST] ftp://ftpeng.cisco.com/ipmulticast/config-notes/msdp- + sa-filter.txt + + [MANTRA] http://www.caida.org/tools/measurement/mantra Author's Address Bill Nickless Argonne National Laboratory 9700 South Cass Avenue #221 Phone: +1 630 252 7390 Argonne, IL 60439 Email: nickless@mcs.anl.gov - Nickless Informational - Expires August 2002 12 + Nickless Informational - Expires December 2003 12