IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)
Setting up a registry for IGMP message type codes
Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", RFC 3228, DOI 10.17487/RFC3228, February 2002, <https://www.rfc-editor.org/info/rfc3228>.
@misc{rfc3228,
series = {Request for Comments},
number = 3228,
howpublished = {RFC 3228},
publisher = {RFC Editor},
doi = {10.17487/RFC3228},
url = {https://www.rfc-editor.org/info/rfc3228},
author = {B. Fenner},
title = {{IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)}},
pagetotal = 4,
year = 2002,
month = feb,
} RFC text
Contents
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.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 1
2. IANA Considerations for fields in the IPv4 IGMP header. . . . 2
3. Assignments for testing and experimentation . . . . . . . . . 2
4. Security Considerations . . . . . . . . . . . . . . . . . . . 2
5. Normative References. . . . . . . . . . . . . . . . . . . . . 2
6. Informative References. . . . . . . . . . . . . . . . . . . . 3
7. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 3
8. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 4
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 [2].
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 [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.
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. Normative References
[1] Fenner, W., "Internet Group Management Protocol, Version 2",
RFC 2236, November 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
6. Informative References
[3] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP 37,
RFC 2780, March 2000.
[4] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", Work in Progress.
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 (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.
AI ELI5
On this page
§1What the RFC Does
RFC 3228 is a Best Current Practice that asks IANA to create and manage a registry for fields in the IGMP (Internet Group Management Protocol) header. IGMP lets programs tell a network they want to receive multicast messages sent to a group.
The IGMP header contains two kinds of values that IANA must manage: Type (which kind of IGMP message) and Code (which subtype or behavior for that Type). Without a clear registry, two different RFCs might assign the same value to different uses, breaking the protocol.
IGMP messages have labels and codes. This RFC says someone official should keep a list of what each label and code means, so two people don't both pick the number 5 for their own idea.
§2How IANA Assigns Type and Code Values
New Type values are assigned only through IESG Approval (Internet Engineering Steering Group approves) or Standards Action (the value is defined in a Standards Track RFC). Code values for existing Types follow the same rule unless the RFC defining that Type says otherwise.
The key insight is that different Types can have different Code policies. When an RFC introduces a new Type, it can specify in that same RFC how Code values for that Type will be allocated.
New labels need official approval from important people. Each label can have its own rules for its codes, written in the RFC that first uses that label.
§3Codes Reserved for Testing
IGMP Code values 240 to 255 (in hexadecimal: 0xf0 to 0xff) are reserved for protocol testing and experimentation. Systems that receive IGMP messages with unknown Code values must silently ignore them, rather than treating them as errors.
This reserve encourages engineers to experiment safely without corrupting the production protocol, and the silent-ignore rule prevents cascading failures when an experimental code reaches a system that has not been updated to recognize it.
There are special test numbers (240-255) that engineers can use to try new ideas. If a program gets a message with a number it doesn't recognize, it just ignores it quietly rather than crashing.
§4Why This Matters for Security
Network firewalls and intrusion detection systems monitor IGMP traffic to spot attacks. If a new Type or Code value is assigned but the security tool doesn't yet understand it, the tool might either block the traffic (breaking service) or pass it through without checking (opening a security hole).
This is why RFC 3228 says new Type values should go through Standards Action or IESG Approval: the visibility ensures security tools have time to understand the change before the new value is widely used.
When something new gets a number, people protecting the network need to know about it soon, or their guards might accidentally block it or let bad things through.