< draft-holbrook-idmr-igmpv3-ssm-07.txt		draft-holbrook-idmr-igmpv3-ssm-08.txt >
	INTERNET-DRAFT IGMPv3/MLDv2 for SSM H. Holbrook		INTERNET-DRAFT IGMPv3/MLDv2 for SSM H. Holbrook
	Expires Dec 5, 2004 Cisco Systems		Expires Apr 1, 2005 Cisco Systems
	B. Cain		B. Cain
	Storigen Systems		Storigen Systems
	B. Haberman		B. Haberman
	Caspian Networks		JHU APL
	Jun 5, 2004		Oct 1, 2004
	Using IGMPv3 and MLDv2 for Source-Specific Multicast		Using IGMPv3 and MLDv2 for Source-Specific Multicast
	<draft-holbrook-idmr-igmpv3-ssm-07.txt>		<draft-holbrook-idmr-igmpv3-ssm-08.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable patent		By submitting this Internet-Draft, I certify that any applicable patent
	or other IPR claims of which I am aware have been disclosed, and any of		or other IPR claims of which I am aware have been disclosed, and any of
	which I become aware will be disclosed, in accordance with RFC 3667.		which I become aware will be disclosed, in accordance with RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups		Force (IETF), its areas, and its working groups. Note that other groups
	may also distribute working documents as Internet-Drafts.		may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet- Drafts as reference material		time. It is inappropriate to use Internet- Drafts as reference material
	or to cite them other than as "work in progress."		or to cite them other than as "work in progress."
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	The Internet Group Management Protocol Version 3 (IGMPv3) and the		The Internet Group Management Protocol Version 3 (IGMPv3) and the
	Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols		Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols
	that allow a host to inform its neighboring routers of its desire to		that allow a host to inform its neighboring routers of its desire to
	receive IPv4 and IPv6 multicast transmissions, respectively. Source-		receive IPv4 and IPv6 multicast transmissions, respectively. Source-
	Specific Multicast (SSM) is a form of multicast in which a receiver is		Specific Multicast (SSM) is a form of multicast in which a receiver is
	required to specify both the network-layer address of the source and the		required to specify both the network-layer address of the source and the
	multicast destination address in order to receive the multicast		multicast destination address in order to receive the multicast
	transmission. This document defines the notion of an "SSM-aware" router		transmission. This document defines the notion of an "SSM-aware" router
	and host, and clarifies and, in some cases, modifies the behavior of		and host, and clarifies and, in some cases, modifies the behavior of
	IGMPv3 and MLDv2 on SSM-aware routers and hosts to accomodate source-		IGMPv3 and MLDv2 on SSM-aware routers and hosts to accomodate source-
	specific multicast.		specific multicast. This document updates the IGMPv3 and MLDv2
			specifications.
	1. Introduction		1. Introduction
	The Internet Group Management Protocol (IGMP) [RFC1112,IGMPv2,IGMPv3],		The Internet Group Management Protocol (IGMP) [RFC1112,IGMPv2,IGMPv3],
	allows an IPv4 host to communicate IP multicast group membership		allows an IPv4 host to communicate IP multicast group membership
	information to its neighboring routers. IGMP version 3 (IGMPv3)		information to its neighboring routers. IGMP version 3 (IGMPv3)
	[IGMPv3] provides the ability for a host to selectively request or		[IGMPv3] provides the ability for a host to selectively request or
	filter traffic from individual sources within a multicast group.		filter traffic from individual sources within a multicast group.
	The Multicast Listener Discovery Protocol (MLD) [RFC2710, MLDv2] offers		The Multicast Listener Discovery Protocol (MLD) [RFC2710, MLDv2] offers
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 44 ¶
	Filtering GMP", or "SFGMP" will be used to refer jointly to the IGMPv3		Filtering GMP", or "SFGMP" will be used to refer jointly to the IGMPv3
	and MLDv2 group management protocols.		and MLDv2 group management protocols.
	The use of source-specific multicast is facilitated by small changes to		The use of source-specific multicast is facilitated by small changes to
	the SFGMP protocols on both hosts and routers. [SSM] defines general		the SFGMP protocols on both hosts and routers. [SSM] defines general
	requirements that must be followed by systems that implement the SSM		requirements that must be followed by systems that implement the SSM
	service model; this document defines the concrete application of those		service model; this document defines the concrete application of those
	requirements to systems that implement IGMPv3 and MLDv2. In doing so,		requirements to systems that implement IGMPv3 and MLDv2. In doing so,
	this document defines modifications to the host and router portions of		this document defines modifications to the host and router portions of
	IGMPv3 and MLDv2 for use with SSM, and presents a number of		IGMPv3 and MLDv2 for use with SSM, and presents a number of
	clarifications to their behavior when used with SSM addresses.		clarifications to their behavior when used with SSM addresses. This
			document updates the IGMPv3 and MLDv2 specifications.
			1.1. Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [RFC 2119].
	In order to emphasize the parts of this document that modify the		In order to emphasize the parts of this document that modify the
	existing protocol specifications, as opposed to merely clarifying them,		existing protocol specifications ([RFC2710,MLDv2,IGMPv3]), as opposed to
	the modifications are marked with the tag "MODIFICATION".		merely clarifying them, any protocol modifications are marked with the
			tag "MODIFICATION".
	2. Host Requirements for Source-Specific Multicast		2. Host Requirements for Source-Specific Multicast
	This section defines the notion of an "SSM-aware" host and then goes on		This section defines the notion of an "SSM-aware" host and then goes on
	to describe the API requirements and the SFGMP protocol requirements of		to describe the API requirements and the SFGMP protocol requirements of
	an SSM-aware host. It is important to note that SSM can be used by any		an SSM-aware host. It is important to note that SSM can be used by any
	host that supports source filtering APIs and whose operating system		host that supports source filtering APIs and whose operating system
	supports the appropriate SFGMP. The SFGMP modifications described in		supports the appropriate SFGMP. The SFGMP modifications described in
	this section make SSM work better on an SSM-aware host, but they are not		this section make SSM work better on an SSM-aware host, but they are not
	strict prerequisites for the use of SSM.		strict prerequisites for the use of SSM.
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 30 ¶
	If a host receives an IGMPv2 or MLDv1 Group Specific Query for an		If a host receives an IGMPv2 or MLDv1 Group Specific Query for an
	address in any configured source-specific range, it should process the		address in any configured source-specific range, it should process the
	query normally, as per [IGMPv3,MLDv2], even if the group queried is a		query normally, as per [IGMPv3,MLDv2], even if the group queried is a
	source-specific destination address. The transmission of such a query		source-specific destination address. The transmission of such a query
	likely indicates that the sending router is either not compliant with		likely indicates that the sending router is either not compliant with
	this document or that it is not configured with the same SSM address		this document or that it is not configured with the same SSM address
	range(s) as the receiving host. A host SHOULD log an error in this case		range(s) as the receiving host. A host SHOULD log an error in this case
	(MODIFICATION).		(MODIFICATION).
	2.2.6. IGMPv3 and MLDv1 Group Specific Query		2.2.6. IGMPv3 and MLDv2 Group Specific Query
	If an SSM-aware host receives an SFGMP Group-Specific Query for an SSM		If an SSM-aware host receives an SFGMP Group-Specific Query for an SSM
	address, it must respond with a report if the group matches the source-		address, it must respond with a report if the group matches the source-
	specific destination address of any of its subscribed source-specific		specific destination address of any of its subscribed source-specific
	channels, as specified in [IGMPv3,MLDv2].		channels, as specified in [IGMPv3,MLDv2].
	The rationale for this is that, although in the current SFGMP protocol		The rationale for this is that, although in the current SFGMP protocol
	specifications, a router would have no reason to send one, the semantics		specifications, a router would have no reason to send one, the semantics
	of such a query are well-defined in this range and future		of such a query are well-defined in this range and future
	implementations may have reason to send such a query. Be liberal in		implementations may have reason to send such a query. Be liberal in
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 34 ¶
	address, thus creating a potential for an attacker to deny SSM service		address, thus creating a potential for an attacker to deny SSM service
	to other hosts on the same link.		to other hosts on the same link.
	5. IANA Considerations		5. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	6. Acknowledgments		6. Acknowledgments
	The authors would like to thank Vince Laviano, Nidhi Bhaskar, Steve		The authors would like to thank Vince Laviano, Nidhi Bhaskar, Steve
	Deering, Toerless Eckert, and Pekka Savola and for their input and		Deering, Toerless Eckert, and Pekka Savola for their input and careful
	careful review.		review.
	7. Normative References		7. Normative References
	[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2,"		[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2,"
	RFC 2236, November 1997.		RFC 2236, November 1997.
	[IGMPv3] Cain, B., Deering, S., Fenner, B., Kouvelas, I., and		[IGMPv3] Cain, B., Deering, S., Fenner, B., Kouvelas, I., and
	Thyagarajan, A., "Internet Group Management Protocol, Version 3," RFC		Thyagarajan, A., "Internet Group Management Protocol, Version 3," RFC
	3376, October 2002.		3376, October 2002.
	skipping to change at page 9, line 47 ¶		skipping to change at page 10, line 15 ¶
	[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112,		[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112,
	August 1989.		August 1989.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels," RFC 2119, March 1997.		Requirement Levels," RFC 2119, March 1997.
	[SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP",		[SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP",
	draft-ietf-ssm-arch-04.txt. Work in Progress.		draft-ietf-ssm-arch-04.txt. Work in Progress.
	[MLDv2] Vida, R., and Costa, L., "Multicast Listener Discovery Version 2		[MLDv2] Vida, R., and Costa, L., "Multicast Listener Discovery Version 2
	(MLDv2) for IPv6", draft-vida-mld-v2-08.txt. Work in progress.		(MLDv2) for IPv6", RFC3810, June 2004.
	[RFC2710] Deering, S., Fenner, B., and Haberman, B., "Multicast Listener		[RFC2710] Deering, S., Fenner, B., and Haberman, B., "Multicast Listener
	Discovery (MLD) for IPv6", RFC 2710, October 1999.		Discovery (MLD) for IPv6", RFC 2710, October 1999.
	8. Informative References		8. Informative References
	[IANA-ALLOCATION] Internet Assigned Numbers Authority,		[IANA-ALLOCATION] Internet Assigned Numbers Authority,
	http://www.isi.edu/in-notes/iana/assignments/multicast-addresses.		http://www.iana.org/assignments/multicast-addresses.
	[RFC3306] Haberman, B., and Thaler, D., "Unicast-prefix-based IPv6		[RFC3306] Haberman, B., and Thaler, D., "Unicast-prefix-based IPv6
	Multicast Addresses", RFC 3306, August 2002.		Multicast Addresses", RFC 3306, August 2002.
	Authors' Addresses		Authors' Addresses
	Hugh Holbrook		Hugh Holbrook
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	holbrook@cisco.com		holbrook@cisco.com
	Brad Cain		Brad Cain
	Storigen Systems		Storigen Systems
	650 Suffolk St.		650 Suffolk St.
	Lowell, MA 01854		Lowell, MA 01854
	bcain99@storigen.com		bcain@storigen.com
	Brian Haberman		Brian Haberman
	Caspian Networks		Johns Hopkins University Applied Physics Lab
	1 Park Drive, Suite 300		11100 Johns Hopkins Road
	Research Triangle Park, NC 27709		Laurel, MD 20723-6099
	brian@innovationslab.net		brian@innovationslab.net
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject to		Copyright (C) The Internet Society (2004). This document is subject to
	the rights, licenses and restrictions contained in BCP 78, and except as		the rights, licenses and restrictions contained in BCP 78, and except as
	set forth therein, the authors retain all their rights.		set forth therein, the authors retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
	skipping to change at page 11, line 29 ¶		skipping to change at page 11, line 43 ¶
	proprietary rights by implementers or users of this specification can be		proprietary rights by implementers or users of this specification can be
	obtained from the IETF on-line IPR repository at		obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary rights		copyrights, patents or patent applications, or other proprietary rights
	that may cover technology that may be required to implement this		that may cover technology that may be required to implement this
	standard. Please address the information to the IETF at ietf-		standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	This document expires Dec 5, 2004.		This document expires Apr 1, 2005.
End of changes. 14 change blocks.
	18 lines changed or deleted		27 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/