Internet Engineering Task Force MAGMA WG INTERNET-DRAFT B. Fenner/AT&T draft-ietf-magma-msnip-04.txt B. Haberman/Caspian Networks H. Holbrook/Cisco I. Kouvelas/Cisco 19 June 2003 Expires: December 2003 Multicast Source Notification of Interest Protocol (MSNIP) Status of this Document 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. This document is a product of the IETF MAGMA WG. Comments should be addressed to the authors, or the WG's mailing list at magma@ietf.org. Abstract This document discusses the Multicast Source Interest Notification Protocol (MSNIP). MSNIP is an extension to IGMPv3 and MLDv2 that provides membership notification services for sources of multicast traffic operating within the SSM destination address range. Fenner/Haberman/Holbrook/Kouvelas [Page 1]
INTERNET-DRAFT Expires: December 2003 June 2003 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 2. Routing Protocol Support. . . . . . . . . . . . . . . . 3 3. Service Interface for Requesting Membership Noti- fication . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Application Operation. . . . . . . . . . . . . . . . 5 4. MSNIP Managed Address Range Negotiation . . . . . . . . 6 4.1. Router Coordination. . . . . . . . . . . . . . . . . 6 4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6 4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7 4.2. Managed Range Discovery by Source Systems. . . . . . 8 5. Requesting and Receiving Notifications. . . . . . . . . 8 5.1. Host Interest Solicitation . . . . . . . . . . . . . 9 5.2. Router Receiver Membership Reports . . . . . . . . . 9 6. Application Notification. . . . . . . . . . . . . . . . 11 7. Router Processing . . . . . . . . . . . . . . . . . . . 13 8. Message Formats . . . . . . . . . . . . . . . . . . . . 14 8.1. Host Interest Solicitation Message . . . . . . . . . 15 8.2. Receiver Membership Report Packet. . . . . . . . . . 16 8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . 18 8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . 18 9. Constants Timers and Default Values . . . . . . . . . . 18 10. Possible Optimisations . . . . . . . . . . . . . . . . 19 10.1. Suppressing HIS Messages. . . . . . . . . . . . . . 19 10.2. Host Stack Filtering. . . . . . . . . . . . . . . . 19 10.3. Responding to Unexpected IGMP Queries . . . . . . . 19 10.4. Host and Router Startup . . . . . . . . . . . . . . 20 11. Inter-operation with IGMP / MLD Proxying . . . . . . . 20 12. Security Considerations. . . . . . . . . . . . . . . . 21 12.1. Receiver Membership Report attacks. . . . . . . . . 21 12.2. Host Interest Solicitation attacks. . . . . . . . . 22 12.3. MSNIP Managed Range Discovery . . . . . . . . . . . 22 13. IANA Considerations. . . . . . . . . . . . . . . . . . 23 14. Acknowledgments. . . . . . . . . . . . . . . . . . . . 23 15. Normative References . . . . . . . . . . . . . . . . . 23 16. Informative References . . . . . . . . . . . . . . . . 24 Fenner/Haberman/Holbrook/Kouvelas [Page 2]
INTERNET-DRAFT Expires: December 2003 June 2003 1. Introduction The Multicast Source Notification of Interest Protocol (MSNIP) is an extension to version 3 of the Internet Group Membership Protocol (IGMPv3 [1]) and version 2 of the Multicast Listener Discovery Protocol (MLDv2 [2]). MSNIP operates between multicast sources and their first- hop routers to provide information on the presence of receivers to the source systems. Using the services offered by MSNIP an application on an IP system wishing to source multicast data can register to be notified when receivers join and leave the session. This enables multicast sources to avoid the work of transmitting packets onto their first-hop link when there are no joined receivers. A common scenario where MSNIP may be useful is one where there is a multicast server offering a large pool of potential flows that map onto separate multicast destination addresses but receivers exist only for a small subset of the flows. If the source were to continuously transmit data for all the flows that could potentially have receivers, significant resources would be wasted in the system itself as well as the first-hop link and first-hop router. Using a higher level control protocol to determine the existence of receivers for particular flows may not be practical as there may be many potential receivers in each active session. Information on which multicast destination addresses have receivers for a particular sender is typically available to the multicast routing protocol on the first hop router for a source. MSNIP uses this information to notify the application in the sending system of when it should start or stop transmitting. This is achieved without any destination address specific state on the first-hop router for potential sources without receivers. 2. Routing Protocol Support For reasons described in this section, MSNIP only supports transmission control for applications that use multicast destination addresses that are routed using Source Specific Multicast (SSM). Many currently deployed multicast routing protocols require data from an active source to be propagated past the first-hop router before information on the existence of receivers becomes available on the first-hop. In addition, such protocols require that this activity is repeated periodically to maintain source liveness state on remote routers. All dense-mode protocols fall under this category as well as sparse-mode protocols that use shared trees for source discovery (such as PIM-SM [11]). In order to provide receiver interest notification for such protocols, the default mode of operation would require that the Fenner/Haberman/Holbrook/Kouvelas Section 2. [Page 3]
INTERNET-DRAFT Expires: December 2003 June 2003 source IP system periodically transmits on all potential destination addresses and the first-hop routers prune the traffic back. Such a flood-and-prune behaviour on the first-hop link significantly diminishes the benefits of managing source transmission. In contrast, with source-specific sparse-mode protocols such as PIM-SSM [11] availability of receiver membership information on the first-hop routers is independent of data transmission. Such protocols use an external mechanism for source discovery (like source-specific IGMPv3 membership reports) to build source-specific multicast trees. Clearly these two classes of routing protocols require different handling for the problem MSNIP is trying to solve. In addition the second type covers the majority of applications that MSNIP is targeted at. MSNIP avoids the extra complication in supporting routing protocols that require a flood and prune behaviour. 3. Service Interface for Requesting Membership Notification Applications within an IP system that wish to source multicast packets and are interested in being notified on the existence of receivers must register with the IP layer of the system. MSNIP requires that within the IP system, there is (at least conceptually) a service interface that can be used to register with the IP layer for such notifications. Dual stack systems supporting both IPv4 and IPv6 need to provide separate service interfaces for each protocol. A system's IPv4 or IPv6 service interface must support the following operation or any logical equivalent: IPMulticastSourceRegister (socket, source-address, multicast-address) IPMulticastSourceDeregister (socket, source-address, multicast-address) In addition the application must provide the following interface for receiving notifications from the IP system: IPMulticastSourceStart (socket, source-address, multicast-address) IPMulticastSourceStop (socket, source-address, multicast-address) where: socket is an implementation-specific parameter used to distinguish amongst different requesting entities (e.g., programs or processes) within the system; the socket parameter of BSD UNIX system calls is a specific example. Fenner/Haberman/Holbrook/Kouvelas Section 3. [Page 4]
INTERNET-DRAFT Expires: December 2003 June 2003 source-address is the IP unicast source address that the application wishes to use in transmitting data to the specified multicast address. The specified address must be one of the IP addresses associated with the network interfaces of the IP system. Note that an interface in an IP system may be associated with more than one IP address. An implementation may allow a special "unspecified" value to be passed as the source-address parameter, in which case the request would apply to the "primary" IP address of the "primary" or "default" interface of the system (perhaps established by system configuration). If transmission to the same multicast address is desired using more than one source IP address, IPMulticastSourceRegister must be invoked separately for each desired source address. multicast-address is the IP multicast destination address to which the request pertains. If the application wishes to transmit data to more than one multicast addresses for a given source address, IPMulticastSourceRegister must be invoked separately for each desired multicast address. 3.1. Application Operation Applications wishing to use MSNIP to control their multicast data transmission to destination G from source address S operate as follows. Initially the application contacts the IP system to obtain the socket handle for use on all subsequent interactions. The application invokes IPMulticastSourceRegister for the desired S and G and then waits without transmitting any packets for the IP system to notify that receivers for the session exist. If and when the IP system notifies the application that receivers exist using the IPMulticastSourceStart call, the application may start transmitting data. After the application has been notified to send, if all receivers for the session leave, the IP system will notify the application using the IPMulticastSourceStop call. At this point the application should stop transmitting data until it is notified again that receivers have joined through another IPMulticastSourceStart call. When the application no longer wishes to transmit data it should invoke the IPMulticastSourceDeregister call to let the IP system know that it is no longer interested in notifications for this source and destination. The IPMulticastSourceDeregister call should be implicit in the teardown of the associated socket state. Fenner/Haberman/Holbrook/Kouvelas Section 3.1. [Page 5]
INTERNET-DRAFT Expires: December 2003 June 2003 4. MSNIP Managed Address Range Negotiation With current multicast deployment in the Internet, different multicast routing protocols coexist and operate under separate parts of the multicast address space. Multicast routers are consistently configured with information that maps specific multicast address ranges to multicast routing protocols. Part of this configuration describes the subset of the address space that is used by source-specific multicast (SSM) [12]. As described in section 2, MSNIP only tries to control application transmission within the SSM address range. It is desirable for applications within an IP system that supports MSNIP to have a consistent service interface for multicast transmission that does not require the application to be aware of the SSM address range. MSNIP supports this by allowing applications to use the service interface described in section 3 for multicast destination addresses that are outside its operating range. When an application registers for notifications for a destination address that is not managed by MSNIP it is immediately notified to start transmitting. This is equivalent to the default behaviour of IP multicast without MSNIP support which forces multicast applications to assume that there are multicast receivers present in the network. 4.1. Router Coordination In order for MSNIP to operate on a shared link where two or more multicast routers may be present, all the multicast routers must be MSNIP-capable and have an identical configuration for the SSM address range. MSNIP enforces these requirements by using two new options for IPv4 in the Multicast Router Discovery protocol [3] and one new option for IPv6 in the Neighbour Discovery / ICMPv6 protocol [6]. 4.1.1. MSNIP Operation Option A multicast router advertises that it is participating in MSNIP using the MSNIP Operation option in either the Multicast Router Discovery protocol for IPv4 or the Neighbour Discovery / ICMPv6 protocol for IPv6. This option MUST be included in all router advertisement messages of a router that is configured for MSNIP. The format of the option is as follows: Fenner/Haberman/Holbrook/Kouvelas Section 4.1.1. [Page 6]
INTERNET-DRAFT Expires: December 2003 June 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The type field is set to WW (TBD by IANA) for IPv4 and ZZ (TBD by IANA) for IPv6. Length The length field is set to 0 for IPv4 and 1 for IPv6. Padding The six extra bytes of padding are only present in IPv6 and are required to bring the size of the option up to the eight octet boundary. The value of the padding bytes must be set to zero on transmission and ignored on receipt. A multicast router uses received Multicast Router Advertisement and Neighbour Discovery / ICMPv6 messages to determine if all live neighbour multicast routers on each interface are participating in MSNIP. When a router advertisement message not containing an MSNIP option is received by a router participating in MSNIP, the mis-configuration SHOULD be logged to the operator in a rate-limited manner. If even one multicast router on a link does not have MSNIP capability then ALL routers on that link MUST be configured to not provide MSNIP services and to not advertise the MSNIP Operation option. 4.1.2. SSM Range Option The SSM Range Multicast Router Discovery option advertises the IPv4 SSM Range with which the router is configured. The option is defined in [4]. This option is only valid in IPv4. The SSM range for IPv6 is well defined for all valid scopes [15] and a mechanism to allow additional ranges to operate in SSM mode on a per-link bases is not required. Fenner/Haberman/Holbrook/Kouvelas Section 4.1.2. [Page 7]
INTERNET-DRAFT Expires: December 2003 June 2003 4.2. Managed Range Discovery by Source Systems When an application in an IP system uses the MSNIP service interface to register for notification, the IP system must behave differently depending on whether or not the destination address for which the application registered is operating under SSM (and is being managed by MSNIP). For SSM channels, the IP system should only instruct the application to transmit when there are receivers for the multicast destination. For non-SSM destination addresses the IP system will not be able to determine if there are receivers and should immediately instruct the application to transmit. In addition, an MSNIP-capable IP system must be able to detect if there are multicast routers on its connected links and if they support MSNIP operation. If no multicast routers are present or if the multicast routers are not MSNIP-capable then the IP system MUST default to flooding and immediately instruct applications to transmit. An IP system controls transmission behaviour under the different possible conditions by adapting its definition of the MSNIP-managed multicast destination address range: o On a link with multicast routers operating the MSNIP protocol the IP system MUST use the SSM multicast destination address range as the MSNIP-managed range. IPv4 systems MUST use the contents of the SSM Range option in received Multicast Router Advertisement messages [4] to discover the configured SSM range. SSM range discovery is not needed in IPv6 where the SSM destination address range is fixed. o On a link not connected to a multicast routed infrastructure or on a link with multicast routers that do not support MSNIP operation, the IP system MUST use an empty range as its MSNIP- managed range. This forces applications transmitting to any multicast destination address to default to flooding thus providing backward compatibility. As described in 4.1.1, an IP system can determine the status of a link and distinguish between the above two cases through the reception of IPv4 Multicast Router Advertisement and Neighbour Discovery / ICMPv6 messages. 5. Requesting and Receiving Notifications Like IGMP, MSNIP is an asymmetric protocol specifying different behaviour for systems wishing to source traffic and for multicast routers. Host IP systems multicast Host Interest Solicitation messages to register for notification with their first-hop routers. Routers unicast Router Receiver Membership Reports to IP systems to notify them Fenner/Haberman/Holbrook/Kouvelas Section 5. [Page 8]
INTERNET-DRAFT Expires: December 2003 June 2003 of the arrival of the first or departure of the last receiver for a session. Note that a system may perform at the same time both of the above functions. An example is a router that wishes to source traffic. 5.1. Host Interest Solicitation Source systems that wish to be managed by MSNIP periodically transmit a Host Interest Solicitation message. This message is multicast with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) or ALL_MLDv2_ROUTERS (TBA) and is transmitted every [Interest Solicitation Interval] seconds. The Host Interest Solicitation message contains a holdtime which is set to [Interest Solicitation Holdtime] and instructs the multicast first-hop routers to maintain MSNIP state for this IP system for the specified period. Systems with multiple interfaces or multiple IP addresses per interface must originate separate Host Interest Solicitation messages from each of their IP addresses that they wish to have managed by MSNIP. In practice a system with more than one IP address is treated by MSNIP as multiple IP systems. When an IP system first comes up it transmits [Robustness Variable] Host Interest Solicitation messages spaced by [Initial Interest Solicitation Interval] seconds. All MSNIP capable routers that receive a Host Interest Solicitation message from an IP system, maintain a system interest record of the form: (IP system address, holdtime timer) Each time a Host Interest Solicitation message is received from the IP system, the holdtime timer is reset to the holdtime in the received message. In addition the router may respond to the solicitation message with a Receiver Membership Report message described in section 5.2. The message contains a TRANSMIT record for each of the multicast destination addresses within the MSNIP-managed range for which the routing protocol indicates there are receivers for this source system. The holdtime timer of a record counts down to zero. When the holdtime timer of a specific system interest record expires, the record is deleted. 5.2. Router Receiver Membership Reports Receiver Membership Report messages are used by routers to communicate the receiver membership status of particular multicast Fenner/Haberman/Holbrook/Kouvelas Section 5.2. [Page 9]
INTERNET-DRAFT Expires: December 2003 June 2003 destination addresses to a specific IP system. Each message contains a list of transmission control records of either TRANSMIT or HOLD type that instruct a system to respectively start or stop sending traffic on this link to the specified multicast destination address. Receiver Membership Report messages are unicast to the target system. In addition to reports sent in response to Host Interest Solicitation messages, routers send unsolicited Receiver Membership Reports to IP systems when the receiver membership status reported by the multicast routing protocol changes for a specific source and multicast destination. Such reports are only sent if the multicast destination address is managed by MSNIP and the router has a system interest record created by a previously received Host Interest Solicitation message with an IP system address equal to the source address. If the source / destination pair satisfy these conditions then [Robustness Variable] Receiver Membership Reports are sent out spaced by [Unsolicited Membership Report Interval] seconds. If the membership status changes again for the same destination address and source system while transmission of Receiver Membership Reports is still pending then the pending report messages are canceled and a new set of [Robustness Variable] messages indicating the new state are scheduled. When an IP system receives a Receiver Membership Report message, for each of the TRANSMIT records listed in the message, it creates or updates a transmission record of the form: (router address, source address, multicast address, holdtime timer) The router address is obtained from the source address on the IP header of the received message. The source address is obtained from the destination address of the IP header of the received message. The multicast address is obtained from the information in the TRANSMIT record. The holdtime timer is set to the value of the holdtime field in the received Receiver Membership Report message. For each HOLD record present in the message, the system deletes the matching previously created transmission record from its state. The holdtime timer of a record counts down to zero. When the holdtime timer of a specific transmission record expires, the record is deleted. Note that creation and deletion of transmission records in an IP system's state may cause local applications to be notified to start and stop transmitting data (see section 6). Fenner/Haberman/Holbrook/Kouvelas Section 5.2. [Page 10]
INTERNET-DRAFT Expires: December 2003 June 2003 6. Application Notification This section describes the relation between protocol events and notifications to source applications within an IP system. The state machine below is specific to each source address of the IP system and each multicast destination address. The initial state is the No Info state. +-----------------------------------+ | Figures omitted from text version | +-----------------------------------+ Figure 1: Per source-address (S) and multicast destination address (G) state machine at an IP system In tabular form, the state-machine is: +-------------------+---------------------------------------------------+ | | Prev State | | Event +----------------+------------------+---------------+ | | No Info | Hold | Transmit | +-------------------+----------------+------------------+---------------+ | New Register | - | - | - | | | Start new | | Start new | +-------------------+----------------+------------------+---------------+ | | -> Hold | - | - | | Start Manage | Stop ALL | | | | | registered | | | +-------------------+----------------+------------------+---------------+ | | - | -> No Info | -> No Info | | Stop Manage | | Stop ALL | | | | | registered | | +-------------------+----------------+------------------+---------------+ | | - | -> Transmit | - | | Recv TRANSMIT | | Start ALL | | | | | registered | | +-------------------+----------------+------------------+---------------+ | Recv last HOLD | - | - | -> Hold | | or timeout | | | Stop ALL | | | | | registered | +-------------------+----------------+------------------+---------------+ The events in the state machine above have the following meaning: New register A new application has registered through a call to Fenner/Haberman/Holbrook/Kouvelas Section 6. [Page 11]
INTERNET-DRAFT Expires: December 2003 June 2003 IPMulticastSourceRegister for this S and G. Start manage We received a SSM Range option in an MRD packet on the interface that S belongs to that changed the status of G from a non-managed to a MSNIP-managed destination address. The SSM Range option is only valid in IPv4. Stop manage We received a SSM Range option in an MRD packet on the interface that S belongs to that changed the status of G from a MSNIP-managed to a non-managed destination address or the mapping state that caused this destination address to be managed expired. The SSM Range option is only valid in IPv4. Receive TRANSMIT We received a Receiver Membership Report with S as the IP destination address that contains a TRANSMIT record for G. Receive last HOLD or timeout We either received a Receiver Membership Report with S as the IP destination address that contains a HOLD record for G or the holdtime timer in a transmission record for S and G expired and there are no other transmission records for S and G. This means that the last router that was reporting receivers no longer does so and there are no routers left wishing to receive traffic from this S to destination address G. The state machine actions have the following meaning: Start new Send an IPMulticastSourceStart notification to the application that just registered for this S and G. Start ALL registered Send an IPMulticastSourceStart notification to all applications that are registered for this S and G. Stop ALL registered Send an IPMulticastSourceStop notification to all applications that Fenner/Haberman/Holbrook/Kouvelas Section 6. [Page 12]
INTERNET-DRAFT Expires: December 2003 June 2003 are registered for this S and G. 7. Router Processing This section describes the per-source system tracking state machine operated by each first-hop router. The initial state is No Info. +-----------------------------------+ | Figures omitted from text version | +-----------------------------------+ Figure 2: Per IP source system (S) state machine at a router In tabular form, the state-machine is: +----------------------+------------------------------------------------+ | | Prev State | | Event +------------------------+-----------------------+ | | Not tracking | Tracking | +----------------------+------------------------+-----------------------+ | | -> Tracking | - | | Receive HIS | Set HT to message | Set HT to message | | | holdtime; Send ALL | holdtime; Send ALL | | | existing TRANSMITs | existing TRANSMITs | +----------------------+------------------------+-----------------------+ | HIS timeout | - | -> Not tracking | | | | | +----------------------+------------------------+-----------------------+ | Receivers for new | - | - | | destination G | | Send TRANSMIT for | | | | G | +----------------------+------------------------+-----------------------+ | Receivers of G | - | - | | leave | | Send HOLD for G | +----------------------+------------------------+-----------------------+ The events in state machine above have the following meaning: Receive HIS The router has received a Host Interest Solicitation from S. HIS timeout The holdtime timer (HT) in the host interest record associated with S has expired. Fenner/Haberman/Holbrook/Kouvelas Section 7. [Page 13]
INTERNET-DRAFT Expires: December 2003 June 2003 Receivers for new destination G The routing protocol has informed MSNIP that it now has receivers for the MSNIP-managed destination address G and source IP system S. Receivers of G leave The routing protocol has informed MSNIP that all receivers for the MSNIP-managed destination address G and source IP system S have left the channel. The state machine actions have the following meaning: Set HT to message holdtime The holdtime timer in the host interest record associated with S is restarted to the value of the holdtime field in the received Host Interest Solicitation message. Send ALL existing TRANSMITs The router builds and transmits Receiver Membership Reports to S that contain a TRANSMIT record for each of the MSNIP-managed destination addresses that have receivers for S. Send TRANSMIT for G The router builds and transmits a Receiver Membership Report to S that contains a TRANSMIT record for the destination address G. Send HOLD for G The router builds and transmits a Receiver Membership Report to S that contains a HOLD record for the destination address G. 8. Message Formats The following packet formats are valid for both IPv4 and IPv6. IP version-specific values will be explicitly defined. There are two message types of concern to the MSNIP protocol described in this document: +-------------------+----------------------------+ | Type Number (hex) | Message Name | +-------------------+----------------------------+ Fenner/Haberman/Holbrook/Kouvelas Section 8. [Page 14]
INTERNET-DRAFT Expires: December 2003 June 2003 | | | | 0xXX | Host Interest Solicitation | +-------------------+----------------------------+ | 0xYY | Receiver Membership Report | +-------------------+----------------------------+ Both the Host Interest Solicitation message and the Receiver Membership Report message MUST not be forwarded by routers (see section 12). The Router Alert option [9] [10] MUST be included in the packet by the router or host IP system transmitting the message. Routers receiving Host Interest Solicitation messages and IP systems receiving Receiver Membership Reports MUST not process a received MSNIP message if the Router Alert option is not present. 8.1. Host Interest Solicitation Message A Host Interest Solicitation message is periodically multicast by MSNIP capable systems to declare interest in Receiver Membership Reports from multicast routers on the link. The Host Interest Solicitation message is multicast with a destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) or ALL_MLDv2_ROUTERS (TBA). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holdtime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The type field is set to XX (to be assigned by IANA as an IGMP type for IPv4 and an ICMPv6 type for IPv6). Reserved Transmitted as zero. Ignored upon receipt. Checksum In IPv4, the Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). In IPv6, the Checksum is the standard ICMPv6 checksum, covering the entire MLDv2 message plus a "pseudo-header" of IPv6 header fields [5]. For computing the checksum, the Checksum field is set to zero. Fenner/Haberman/Holbrook/Kouvelas Section 8.1. [Page 15]
INTERNET-DRAFT Expires: December 2003 June 2003 When receiving packets, the checksum MUST be verified before processing a packet. Holdtime The amount of time a receiving router must keep the system interest state alive, in seconds. The default value for this field is [Interest Solicitation Holdtime]. 8.2. Receiver Membership Report Packet A Receiver Membership Report packet is unicast by first-hop multicast routers and targeted at potential sources to inform them of the existence or not of receivers for the listed multicast destination addresses. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Dest Count | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holdtime | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record-Type-1 | Record-Reserved-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The type field is set to YY (to be assigned by IANA as an IGMP type for IPv4 and an ICMPv6 type for IPv6). Dest Count The number of multicast destination address records present in this message. Checksum In IPv4, the Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). In IPv6, the Checksum is the standard ICMPv6 checksum, covering the entire MLDv2 message plus a "pseudo-header" of IPv6 header fields Fenner/Haberman/Holbrook/Kouvelas Section 8.2. [Page 16]
INTERNET-DRAFT Expires: December 2003 June 2003 [5]. For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a packet. Holdtime The amount of time in seconds that the target host must keep alive the transmission record state created or updated by the TRANSMIT records in this report. The router originating the Receiver Membership Report sets this field to the current value of the holdtime timer in the system interest record corresponding to the target host. As a result Receiver Membership Reports sent in response to the reception of a Host Interest Solicitation message have their holdtime set to the value of the holdtime field in the received HIS message. Reserved Transmitted as zero. Ignored upon receipt. Record-Type-1 The type of the first transmission control record in this message. Valid values are: +-------------+----------------------------------------------+-------+ | Record Type | Description | Value | +-------------+----------------------------------------------+-------+ | TRANSMIT | Request to start transmitting to destination | 1 | +-------------+----------------------------------------------+-------+ | HOLD | Request to stop transmitting to destination | 2 | +-------------+----------------------------------------------+-------+ Reserved Transmitted as zero. Ignored upon receipt. Destination-Address-1 The multicast destination address of the first record in the message. Fenner/Haberman/Holbrook/Kouvelas Section 8.2. [Page 17]
INTERNET-DRAFT Expires: December 2003 June 2003 8.3. IPv4 Header Fields Like all IGMP messages, MSNIP messages are encapsulated in IPv4 datagrams, with an IP protocol number of 2. MSNIP messages can be identified from other IGMP messages by the message types listed in section 8. Every MSNIP message described in this document is sent with an IP Time-to-Live of 1, and carries an IP Router Alert option [9] in its IP header. 8.4. IPv6 Header Fields MLD messages are a sub-protocol of the Internet Control Message Protocol (ICMPv6 [5]). MSNIP messages are identified in IPv6 packets by the combination of a preceding Next Header value of 58 and by the MLD message types listed in section 8. All MSNIP messages described in this document are sent with a link-local IPv6 Source Address (or the unspecified address, if a valid link-local address is not available), an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [10] in a Hop-by- hop Options header. 9. Constants Timers and Default Values Robustness Variable The Robustness Variable allows tuning for the expected packet loss on a network. If a network is expected to be lossy, the Robustness Variable may be increased. MSNIP is robust to (Robustness Variable - 1) packet losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2 Interest Solicitation Interval The interval used by MSNIP capable systems between transmissions of Host Interest Solicitation messages. Default: 60 secs Interest Solicitation Holdtime The interval inserted in Host Interest Solicitation messages by systems to instruct routers how long they should maintain system interest state for. This MUST be ((the Robustness Variable) times (the Interest Solicitation Interval) plus (one second)). Initial Interest Solicitation Interval The interval used by systems to send out the initial Host Interest Solicitation messages when they first come up. Default: 1 second. Unsolicited Membership Report Interval The interval used by routers to send out a set of Membership Report messages when the receiver membership changes for a specific system. Default: 1 second. Fenner/Haberman/Holbrook/Kouvelas Section 9. [Page 18]
INTERNET-DRAFT Expires: December 2003 June 2003 10. Possible Optimisations 10.1. Suppressing HIS Messages A possible optimisation for MSNIP is to suppress the transmission of Host Interest Solicitation messages from the source address of an IP system for which no local application has registered interest. In addition to conserving bandwidth, not transmitting HIS messages prevents remote receivers for groups with no matching source application from creating transmission record state in the host system. 10.2. Host Stack Filtering Legacy applications that have not been coded with MSNIP support can still be prevented from wasting first-hop link bandwidth by filtering transmitted packets at the operating system level. Even though such applications will not register for MSNIP notifications with the host operating system, if the OS is MSNIP-capable and the application is transmitting data to an MSNIP-managed group for which there are no transmit records, the OS can safely filter the packets and not transmit them on the wire. A problem with the filtering approach is that it cannot be combined with the HIS message suppression optimisation (see section 10.1). If there are no registered applications in the system and HIS messages are being suppressed then the first-hop routers will not send any Receiver Membership Reports to the system. As a result, knowledge of receiver membership from the presence of transmit records for groups operated by legacy applications will not exist. It therefore becomes unsafe to filter packets from legacy applications. 10.3. Responding to Unexpected IGMP Queries Under steady state the router side of the IGMP protocol elects a single router on each link that is responsible for issuing IGMP Queries. Routers other than the acting IGMP querier will send an IGMP Query only if they restart and have no IGMP querier election state or if the active Querier crashes and a new election takes place. MSNIP can take advantage of this mechanism to quickly populate the host interest records of a new router starting up. When the router comes up it will issue an IGMP Query in an attempt to be elected as a Querier. MSNIP-capable hosts will notice that the sender of the Query is not the acting Querier. They can use this trigger to respond with Host Interest Solicitation Messages (with transmission randomised over a small interval) to quickly bring the new router up-to-date. Fenner/Haberman/Holbrook/Kouvelas Section 10.3. [Page 19]
INTERNET-DRAFT Expires: December 2003 June 2003 10.4. Host and Router Startup When a host operating system is restarted there may be applications that are started as part of the initialisation process and want to source IPv4 multicast traffic. It is possible for the applications to register through MSNIP with the IP subsystem and to start transmitting multicast data before the host receives the MSNIP-managed range definition through the SSM Range option of the Multicast Router Discovery protocol. This temporary flooding can be avoided if the host OS holds off notifying MSNIP-capable applications that they can transmit until it receives an MRD advertisement and learns the SSM configuration for the network. This behaviour has the drawback that it is not compatible with legacy networks with no MRD deployment. In such a network the host OS has to be able to determine after a configurable period that MRD is not enabled and hence all multicast applications wishing to source traffic should be notified to transmit. A good default value for this period is the MAX_RESPONSE_DELAY of the Multicast Router Discovery protocol [4]. Late router startup is harder to deal with. Hosts that start up before the multicast router may time out waiting for an MRD advertisement and instruct all MSNIP-capable multicast source applications to transmit data. One way to work around this problem is to configure the host OS to wait forever for an MRD advertisement before instructing MSNIP applications to transmit. 11. Inter-operation with IGMP / MLD Proxying MSNIP is intended for use on networks with multicast servers offering a large number of potential sessions. Although unlikely, it is possible to deploy such a server behind an IGMP / MLD Proxy [14]. If the proxy is not MSNIP-aware and does not implement the extensions described below then sources behind the proxy will default to flooding. If a device performing IGMP / MLD Proxying wishes to proxy MSNIP, it MUST forward MSNIP Host Interest Solicitation messages that are received on downstream interfaces to its upstream interface. No special treatment is required for MSNIP Receiver Membership Reports as they are unicast to the target host. In addition to the forwarding of MSNIP messages, an IGMP proxy MUST operate the Multicast Router Discovery protocol [3] on all its downstream interfaces and advertise the MSNIP capability option (section 4.1.1) and SSM address range option (section 4.1.2). The MSNIP capability option should be advertised on downstream interfaces only if it is included in MRD messages received on the upstream interface. The address range to be included in the SSM Range option MUST be determined Fenner/Haberman/Holbrook/Kouvelas Section 11. [Page 20]
INTERNET-DRAFT Expires: December 2003 June 2003 by MRD and IGMP messages received on the upstream interface of the proxy according to the rules in section 4.2. In addition to the forwarding of MSNIP messages, an MLD proxy MUST operate the IPv6 Neighbour Discovery protocol. The MSNIP capability option should be advertised on downstream interfaces when it is included in IPv6 Neighbour Discovery messages received on the upstream interface. 12. Security Considerations We consider the ramifications of a forged message of each type. As described in [1] and [2], IPSEC AH can be used to authenticate IGMP and MLD messages if desired. 12.1. Receiver Membership Report attacks A DoS attack on a host could be staged through forged Receiver Membership Report messages. The attacker can send a large number of reports, each with a large number of TRANSMIT records and a holdtime field set to a large value. The host will have to store and maintain the transmission records specified in all of those reports for the duration of the holdtime. This would consume both memory and CPU cycles in the host. Forged Receiver Membership Report messages from the local network can be easily traced. There are three measures necessary to defend against externally forged reports: o Routers SHOULD NOT forward Receiver Membership Reports. This is easier for a router to accomplish if the report carries the Router-Alert option. o Hosts SHOULD ignore Receiver Membership Reports without the Router-Alert option. Note that a remote attack through the multicast routing protocol is possible. A remote site can originate join state for a large number of groups that will propagate through MSNIP to the target source host. Such attacks are considered a more significant problem for the routers involved and are left up to the routing protocol security. HOLD records in forged Receiver Membership Report messages are not a significant threat as hosts track the individual interests of each first-hop router separately. Only by forging the source address of the report message so that is appears to have originated from a real first- hop router can the attacker cause the source to stop transmitting to a group that has valid receivers. Such forged messages can be detected by Fenner/Haberman/Holbrook/Kouvelas Section 12.1. [Page 21]
INTERNET-DRAFT Expires: December 2003 June 2003 the router itself. 12.2. Host Interest Solicitation attacks Forged Host Interest Solicitation messages can have two effects: o When non-existent source addresses are used the solicitation messages can create unwanted host record state on attached routers for the duration of the holdtime specified in the message. o When a source address corresponding to an existing host is used in the forged HIS message, receipt of the message by attached routers will cause them to transmit Receiver Membership Reports messages for all MSNIP-managed multicast destination addresses with receivers for the target host. Although no additional state will be created in routers or hosts from this attack, bandwidth and CPU is wasted in both the first-hop routers and the target host. Just like for the Receiver Membership Report message, attacks using the Host Interest Solicitation message can be reduced by requiring the use of the Router-Alert option on the message. 12.3. MSNIP Managed Range Discovery As discussed in [4] it is possible for directly connected systems to send forged Multicast Router Advertisement messages containing the SSM Range Discovery option. As the SSM Range Discovery option determines the MSNIP-managed range under IPv4, such forged messages can temporarily replace the managed range map with incorrect information in receiving hosts. An incorrect mapping can have two effects: o Applications using a multicast destination address within the real SSM range that have no valid receivers can be tricked into thinking that their chosen destination address is no longer an SSM address and will therefore start transmitting data. o Applications using group addresses outside the valid SSM range can be tricked into thinking that they are using an SSM destination address and therefore prevented from transmitting data. The Multicast Router Discovery SSM Range Option specification suggests that a router receiving a Multicast Router Advertisement with an inconsistent SSM Range Option log the event to the operator. Such Fenner/Haberman/Holbrook/Kouvelas Section 12.3. [Page 22]
INTERNET-DRAFT Expires: December 2003 June 2003 logging will enable tracking of this type of attack. 13. IANA Considerations This document introduces the following new types and options that require allocation by IANA: o Two new IGMP messages for Host Interest Solicitation and Receiver Membership Report. Each of these messages requires a new IGMP type value to be assigned by IANA [13]. o The new MSNIP Operation option for the Multicast Router Discovery protocol. This option requires a new MRD type value to be assigned by IANA. o The new MSNIP Operation option for the Neighbour Discovery / ICMPv6 protocol. This option requires a new NDP / ICMPv6 type value to be assigned by IANA. 14. Acknowledgments The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless Eckert, Haixiang He, Pekka Savola and Karen Kimball for their contribution to this specification. 15. Normative References [1] Cain B., Deering S., Fenner W., Kouvelas I. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376. [2] Vida R. and Costa L., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", work in progress, <draft-vida-mld-v2-07.txt>, June 2003. [3] Biswas S. and Haberman B., "IGMP Multicast Router Discovery", Work In Progress, <draft-ietf-idmr-igmp-mrdisc-10.txt>, January 2003. [4] Kouvelas I., "Multicast Router Discovery SSM Range Option", work in progress, <draft-ietf-magma-mrdssm-03.txt>, June 2003. [5] Conta A. and Deering S., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463. [6] Narten T., Nordmark E. and Simpson W., "Neighbour Discovery for IP Version 6 (IPv6)", RFC 2461. Fenner/Haberman/Holbrook/Kouvelas Section 15. [Page 23]
INTERNET-DRAFT Expires: December 2003 June 2003 [7] Holbrook H. and Cain B., "Source-Specific Multicast for IP", work in progress, <draft-ietf-ssm-arch-02.txt>, March 2003. [8] Kent S. and Atkinson R., "Security Architecture for the Internet Protocol.", RFC 2401. [9] Katz D., "IP Router Alert Option", RFC 2113. [10] Partridge C. and Jackson A., "IPv6 Router Alert Option", RFC 2711. 16. Informative References [11] Fenner W., Handley M., Holbrook H. and Kouvelas I., "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Work In Progress, <draft-ietf-pim-sm- v2-new-07.txt>, March 2003. [12] Albanna Z., Almeroth K. and Meyer D., "IANA Guidelines for IPv4 Multicast Address Allocation", Best Current Practices, <draft-ietf- iana-IPv4-mcast-guidelines-00.txt>, 2001. [13] Fenner W., "IANA Considerations for IGMP", http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP 57), February 2002. [14] Fenner W., He H., Haberman B. and Sandick H., "IGMP / MLD-based Multicast Forwarding (IGMP / MLD Proxying)" draft-ietf-magma-igmp- proxy-02.txt, March 2003. [15] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002. Fenner/Haberman/Holbrook/Kouvelas Section 16. [Page 24]
INTERNET-DRAFT Expires: December 2003 June 2003 Authors' Addresses Bill Fenner AT&T Labs - Research 75 Willow Road Menlo Park, CA 94025 fenner@research.att.com Brian Haberman Caspian Networks 1 Park Drive, Suite 300 Research Triangle Park, NC 27709 brian@innovationslab.net Hugh Holbrook Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 holbrook@cisco.com Isidor Kouvelas Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 kouvelas@cisco.com Full Copyright Statement Copyright (C) The Internet Society (Apr 1 2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organisations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Fenner/Haberman/Holbrook/Kouvelas Section 16. [Page 25]
INTERNET-DRAFT Expires: December 2003 June 2003 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Fenner/Haberman/Holbrook/Kouvelas Section 16. [Page 26]
