idnits 2.17.1 draft-fenner-igmp-iana-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2001) is 8258 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-narten-iana-experimental-allocations-00 ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) -- Duplicate reference: RFC2236, mentioned in 'RFC2236', was also mentioned in '1'. -- Possible downref: Non-RFC (?) normative reference: ref. 'Fenner' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission Bill Fenner 2 INTERNET-DRAFT AT&T Research 3 Expires: March 2002 September 2001 5 IANA Considerations for IGMP 6 draft-fenner-igmp-iana-01.txt 8 Status of this Document 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This document is a product of an individual. Comments are solicited and 29 should be addressed to the author. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 Abstract 37 This memo requests that the IANA create a registry for fields in the 38 IGMP protocol header, and provides guidance for the IANA to use in 39 assigning parameters for those fields. 41 Table of Contents 43 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 44 2. IANA Considerations for fields in the IPv4 IGMP 45 header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 46 3. Assignments for testing and experimentation . . . . . . . . . . . 2 47 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 2 48 5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 6. Current IGMP Type/Code Assignments. . . . . . . . . . . . . . . . 3 50 7. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 6 51 8. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 6 53 1. Introduction 55 This memo requests that the IANA create a registry for fields in the 56 IGMP protocol header. 58 The terms "Specification Required", "Expert Review", "IESG Approval", 59 "IETF Consensus", and "Standards Action", are used in this memo to refer 60 to the processes described in [4]. 62 2. IANA Considerations for fields in the IPv4 IGMP header 64 The IPv4 IGMP header [1] contains the following fields that carry values 65 assigned from IANA-managed name spaces: Type and Code. Code field values 66 are defined relative to a specific Type value. 68 Values for the IPv4 IGMP Type fields are allocated using an IESG 69 Approval or Standards Action processes. Code Values for existing IPv4 70 IGMP Type fields are allocated using IESG Approval or Standards Action 71 processes. The policy for assigning Code values for new IPv4 IGMP Types 72 should be defined in the document defining the new Type value. 74 3. Assignments for testing and experimentation 76 Instead of suggesting temporary assignments as in [2], this document 77 follows the lead of [3] and assigns a range of values for experimental 78 use. The IGMP Code values 240-255 inclusive (0xf0 - 0xff) are reserved 79 for protocol testing and experimentation. 81 Systems should silently ignore IGMP messages with unknwon Code values. 83 4. Security Considerations 85 Security analyzers such as firewalls and network intrusion detection 86 monitors often rely on unambiguous interpretations of the fields 87 described in this memo. As new values for the fields are assigned, 88 existing security analyzers that do not understand the new values may 89 fail, resulting in either loss of connectivity if the analyzer declines 90 to forward the unrecognized traffic, or loss of security if it does 91 forward the traffic and the new values are used as part of an attack. 92 This vulnerability argues for high visibility (which the Standards 93 Action and IETF Consensus processes ensure) for the assignments whenever 94 possible. 96 5. References 98 [1] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 99 2236, November 1997 101 [2] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In 102 the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 103 2000. 105 [3] Narten, T. "Assigning Experimental and Testing Numbers Considered 106 Useful", draft-narten-iana-experimental-allocations-00.txt, July 107 2001. 109 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 110 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 112 6. Current IGMP Type/Code Assignments 114 This section is suitable for use as initial version of the IANA's igmp- 115 parameters file. It is to be removed before publication as RFC. 117 IGMP TYPE NUMBERS 119 The Internet Group Message Protocol (IGMP) has many messages that 120 are identified by a "type" field. 122 Note that the original definition of IGMP in RFC1112 divided this 123 field into two 4-byte values, "version" and "type". This was 124 decided to be too restrictive, so the fields were combined into a 125 single 8-bit type space. 127 Type Name Reference 128 ---- ---------------------- --------- 129 0x11 IGMP Membership Query [RFC1112] 130 0x12 IGMPv1 Membership Report [RFC1112] 131 0x13 DVMRP [...] 132 0x14 PIM version 1 133 0x15 Cisco Trace Messages 134 0x16 IGMPv2 Membership Report [RFC2236] 135 0x17 IGMPv2 Leave Group [RFC2236] 136 0x1e Multicast Traceroute Response [Fenner] 137 0x1f Multicast Traceroute [Fenner] 138 0x22 IGMPv3 Membership Report [...] 139 0xf0-0xff Reserved for experimentation [...] 141 Many of these IGMP types have a "code" field. Here we list the types 142 again with their assigned code fields. 144 Type Name Reference 145 ---- ------------------------- --------- 146 0x11 IGMP Membership Query [RFC1112] 148 Codes 149 0 IGMP Version 1 150 1-255 IGMP Version 2 or above Max Response Time 152 0x12 IGMPv1 Membership Report [RFC1112] 153 0x13 DVMRP [...] 155 Codes 156 1 Probe 157 2 Route Report 158 3 Old Ask Neighbors 159 4 Old Neighbors Reply 160 5 Ask Neighbors 161 6 Neighbors Reply 162 7 Prune 163 8 Graft 164 9 Graft Ack 166 0x14 PIM version 1 168 Codes 169 0 Query 170 1 Register 171 2 Register-Stop 172 3 Join/Prune 173 4 RP-Reachable 174 5 Assert 175 6 Graft 176 7 Graft Ack 177 8 Mode 179 0x16 IGMPv2 Membership Report [RFC2236] 181 0x17 IGMPv2 Leave Group [RFC2236] 183 0x1e Multicast Traceroute Response [Fenner] 185 0x1f Multicast Traceroute [Fenner] 187 0x22 IGMPv3 Membership Report [...] 189 0xf0-0xff Reserved for experimentation [...] 191 REFERENCES 192 ---------- 194 [RFC1112] Deerins, S., "Host extensions for IP multicasting", RFC 1112, 195 Stanford University, August 1989. 197 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", 198 RFC 2236, Xerox PARC, November 1997. 200 [...] Pusateri, T., "DVMRP Version 3", work in progress, 201 Juniper Networks, July? 2001. 203 [...] Cain, B., S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, 204 "Internet Group Management Protocol, Version 3", work in 205 progress, July? 2001. 207 [...] Fenner, W., "IANA Considerations for IGMP", work in progress, 208 September 2001. 210 PEOPLE 211 ------ 213 [Fenner] Bill Fenner, 215 [] 217 7. Author's Address 219 Bill Fenner 220 AT&T Labs -- Research 221 75 Willow Rd 222 Menlo Park, CA 94025 223 USA 225 Email: fenner@research.att.com 227 8. Full Copyright Statement 229 Copyright (C) The Internet Society (2001). All Rights Reserved. 231 This document and translations of it may be copied and furnished to 232 others, and derivative works that comment on or otherwise explain it or 233 assist in its implementation may be prepared, copied, published and 234 distributed, in whole or in part, without restriction of any kind, 235 provided that the above copyright notice and this paragraph are included 236 on all such copies and derivative works. However, this document itself 237 may not be modified in any way, such as by removing the copyright notice 238 or references to the Internet Society or other Internet organizations, 239 except as needed for the purpose of developing Internet standards in 240 which case the procedures for copyrights defined in the Internet 241 Standards process must be followed, or as required to translate it into 242 languages other than English. 244 The limited permissions granted above are perpetual and will not be 245 revoked by the Internet Society or its successors or assigns. 247 This document and the information contained herein is provided on an "AS 248 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 249 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 250 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 251 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 252 FITNESS FOR A PARTICULAR PURPOSE.