idnits 2.17.1 draft-shore-icmp-aup-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2012) is 4298 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) == Missing Reference: 'SLA' is mentioned on line 275, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Shore 3 Internet-Draft No Mountain Software 4 Expires: January 14, 2013 C. Pignataro 5 Cisco Systems, Inc. 6 July 13, 2012 8 An Acceptable Use Policy for New ICMP Types and Codes 9 draft-shore-icmp-aup-01 11 Abstract 13 Some recent proposals to add new Internet Control Message Protocol 14 (ICMP) types and/or codes have highlighted a need to describe 15 policies for when adding new features to ICMP is desirable and when 16 it is not. In this document we provide a basic description of ICMP's 17 role in the IP stack and some guidelines for the future. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 14, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Acceptable use policy . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Classification of existing message types . . . . . . . . . 4 56 3. ICMP's role in the internet . . . . . . . . . . . . . . . . . 8 57 4. Management vs control . . . . . . . . . . . . . . . . . . . . 9 58 5. Security considerations . . . . . . . . . . . . . . . . . . . 11 59 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 61 8. Informative references . . . . . . . . . . . . . . . . . . . . 14 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 64 1. Introduction 66 There have been some recent proposals to add new message types and 67 codes to ICMP [RFC792]. Not all of these proposal are consistent 68 with the design and intent of ICMP, and so we attempt to lay out a 69 description of when (and when not) to move functionality into ICMP. 71 This document is the result of discussions within the IETF Operations 72 area "ICMP Society," and concerns expressed by the OPS area 73 leadership. 75 2. Acceptable use policy 77 In this document we describe a proposed acceptable use policy for new 78 ICMP message types and codes, and provide some background behind the 79 proposed policy. 81 In summary, we propose that any future message types added to ICMP 82 should be limited to two broad categories: 84 1. to inform a datagram's originator that a forwarding plane anomaly 85 has been encountered downstream. The datagram originator must be 86 able to determine whether or not the datagram was discarded by 87 examining the ICMP message 89 2. to discover on-link routers and hosts 91 2.1. Classification of existing message types 93 This section provides a rough breakdown of existing message types 94 according to the taxonomy described in Section 2. 96 IPV4 forwarding plane anomaly reporting 98 3: Destination unreachable 100 4: Source quench (deprecated) 102 5: Redirect 104 6: Alternate host address 106 11 Time exceeded 108 12 Parameter problem 110 31: Datagram converson error 112 32: Mobile host redirect 114 41: ICMP messages utilized by experimental mobility protocols, 115 such as Seamoby 117 IPv4 router or host discovery 118 0: Echo reply 120 8: Echo 122 9: Router advertisement 124 10: Router solicitation 126 13: Timestamp 128 14: Timestamp reply 130 15: Information request 132 16: Information reply 134 17: Address mask request 136 18: Address mask reply 138 30: Traceroute 140 33: IPv6 Where-Are-You 142 34: IPv6 I-Am-Here 144 35: Mobile registration request 146 36: Mobile registration reply 148 37: Domain name request 150 38: Domain name reply 152 39: SKIP 154 40: Photuris 156 41: ICMP messages utilized by experimental mobility protocols, 157 such as Seamoby 159 IPv6 forwarding plane anomaly reporting 160 1: Destination unreachable 162 2: Packet too big 164 3: Time exceeded 166 4: Parameter problem 168 137: Redirect message 170 150: ICMP messages utilized by experimental mobility protocols, 171 such as Seamoby 173 IPv6 router or host discovery 175 128: Echo request 177 129: Echo reply 179 130: Multicast listener query 181 131: Multicast listener report 183 132: Multicast listener done 185 133: Router solicitation 187 134: Router advertisement 189 135: Neighbor solicitation 191 136: Neighbor advertisement 193 138: Router renumbering 195 139: ICMP node information query 197 140: ICMP node information response 199 141: Inverse neighbor discovery solicitation message 201 142: Inverse neighbor discovery advertisement message 202 143: Version 2 multicast listener report 204 144: Home agent address discovery request message 206 145: Home agent address discovery reply message 208 146: Mobile prefix solicitation 210 147: Mobile prefix advertisement 212 148: Certification path solicitation message 214 149: Certification path advertisement message 216 150: ICMP messages utilized by experimental mobility protocols, 217 such as Seamoby 219 151: Multicast router advertisement 221 152: Multicast router solicitation 223 153: Multicast router termination 225 154: FMIPv6 messages 227 155: RPL control message 229 3. ICMP's role in the internet 231 ICMP was originally intended to be a mechanism for routers to report 232 error conditions back to hosts [RFC792]. The word "control" in the 233 protocol name did not describe ICMP's function (i.e. it did not 234 "control" the internet), but rather that it was used to communicate 235 about the control functions in the internet. For example, even 236 though ICMP included a redirect message type, it was and is not used 237 as a routing protocol. 239 Most likely because of the presence of the word "control" in the 240 protocol name, ICMP is often understood to be a control protocol, 241 borrowing some terminology from circuit networks and the PSTN. That 242 is probably not correct - it might be more correct to describe it as 243 being closer to a management plane protocol, given the data plane/ 244 control plane/ management plane taxonomy often used in describing 245 telephony protocols. However, layering in IP networks is not very 246 clean and there's often some intermingling of function that can tend 247 to lead to confusion about where to place new functions. 249 In following sections we provide some background on the differences 250 between control and management traffic. 252 4. Management vs control 254 In this section we attempt to draw a distinction between management 255 and control planes, acknowledging in advance that this may serve to 256 muddle the differences even further. Ultimately the difference may 257 not matter that much for the purpose of creating a policy for adding 258 new types to ICMP, but because that terminology has become 259 ubiquitous, even in IETF discussions, and because it has come up in 260 prior discussions of ICMP policies, it seems worthwhile to take a few 261 paragraph to describe what they are and what they are not. 263 The terms "management plane" and "control plane" came into use to 264 describe one aspect of layering in telecommunications networks. It 265 is particularly important, in the context of this discussion, to 266 understand that "control plane" in telecomm networks almost always 267 refers to 'signaling,' or call control and network control 268 information. This includes "call" establishment and teardown, route 269 establishment and teardown, requesting QoS or other parameters, and 270 so on. 272 "Management," on the other hand, tends to fall under the rubric 273 "OAM," or "Operations, Administration, and Management." typical 274 functions include fault management and performance monitoring 275 (Service Level Agreement [SLA] compliance), discovery, etc. 277 The correct answer to the question of where ICMP fits into the 278 management/control/data taxonomy is that it doesn't, at least not 279 neatly. While some of the message types are unambiguously management 280 message (ICMP type 3, or "unreachable" messages), others are less 281 clearly identifiable. For example, the "redirect" (ICMP type 5) 282 message can be construed to contain control (in this case, routing) 283 information, even though it is in some very real sense an error 284 message. 286 At this time, 288 o there are many, many other protocols that can be (and are) used 289 for control traffic, whether they're routing protocols, telephony 290 signaling protocols, QoS protocols, middlebox protocols, AAA 291 protocols, etc. 293 o the transport characteristics needed by control traffic can be 294 incompatible with the ICMP protocol standard -- for example, they 295 may require reliable delivery, very large payloads, or have 296 security requirements that cannot be met. 298 and because of this we propose that any future message types added to 299 ICMP must conform to the policy proposed in Section 2. ICMP should 300 not be used as a routing or network management protocol. 302 5. Security considerations 304 This document attempts to describe a high-level policy for adding 305 ICMP types and codes. While special attention must be paid to the 306 security implications of any particular new ICMP type or code, 307 specific security considerations are outside the scope of this paper. 309 6. IANA considerations 311 There are no actions required by IANA. 313 7. Acknowledgments 315 This document was originally proposed by, and received substantial 316 review and suggestions from, Ron Bonica. 318 8. Informative references 320 [RFC792] Postel, J., "INTERNET CONTROL MESSAGE PROTOCOL", RFC 792, 321 September 1981. 323 Authors' Addresses 325 Melinda Shore 326 No Mountain Software 327 PO Box 16271 328 Two Rivers, AK 99716 329 US 331 Phone: +1 907 322 9522 332 Email: melinda.shore@nomountain.net 334 Carlos Pignataro 335 Cisco Systems, Inc. 336 7200-12 Kit Creek Road 337 Research Triangle Park, NC 27709 338 US 340 Email: cpignata@cisc.com