< draft-ietf-idmr-igmp-mrdisc-05.txt		draft-ietf-idmr-igmp-mrdisc-06.txt >
	IDMR Working Group S. Biswas		IDMR Working Group S. Biswas
	Internet Draft B. Haberman		Internet Draft B. Haberman
	draft-ietf-idmr-igmp-mrdisc-05.txt Nortel Networks		draft-ietf-idmr-igmp-mrdisc-06.txt Nortel Networks
	October 2000 B. Cain		May 2001 B. Cain
	Expires April 2001 Mirror Image Internet		Expires November 2001 Cereva Networks
	IGMP Multicast Router Discovery		IGMP Multicast Router Discovery
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at line 37 ¶		skipping to change at line 37 ¶
	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 schemes for layer-2		Companies have been proposing IGMP snooping schemes for layer-2
	bridging devices. A method for discovering multicast capable routers		bridging devices. A method for discovering multicast capable routers
	is necessary for these schemes. An IGMP query message is inadequate		is necessary for these schemes. An IGMP query message is inadequate
	for discovering multicast routers as one querier is elected. In		for discovering multicast routers as one querier is elected. In
	order to "discover" multicast routers, we introduce three new types		order to "discover" multicast routers, we introduce three new types
	of IGMP messages: Multicast Router Advertisement and Multicast Router		of IGMP messages: Multicast Router Advertisement, Multicast Router
	Solicitation. These two messages can be used by any device which		Solicitation, and Multicast Router Termination. These messages can
	listens to IGMP to discovery multicast routers. Multicast Router		be used by any device which listens to IGMP to discovery multicast
	Solicitation messages may be used by any network device (e.g. layer-2		routers. Multicast Router Solicitation messages may be used by any
	switch) to solicit discovery messages from multicast routers.		network device (e.g. layer-2 switch) to solicit discovery messages
			from 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 determine		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		Biswas, Cain, Haberman 1
			where to send multicast source data and IGMP Host Membership Reports
	[RFC1112] [IGMPv2]. Multicast source data and IGMP Host Membership		[RFC1112] [RFC2236]. Multicast source data and IGMP Host Membership
	Reports must be received by all multicast routers on a segment.		Reports must be received by all multicast routers on a segment.
	Using IGMP Host Membership Queries to discover multicast routers is		Using IGMP Host Membership Queries to discover multicast routers is
	not useful because of query suppression in IGMP.		not useful because of query suppression in IGMP.
	Unlike ICMP router discovery messages [RFC1256], multicast router		Unlike ICMP router discovery messages [RFC1256], multicast router
	discovery advertisements should not be listened to by hosts. Hosts		discovery advertisements should not be listened to by hosts. Hosts
	need not know the identity of multicast routers.		need not know the identity of multicast routers.
	The use of the multicast router advertisement is not precluded from		The use of the multicast router advertisement is not precluded from
	being used for other purposes. Extensible options have been included		being used for other purposes. Extensible options have been included
	in the advertisement message for future enhancements.		in the advertisement message for future enhancements.
	The following are justifications for inventing another router		The following are justifications for inventing another router
	discovery protocol:		discovery protocol:
	o Using ICMP router discovery is not an appropriate solution		o Using ICMP router discovery is not an appropriate solution
	for multicast router discovery because: 1.) It may confuse		for multicast router discovery because: 1.) It may confuse
	hosts listening to ICMP router advertisements; unicast and		hosts listening to ICMP router advertisements; unicast and
	multicast topologies may not be congruent. 2.) There is		multicast topologies may not be congruent. 2.) There is
	no way to tell from an ICMP router advertisement if a		no way to tell from an ICMP router advertisement if a
	router is running a multicast routing protocol.		router is running a multicast routing protocol.
	o By making multicast router discovery messages extensible,		o By making multicast router discovery messages extensible,
	future enhancements can be made.		future enhancements can be made.
	o By inventing a generic IP layer message, multiple types of		o By inventing a generic IP layer message, multiple types of
	messages per link layer are not needed (i.e. including		messages per link layer are not needed (i.e. including
	this functionality as part of IP is better than inventing		this functionality as part of IP is better than inventing
	N discovery protocols for N layer-2 technologies).		N discovery protocols for N layer-2 technologies).
	Although multicast router discovery messages could be sent as ICMP		Although multicast router discovery messages could be sent as ICMP
	messages, IGMP was chosen because IGMP snooping switches already		messages, IGMP was chosen because IGMP snooping switches already
	snoop IGMP messages and because the intended first use of these		snoop IGMP messages and because the intended first use of these
	protocol messages is multicast specific.		protocol messages is multicast specific.
	2. Protocol Overview		2. Protocol Overview
	skipping to change at line 169 ¶		skipping to change at line 169 ¶
	3.2.3 Time-to-Live		3.2.3 Time-to-Live
	The Time-to-Live field MUST be 1.		The Time-to-Live field MUST be 1.
	3.2.4 Protocol		3.2.4 Protocol
	The protocol field is set to IGMP (2).		The protocol field is set to IGMP (2).
	3.3 Multicast Router Advertisement Message Format		3.3 Multicast Router Advertisement 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 | Ad. Interval | Checksum |		| Type | Ad. Interval | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Unused | Number of Options (N) |		| Unused | Number of Options (N) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option [1] (TLV encoded) |		| Option [1] (TLV encoded) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option [...] (TLV encoded) |		| Option [...] (TLV encoded) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Option [N] (TLV encoded) |		| Option [N] (TLV encoded) |
	skipping to change at line 228 ¶		skipping to change at line 228 ¶
	Type: Set to option type being advertised		Type: Set to option type being advertised
	Length: Length in bytes of Value field		Length: Length in bytes of Value field
	Value: Option dependent value		Value: Option dependent value
	3.4 Sending Multicast Router Advertisements		3.4 Sending Multicast Router Advertisements
	Router Advertisements are sent when the following events occur:		Router Advertisements are sent when the following events occur:
	o When the periodic advertisement interval timer expires.		o When the periodic advertisement interval timer expires.
	Note that it is not strictly periodic because the		Note that it is not strictly periodic because the
	advertisement interval is a random number between		advertisement interval is a random number between
	MaxAdvertisementInterval and MinAdvertisementInterval.		MaxAdvertisementInterval and MinAdvertisementInterval.
	o After waiting for a random delay less than		o After waiting for a random delay less than
	MaxInitialAdvertisementInterval when an interface first		MaxInitialAdvertisementInterval when an interface first
	comes up, is (re)initialized, or IGMP Multicast Router		comes up, is (re)initialized, or IGMP Multicast Router
	Discovery is enabled. A router may send up to a maximum		Discovery is enabled. A router may send up to a maximum
	of MaxInitialAdvertisements advertisements, waiting for a		of MaxInitialAdvertisements advertisements, waiting for a
	random delay less than MaxInitialAdvertisementInterval		random delay less than MaxInitialAdvertisementInterval
	between each successive advertisement. Multiple messages		between each successive advertisement. Multiple messages
	are sent for robustness in the face of packet loss on the		are sent for robustness in the face of packet loss on the
	network.		network.
	This is to prevent an implosion of router advertisements. An example		This is to prevent an implosion of router advertisements. An example
	skipping to change at line 260 ¶		skipping to change at line 260 ¶
	Whenever an advertisement is sent, the periodic advertisement		Whenever an advertisement is sent, the periodic advertisement
	interval timer must be reset.		interval timer must be reset.
	3.5 Receiving Multicast Router Advertisements		3.5 Receiving Multicast Router Advertisements
	Biswas, Cain, Haberman 5		Biswas, Cain, Haberman 5
	Upon receiving a router advertisement, devices will validate the		Upon receiving a router advertisement, devices will validate the
	message by the following criteria:		message by the following criteria:
	1.		1. Verifying the IGMP checksum
	Verifying the IGMP checksum
	2.		2. IP Destination Address = All-Routers multicast address
	IP Destination Address = All-Routers multicast address
	A router advertisement not meeting the validity requirements should		A router advertisement not meeting the validity requirements should
	be silently discarded or logged in a rate-limited manner. Devices		be silently discarded or logged in a rate-limited manner. Devices
	MUST process all options, discarding options that are not recognized.		MUST process all options, discarding options that are not recognized.
	If a router advertisement is not received for a particular neighbor		If a router advertisement is not received for a particular neighbor
	within NeighborDeadInterval time interval, then the neighbor is		within NeighborDeadInterval time interval, then the neighbor is
	considered to be unreachable.		considered to be unreachable.
	3.6 Multicast Router Advertisement Configuration Variables		3.6 Multicast Router Advertisement Configuration Variables
	skipping to change at line 392 ¶		skipping to change at line 390 ¶
	4.3.3 Checksum		4.3.3 Checksum
	The checksum is the 16-bit one's complement of the one's complement		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		sum of the IGMP message, starting with the IGMP type. For computing
	the checksum, the Checksum field is set to 0.		the checksum, the Checksum field is set to 0.
	4.4 Sending Multicast Router Solicitations		4.4 Sending Multicast Router Solicitations
	Router solicitations are sent when the following events occur:		Router solicitations are sent when the following events occur:
	1.		1. After waiting for a random delay less than SOLICITATION_INTERVAL
	After waiting for a random delay less than SOLICITATION_INTERVAL
	when an interface first comes up, is (re)initialized, or IGMP		when an interface first comes up, is (re)initialized, or IGMP
	Multicast Router Discovery is enabled. A device may send up to		Multicast Router Discovery is enabled. A device may send up to
	a maximum of MAX_SOLICITATIONS, waiting for a random delay less		a maximum of MAX_SOLICITATIONS, waiting for a random delay less
	than SOLICITATION_INTERVAL between each successive solicitation.		than SOLICITATION_INTERVAL between each successive solicitation.
	2.		2. Optionally, for an implementation specific event. Solicitations
	Optionally, for an implementation specific event. Solicitations
	MUST be rate-limited; no more than MAX_SOLICITATIONS MUST be		MUST be rate-limited; no more than MAX_SOLICITATIONS MUST be
	sent in SOLICITATION_INTERVAL seconds.		sent in SOLICITATION_INTERVAL seconds.
	4.5 Receiving Multicast Router Solicitations		4.5 Receiving Multicast Router Solicitations
	Upon receiving a router solicitation, routers will validate the		Upon receiving a router solicitation, routers will validate the
	message by:		message by:
	1.		1. Verifying the IGMP checksum
	Verifying the IGMP checksum
	2.		2. IP Destination Address = All-Routers multicast address
	IP Destination Address = All-Routers multicast address
	A router solicitation not meeting the validity requirements should be		A router solicitation not meeting the validity requirements should be
	silently discarded or logged in a rate-limited manner.		silently discarded or logged in a rate-limited manner.
	Biswas, Cain, Haberman 8		Biswas, Cain, Haberman 8
	Solicitation message IP source addresses MUST NOT be used as part of		Solicitation message IP source addresses MUST NOT be used as part of
	the validity check.		the validity check.
	4.6 Multicast Router Solicitation Configuration Variables		4.6 Multicast Router Solicitation Configuration Variables
	skipping to change at line 483 ¶		skipping to change at line 477 ¶
	5.3.3 Checksum		5.3.3 Checksum
	The checksum is the 16-bit one's complement of the one's complement		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		sum of the IGMP message, starting with the IGMP type. For computing
	the checksum, the Checksum field is set to 0.		the checksum, the Checksum field is set to 0.
	5.4 Sending Multicast Router Termination Messages		5.4 Sending Multicast Router Termination Messages
	Multicast Router Termination messages are sent for three reasons:		Multicast Router Termination messages are sent for three reasons:
	1.		1. Multicast forwarding is disabled on the interface
	Multicast forwarding is disabled on the interface
	2.		2. The interface is administratively disabled
	The interface is administratively disabled
	3.		3. The router is gracefully shutdown
	The router is gracefully shutdown
	5.5 Receiving Multicast Router Termination Messages		5.5 Receiving Multicast Router Termination Messages
	Upon receiving a termination message, routers will validate the		Upon receiving a termination message, routers will validate the
	message by the following criteria:		message by the following criteria:
	1.		1. Verifying the IGMP checksum
	Verifying the IGMP checksum
	2.		2. IP Destination Address = All-Routers multicast address
	IP Destination Address = All-Routers multicast address
	A termination message not meeting the validity requirements should be		A termination message not meeting the validity requirements should be
	silently discarded or logged in a rate-limited manner.		silently discarded or logged in a rate-limited manner.
	6. Multicast Router Discovery Protocol Constants		6. Multicast Router Discovery Protocol Constants
	o MAX_RESPONSE_DELAY 2 seconds		o MAX_RESPONSE_DELAY 2 seconds
	o MAX_SOLICITATION_DELAY 1 second		o MAX_SOLICITATION_DELAY 1 second
	o SOLICITATION_INTERVAL 3 seconds		o SOLICITATION_INTERVAL 3 seconds
	o MAX_SOLICITATIONS 3 transmissions		o MAX_SOLICITATIONS 3 transmissions
	7. Mandatory Advertisement Options		7. Mandatory Advertisement Options
	7.1 Overview of Options		7.1 Overview of Options
	The following options MUST be supported by an implementation of IGMP		The following options MUST be supported by an implementation of IGMP
	Multicast Router Discovery: Query Interval Advertisement Option and		Multicast Router Discovery: Query Interval Advertisement Option and
	Robustness Variable Advertisement Option. These options advertise		Robustness Variable Advertisement Option. These options advertise
	specific IGMP variables and are sent in an advertisement depending on		specific IGMP variables and are sent in an advertisement depending on
	the version of IGMP enabled on an interface. Although no		the version of IGMP enabled on an interface. Although no
	skipping to change at line 602 ¶		skipping to change at line 591 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cur Hop Limit |M|O|H|D|E|Rsrvd| Router Lifetime |		| Cur Hop Limit |M|O|H|D|E|Rsrvd| Router Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reachable Time |		| Reachable Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Retrans Timer |		| Retrans Timer |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Options ...		| Options ...
	+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-
	The two new fields are the 'D' and 'E' bits. All other fields retain		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		their definitions and functions as described in Section 4.2 of the
	NDP specification [RFC2461].		NDP specification [RFC2461].
	8.1.1 Discovery (D) bit		8.1.1 Discovery (D) bit
	The 'D' bit is used by a router to indicate support for the Multicast		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		Router Discovery protocol. A value of '1' indicates that the router
	supports the discovery protocol. A value of '0' indicates no		supports the discovery protocol. A value of '0' indicates no
	skipping to change at line 637 ¶		skipping to change at line 626 ¶
	timer.		timer.
	8.2 Router Solicitations		8.2 Router Solicitations
	Biswas, Cain, Haberman 12		Biswas, Cain, Haberman 12
	An NDP Router Solicitation message can be sent to solicit a Router		An NDP Router Solicitation message can be sent to solicit a Router
	Advertisement message in order to determine the multicast forwarding		Advertisement message in order to determine the multicast forwarding
	state of a router. The periodic transmission of solicitation		state of a router. The periodic transmission of solicitation
	messages is outlined in RFC 2461.		messages is outlined in RFC 2461.
	9. Acknowledgements		9. Security Considerations
			The Multicast Router Advertisement message may allow rogue machines
			to masquerade as multicast routers. This could allow those machines
			to eavesdrop on multicast data transmission or create a denial of
			service attack on multicast flows. However, these new messages are
			extensible and that allows for the introduction of security
			associations into the protocol. These security extensions could be
			used to authenticate or encrypt the messages.
			10. Acknowledgements
	ICMP Router Discovery [RFC1256] was used as a general model for IGMP		ICMP Router Discovery [RFC1256] was used as a general model for IGMP
	Multicast Router Discovery.		Multicast Router Discovery.
	10. References		11. References
	[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,		[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
	September 1991.		September 1991.
	[RFC1112] Deering, S., "Host Extensions for IP Multicasting",		[RFC1112] Deering, S., "Host Extensions for IP Multicasting",
	RFC 1112, August 1989.		RFC 1112, August 1989.
	[IGMPv2] Fenner, W., "Internet Group Management Protocol,		[RFC2236] Fenner, W., "Internet Group Management Protocol,
	Version 2", Internet-Draft, November 1997.		Version 2", RFC 2236, November 1997.
	[IGMPv3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group		[IGMPv3] Cain, B., Deering, S., Thyagarajan, A., "Internet Group
	Management Protocol, Version 3", Internet-Draft, November		Management Protocol, Version 3", work in progress,
	1997.		March 2001.
	[RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996.		[RFC2113] Katz, D., "IP Router Alert Option," RFC 2113, April 1996.
	[RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor		[RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor
	Discovery IP Version 6 (IPv6)", RFC 2461, December 1998.		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
	Mirror Image Internet		Cereva Networks
	49 Dragon Court
	Woburn, MA 01801		Biswas, Cain, Haberman 13
	Email: brad.cain@mirror-image.com		Email: bcain@cereva.com
	Phone: 1-781-276-1904
	Brian Haberman		Brian Haberman
	Nortel Networks		Nortel Networks
	4309 Emperor Blvd		4309 Emperor Blvd
	Suite 200		Suite 200
	Durham, NC 27703		Durham, NC 27703
	Biswas, Cain, Haberman 13
	Email: haberman@nortelnetworks.com		Email: haberman@nortelnetworks.com
	Phone: 1-919-992-4439		Phone: 1-919-992-4439
	Biswas, Cain, Haberman 14		Biswas, Cain, Haberman 14
End of changes. 32 change blocks.
	60 lines changed or deleted		56 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/