Internet Draft IDMR Working Group S. Biswas Internet Draft B. Cain draft-ietf-idmr-igmp-mrdisc-04.txt B. Haberman July 2000 Nortel Networks Expires January 2001 IGMP Multicast Router Discovery 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 Companies have been proposing IGMP snooping schemes for layer-2 bridging devices. A method for discovering multicast capable routers is necessary for these schemes. An IGMP query message is inadequate for discovering multicast routers as one querier is elected. In order to "discover" multicast routers, we introduce two new types of IGMP messages: Multicast Router Advertisement and Multicast Router Solicitation. These two messages can be used by any device which listens to IGMP to discovery multicast routers. Multicast Router Solicitation messages may be used by any network device (e.g. layer-2 switch) to solicit discovery messages from multicast routers. 1. Introduction Multicast router discovery messages are useful for discovering multicast capable routers. This capability is useful in a layer-2 bridging domain with "IGMP snooping" type of schemes. By listening to multicast router discovery messages, layer-2 devices can determine where to send multicast source data and IGMP Host Membership Reports Biswas, Cain, Haberman 1 Internet Draft IGMP Multicast Router Discovery September 2000 [RFC1112] [IGMPv2]. Multicast source data and IGMP Host Membership Reports must be received by all multicast routers on a segment. Using IGMP Host Membership Queries to discover multicast routers is not useful because of query suppression in IGMP. Unlike ICMP router discovery messages [RFC1256], multicast router discovery advertisements should not be listened to by hosts. Hosts need not know the identity of multicast routers. The use of the multicast router advertisement is not precluded from being used for other purposes. Extensible options have been included in the advertisement message for future enhancements. The following are justifications for inventing another router discovery protocol: o Using ICMP router discovery is not an appropriate solution for multicast router discovery because: 1.) It may confuse hosts listening to ICMP router advertisements; unicast and multicast topologies may not be congruent. 2.) There is no way to tell from an ICMP router advertisement if a router is running a multicast routing protocol. o By making multicast router discovery messages extensible, future enhancements can be made. o By inventing a generic IP layer message, multiple types of messages per link layer are not needed (i.e. including this functionality as part of IP is better than inventing N discovery protocols for N layer-2 technologies). Although multicast router discovery messages could be sent as ICMP messages, IGMP was chosen because IGMP snooping switches already snoop IGMP messages and because the intended first use of these protocol messages is multicast specific. 2. Protocol Overview IGMP Multicast Router Discovery consists of three messages for discovering multicast routers. The Multicast Router Advertisement is sent by routers to advertise IP multicast forwarding enabled on an interface. The Multicast Router Solicitation is used by routers to solicit Multicast Router Advertisements. The Multicast Router Termination message is sent when a router terminates its multicast routing functions. Multicast routers send Multicast Router Advertisements (hereafter called advertisements) periodically on all interfaces on which multicast forwarding is enabled. Biswas, Cain, Haberman 2 Internet Draft IGMP Multicast Router Discovery September 2000 Multicast Router Advertisements are also sent in response to Multicast Router Solicitations (hereafter called solicitations). These are sent to solicit a response of Multicast Router Advertisements from all multicast routers on a subnet. Solicitations are sent to the ALL-Routers (224.0.0.2) multicast group. Multicast Router Solicitations are sent whenever a device wishes to discover multicast routers on a directly attached subnet. Multicast Router Termination messages are sent when a router terminates its multicast routing functions. All IGMP Multicast Router Discovery messages are sent with an IP TTL of 1 and contain the IP Router Alert Option [RFC2113] in their IP header. All IGMP Multicast Router Discovery messages are sent with to the All-Routers multicast group (224.0.0.2). Other non-IP forwarding devices (e.g. layer-2 switches) may send Multicast Router Solicitations to solicit Multicast Router Advertisements. 3. Multicast Router Advertisement 3.1 Overview Multicast Router Advertisements are sent periodically on all router interfaces on which multicast forwarding is enabled. They are also sent in response to Multicast Router Solicitations. Router advertisements are sent upon expiration of a periodic timer, when a router starts up, and when a router interface (that has IP multicast forwarding enabled) initializes/restarts. Advertisements are sent as IGMP messages to the All-Routers multicast address (224.0.0.2) and should be rate-limited. Router advertisements may contain any number of options. Two options are defined in this document and MUST be supported by any implementation of IGMP multicast router discovery. These options are described in Section 5. Additional options may be defined as needed by future work. 3.2 IP Header Fields 3.2.1 Source Address An IP address belonging to the interface from which this message is sent. If multiple source addresses are configured on an interface, then the one chosen is implementation dependent. Biswas, Cain, Haberman 3 Internet Draft IGMP Multicast Router Discovery September 2000 3.2.2 Destination Address Router Advertisements are sent to the All-Routers multicast address (224.0.0.2). 3.2.3 Time-to-Live The Time-to-Live field MUST be 1. 3.2.4 Protocol The protocol field is set to IGMP (2). 3.3 Multicast Router Advertisement Message Format 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 | Ad. Interval | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused | Number of Options (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option [1] (TLV encoded) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option [...] (TLV encoded) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option [N] (TLV encoded) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3.1 Type Field The type field is set to 0x24. 3.3.2 Advertisement Interval This specifies the periodic time interval at which Multicast Router Advertisements are sent in units of seconds. This value is set to the configured MaxAdvertisementInterval variable. 3.3.3 Checksum The checksum is the 16-bit one's complement of the one's complement sum of the IGMP message, starting with the IGMP type. For computing the checksum, the Checksum field is set to 0. 3.3.4 Number of Options (N) The number of options contained in the router advertisement. If no options are sent this field MUST be set to 0. Biswas, Cain, Haberman 4 Internet Draft IGMP Multicast Router Discovery September 2000 3.3.5 Option[1..N] Options are encoded as TLV in the following manner: 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 | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the Number of Options field is not zero, a receiver MUST examine all options. No strict ordering of options is enforced. Type: Set to option type being advertised Length: Length in bytes of Value field Value: Option dependent value 3.4 Sending Multicast Router Advertisements Router Advertisements are sent when the following events occur: o When the periodic advertisement interval timer expires. Note that it is not strictly periodic because the advertisement interval is a random number between MaxAdvertisementInterval and MinAdvertisementInterval. o After waiting for a random delay less than MaxInitialAdvertisementInterval when an interface first comes up, is (re)initialized, or IGMP Multicast Router Discovery is enabled. A router may send up to a maximum of MaxInitialAdvertisements advertisements, waiting for a random delay less than MaxInitialAdvertisementInterval between each successive advertisement. Multiple messages are sent for robustness in the face of packet loss on the network. This is to prevent an implosion of router advertisements. An example of this occurring would be when many routers are powered on at the same time. When a solicitation is received, a router advertisement is sent in response with a random delay less than MAX_RESPONSE_DELAY. If a solicitation is received while an advertisement is pending (because of a recent solicitation), that solicitation will be ignored. Whenever an advertisement is sent, the periodic advertisement interval timer must be reset. 3.5 Receiving Multicast Router Advertisements Biswas, Cain, Haberman 5 Internet Draft IGMP Multicast Router Discovery September 2000 Upon receiving a router advertisement, devices will validate the message by the following criteria: 1. Verifying that the IGMP type is 0x24 2. Verifying the IGMP checksum 3. IP Destination Address = All-Routers multicast address A router advertisement not meeting the validity requirements will be silently discarded. Devices MUST process all options, discarding options that are not recognized. If a router advertisement is not received for a particular neighbor within NeighborDeadInterval time interval, then the neighbor is considered to be unreachable. 3.6 Multicast Router Advertisement Configuration Variables A router that implements multicast router discovery MUST allow for the following variables to be configured by system management; default values are specified so as to make it unnecessary to configure any of these variables in many cases. For each interface the following configurable variables are defined: 3.6.1 MaxAdvertisementInterval The maximum time allowed between sending router advertisements from the interface, in seconds. Must be no less than 2 seconds and no greater than 180 seconds. Default: 20 seconds. 3.6.2 MinAdvertisementInterval The minimum time allowed between sending unsolicited router advertisements from the interface, in seconds. Must be no less than 3 seconds and no greater than MaxAdvertisementInterval. Default: 0.75 * MaxAdvertisementInterval 3.6.3 MaxInitialAdvertisementInterval The first router advertisement out of an interface is sent after waiting for a random interval less than this variable. This will prevent a flood of router advertisements when many routers start up at the same time. Default: 2 seconds Biswas, Cain, Haberman 6 Internet Draft IGMP Multicast Router Discovery September 2000 3.6.4 MaxInitialAdvertisements The maximum number of router advertisements that will be sent on a subnet after a router boots. Default: 3 3.6.5 NeighborDeadInterval The maximum time allowed before a neighbor can be declared "dead". This variable is defined in seconds. In order for all devices to have a consistent state, it is necessary for the MaxAdvertisementInterval to be configured the same on all routers per subnet. Default: 3 * MaxAdvertisementInterval 4. Multicast Router Solicitation 4.1 Overview Multicast Router Solicitations are used to solicit Multicast Router Advertisements. These messages are used when a device wishes to discover multicast routers. Upon receiving a solicitation on an interface with IP multicast forwarding enabled and multicast router discovery enabled, a router will respond with an advertisement. Router solicitations may be sent when a router starts up, when a router interface (re)initializes, or when IGMP Multicast Router Discovery is enabled. Solicitations are sent as IGMP messages to the All-Routers multicast address (224.0.0.2) and must be rate-limited. 4.2 IP Header Fields 4.2.1 Source Address An IP address belonging to the interface from which this message is sent. If multiple source addresses are configured on an interface, then the one chosen is implementation dependent. If the solicitation is being sent from a device that does not have an IP address (i.e. non-managed layer-2 switch), then the source address should be set to all zeros. 4.2.2 Destination Address Solicitation messages are sent to the All-Routers multicast address (224.0.0.2). 4.2.3 Time-to-Live The time-to-live field MUST be 1. Biswas, Cain, Haberman 7 Internet Draft IGMP Multicast Router Discovery September 2000 4.2.4 Protocol The protocol field is set to IGMP (2). 4.3 Multicast Router Solicitation Message Format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.1 Type Field The type field is set to 0x25. 4.3.2 Reserved Field Sent as 0; ignored on reception. 4.3.3 Checksum The checksum is the 16-bit one's complement of the one's complement sum of the IGMP message, starting with the IGMP type. For computing the checksum, the Checksum field is set to 0. 4.4 Sending Multicast Router Solicitations Router solicitations are sent when the following events occur: 1. After waiting for a random delay less than SOLICITATION_INTERVAL when an interface first comes up, is (re)initialized, or IGMP Multicast Router Discovery is enabled. A router may send up to a maximum of MAX_SOLICITATIONS, waiting for a random delay less than SOLICITATION_INTERVAL between each successive solicitation. 2. Optionally, for an implementation specific event. Solicitations MUST be rate-limited; no more than MAX_SOLICITATIONS MUST be sent in SOLICITATION_INTERVAL seconds. 4.5 Receiving Multicast Router Solicitations Upon receiving a router solicitation, routers will validate the message by: 1. Verifying that the IGMP type is 0x25 2. Verifying the IGMP checksum 3. IP Destination Address = All-Routers multicast address Biswas, Cain, Haberman 8 Internet Draft IGMP Multicast Router Discovery September 2000 A router solicitation not meeting the validity requirements will be silently discarded. Solicitation message IP source addresses MUST NOT be used as part of the validity check. 4.6 Multicast Router Solicitation Configuration Variables There are no configurable variables with respect to router solicitations. 5. Multicast Router Termination 5.1 Overview The Multicast Router Termination message is used to expedite the notification of a change in the status of a routers multicast forwarding functions. 5.2 IP Header Fields 5.2.1 Source Address An IP address belonging to the interface from which this message is sent. If multiple source addresses are configured on an interface, then the one chosen is implementation dependent. 5.2.2 Destination Address Multicast Router Termination messages are sent to the All-Routers multicast address (224.0.0.2). 5.2.3 Time-to-Live The Time-to-Live field MUST be 1. 5.2.4 Protocol The protocol field is set to IGMP (2). 5.3 Multicast Router Termination Message Format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3.1 Type Field Biswas, Cain, Haberman 9 Internet Draft IGMP Multicast Router Discovery September 2000 The type field is set to 0x26. 5.3.2 Reserved Field Sent as 0; ignored on reception. 5.3.3 Checksum The checksum is the 16-bit one's complement of the one's complement sum of the IGMP message, starting with the IGMP type. For computing the checksum, the Checksum field is set to 0. 5.4 Sending Multicast Router Termination Messages Multicast Router Termination messages are sent for three reasons: 1. Multicast forwarding is disabled on the interface 2. The interface is administratively disabled 3. The router is gracefully shutdown 5.5 Receiving Multicast Router Termination Messages Upon receiving a termination message, routers will validate the message by the following criteria: 1. Verifying that the IGMP type is 0x26 2. Verifying the IGMP checksum 3. IP Destination Address = All-Routers multicast address A termination message not meeting the validity requirements will be silently discarded. 6. Multicast Router Discovery Protocol Constants o MAX_RESPONSE_DELAY 2 seconds o MAX_SOLICITATION_DELAY 1 second o SOLICITATION_INTERVAL 3 seconds o MAX_SOLICITATIONS 3 transmissions 7. Mandatory Advertisement Options 7.1 Overview of Options Biswas, Cain, Haberman 10 Internet Draft IGMP Multicast Router Discovery September 2000 The following options MUST be supported by an implementation of IGMP Multicast Router Discovery: Query Interval Advertisement Option and Robustness Variable Advertisement Option. These options advertise specific IGMP variables and are sent in an advertisement depending on the version of IGMP enabled on an interface. Although no requirements exist for multicast routers at this time, it is assumed that all multicast routers support the IGMP protocol. 7.2 Query Interval Advertisement Option 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=1 | Length=2 | IGMP Query Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a multicast router has any version of IGMP [RFC1112] enabled on an interface on which IGMP Multicast Router Discovery is also enabled, it MUST send all advertisements with the Query Interval Advertisement Option. This option contains the IGMP "Query Interval" configured on the interface on which advertisements are sent. This option is sent regardless of whether the router is currently the IGMP querier for the subnet. This option is sent regardless of what version of IGMP the router is running. IGMP Query Interval field is equal (in seconds) to the configured IGMP "query interval" on the interface from which the advertisement was sent. 7.3 Robustness Variable Advertisement Option 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=2 | Length=2 | Robustness Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a multicast router has IGMPv2 [IGMPv2] or IGMPv3 [IGMPv3] enabled on an interface on which IGMP Multicast Router Discovery is also enabled, it MUST send all advertisements with the Robustness Variable Advertisement Option. This option contains the IGMP "Robustness Variable" configured on the interface on which advertisements are sent. This option is sent regardless of whether the router is currently the IGMP querier for the subnet. This option may be omitted if IGMPv1 is enabled on the interface. Robustness Variable is an integer that MUST not be zero [IGMPv2] and is equal to the IGMPv2 robustness variable. Biswas, Cain, Haberman 11 Internet Draft IGMP Multicast Router Discovery September 2000 8. IPv6 Support The Multicast Router Discovery function for IPv6 is accomplished using the Neighbor Discovery Protocol for IPv6 [RFC2461] (hereafter called NDP). Specifically, the Router Advertisement message contains new fields to support the discovery of multicast routers. For this reason, the timing mechanisms defined for NDP will be used instead of those defined in this document for IPv4 support. 8.1 Router Advertisement Message The Router Advertisement message contains two new fields to support the multicast router discovery mechanism. The modified message format is: 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H|D|E|Rsrvd| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- The two new fields are the 'D' and 'E' bits. All other fields retain their definitions and functions as described in Section 4.2 of the NDP specification [RFC2461]. 8.1.1 Discovery (D) bit The 'D' bit is used by a router to indicate support for the Multicast Router Discovery protocol. A value of '1' indicates that the router supports the discovery protocol. A value of '0' indicates no support. This allows for backwards compatibility of the Router Advertisement message. 8.1.2 Enabled (E) bit The 'E' bit indicates whether multicast routing is enabled on the router's interface. A value of '1' indicates that multicast forwarding is enabled on the router's interface. A value of '0' indicates that multicast forwarding is disabled. When the state of multicast forwarding changes on an interface, a router must stop its Router Advertisement timer, transmit a Router Biswas, Cain, Haberman 12 Internet Draft IGMP Multicast Router Discovery September 2000 Advertisement with the 'E' bit set to the value associated with the new multicast forwarding state, and restart its Router Advertisement timer. 8.2 Router Solicitations An NDP Router Solicitation message can be sent to solicit a Router Advertisement message in order to determine the multicast forwarding state of a router. The periodic transmission of solicitation messages is outlined in RFC 2461. 9. Acknowledgements ICMP Router Discovery [RFC1256] was used as a general model for IGMP Multicast Router Discovery. 10. References [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991. [RFC1112] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, August 1989. [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2", Internet-Draft, November 1997. [IGMPv3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group Management Protocol, Version 3", Internet-Draft, November 1997. [RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996. [RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery IP Version 6 (IPv6)", RFC 2461, December 1998. 10. Authors' Addresses Shantam Biswas Nortel Networks 600 Technology Park Drive Billerica, MA 01821 Email: sbiswas@baynetworks.com Phone: 1-978-916-8048 Brad Cain Nortel Networks 600 Technology Park Drive Billerica, MA 01821 Email: bcain@baynetworks.com Phone: 1-978-916-1316 Biswas, Cain, Haberman 13 Internet Draft IGMP Multicast Router Discovery September 2000 Brian Haberman Nortel Networks 4309 Emperor Blvd Suite 200 Durham, NC 27703 Email: haberman@nortelnetworks.com Phone: 1-919-992-4439 Biswas, Cain, Haberman 14