Network Working Group H. Holbrook Request for Comments: 4604 Arastra, Inc. Updates: 3376, 3810 B. Cain Category: Standards Track Acopia Networks B. Haberman JHU APL August 2006 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractThe Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications.
RFC1112, IGMPv2, IGMPv3] allows an IPv4 host to communicate IP multicast group membership information to its neighboring routers. IGMP version 3 (IGMPv3) [IGMPv3] provides the ability for a host to selectively request or filter traffic from individual sources within a multicast group. The Multicast Listener Discovery Protocol (MLD) [RFC2710, MLDv2] offers similar functionality for IPv6 hosts. MLD version 2 (MLDv2) provides the analogous "source filtering" functionality of IGMPv3 for IPv6. Due to the commonality of function, the term "Group Management Protocol", or "GMP", will be used to refer to both IGMP and MLD. The term "Source Filtering GMP", or "SFGMP", will be used to refer jointly to the IGMPv3 and MLDv2 group management protocols. The use of source-specific multicast is facilitated by small changes to the SFGMP protocols on both hosts and routers. [SSM] defines general requirements that must be followed by systems that implement the SSM service model; this document defines the concrete application of those requirements to systems that implement IGMPv3 and MLDv2. In doing so, this document defines modifications to the host and router portions of IGMPv3 and MLDv2 for use with SSM, and presents a number of clarifications to their behavior when used with SSM addresses. This document updates the IGMPv3 and MLDv2 specifications. RFC2119]. In order to emphasize the parts of this document that modify the existing protocol specifications ([RFC2710, MLDv2, IGMPv3]), as opposed to merely clarify them, any protocol modifications are marked with the tag "MODIFICATION".
modifications described in this section make SSM work better on an SSM-aware host, but they are not strict prerequisites for the use of SSM. The 232/8 IPv4 address range is currently allocated for SSM by IANA [IANA-ALLOCATION]. In IPv6, the FF3x::/32 range (where 'x' is a valid IPv6 multicast scope value) is reserved for SSM semantics [RFC3306], although today SSM allocations are restricted to FF3x::/96. ([SSM] has a more thorough discussion of this topic.) A host that knows the SSM address range and is capable of applying SSM semantics to it is described as an "SSM-aware" host. A host or router may be configured to apply SSM semantics to addresses other than those in the IANA-allocated range. The GMP module on a host or router SHOULD have a configuration option to set the SSM address range(s). If this configuration option exists, it MUST default to the IANA-allocated SSM range. The mechanism for setting this configuration option MUST at least allow for manual configuration. Protocol mechanisms to set this option may be defined in the future. MSFAPI] (MODIFICATION). On a non-SSM-aware host, an application that uses the wrong API (e.g., "join(G)", "IPMulticastListen(G,EXCLUDE(S1))" for IGMPv3, or "IPv6MulticastListen(G,EXCLUDE(S2))" for MLDv2) to request delivery of packets sent to an SSM address will not receive the requested service, because an SSM-aware router (following the rules of this document) will refuse to process the request, and the application will receive no indication other than a failure to receive the requested traffic. IGMPv3, MLDv2]. It also includes a number of clarifications of protocol operations. In doing so, it documents the behavior of an SSM-aware host with respect to sending and receiving the following GMP message types: - IGMPv1/v2 and MLDv1 Reports (2.2.1) - IGMPv3 and MLDv2 Reports (2.2.2) - IGMPv1 Queries, IGMPv2 and MLDv1 General Queries (2.2.3)
- IGMPv2 Leave and MLDv1 Done (2.2.4) - IGMPv2 and MLDv1 Group Specific Query (2.2.5) - IGMPv3 and MLDv2 Group Specific Query (2.2.6) - IGMPv3 and MLDv2 Group-and-Source Specific Query (2.2.7) IGMPv3, MLDv2] could send an IGMPv1, IGMPv2, or MLDv1 report for an SSM address when it is operating in "older-version compatibility mode." This is an exceptional (error) condition, indicating that the router(s) cannot provide the SFGMP support needed for SSM, and an error is logged when the host enters compatibility mode for an SSM address, as described below. In this situation, it is likely that traffic sent to a channel (S,G) will not be delivered to a receiving host that has requested to receive channel (S,G). [IGMPv3] and [MLDv2] specify that a host MAY allow an older-version report to suppress its own IGMPv3 or MLDv2 Membership Record. An SSM-aware host, however, MUST NOT allow its report to be suppressed in this situation (MODIFICATION). Suppressing reports in this scenario would provide an avenue for an attacker to deny SSM service to other hosts on the link.
An SSM-aware host SHOULD NOT send any of the following record types for an SSM address. - MODE_IS_EXCLUDE as part of a Current-State Record - CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record This is a MODIFICATION to [IGMPv3, MLDv2], imposing a restriction on its use for SSM destination addresses. The rationale is that EXCLUDE mode does not apply to SSM addresses, and an SSM-aware router will ignore MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM range, as described below.
IGMPv3, MLDv2], even if the group queried is a source-specific destination address. The transmission of such a query likely indicates either that the sending router is not compliant with this document or that it is not configured with the same SSM address range(s) as the receiving host. A host SHOULD log an error in this case (MODIFICATION). IGMPv3, MLDv2]. The rationale for this is that, although in the current SFGMP protocol specifications a router would have no reason to send one, the semantics of such a query are well-defined in this range and future implementations may have reason to send such a query. Be liberal in what you accept. IGMPv3, MLDv2]. The use of an SSM address does not change this behavior. A host must be able to process a query with multiple sources listed per group, again as required by [IGMPv3, MLDv2]. The use of an SSM address does not modify the behavior of the SFGMPs in this regard.
This section documents the behavior of routers with respect to the following types of SFGMP messages for source-specific destination addresses: - IGMPv3 and MLDv2 Reports (3.1) - IGMPv3 and MLDv2 General Query (3.2) - IGMPv3 and MLDv2 Group-Specific Query (3.3) - IGMPv3 and MLDv2 Group-and-Source Specific Query (3.4) - IGMPv1/v2 and MLDv1 Reports (3.5) - IGMPv1/v2 and MLDv1 Queries (3.6) - IGMPv2 Leave and MLDv1 Done (3.7) IGMPv3, MLDv2] to prevent non-source-specific semantics from being applied to SSM addresses, and to avoid reverting to older-version compatibility mode. A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record is processed per the normal SFGMP rules; Section 2.2.2 describes a legitimate scenario when this could occur. IGMPv3, MLDv2] would not send one.
IGMPv3, MLDv2]. IGMPv3, MLDv2]. A router MAY log an error if it receives such a report (also a MODIFICATION). IGMPv3, MLDv2]. SSM] for an analysis of SSM-specific security issues. It is important that a router not accept non-source-specific reception requests for an SSM destination address. The rules of [IGMPv3] and [MLDv2] require a router, upon receiving such a membership report, to revert to earlier version compatibility mode for the group in question. If the router were to revert in this situation, it would prevent an IGMPv3-capable host from receiving SSM service for that destination address, thus creating a potential for an attacker to deny SSM service to other hosts on the same link.
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [IGMPv3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [MSFAPI] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [SSM] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [IANA-ALLOC] Internet Assigned Numbers Authority, http://www.iana.org/assignments/multicast-addresses. [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).