MAGMA Working Group Bill Fenner
INTERNET-DRAFT AT&T Research
Expires: April 2002 October 2001
IANA ConsiderationsA new Request for IGMP
draft-ietf-magma-igmp-iana-00.txt
Status of this Document
This document is an Internet-Draft and Comments is now available 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 online RFC libraries.
BCP 57
RFC 3228
Title: IANA Considerations 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 IPv4
Internet Society (2001). All Rights Reserved.
Abstract 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
I-D Tag: draft-ietf-magma-igmp-iana-01.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3228.txt
This memo requests that the IANA create a registry for fields in the
IGMP (Internet Group Management Protocol) protocol header, and
provides guidance for the IANA to use in assigning parameters for
those fields.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 2
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
This memo requests that the IANA create a registry for fields in the
IGMP protocol header.
The terms "Specification Required", "Expert Review", "IESG Approval",
"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 is 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 product of connectivity if the analyzer declines
to forward the unrecognized traffic, or loss Multicast & Anycast Group Membership
Working Group of security if it does
forward the traffic and the new values are used as part of an attack. IETF.
This vulnerability argues for high visibility (which the Standards
Action and IETF Consensus processes ensure) document specifies an Internet Best Current Practices 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 Community, and Testing Numbers Considered
Useful", draft-narten-iana-experimental-allocations-00.txt, July
2001.
[4] Narten, T. requests discussion 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 suggestions for use as initial version
improvements. Distribution of the IANA's igmp-
parameters file. It this memo is to be removed before publication as RFC.
One open issue: unlimited.
This announcement is there a place sent 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" IETF list and "type". This was
decided the RFC-DIST list.
Requests to be too restrictive, so added to or deleted from 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 IETF distribution 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
AT&T Labs -- Research
75 Willow Rd
Menlo Park, CA 94025
USA
Email: fenner@research.att.com
8. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may
should be copied and furnished sent to IETF-REQUEST@IETF.ORG. Requests to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole
added to or in part, without restriction of any kind,
provided that deleted from the above copyright notice and this paragraph are included RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on all such copies and derivative works. However, this document itself obtaining RFCs via FTP or EMAIL may not be modified in any way, such as obtained by removing the copyright notice
or references sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the Internet Society or other Internet organizations,
except as needed message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the purpose
author of developing Internet standards in
which case the procedures for copyrights defined RFC in the Internet
Standards process must be followed, question, or as required to translate it into
languages other than English.
The limited permissions granted above RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are perpetual and will not for
unlimited distribution.echo
Submissions for Requests for Comments should be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.