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