Internet Draft B. Nickless Document: draft-nickless-ipv4-mcast-bcp-00.txt Argonne National Laboratory Expires: October 2001 April 2001 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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes best current practices for IPv4 multicast deployment, both within and between PIM Domains and Autonomous Systems. Nickless Informational - Expires October 2001 1 IPv4 Multicast Best Current Practice April 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................2 Introduction and Terminology.......................................2 Any Source Multicast...............................................3 Source Specific Multicast..........................................3 Multiprotocol BGP..................................................3 PIM Sparse Mode....................................................4 Internet Group Management Protocol.................................5 Multicast Source Discovery Protocol................................5 Model IPv4 Multicast-Capable BGPv4 Configuration...................5 Model IPv4 Multicast Inter-domain PIM Sparse Mode Configuration....6 Model PIM Sparse Mode Rendezvous Point Location....................6 Model MSDP Configuration Between Autonomous Systems................6 Acknowledgements...................................................7 Security Considerations............................................7 References.........................................................8 Author's Address...................................................8 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 document describes best current practices for configuring these protocols, individually and in combination. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Introduction and Terminology IPv4 multicast [MCAST] is an internetwork service that allows IPv4 datagrams sent from a source to be delivered to more than one interested receiver. That is, a given source sends a packet the network with a destination address 224/4 CIDR [CIDR] range. The network transports This packet to all receivers (replicated where necessary) that have registered their interest in receiving these packets. Nickless Informational - Expires October 2001 2 IPv4 Multicast Best Current Practice April 2001 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 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). Any Source Multicast Any Source Multicast (ASM) is the traditional IPv4 multicast [MCAST] model. IPv4 multicast sources send IPv4 datagrams to the network, with the destination address of each IPv4 datagram set to a specific ô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. 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. 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 ô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 the Internet Group Management Protocol Version 3 (IGMPv3) [IGMPV3]. That is, IGMPv3 supports (S,G) registrations. 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 are advertised separately. (See [MBGP] for details and the definition of Network Layer Nickless Informational - Expires October 2001 3 IPv4 Multicast Best Current Practice April 2001 Reachability Information (NLRI)). The practical definition of reachability is different for IPv4 unicast (NLRI=unicast) and IPv4 multicast (NLRI=Multicast). In the case of BGP unicast advertisements (NLRI=Unicast), reachability means 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), reachability means two things: 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. 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. Note that while MSDP is not strictly necessary for Autonomous Systems that only support Source Specific Multicast [SSM], MSDP depends on the latter semantic 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. PIM Sparse Mode The PIM Sparse Mode protocol [PIM-SM] is used to create forwarding state from IPv4 multicast sources to interested receivers. Within a PIM Sparse Mode domain, the standard PIM Sparse Mode mechanisms are used to build shared forwarding trees and source specific trees from IPv4 multicast sources to interested receivers. IPv4 multicast sources are registered with the PIM Rendezvous Point (RP). Interested IPv4 multicast receivers make their group interest known through the Internet Group Management Protocol, and the associated PIM Designated Router (DR) sends PIM Join messages towards the RP to build the appropriate forwarding trees. 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. PIM-SM source-specific 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 October 2001 4 IPv4 Multicast Best Current Practice April 2001 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 in a Virtual Local Area Network (VLAN). 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. IGMPv2 [IGMPV2] supports the ASM model. IGMPv3 [IGMPV3] supports the ASM model as well as the SSM model. Wide Area Network Access servers, even those that use dial-up modems, SHOULD support IGMP specifically and IPv4 multicast generally. Multicast Source Discovery Protocol Inter-domain IP multicast forwarding trees are all 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 to send (S,G) joins towards each sender. Each (S,G) join from a PIM Sparse Mode Rendezvous Point 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 PIM Sparse Mode Rendezvous Points. MSDP-speaking PIM Sparse Mode Rendezvous Points flood knowledge of all active sources in the internetwork to each other. Model IPv4 Multicast-Capable BGPv4 Configuration IPv4 multicast reachability is communicated between Autonomous Systems by BGPv4 prefix announcements. That is, with prefixes carrying within the NLRI=Multicast address family. As outlined above, the semantics of a BGPv4 advertisement of an IPv4 NLRI=Multicast prefix are twofold: First, such an advertisement means that the router with the NEXT_HOP address of that advertisement will supply packets from any transmitting source S whose address matches the prefix advertised. Thus, the two BGPv4 speakers that communicate NLRI=Multicast advertisements MUST also have a PIM Sparse Mode adjacency configured. Nickless Informational - Expires October 2001 5 IPv4 Multicast Best Current Practice April 2001 Second, such an advertisement means that the router with the NEXT_HOP address of that advertisement will supply MSDP Source Active messages from any PIM Sparse Mode Rendezvous Point whose address matches the prefix advertised. Thus, the two Autonomous Systems with BGPv4 speakers that communicate NLRI=Multicast advertisements MUST also have appropriate MSDP peerings configured. Model IPv4 Multicast Inter-domain PIM Sparse Mode Configuration As outlined above, each IPv4 BGPv4 NLRI=Multicast capable peering MUST have an associated PIM Sparse Mode adjacency. This PIM Sparse Mode adjacency SHOULD be configured in the following ways: The minimum TTL Threshold for traffic crossing this peering SHOULD be 32. The PIM Sparse Mode Adjacency MUST deny traffic across the peering for 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 Model PIM Sparse Mode Rendezvous Point Location A PIM Sparse Mode Rendezvous Point SHOULD have access to the full BGP NLRI=Multicast reachability table so as to send PIM Sparse Mode Source Specific Joins to the appropriate external peer networks. Access to the BGPv4 NLRI=Multicast reachability table is also important so that the Rendezvous Point will perform MSDP Reverse- Path-Forwarding (RPF) checks correctly. (Note that MSDP speakers are, by definition, PIM Sparse Mode Rendezvous Points.) PIM Sparse Mode Rendezvous Points SHOULD be located at a border router of an Autonomous System where the BGPv4 NLRI=Multicast reachability table is already maintained. If necessary, an MSDP Mesh Group can be created if there are multiple BGPv4 NLRI=Multicast speakers within an Autonomous System. The IPv4 address of each PIM Sparse Mode Rendezvous Point MUST be chosen so that it is within an advertised BGPv4 NLRI=Multicast prefix. The MSDP RPF checks operate on the address of the PIM Sparse Mode Rendezvous Point within the MSDP Source Active message, not the advertised source S. Model MSDP Configuration Between Autonomous Systems As outlined above, an MSDP speaker is (by definition) a PIM Sparse Mode Rendezvous Point. Thus, the PIM Sparse Mode Rendezvous Point(s) MUST be ôtied downö to known addresses and routers for the inter-AS peerings to operate correctly. Nickless Informational - Expires October 2001 6 IPv4 Multicast Best Current Practice April 2001 MSDP speaking PIM Sparse Mode Rendezvous Points MUST be addressed within BGPv4 NLRI=Multicast advertisements. (Otherwise the Rendezvous Point address Reverse Path Forwarding checks done by peer MSDP-speaking PIM Sparse Mode Rendezvous Points will fail, and the MSDP Source Active messages will be discarded.) MSDP speakers SHOULD NOT advertise sources to external peers from the following groups. MSDP speakers SHOULD NOT accept source advertisements from external peers within the following groups: 224.0.1.2/32: SGI ôDogfightö game 224.0.1.3/32: RWHOD 224.0.1.22/32: SVRLOC 224.0.1.24/32: MICROSOFT-DS 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.2/32: SunÆs Remote Procedure Call Protocol 229.55.150.208/32: Norton ôGhostö disk duplication software 232.0.0.0/8: Source-Specific Multicast MSDP speakers SHOULD NOT accept or advertise sources to or from external peers with Private Internet addresses [RFC1918]. MSDP-speaking PIM Sparse Mode Rendezvous Points SHOULD be configured, wherever possible, to only advertise sources within prefixes that they are advertising as BGPv4 NLRI=Multicast announcements. Each MSDP peering SHOULD be configured with reasonable rate limits to dampen explosions of MSDP SA advertisements. These explosions can occur when malicious software generates packets addressed to many IPv4 multicast groups in a very short period of time. 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 MUST be updated to disallow incoming IPv4 datagrams with addresses in the 239/8 CIDR range, and to allow incoming IPv4 datagrams with destination addresses in the 224/4 CIDR range. Acknowledgements 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. Nickless Informational - Expires October 2001 7 IPv4 Multicast Best Current Practice April 2001 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. [CIDR] RFC 1519: Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993. [IGMPV2] RFC 2232: Internet Group Management Protocol, Version 2. W. Fenner. November 1997. [SSM] draft-holbrook-ssm-arch-02.txt: Source-Specific Multicast for IP. H. Holbrook, B. Cain. 1 March 2001. [IGMPV3] draft-ietf-idmr-igmp-v3-07.txt: Internet Group Management Protocol, Version 3. B. Cain, S. Deering, B. Fenner, I Kouvelas, A. Thyagarajan. March 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-07.txt: Multicast Source Discovery Protocol (MSDP). D. Meyer (Editor). March 2001. [RFC1918] Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberk, G. J. de Groot, E. Lear. February 1996. 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 October 2001 8