Individual Submission Bill Fenner
INTERNET-DRAFT AT&T Research
Expires: March 2002 September 2001
IANA Considerations for IGMP
draft-fenner-igmp-iana-01.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 an individual. Comments are solicited and
should be addressed to the author.
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
IGMP protocol header, and provides guidance for the IANA to use in
assigning parameters for those fields.
Fenner [Page 1]
INTERNET-DRAFT Expires: March 2002 September 2001
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 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 unknwon 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,
Fenner Section 4. [Page 2]
INTERNET-DRAFT Expires: March 2002 September 2001
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.
Fenner Section 6. [Page 3]
INTERNET-DRAFT Expires: March 2002 September 2001
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.
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
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
Fenner Section 6. [Page 4]
INTERNET-DRAFT Expires: March 2002 September 2001
4 Old Neighbors Reply
5 Ask Neighbors
6 Neighbors Reply
7 Prune
8 Graft
9 Graft Ack
0x14 PIM version 1
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] Deerins, 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.
[...] 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 Section 6. [Page 5]
INTERNET-DRAFT Expires: March 2002 September 2001
[...] Fenner, W., "IANA Considerations for IGMP", work in progress,
September 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 be copied and furnished 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 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
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
Fenner Section 8. [Page 6]
INTERNET-DRAFT Expires: March 2002 September 2001
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Fenner Section 8. [Page 7]