idnits 2.17.1 draft-shore-icmp-aup-03.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 issues found here. 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 (March 25, 2013) is 4051 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SLA' is mentioned on line 294, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 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 Intended status: BCP C. Pignataro 5 Expires: September 26, 2013 Cisco Systems, Inc. 6 March 25, 2013 8 An Acceptable Use Policy for New ICMP Types and Codes 9 draft-shore-icmp-aup-03 11 Abstract 13 Concerns about lack of clarity concerning when to add new Internet 14 Control Message Protocol (ICMP) types and/or codes have highlighted a 15 need to describe policies for when adding new features to ICMP is 16 desirable and when it is not. In this document we provide a basic 17 description of ICMP's role in the IP stack and some guidelines for 18 the future. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 26, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Acceptable use policy . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Classification of existing message types . . . . . . . . . 4 57 2.1.1. A few notes on RPL . . . . . . . . . . . . . . . . . . 7 58 3. ICMP's role in the internet . . . . . . . . . . . . . . . . . 8 59 4. Management vs. control . . . . . . . . . . . . . . . . . . . . 9 60 5. Security considerations . . . . . . . . . . . . . . . . . . . 11 61 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 62 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 63 8. Informative references . . . . . . . . . . . . . . . . . . . . 14 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 66 1. Introduction 68 There has been some recent concern expressed about a lack of clarity 69 around when to add new message types and codes to ICMP (including 70 ICMPv4 [RFC792] and ICMPv6 [RFC4443]). We attempt to lay out a 71 description of when (and when not) to move functionality into ICMP. 73 This document is the result of discussions among ICMP experts within 74 the OPS area's IP Diagnostics Technical Interest Group [1] and 75 concerns expressed by the OPS area leadership. 77 2. Acceptable use policy 79 In this document we describe a proposed acceptable use policy for new 80 ICMP message types and codes, and provide some background behind the 81 proposed policy. 83 In summary, we propose that any future message types added to ICMP 84 should be limited to two broad categories: 86 1. to inform a datagram's originator that a forwarding plane anomaly 87 has been encountered downstream. The datagram originator must be 88 able to determine whether or not the datagram was discarded by 89 examining the ICMP message 91 2. to discover on-link routers and hosts, and network-specific 92 parameters 94 While we do not want ICMP to be a general-purpose network management 95 protocol it does have a role to play in conveying dynamic information 96 about a network. 98 2.1. Classification of existing message types 100 This section provides a rough breakdown of existing message types 101 according to the taxonomy described in Section 2. 103 IPV4 forwarding plane anomaly reporting 105 3: Destination unreachable 107 4: Source quench (deprecated) 109 5: Redirect 111 6: Alternate host address 113 11 Time exceeded 115 12 Parameter problem 117 31: Datagram converson error 119 32: Mobile host redirect 120 41: ICMP messages utilized by experimental mobility protocols, 121 such as Seamoby 123 IPv4 router or host discovery 125 0: Echo reply 127 8: Echo 129 9: Router advertisement 131 10: Router solicitation 133 13: Timestamp 135 14: Timestamp reply 137 15: Information request 139 16: Information reply 141 17: Address mask request 143 18: Address mask reply 145 30: Traceroute 147 33: IPv6 Where-Are-You 149 34: IPv6 I-Am-Here 151 35: Mobile registration request 153 36: Mobile registration reply 155 37: Domain name request 157 38: Domain name reply 159 39: SKIP 161 40: Photuris 162 41: ICMP messages utilized by experimental mobility protocols, 163 such as Seamoby 165 IPv6 forwarding plane anomaly reporting 167 1: Destination unreachable 169 2: Packet too big 171 3: Time exceeded 173 4: Parameter problem 175 137: Redirect message 177 150: ICMP messages utilized by experimental mobility protocols, 178 such as Seamoby 180 IPv6 router or host discovery 182 128: Echo request 184 129: Echo reply 186 130: Multicast listener query 188 131: Multicast listener report 190 132: Multicast listener done 192 133: Router solicitation 194 134: Router advertisement 196 135: Neighbor solicitation 198 136: Neighbor advertisement 200 138: Router renumbering 202 139: ICMP node information query 203 140: ICMP node information response 205 141: Inverse neighbor discovery solicitation message 207 142: Inverse neighbor discovery advertisement message 209 143: Version 2 multicast listener report 211 144: Home agent address discovery request message 213 145: Home agent address discovery reply message 215 146: Mobile prefix solicitation 217 147: Mobile prefix advertisement 219 148: Certification path solicitation message 221 149: Certification path advertisement message 223 150: ICMP messages utilized by experimental mobility protocols, 224 such as Seamoby 226 151: Multicast router advertisement 228 152: Multicast router solicitation 230 153: Multicast router termination 232 154: FMIPv6 messages 234 155: RPL control message 236 2.1.1. A few notes on RPL 238 RPL, the IPv6 Routing protocol for low-power and lossy networks (see 239 [RFC6550]) appears to be something of an outlier among the existing 240 ICMP message types, as the expansion of its acronym appears to be an 241 actual routing protocol using ICMP for transport. 243 This should be considered anomalous and is not a model for future 244 ICMP message types. Our understanding is that the working group 245 initially defined a discovery protocol extending existing ICMPv6 ND 246 messages before moving to its own native ICMP type. 248 3. ICMP's role in the internet 250 ICMP was originally intended to be a mechanism for routers to report 251 error conditions back to hosts [RFC792]. The word "control" in the 252 protocol name did not describe ICMP's function (i.e. it did not 253 "control" the internet), but rather that it was used to communicate 254 about the control functions in the internet. For example, even 255 though ICMP included a redirect message type, it was and is not used 256 as a routing protocol. 258 Most likely because of the presence of the word "control" in the 259 protocol name, ICMP is often understood to be a control protocol, 260 borrowing some terminology from circuit networks and the PSTN. That 261 is probably not correct - it might be more correct to describe it as 262 being closer to a management plane protocol, given the data plane/ 263 control plane/ management plane taxonomy often used in describing 264 telephony protocols. However, layering in IP networks is not very 265 clean and there's often some intermingling of function that can tend 266 to lead to confusion about where to place new functions. 268 In following sections we provide some background on the differences 269 between control and management traffic. 271 4. Management vs. control 273 In this section we attempt to draw a distinction between management 274 and control planes, acknowledging in advance that this may serve to 275 muddle the differences even further. Ultimately the difference may 276 not matter that much for the purpose of creating a policy for adding 277 new types to ICMP, but because that terminology has become 278 ubiquitous, even in IETF discussions, and because it has come up in 279 prior discussions of ICMP policies, it seems worthwhile to take a few 280 paragraph to describe what they are and what they are not. 282 The terms "management plane" and "control plane" came into use to 283 describe one aspect of layering in telecommunications networks. It 284 is particularly important, in the context of this discussion, to 285 understand that "control plane" in telecomm networks almost always 286 refers to 'signaling,' or call control and network control 287 information. This includes "call" establishment and teardown, route 288 establishment and teardown, requesting QoS or other parameters, and 289 so on. 291 "Management," on the other hand, tends to fall under the rubric 292 "OAM," or "Operations, Administration, and Management." typical 293 functions include fault management and performance monitoring 294 (Service Level Agreement [SLA] compliance), discovery, etc. 296 The correct answer to the question of where ICMP fits into the 297 management/control/data taxonomy is that it doesn't, at least not 298 neatly. While some of the message types are unambiguously management 299 message, at least within the narrow confines of a management/control 300 dichotomy (ICMP type 3, or "unreachable" messages), others are less 301 clearly identifiable. For example, the "redirect" (ICMP type 5) 302 message can be construed to contain control (in this case, routing) 303 information, even though it is in some very real sense an error 304 message. 306 At this time, 308 o there are many, many other protocols that can be (and are) used 309 for control traffic, whether they're routing protocols, telephony 310 signaling protocols, QoS protocols, middlebox protocols, AAA 311 protocols, etc. 313 o the transport characteristics needed by control traffic can be 314 incompatible with the ICMP protocol standard -- for example, they 315 may require reliable delivery, very large payloads, or have 316 security requirements that cannot be met. 318 and because of this we propose that any future message types added to 319 ICMP must conform to the policy proposed in Section 2. ICMP should 320 not be used as a routing or network management protocol. 322 5. Security considerations 324 This document attempts to describe a high-level policy for adding 325 ICMP types and codes. While special attention must be paid to the 326 security implications of any particular new ICMP type or code, 327 specific security considerations are outside the scope of this paper. 329 6. IANA considerations 331 There are no actions required by IANA. 333 7. Acknowledgments 335 This document was originally proposed by, and received substantial 336 review and suggestions from, Ron Bonica. Discussions with Pascal 337 Thubert helped clarify the history of RPL's use of ICMP. We are 338 grateful for feedback from Joe Clarke and Wen Zhang. 340 8. Informative references 342 [RFC792] Postel, J., "INTERNET CONTROL MESSAGE PROTOCOL", RFC 792, 343 September 1981. 345 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 346 Message Protocol (ICMPv6) for the Internet Protocol 347 Version 6 (IPv6) Specification", RFC 4443, March 2006. 349 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 350 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 351 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 352 Lossy Networks", RFC 6550, March 2012. 354 [1] 356 Authors' Addresses 358 Melinda Shore 359 No Mountain Software 360 PO Box 16271 361 Two Rivers, AK 99716 362 US 364 Phone: +1 907 322 9522 365 Email: melinda.shore@nomountain.net 367 Carlos Pignataro 368 Cisco Systems, Inc. 369 7200-12 Kit Creek Road 370 Research Triangle Park, NC 27709 371 US 373 Email: cpignata@cisco.com