< draft-ietf-pim-3376bis-00.txt		draft-ietf-pim-3376bis-01.txt >
	Network Working Group B. Haberman, Ed.		Network Working Group B. Haberman, Ed.
	Internet-Draft JHU APL		Internet-Draft JHU APL
	Obsoletes: 3376 (if approved) September 2021		Obsoletes: 3376 (if approved) October 2021
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 1 April 2022		Expires: 28 April 2022
	Internet Group Management Protocol, Version 3		Internet Group Management Protocol, Version 3
	draft-ietf-pim-3376bis-00		draft-ietf-pim-3376bis-01
	Abstract		Abstract
	This document specifies a revised Version 3 of the Internet Group		This document specifies a revised Version 3 of the Internet Group
	Management Protocol, IGMPv3. IGMP is the protocol used by IPv4		Management Protocol, IGMPv3. IGMP is the protocol used by IPv4
	systems to report their IP multicast group memberships to neighboring		systems to report their IP multicast group memberships to neighboring
	multicast routers. Version 3 of IGMP adds support for source		multicast routers. Version 3 of IGMP adds support for source
	filtering, that is, the ability for a system to report interest in		filtering, that is, the ability for a system to report interest in
	receiving packets only from specific source addresses, or from all		receiving packets only from specific source addresses, or from all
	but specific source addresses, sent to a particular multicast		but specific source addresses, sent to a particular multicast
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	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		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 5 March 2022.		This Internet-Draft will expire on 4 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 11 ¶
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 46		9. Security Considerations . . . . . . . . . . . . . . . . . . . 46
	9.1. Query Message . . . . . . . . . . . . . . . . . . . . . . 47		9.1. Query Message . . . . . . . . . . . . . . . . . . . . . . 47
	9.2. Current-State Report messages . . . . . . . . . . . . . . 47		9.2. Current-State Report messages . . . . . . . . . . . . . . 47
	9.3. State-Change Report Messages . . . . . . . . . . . . . . 48		9.3. State-Change Report Messages . . . . . . . . . . . . . . 48
	9.4. 9.4. IPSEC Usage . . . . . . . . . . . . . . . . . . . . 49		9.4. 9.4. IPSEC Usage . . . . . . . . . . . . . . . . . . . . 49
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
	13.1. Normative References . . . . . . . . . . . . . . . . . . 50		13.1. Normative References . . . . . . . . . . . . . . . . . . 50
	13.2. Informative References . . . . . . . . . . . . . . . . . 50		13.2. Informative References . . . . . . . . . . . . . . . . . 51
	Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 51		Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 51
	A.1. The Need for State-Change Messages . . . . . . . . . . . 51		A.1. The Need for State-Change Messages . . . . . . . . . . . 51
	A.2. Host Suppression . . . . . . . . . . . . . . . . . . . . 51		A.2. Host Suppression . . . . . . . . . . . . . . . . . . . . 52
	A.3. Switching Router Filter Modes from EXCLUDE to INCLUDE . . 52		A.3. Switching Router Filter Modes from EXCLUDE to INCLUDE . . 52
	Appendix B. Summary of Changes from IGMPv2 . . . . . . . . . . . 52		Appendix B. Summary of Changes from IGMPv2 . . . . . . . . . . . 53
	Appendix C. Summary of Changes from RFC 3376 . . . . . . . . . . 53		Appendix C. Summary of Changes from RFC 3376 . . . . . . . . . . 53
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53
	1. Introduction		1. Introduction
	The Internet Group Management Protocol (IGMP) is used by IPv4 systems		The Internet Group Management Protocol (IGMP) is used by IPv4 systems
	(hosts and routers) to report their IP multicast group memberships to		(hosts and routers) to report their IP multicast group memberships to
	any neighboring multicast routers. Note that an IP multicast router		any neighboring multicast routers. Note that an IP multicast router
	may itself be a member of one or more multicast groups, in which case		may itself be a member of one or more multicast groups, in which case
	it performs both the multicast router part of the protocol (to		it performs both the multicast router part of the protocol (to
	skipping to change at page 29, line 34 ¶		skipping to change at page 29, line 34 ¶
	for that group is updated to cover all the requested sources using		for that group is updated to cover all the requested sources using
	the least amount of state. As a rule, once a group record with a		the least amount of state. As a rule, once a group record with a
	filter-mode of EXCLUDE is received, the router filter-mode for that		filter-mode of EXCLUDE is received, the router filter-mode for that
	group will be EXCLUDE.		group will be EXCLUDE.
	When a router filter-mode for a group is EXCLUDE, the source record		When a router filter-mode for a group is EXCLUDE, the source record
	list contains two types of sources. The first type is the set which		list contains two types of sources. The first type is the set which
	represents conflicts in the desired reception state; this set must be		represents conflicts in the desired reception state; this set must be
	forwarded by some router on the network. The second type is the set		forwarded by some router on the network. The second type is the set
	of sources which hosts have requested to not be forwarded.		of sources which hosts have requested to not be forwarded.
	Appendix A describes the reasons for keeping this second set when in		Appendix A describes the reasons for keeping two different sets when
	EXCLUDE mode.		in EXCLUDE mode.
	When a router filter-mode for a group is INCLUDE, the source record		When a router filter-mode for a group is INCLUDE, the source record
	list is the list of sources desired for the group. This is the total		list is the list of sources desired for the group. This is the total
	desired set of sources for that group. Each source in the source		desired set of sources for that group. Each source in the source
	record list must be forwarded by some router on the network.		record list must be forwarded by some router on the network.
	Because a reported group record with a filter-mode of EXCLUDE will		Because a reported group record with a filter-mode of EXCLUDE will
	cause a router to transition its filter-mode for that group to		cause a router to transition its filter-mode for that group to
	EXCLUDE, a mechanism for transitioning a router's filter-mode back to		EXCLUDE, a mechanism for transitioning a router's filter-mode back to
	INCLUDE must exist. If all systems with a group record in EXCLUDE		INCLUDE must exist. If all systems with a group record in EXCLUDE
	skipping to change at page 36, line 44 ¶		skipping to change at page 36, line 44 ¶
	Table 8		Table 8
	When a router sends or receives a query with the Suppress Router-Side		When a router sends or receives a query with the Suppress Router-Side
	Processing flag set, it will not update its timers.		Processing flag set, it will not update its timers.
	6.6.2. Querier Election		6.6.2. Querier Election
	IGMPv3 elects a single querier per subnet using the same querier		IGMPv3 elects a single querier per subnet using the same querier
	election mechanism as IGMPv2, namely by IP address. When a router		election mechanism as IGMPv2, namely by IP address. When a router
	receives a query with a lower IP address, it sets the Other-Querier-		receives a general query with a lower IP address, it sets the Other-
	Present timer to Other Querier Present Interval and ceases to send		Querier- Present timer to Other Querier Present Interval and ceases
	queries on the network if it was the previously elected querier.		to send general queries on the network if it was the previously
	After its Other-Querier Present timer expires, it should begin		elected querier. After its Other-Querier Present timer expires, it
	sending General Queries.		should begin sending General Queries.
	If a router receives an older version query, it MUST use the oldest		If a router receives an older version general query, it MUST use the
	version of IGMP on the network. For a detailed description of		oldest version of IGMP on the network. For a detailed description of
	compatibility issues between IGMP versions see section Section 7.		compatibility issues between IGMP versions see section Section 7.
	6.6.3. Building and Sending Specific Queries		6.6.3. Building and Sending Specific Queries
	6.6.3.1. Building and Sending Group Specific Queries		6.6.3.1. Building and Sending Group Specific Queries
	When a table action "Send Q(G)" is encountered, then the group timer		When a table action "Send Q(G)" is encountered, then the group timer
	must be lowered to LMQT. The router must then immediately send a		must be lowered to LMQT. The router must then immediately send a
	group specific query as well as schedule [Last Member Query Count -		group specific query as well as schedule [Last Member Query Count -
	1] query retransmissions to be sent every [Last Member Query		1] query retransmissions to be sent every [Last Member Query
	skipping to change at page 50, line 11 ¶		skipping to change at page 50, line 11 ¶
	All IGMP types described in this document are already assigned in		All IGMP types described in this document are already assigned in
	[RFC3228].		[RFC3228].
	11. Contributors		11. Contributors
	Brad Cain, Steve Deering, Isidor Kouvelas, Bill Fenner, and Ajit		Brad Cain, Steve Deering, Isidor Kouvelas, Bill Fenner, and Ajit
	Thyagarajan are the authors of RFC 3376, which forms the bulk of the		Thyagarajan are the authors of RFC 3376, which forms the bulk of the
	content contained herein.		content contained herein.
			Anuj Budhiraja, Toerless Eckert, Olufemi Komolafe and Tim Winters
			have contributed valuable content to this version of the
			specification.
	12. Acknowledgments		12. Acknowledgments
	We would like to thank Ran Atkinson, Luis Costa, Toerless Eckert,		We would like to thank Ran Atkinson, Luis Costa, Toerless Eckert,
	Dino Farinacci, Serge Fdida, Wilbert de Graaf, Sumit Gupta, Mark		Dino Farinacci, Serge Fdida, Wilbert de Graaf, Sumit Gupta, Mark
	Handley, Bob Quinn, Michael Speer, Dave Thaler and Rolland Vida for		Handley, Bob Quinn, Michael Speer, Dave Thaler and Rolland Vida for
	comments and suggestions on RFC 3376.		comments and suggestions on RFC 3376.
			Stig Venaas, Hitoshi Asaeda, and Mike McBride have provided valuable
			feedback on this version of the specification and we thank them for
			their input.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,		[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
	RFC 1112, DOI 10.17487/RFC1112, August 1989,		RFC 1112, DOI 10.17487/RFC1112, August 1989,
	<https://www.rfc-editor.org/info/rfc1112>.		<https://www.rfc-editor.org/info/rfc1112>.
	[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,		[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
	DOI 10.17487/RFC2113, February 1997,		DOI 10.17487/RFC2113, February 1997,
End of changes. 12 change blocks.
	16 lines changed or deleted		24 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/