INTERNET-DRAFT Source-Specific Multicast H. Holbrook Expires January 14, 2001 Cisco Systems B. Cain Mirror Image Internet 14 July 2000 Source-Specific Multicast for IP 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. 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 [RFC 2119]. Holbrook/Cain [Page 1] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 Abstract IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols [IANA-ALLOCATION]. This document defines the semantics of source- specific multicast addresses and specifies the policies governing their use. It defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this service. A companion document, [IGMPSSM], describes how the Internet Group Management Protocol Version 3 (IGMPv3) [IGMPv3] can be adapted to support source-specific multicast. 1. Overview and Rationale The Internet Protocol (IP) multicast service model is defined in RFC 1112 [RFC1112]. RFC 1112 specifies that a datagram sent to an IP class D address (224.0.0.0 through 239.255.255.255) G is delivered to each "upper-layer protocol module" that has requested reception of datagrams sent to address G. RFC 1112 calls the network service identified by a multicast destination address G a "host group." This model supports both one-to-many and many-to-many group communication. This document uses the term "Any-Source Multicast" (ASM) to refer to the RFC 1112 model of multicast. IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. Source-Specific Multicast delivery semantics are provided for a datagram sent to an SSM address. That is, a datagram with source IP address S and SSM destination address G is delivered (only) to each upper-layer "socket" that has specifically requested the reception of datagrams sent to address G by source S. The network service identified by (S,G), for SSM address G and source host address S, is referred to as a "channel." In contrast to the ASM model of RFC 1112, SSM provides network-layer support for one-to-many delivery only. The benefits of source-specific multicast include: Elimination of cross-delivery of traffic when two sources simultaneously use the same source-specific destination address. The simultaneous use of an SSM destination address by multiple sources is explicitly supported. Avoidance of the need for inter-host coordination when choosing Holbrook/Cain [Page 2] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 source-specific addresses, as a consequence of the above. Avoidance of many of the router protocols and algorithms that are needed to provide the ASM service model. For instance, the "shared trees" and Rendezvous Points of the PIM-SM protocol are not necessary to support the source-specific address range. The router mechanisms required to support SSM are not new, and are in fact largely a subset of those required to support ASM. For example, a network that uses the PIM-SM protocol can readily provide for source-specific multicast by using PIM's shortest-path trees. Like ASM, SSM is receiver-driven, and the receivers are unknown to the sender. An SSM source is provided with neither the identity of receivers nor their number. This document defines the semantics of source-specific multicast addresses and specifies the policies governing their use. In particular, it defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines host extensions to support the network service. Hosts, routers, applications, and protocols that use these addresses MUST comply with the policies outlined in this document. Failure of hosts to comply may prevent a host from receiving traffic sent to an SSM channel, and failure of a router to comply may result in SSM traffic being delivered to parts of the network where it is unwanted, placing an undue burden on the network infrastructure. [IGMPSSM] describes changes to the Internet Group Management Protocol Version 3 (IGMPv3) [IGMPv3] to support source-specific multicast. 2. Semantics of Source-Specific Multicast Addresses The source-specific multicast service is defined as follows: A datagram sent with source IP address S and destination IP address G in the SSM range is delivered to each host socket that has specifically requested delivery of datagrams sent by S to G, and only to those sockets. Where, using the terminology of [IGMPv3]: "socket" is an implementation-specific parameter used to distinguish among different requesting entities (e.g., programs or processes or communication end-points within a program or process) within the requesting host; the socket parameter of BSD Unix system calls is a specific example. Holbrook/Cain [Page 3] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 Any host may send a datagram to any SSM address, and delivery is provided according to the above semantics. The IP module interface to upper-layer protocols is extended to allow a socket to "Subscribe" to or "Unsubscribe" from a particular channel identified by an SSM destination address and a source IP address. The extended interface is defined in section 4.1. It is meaningless for an application or host to request reception of datagrams sent to an SSM destination address G, as is supported in "classic" IP Multicast (Any- Source Multicast), without also specifying a corresponding source address, and routers MUST ignore any such request from a host, pursuant to [IGMPSSM]. Multiple source applications on different hosts can use the same SSM destination address G without conflict because datagrams sent by each source host Si are delivered only to those sockets that requested delivery of datagrams sent to G specifically by Si. The key distinguishing property of the model is that a channel is identified (addressed) by the combination of a (unicast) source address and a multicast destination address in the SSM range. So, for example the channel S,G = (36.18.0.1, 232.7.8.9) differs from S,G = (36.18.0.2, 232.7.8.9). 3. Terminology To avoid confusion between Internet Standard Multicast and Source- Specific Multicast, we use different terminology when discussing the two service models. We use the term "channel" to refer to the service associated with an SSM address. A channel is identified by the combination of an SSM destination address and a specific source, e.g., an (S,G) pair. We use the term "host group" (used in RFC 1112) to refer to the service associated with "regular" class D addresses (excluding those in the SSM range). A host group is identified by a single class D address. Any host can send to a host group, and similarly, any host can send to an SSM destination address. A packet sent by a host S to an ASM destination address G is delivered to the host group identified by G. A Holbrook/Cain [Page 4] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 packet sent by host S to an SSM destination address G is delivered to the channel identified by (S,G). The receiver operations allowed on a host group are called "join(G)" and "leave(G)" (as per RFC 1112). The receiver operations allowed on a channel are called "Subscribe(S,G)" and "Unsubscribe(S,G)." The following table summarizes the terminology: Service Model: Any-Source Source-Specific Network Abstraction: group channel Identifier: G S,G Receiver Operations: join, leave subscribe, unsubscribe We note that, although this document specifies a new service model available to applications, the protocols and techniques necessary to support the service model are largely a subset of those used to support ASM. 4. Host Requirements This section describes requirements on hosts that support Source- Specific Multicast, including: - Extensions to the IP Module Interface - Extensions to the IP Module - Allocation of SSM Addresses 4.1. Extensions to the IP Module Interface The IP module interface to upper-layer protocols is extended to allow protocols to request reception of all datagrams sent to a particular channel. Subscribe ( socket, source-address, group-address, interface ) Unsubscribe ( socket, source-address, group-address, interface ) where "socket" is as previously defined, and, paraphrasing [IGMPv3], Holbrook/Cain [Page 5] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 "interface" is a local identifier of the network interface on which reception of the channel identified by the (source-address,group- address) pair is to be enabled or disabled. A special value may be used to indicate a "default" interface, as per [IGMPv3]. If reception of the same channel is desired on multiple interfaces, Subscribe is invoked once for each. The above are abstract functional APIs -- the functionality can be provided in an implementation-specific way. On a host that supports a full IGMPv3 API, the Subscribe and Unsubscribe MAY be provided via those APIs, for instance using [MSFAPI]. Widespread implementations of the IP packet reception interface (e.g., the recvfrom() system call in BSD unix) do not allow a receiver to determine the destination address to which a datagram was sent. On a host with such an IP implemntation the destination address of a datagram cannot be inferred when the socket on which the datagram is received is Subscribed to multiple channels. Host operating systems SHOULD provide a way for a host to determine both the source and the destination address to which a datagram was sent. (As one example, the Linux operating system provides the destination of a packet as part of the response to the recvmsg() system call.) Until this capability is present, applications are forced to use higher-layer mechanisms to identify the channel to which a datagram was sent. 4.2. Requirements on the Host IP Module An incoming datagram destined to an SSM address MUST be delivered by the IP module to all sockets that have indicated (via Subscribe) a desire to receive data that matches the datagram's source address, destination address, and arriving interface. It MUST NOT be delivered to other sockets. When the first socket on host H subscribes to a channel (S,G) on interface I, the host IP module on H sends a request on interface I to indicate to neighboring routers that the host wishes to receive traffic sent by source S to source-specific destination G. Similarly, when the last socket on a host unsubscribes from a channel on interface I, the host IP module sends an unsubscription request for that channel out interface I. These requests will typically be IGMPv3 messages, and the exact rules for sending source-specific subscription and unsubscription requests and the algorithms used to maintain subscriptions are defined in [IGMPSSM]. Holbrook/Cain [Page 6] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 4.3. Allocation of Source-Specific Multicast Addresses The SSM destination address 232.0.0.0 is reserved, and hosts MUST NOT send datagrams with destination address of 232.0.0.0. The address range 232.0.0.1-232.0.0.255 is reserved for allocation by IANA. The policy for allocating the rest of the SSM addresses to sending applications is strictly locally determined at the sender's host. When allocating addresses from the locally allocated range (232.0.1.0 - 232.255.255.255), a host or host operating system MUST NOT start at the first allowed address, 232.0.1.0, and allocate addresses sequentially. As described in Section 6, the mapping of an IP packet with SSM destination address onto a link-layer multicast address does not take into account the datagram's source IP address (on commonly-used link layers like Ethernet). If all hosts started at 232.0.1.0, then with high probability, many source-specific channels on shared-medium local area networks would collide on the same link-layer multicast address. As a result, traffic destined for one channel member would burden another as the link-layer (unaware of the IP Source Address) accepts the multicast datagram, passes it to the IP layer, which then simply rejects it. A RECOMMENDED allocation policy is for a host to allocate SSM addresses to applications randomly, while ensuring that allocated addresses are not given simultaneously to multiple applications and while avoiding the reserved space. A host operating system SHOULD provide an interface to allow an application to request a unique allocation of a channel destination address in advance of a session's commencement, and this allocation database SHOULD persist across host reboots. By providing persistent allocations, a host application can advertise the session in advance of its start time on a web page or in another directory. (We note that this issue is not specific to SSM applications -- the same problem arises when ASM is used.) This document neither defines the interfaces for requesting or returning addresses nor specifies the host algorithms for storing those allocations. One plausible abstract API is defined in RFC 2771 [RFC2771], although the interface of RFC 2771 would allow an application to request an address from a specific sub-range of the SSM allocation, which is NOT RECOMMENDED for SSM, unless the start address of the allowed range is selected at random. Randomization is important to minimize link-layer collisions. No globally agreed-upon administratively-scoped address range [ADMIN- SCOPE] is needed for the source-specific multicast range because there Holbrook/Cain [Page 7] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 is no possibility of address conflict between hosts in different administrative domains (or between two hosts of any kind). Administrative scoping of SSM addresses MAY be implemented within an administrative domain by filtering at domain boundary routers. 5. Router Requirements 5.1. Packet Forwarding A router that receives an IP datagram with a source-specific destination address MUST silently drop it unless a neighboring host or router has communicated a desire to receive packets sent to the source and destination address of the received packet. 5.2. Protocols Certain IP multicast routing protocols already have the ability to communicate source-specific joins to neighboring routers (in particular, PIM-SM), and these protocols can, with slight modifications, be used to provide source-specific semantics. Companion documents will specify the required modifications to those protocols to support the source- specific address range. A network can concurrently support SSM semantics in the SSM address range and Any-Source Multicast in the rest of the class D address space, and it is expected that this will be commonplace. In such a network, a router may receive a non-source-specific, or "(*,G)" in conventional terminology, request for delivery of traffic in the SSM range from a neighbor that does not implement source-specific multicast in a manner compliant with this document. A router that receives such a non-source- specific request for data in the SSM range MUST NOT use the request to establish forwarding state and MUST NOT propagate the request to other neighboring routers. This applies both to any request received from a host, e.g., an IGMPv1 or IGMPv2 host report, and to any request received from a routing protocol, e.g., a PIM-SM (*,G) join [PIM-SM]. The inter- router case is further discussed in section 8, Transition Considerations. It is essential that all routers in the network give source-specific semantics to the same range of addresses in order to achieve the full benefit of SSM. To comply with this specification, a router MUST treat ALL 232/8 addresses with source-specific semantics. Holbrook/Cain [Page 8] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 6. Link-Layer Transmission of Datagrams Source-specific multicast packets are transmitted on link-layer networks as specified in RFC 1112. On most shared-medium link-layer networks that support multicast (e.g., Ethernet), the IP source address is not used in the selection of the link-layer destination address. Consequently, on such a network, all packets sent to destination address G will be delivered to any host that has subscribed to any channel (S,G), regardless of S. And therefore, the IP module MUST filter packets it receives from the link layer before delivering them to the socket layer. A socket on which an (S,G) subscription has been requested MUST receive packets whose source and destination address match the requested subscription(s) for that socket. 7. Security Considerations 7.1. Denial-of-Service A subscription request creates (S,G) state in a router to record the subscription and invokes processing on that router and possibly causes processing at neighboring routers. A host can mount a denial of service attack by requesting a large number of subscriptions. A denial of service can result if: - a large amount of traffic arrives when it was otherwise undesired, consuming network resources to deliver it and host resources to drop it - a large amount of (invalid) source-specific multicast state is created in network routers, using router memory and CPU resources to store and process the state - a large amount of control traffic is generated to manage the source-specific state, using router CPU and network bandwidth To reduce the potential for damage from such an attack, a router MAY have a configuration option to limit the following items: - The total rate at which all hosts on any one interface are allowed to initiate subscriptions (to limit the damage caused by forged source-address attacks) - The total number of subscriptions that can be initated from any single interface. Holbrook/Cain [Page 9] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 Any decision by an implementor to artificially limit the rate or number of subscriptions should be taken carefully, however, as future applications may be developed that can use large numbers of channels. Placing tight limits on the rate or number of channel subscriptions may inhibit the development and deployment of such applications. A router SHOULD verify that the source of a subscription request is a valid address for the interface on which it was received. Failure to do so would exacerbate a spoofed-source address attack. We note that these attacks are not unique to SSM -- they are also present for Any-Source Multicast. 7.2. Spoofed Source Addresses By forging the source address in a datagram, an attacker can potentially transmit datagrams on a channel that belongs to another host, violating the SSM service model. Thus, applications that require strong authentication should not assume that all packets that arrive on a channel were sent by the requested source. Higher-layer authentication mechanisms should be used in such an application. Some degree of protection against spoofed source addresses in multicast is already fairly widespread, because the commonly deployed IP multicast routing protocols [PIM-DM, PIM-SM, DVMRP] incorporate a "reverse-path forwarding check" that validates that a multicast packet arrived on the expected interface for its source address. It is anticipated that the routing protocols used for SSM will also incorporate such a check. 8. Transition Considerations A host that uses the SSM address range in a fashion compliant with this document will send ONLY source-specific host reports for addresses in the SSM range. However, during a transition period, non-compliant hosts might send non-source-specific (IGMPv1 or IGMPv2) host reports for source-specific destination addresses, and routers SHOULD ignore these reports (as stated in [IGMPSSM]). Failure to do so would violate the SSM service model promised to the sender: that a packet sent to (S,G) would only be delivered to hosts that specifically requested delivery of packets sent to G by S. During a transition period, it may be possible to deliver SSM datagrams through domains that are not SSM compliant by simply forwarding any packet destined to G to all hosts that have requested subscription of (S,G) for any S. However, this implementation risks placing an undue Holbrook/Cain [Page 10] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 burden on the network infrastructure to deliver (S,G) datagrams to hosts that did not request them. Such an implementation for addresses in the SSM range is specifically not compliant with Section 5.2 of this document. 9. IANA Considerations IANA has characterized addresses in the 232/8 address range as source- specific multicast addresses [IANA-ALLOCATION]. No address transition plan is required by IANA. Following the policies outlined in [IANA-CONSIDERATIONS], addresses in the range 232.0.0.1 through 232.0.0.255 are reserved for allocation to well-known and widely-applicable source-specific multicast applications and services, under a policy of IETF Expert Review with Specification Required. The addresses in this range are reserved for services with wide applicability that either require or would strongly benefit if all hosts used a well-known SSM destination address for the application. When considering an allocation in the 232.0.0.1-232.0.0.255 range, it should be considered that, on an Ethernet network, any datagram sent to a well- known SSM destination address will be transmitted to the same link-layer destination address, regardless of its IP source address. Therefore, the link-layer impact of allocating a well-known SSM address should be considered carefully. Furthermore, the fact that channels with destinations in 232.0.0/24 use the same link-layer addresses as the reserved IP multicast group range 224.0.0/24 must also be taken under consideration. Except for the aforementioned addresses, IANA SHALL NOT allocate destination addresses in this range to particular entities or for use by particular applications. To do so would compromise one of the important benefits of the source-specific model: the ability for a host to autonomously allocate source-specific addresses without consulting a remote authority. 10. Acknowledgments The SSM service model draws on previous work done on the EXPRESS Multicast model [EXPRESS] with David Cheriton. We would like to thank David Cheriton and Jon Postel for their support in reassigning the 232/8 address range to SSM. Holbrook/Cain [Page 11] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 11. References [IANA-ALLOCATION] Internet Assigned Numbers Authority, http://www.isi.edu/in-notes/iana/assignments/multicast-addresses. [IGMPv3] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group Management Protocol, Version 3," Work in Progress. [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, August 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. [RFC2771] Finlayson, R., "An Abstract API for Multicast Address Allocation," RFC 2771, February 2000. [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," RFC 2236, November 1997. [IANA-CONSIDERATIONS] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," RFC 2434, October 1998. [PIM-DM] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy, A., Meyer, D., and L. Wei, "Protocol Independent Multicast Version 2 Dense Mode Specification," Work in Progress. [PIM-SM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification," RFC 2362, June 1998. [DVMRP] Waitzman, D., Partridge, C., and S. Deering., "Distance Vector Multicast Routing Protocol," RFC 1075, Nov 1988. [ADMIN-SCOPE] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July, 1998. [IGMPSSM] Holbrook, H., and Cain, B. "Using IGMPv3 for Source-Specific Multicast". Work in Progress. [EXPRESS] Holbrook, H., and Cheriton, D. "Explicitly Requested Source- Specific Multicast: EXPRESS support for Large-scale Single-source Applications." Proceedings of ACM SIGCOMM '99, Cambridge, MA, September 1999. [MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface Extensions for Multicast Source Filters." Work in Progress. Holbrook/Cain [Page 12] INTERNET-DRAFT Source-Specific Multicast 14 July 2000 12. Author's Address Brad Cain Mirror Image Internet bcain@mirror-image.com Hugh Holbrook Cisco Systems holbrook@cisco.com This document expires January 14, 2001. Holbrook/Cain [Page 13]