idnits 2.17.1 draft-ietf-magma-igmp-iana-00.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 (October 2001) is 8227 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'. == Outdated reference: A later version (-02) exists of draft-ietf-idmr-pim-spec-01 -- Possible downref: Normative reference to a draft: ref. 'PIMv1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fenner' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MAGMA Working Group Bill Fenner 2 INTERNET-DRAFT AT&T Research 3 Expires: April 2002 October 2001 5 IANA Considerations for IGMP 6 draft-ietf-magma-igmp-iana-00.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 the MAGMA Working Group. Comments should 29 be addressed to the authors, or the mailing list at 30 magma@innovationslab.net. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This memo requests that the IANA create a registry for fields in the 39 IGMP protocol header, and provides guidance for the IANA to use in 40 assigning parameters for those fields. 42 Table of Contents 44 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 45 2. IANA Considerations for fields in the IPv4 IGMP 46 header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 47 3. Assignments for testing and experimentation . . . . . . . . . . . 2 48 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 2 49 5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 6. Current IGMP Type/Code Assignments. . . . . . . . . . . . . . . . 3 51 7. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 6 52 8. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 6 54 1. Introduction 56 This memo requests that the IANA create a registry for fields in the 57 IGMP protocol header. 59 The terms "Specification Required", "Expert Review", "IESG Approval", 60 "IETF Consensus", and "Standards Action", are used in this memo to refer 61 to the processes described in [4]. 63 2. IANA Considerations for fields in the IPv4 IGMP header 65 The IPv4 IGMP header [1] contains the following fields that carry values 66 assigned from IANA-managed name spaces: Type and Code. Code field values 67 are defined relative to a specific Type value. 69 Values for the IPv4 IGMP Type fields are allocated using an IESG 70 Approval or Standards Action processes. Code Values for existing IPv4 71 IGMP Type fields are allocated using IESG Approval or Standards Action 72 processes. The policy for assigning Code values for new IPv4 IGMP Types 73 should be defined in the document defining the new Type value. 75 3. Assignments for testing and experimentation 77 Instead of suggesting temporary assignments as in [2], this document 78 follows the lead of [3] and assigns a range of values for experimental 79 use. The IGMP Code values 240-255 inclusive (0xf0 - 0xff) are reserved 80 for protocol testing and experimentation. 82 Systems should silently ignore IGMP messages with unknown Code values. 84 4. Security Considerations 86 Security analyzers such as firewalls and network intrusion detection 87 monitors often rely on unambiguous interpretations of the fields 88 described in this memo. As new values for the fields are assigned, 89 existing security analyzers that do not understand the new values may 90 fail, resulting in either loss of connectivity if the analyzer declines 91 to forward the unrecognized traffic, or loss of security if it does 92 forward the traffic and the new values are used as part of an attack. 93 This vulnerability argues for high visibility (which the Standards 94 Action and IETF Consensus processes ensure) for the assignments whenever 95 possible. 97 5. References 99 [1] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 100 2236, November 1997 102 [2] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In 103 the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 104 2000. 106 [3] Narten, T. "Assigning Experimental and Testing Numbers Considered 107 Useful", draft-narten-iana-experimental-allocations-00.txt, July 108 2001. 110 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 111 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 113 6. Current IGMP Type/Code Assignments 115 This section is suitable for use as initial version of the IANA's igmp- 116 parameters file. It is to be removed before publication as RFC. 118 One open issue: is there a place to publish the not-a-standard PIMv1 119 spec? It's an I-D that's been expired for 6 years, but is arguably the 120 only place that the packet formats for PIMv1 are defined. Can this spec 121 be placed in a stable place at the RFC-editor site without giving it any 122 kind of official status? 124 IGMP TYPE NUMBERS 126 The Internet Group Message Protocol (IGMP) has many messages that 127 are identified by a "type" field. 129 Note that the original definition of IGMP in RFC1112 divided this 130 field into two 4-byte values, "version" and "type". This was 131 decided to be too restrictive, so the fields were combined into a 132 single 8-bit type space. 134 Type Name Reference 135 ---- ---------------------- --------- 136 0x11 IGMP Membership Query [RFC1112] 137 0x12 IGMPv1 Membership Report [RFC1112] 138 0x13 DVMRP [...] 139 0x14 PIM version 1 [PIMv1] 140 0x15 Cisco Trace Messages 141 0x16 IGMPv2 Membership Report [RFC2236] 142 0x17 IGMPv2 Leave Group [RFC2236] 143 0x1e Multicast Traceroute Response [Fenner] 144 0x1f Multicast Traceroute [Fenner] 145 0x22 IGMPv3 Membership Report [...] 146 0xf0-0xff Reserved for experimentation [...] 148 Many of these IGMP types have a "code" field. Here we list the types 149 again with their assigned code fields. 151 Type Name Reference 152 ---- ------------------------- --------- 153 0x11 IGMP Membership Query [RFC1112] 155 Codes 156 0 IGMP Version 1 157 1-255 IGMP Version 2 or above Max Response Time 159 0x12 IGMPv1 Membership Report [RFC1112] 160 0x13 DVMRP [...] 162 Codes 163 1 Probe 164 2 Route Report 165 3 Old Ask Neighbors 166 4 Old Neighbors Reply 167 5 Ask Neighbors 168 6 Neighbors Reply 169 7 Prune 170 8 Graft 171 9 Graft Ack 173 0x14 PIM version 1 [PIMv1] 175 Codes 176 0 Query 177 1 Register 178 2 Register-Stop 179 3 Join/Prune 180 4 RP-Reachable 181 5 Assert 182 6 Graft 183 7 Graft Ack 184 8 Mode 186 0x16 IGMPv2 Membership Report [RFC2236] 188 0x17 IGMPv2 Leave Group [RFC2236] 190 0x1e Multicast Traceroute Response [Fenner] 192 0x1f Multicast Traceroute [Fenner] 194 0x22 IGMPv3 Membership Report [...] 196 0xf0-0xff Reserved for experimentation [...] 198 REFERENCES 199 ---------- 201 [RFC1112] Deering, S., "Host extensions for IP multicasting", RFC 1112, 202 Stanford University, August 1989. 204 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", 205 RFC 2236, Xerox PARC, November 1997. 207 [PIMv1] Estrin, D. et al, "Protocol Independent Multicast (PIM): 208 Protocol Specification", no stable reference known, 209 draft-ietf-idmr-pim-spec-01.ps, January 1995. 211 [...] Pusateri, T., "DVMRP Version 3", work in progress, 212 Juniper Networks, July? 2001. 214 [...] Cain, B., S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, 215 "Internet Group Management Protocol, Version 3", work in 216 progress, July? 2001. 218 [...] Fenner, W., "IANA Considerations for IGMP", work in progress, 219 October 2001. 221 PEOPLE 222 ------ 224 [Fenner] Bill Fenner, 226 [] 228 7. Author's Address 230 Bill Fenner 231 AT&T Labs -- Research 232 75 Willow Rd 233 Menlo Park, CA 94025 234 USA 236 Email: fenner@research.att.com 238 8. Full Copyright Statement 240 Copyright (C) The Internet Society (2001). All Rights Reserved. 242 This document and translations of it may be copied and furnished to 243 others, and derivative works that comment on or otherwise explain it or 244 assist in its implementation may be prepared, copied, published and 245 distributed, in whole or in part, without restriction of any kind, 246 provided that the above copyright notice and this paragraph are included 247 on all such copies and derivative works. However, this document itself 248 may not be modified in any way, such as by removing the copyright notice 249 or references to the Internet Society or other Internet organizations, 250 except as needed for the purpose of developing Internet standards in 251 which case the procedures for copyrights defined in the Internet 252 Standards process must be followed, or as required to translate it into 253 languages other than English. 255 The limited permissions granted above are perpetual and will not be 256 revoked by the Internet Society or its successors or assigns. 258 This document and the information contained herein is provided on an "AS 259 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 260 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 261 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 262 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 263 FITNESS FOR A PARTICULAR PURPOSE.