< draft-ietf-magma-igmp-iana-00.txt		draft-ietf-magma-igmp-iana-01.txt >
	MAGMA Working Group Bill Fenner		A new Request for Comments is now available in online RFC libraries.
	INTERNET-DRAFT AT&T Research
	Expires: April 2002 October 2001
	IANA Considerations for IGMP
	draft-ietf-magma-igmp-iana-00.txt
	Status of this Document
	This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other groups
	may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference material
	or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This document is a product of the MAGMA Working Group. Comments should
	be addressed to the authors, or the mailing list at
	magma@innovationslab.net.
	Copyright Notice
	Copyright (C) The Internet Society (2001). All Rights Reserved.
	Abstract
	This memo requests that the IANA create a registry for fields in the		BCP 57
	IGMP protocol header, and provides guidance for the IANA to use in		RFC 3228
	assigning parameters for those fields.
	Table of Contents		Title: IANA Considerations for IPv4
			Internet Group Management Protocol (IGMP)
			Author(s): B. Fenner
			Status: Best Current Practice
			Date: February 2002
			Mailbox: fenner@research.att.com
			Pages: 4
			Characters: 6473
			Updates/Obsoletes/SeeAlso: None
	1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 2		I-D Tag: draft-ietf-magma-igmp-iana-01.txt
	2. IANA Considerations for fields in the IPv4 IGMP
	header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Assignments for testing and experimentation . . . . . . . . . . . 2
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 2
	5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	6. Current IGMP Type/Code Assignments. . . . . . . . . . . . . . . . 3
	7. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 6
	8. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3228.txt
	This memo requests that the IANA create a registry for fields in the		This memo requests that the IANA create a registry for fields in the
	IGMP protocol header.		IGMP (Internet Group Management Protocol) protocol header, and
			provides guidance for the IANA to use in assigning parameters for
	The terms "Specification Required", "Expert Review", "IESG Approval",		those fields.
	"IETF Consensus", and "Standards Action", are used in this memo to refer
	to the processes described in [4].
	2. IANA Considerations for fields in the IPv4 IGMP header
	The IPv4 IGMP header [1] contains the following fields that carry values
	assigned from IANA-managed name spaces: Type and Code. Code field values
	are defined relative to a specific Type value.
	Values for the IPv4 IGMP Type fields are allocated using an IESG
	Approval or Standards Action processes. Code Values for existing IPv4
	IGMP Type fields are allocated using IESG Approval or Standards Action
	processes. The policy for assigning Code values for new IPv4 IGMP Types
	should be defined in the document defining the new Type value.
	3. Assignments for testing and experimentation
	Instead of suggesting temporary assignments as in [2], this document
	follows the lead of [3] and assigns a range of values for experimental
	use. The IGMP Code values 240-255 inclusive (0xf0 - 0xff) are reserved
	for protocol testing and experimentation.
	Systems should silently ignore IGMP messages with unknown Code values.
	4. Security Considerations
	Security analyzers such as firewalls and network intrusion detection
	monitors often rely on unambiguous interpretations of the fields
	described in this memo. As new values for the fields are assigned,
	existing security analyzers that do not understand the new values may
	fail, resulting in either loss of connectivity if the analyzer declines
	to forward the unrecognized traffic, or loss of security if it does
	forward the traffic and the new values are used as part of an attack.
	This vulnerability argues for high visibility (which the Standards
	Action and IETF Consensus processes ensure) for the assignments whenever
	possible.
	5. References
	[1] Fenner, W., "Internet Group Management Protocol, Version 2", RFC
	2236, November 1997
	[2] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In
	the Internet Protocol and Related Headers", BCP 37, RFC 2780, March
	2000.
	[3] Narten, T. "Assigning Experimental and Testing Numbers Considered
	Useful", draft-narten-iana-experimental-allocations-00.txt, July
	2001.
	[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
	6. Current IGMP Type/Code Assignments
	This section is suitable for use as initial version of the IANA's igmp-
	parameters file. It is to be removed before publication as RFC.
	One open issue: is there a place to publish the not-a-standard PIMv1
	spec? It's an I-D that's been expired for 6 years, but is arguably the
	only place that the packet formats for PIMv1 are defined. Can this spec
	be placed in a stable place at the RFC-editor site without giving it any
	kind of official status?
	IGMP TYPE NUMBERS
	The Internet Group Message Protocol (IGMP) has many messages that
	are identified by a "type" field.
	Note that the original definition of IGMP in RFC1112 divided this
	field into two 4-byte values, "version" and "type". This was
	decided to be too restrictive, so the fields were combined into a
	single 8-bit type space.
	Type Name Reference
	0x11 IGMP Membership Query [RFC1112]
	0x12 IGMPv1 Membership Report [RFC1112]
	0x13 DVMRP [...]
	0x14 PIM version 1 [PIMv1]
	0x15 Cisco Trace Messages
	0x16 IGMPv2 Membership Report [RFC2236]
	0x17 IGMPv2 Leave Group [RFC2236]
	0x1e Multicast Traceroute Response [Fenner]
	0x1f Multicast Traceroute [Fenner]
	0x22 IGMPv3 Membership Report [...]
	0xf0-0xff Reserved for experimentation [...]
	Many of these IGMP types have a "code" field. Here we list the types
	again with their assigned code fields.
	Type Name Reference
	0x11 IGMP Membership Query [RFC1112]
	Codes
	0 IGMP Version 1
	1-255 IGMP Version 2 or above Max Response Time
	0x12 IGMPv1 Membership Report [RFC1112]
	0x13 DVMRP [...]
	Codes
	1 Probe
	2 Route Report
	3 Old Ask Neighbors
	4 Old Neighbors Reply
	5 Ask Neighbors
	6 Neighbors Reply
	7 Prune
	8 Graft
	9 Graft Ack
	0x14 PIM version 1 [PIMv1]
	Codes
	0 Query
	1 Register
	2 Register-Stop
	3 Join/Prune
	4 RP-Reachable
	5 Assert
	6 Graft
	7 Graft Ack
	8 Mode
	0x16 IGMPv2 Membership Report [RFC2236]
	0x17 IGMPv2 Leave Group [RFC2236]
	0x1e Multicast Traceroute Response [Fenner]
	0x1f Multicast Traceroute [Fenner]
	0x22 IGMPv3 Membership Report [...]
	0xf0-0xff Reserved for experimentation [...]
	REFERENCES
	[RFC1112] Deering, S., "Host extensions for IP multicasting", RFC 1112,
	Stanford University, August 1989.
	[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2",
	RFC 2236, Xerox PARC, November 1997.
	[PIMv1] Estrin, D. et al, "Protocol Independent Multicast (PIM):
	Protocol Specification", no stable reference known,
	draft-ietf-idmr-pim-spec-01.ps, January 1995.
	[...] Pusateri, T., "DVMRP Version 3", work in progress,
	Juniper Networks, July? 2001.
	[...] Cain, B., S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan,
	"Internet Group Management Protocol, Version 3", work in
	progress, July? 2001.
	[...] Fenner, W., "IANA Considerations for IGMP", work in progress,
	October 2001.
	PEOPLE
	[Fenner] Bill Fenner, <fenner@research.att.com>
	[]
	7. Author's Address
	Bill Fenner		This document is a product of the Multicast & Anycast Group Membership
	AT&T Labs -- Research		Working Group of the IETF.
	75 Willow Rd
	Menlo Park, CA 94025
	USA
	Email: fenner@research.att.com		This document specifies an Internet Best Current Practices for the
			Internet Community, and requests discussion and suggestions for
			improvements. Distribution of this memo is unlimited.
	8. Full Copyright Statement		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Copyright (C) The Internet Society (2001). All Rights Reserved.		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and translations of it may be copied and furnished to		To: rfc-info@RFC-EDITOR.ORG
	others, and derivative works that comment on or otherwise explain it or		Subject: getting rfcs
	assist in its implementation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of any kind,
	provided that the above copyright notice and this paragraph are included
	on all such copies and derivative works. However, this document itself
	may not be modified in any way, such as by removing the copyright notice
	or references to the Internet Society or other Internet organizations,
	except as needed for the purpose of developing Internet standards in
	which case the procedures for copyrights defined in the Internet
	Standards process must be followed, or as required to translate it into
	languages other than English.
	The limited permissions granted above are perpetual and will not be		help: ways_to_get_rfcs
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an "AS		Requests for special distribution should be addressed to either the
	IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT		specifically noted otherwise on the RFC itself, all RFCs are for
	LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT		unlimited distribution.echo
	INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR		Submissions for Requests for Comments should be sent to
	FITNESS FOR A PARTICULAR PURPOSE.		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	240 lines changed or deleted		33 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/