Network Working Group B. Fenner Request for Comments: 3228 AT&T Research BCP: 57 February 2002 Category: Best Current Practice
IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)
Status of this Memo
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
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.
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 [2].
Fenner Best Current Practice [Page 1]
RFC 3228 IANA Considerations for IPv4 IGMP February 2002
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.
Instead of suggesting temporary assignments as in [3], this document follows the lead of [4] 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.
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.
Copyright (C) The Internet Society (2002). 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 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.