MAGMA Working Group Bill Fenner 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 IGMP protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. Fenner [Page 1] INTERNET-DRAFT Expires: April 2002 October 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 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, Fenner Section 4. [Page 2] INTERNET-DRAFT Expires: April 2002 October 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: April 2002 October 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. 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] Fenner Section 6. [Page 4] INTERNET-DRAFT Expires: April 2002 October 2001 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. Fenner Section 6. [Page 5] INTERNET-DRAFT Expires: April 2002 October 2001 [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, [] 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 Fenner Section 8. [Page 6] INTERNET-DRAFT Expires: April 2002 October 2001 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 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Fenner Section 8. [Page 7]