idnits 2.17.1 draft-shore-icmp-aup-09.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 (January 3, 2014) is 3765 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) == Outdated reference: A later version (-16) exists of draft-ietf-opsawg-oam-overview-10 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: July 7, 2014 Cisco Systems, Inc. 6 January 3, 2014 8 An Acceptable Use Policy for New ICMP Types and Codes 9 draft-shore-icmp-aup-09 11 Abstract 13 In this document we provide a basic description of ICMP's role in the 14 IP stack and some guidelines for future use. 16 This document is motivated by concerns about lack of clarity 17 concerning when to add new Internet Control Message Protocol (ICMP) 18 types and/or codes. These concerns have highlighted a need to 19 describe policies for when adding new features to ICMP is desirable 20 and when it is not. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 7, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Acceptable use policy . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Classification of existing message types . . . . . . . . . 3 59 2.1.1. A few notes on RPL . . . . . . . . . . . . . . . . . . 5 60 2.2. Extending ICMP . . . . . . . . . . . . . . . . . . . . . . 6 61 2.3. ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . . . 6 62 3. ICMP's role in the internet . . . . . . . . . . . . . . . . . . 6 63 4. Management vs. control . . . . . . . . . . . . . . . . . . . . 7 64 5. Security considerations . . . . . . . . . . . . . . . . . . . . 8 65 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8. Informative references . . . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 There has been some recent concern expressed about a lack of clarity 73 around when to add new message types and codes to ICMP (including 74 ICMPv4 [RFC0792] and ICMPv6 [RFC4443]). We lay out a description of 75 when (and when not) to move functionality into ICMP. 77 This document is the result of discussions among ICMP experts within 78 the OPS area's IP Diagnostics Technical Interest Group [1] and 79 concerns expressed by the OPS area leadership. 81 Note that this document does not supercede the IANA Allocation 82 Guidelines for Values in the Internet Protocol and Related Headers, 83 RFC 2780 [RFC2780], which specifies best practices and processes for 84 the allocation of values in the IANA registries but does not describe 85 the policies to be applied in the standards process. 87 2. Acceptable use policy 89 In this document we describe an acceptable use policy for new ICMP 90 message types and codes, and provide some background behind the 91 policy. 93 In summary, any future message types added to ICMP should be limited 94 to two broad categories: 96 1. to inform a datagram's originator that a forwarding plane anomaly 97 has been encountered downstream. The datagram originator must be 98 able to determine whether or not the datagram was discarded by 99 examining the ICMP message 100 2. to discover and convey dynamic information about a node (other 101 than information usually carried in routing protocols), to 102 discover and convey network-specific parameters, and to discover 103 on-link routers and hosts. 105 Normally, other uses such as implementing a general-purpose routing 106 or network management protocol are not advisable. However, ICMP does 107 have a role to play in conveying dynamic information about a network, 108 which would belong in category 2 above. 110 2.1. Classification of existing message types 112 This section provides a rough breakdown of existing message types 113 according to the taxonomy described in Section 2 at the time of 114 publication. 116 IPv4 forwarding plane anomaly reporting: 118 3: Destination unreachable 119 4: Source quench (deprecated) 120 5: Redirect 121 6: Alternate host address (deprecated) 122 11: Time exceeded 123 12: Parameter problem 124 31: Datagram conversion error (deprecated) 125 32: Mobile host redirect (deprecated) 126 41: ICMP messages utilized by experimental mobility protocols, 127 such as Seamoby 129 IPv4 router or host discovery: 131 0: Echo reply 132 8: Echo 133 9: Router advertisement 134 10: Router solicitation 135 13: Timestamp 136 14: Timestamp reply 137 15: Information request (deprecated) 138 16: Information reply (deprecated) 139 17: Address mask request (deprecated) 140 18: Address mask reply (deprecated) 141 30: Traceroute (deprecated) 142 33: IPv6 Where-Are-You (deprecated) 143 34: IPv6 I-Am-Here (deprecated) 144 35: Mobile registration request (deprecated) 145 36: Mobile registration reply (deprecated) 146 37: Domain name request (deprecated) 147 38: Domain name reply (deprecated) 148 39: SKIP (deprecated) 149 40: Photuris 150 41: ICMP messages utilized by experimental mobility protocols, 151 such as Seamoby 153 Please note that some ICMP message types were formally deprecated by 154 [RFC6918]. 156 IPv6 forwarding plane anomaly reporting: 158 1: Destination unreachable 159 2: Packet too big 160 3: Time exceeded 161 4: Parameter problem 162 137: Redirect message 163 150: ICMP messages utilized by experimental mobility protocols, 164 such as Seamoby 166 IPv6 router or host discovery: 168 128: Echo request 169 129: Echo reply 170 130: Multicast listener query 171 131: Multicast listener report 172 132: Multicast listener done 173 133: Router solicitation 174 134: Router advertisement 175 135: Neighbor solicitation 176 136: Neighbor advertisement 177 138: Router renumbering 178 139: ICMP node information query 179 140: ICMP node information response 180 141: Inverse neighbor discovery solicitation message 181 142: Inverse neighbor discovery advertisement message 182 143: Version 2 multicast listener report 183 144: Home agent address discovery request message 184 145: Home agent address discovery reply message 185 146: Mobile prefix solicitation 186 147: Mobile prefix advertisement 187 148: Certification path solicitation message 188 149: Certification path advertisement message 189 150: ICMP messages utilized by experimental mobility protocols, 190 such as Seamoby 191 151: Multicast router advertisement 192 152: Multicast router solicitation 193 153: Multicast router termination 194 154: FMIPv6 messages 195 155: RPL control message 197 2.1.1. A few notes on RPL 199 RPL, the IPv6 Routing protocol for low-power and lossy networks (see 200 [RFC6550]) appears to be something of an outlier among the existing 201 ICMP message types, as the expansion of its acronym appears to be an 202 actual routing protocol using ICMP for transport. 204 This should be considered anomalous and is not a model for future 205 ICMP message types. Our understanding is that the working group 206 initially defined a discovery protocol extending existing ICMPv6 207 Neighbor Discovery messages before moving to its own native ICMP 208 type. 210 It is typically the case that routing protocols have transport 211 requirements that are not met by ICMP. For example, there will be 212 reliability guarantees and security guarantees that are not provided 213 by ICMP, forcing protocol developers to design their own mechanisms. 214 Given the availability of other IETF standard transports for routing, 215 this reinvention should be avoided. 217 2.2. Extending ICMP 219 ICMP multi-part messages are specified in [RFC4884] by defining an 220 extension mechanism for selected ICMP messages. This mechanism 221 addresses a fundamental problem in ICMP extensibility. An ICMP 222 multi-part message carries all of the information that ICMP messages 223 carried previously, as well as additional information that 224 applications may require. 226 Some currently defined ICMP extensions include ICMP extensions for 227 Multiprotocol Label Switching [RFC4950] and ICMP extensions for 228 interface and next-hop identification [RFC5837]. 230 Extensions to ICMP should follow [RFC4884]. 232 2.3. ICMPv4 vs. ICMPv6 234 Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6 235 routers, IPv6-capable security gateways, and IPv6-capable firewalls 236 normally support administrator configuration of how specific ICMPv6 237 message types are handled. By contrast, deployed IPv4 routers, IPv4- 238 capable security gateways, and IPv4-capable firewalls are less likely 239 to allow an administrator to configure how specific ICMPv4 message 240 types are handled. So, at present, ICMPv6 messages usually have a 241 higher probability of travelling end-to-end than ICMPv4 messages. 243 3. ICMP's role in the internet 245 ICMP was originally intended to be a mechanism for routers to report 246 error conditions back to hosts in ICMPv4 [RFC0792], and ICMPv6 247 [RFC4443] is modeled after it. The word "control" in the protocol 248 name did not describe ICMP's function (i.e. it did not "control" the 249 internet), but rather that it was used to communicate about the 250 control functions in the internet. For example, even though ICMP 251 included a redirect message type that affects routing behavior in the 252 context of a LAN segment, it was and is not used as a generic routing 253 protocol. 255 Most likely because of the presence of the word "control" in the 256 protocol name, ICMP is often understood to be a control protocol, 257 borrowing some terminology from circuit networks and the PSTN. That 258 is probably not correct - it might be more correct to describe it as 259 being closer to a management plane protocol, given the data plane/ 260 control plane/ management plane taxonomy often used in describing 261 telephony protocols. However, layering in IP networks is not very 262 clean and there's often some intermingling of function that can tend 263 to lead to confusion about where to place new functions. 265 In the following section we provide some background on the 266 differences between control and management traffic. 268 4. Management vs. control 270 In this section we attempt to draw a distinction between management 271 and control planes, acknowledging in advance that this may serve to 272 muddle the differences even further. Ultimately the difference may 273 not matter that much for the purpose of creating a policy for adding 274 new types to ICMP, but because the terminology of "management and 275 control planes" has become ubiquitous, even in IETF discussions, and 276 because it has come up in prior discussions of ICMP policies, it 277 seems worthwhile to take a few paragraph to describe what management 278 and control plane are and what they are not. 280 The terms "management plane" and "control plane" came into use to 281 describe one aspect of layering in telecommunications networks. 282 "Management plane" is described in [I-D.ietf-opsawg-oam-overview], 283 and "control plane" is defined in [RFC6192]. 285 It is particularly important, in the context of this discussion, to 286 understand that "control plane" in telecommunications networks almost 287 always refers to 'signaling,' or call control and network control 288 information. This includes "call" establishment and teardown, route 289 establishment and teardown, requesting QoS or other parameters, and 290 other similar artifacts. 292 "Management," on the other hand, involves an exchange between a 293 management application and managed entities such as network nodes, 294 and includes "inline management" and "management" per se. Typical 295 "inline management" functions include fault management and 296 performance monitoring (Service Level Agreement (SLA) compliance), 297 discovery, and typical "management" include protocols such as SNMP 298 and NETCONF. 300 The correct answer to the question of where ICMP fits into the 301 management/control/data taxonomy is that it doesn't, at least not 302 neatly. While some of the message types are unambiguously management 303 messages, at least within the narrow confines of a management/control 304 dichotomy (ICMP type 3, or "unreachable" messages), others are less 305 clearly identifiable. For example, the "redirect" (ICMP type 5) 306 message can be construed to contain control (in this case, routing) 307 information, even though it is in some very real sense an error 308 message. 310 At this time, 311 o there are plethora of other protocols that can be (and are) used 312 for control traffic, whether they're routing protocols, telephony 313 signaling protocols, QoS protocols, middlebox protocols, AAA 314 protocols, etc. 315 o the transport characteristics needed by control traffic can be 316 incompatible with the ICMP protocol standard -- for example, they 317 may require reliable delivery, very large payloads, or have 318 security requirements that cannot be met. 319 and because of this any future message types added to ICMP should 320 conform to the policy in Section 2. ICMP should not be used as a 321 routing or network management protocol. 323 5. Security considerations 325 This document describes a high-level policy for adding ICMP types and 326 codes. While special attention must be paid to the security 327 implications of any particular new ICMP type or code, this 328 recommendation presents no new security considerations. 330 From a security perspective, ICMP plays a part in the Photuris 331 protocol. But more generally, ICMP is not a secure protocol, and 332 does not include features to be used to discover network security 333 parameters or to report on network security anomalies in the 334 forwarding plane. 336 6. IANA considerations 338 There are no actions required by IANA. 340 7. Acknowledgments 342 This document was originally proposed by, and received substantial 343 review and suggestions from, Ron Bonica. Discussions with Pascal 344 Thubert helped clarify the history of RPL's use of ICMP. We are very 345 grateful for feedback and comments from Ran Atkinson, Joe Clarke, Ray 346 Hunter, JINMEI Tatuya, and Wen Zhang, which resulted in a much 347 improved document. 349 8. Informative references 351 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 352 RFC 792, September 1981. 354 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 355 Values In the Internet Protocol and Related Headers", 356 BCP 37, RFC 2780, March 2000. 358 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 359 Message Protocol (ICMPv6) for the Internet Protocol 360 Version 6 (IPv6) Specification", RFC 4443, March 2006. 362 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 363 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 364 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 365 Lossy Networks", RFC 6550, March 2012. 367 [RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some 368 ICMPv4 Message Types", RFC 6918, April 2013. 370 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 371 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 372 April 2007. 374 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 375 Extensions for Multiprotocol Label Switching", RFC 4950, 376 August 2007. 378 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 379 Rivers, "Extending ICMP for Interface and Next-Hop 380 Identification", RFC 5837, April 2010. 382 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 383 Router Control Plane", RFC 6192, March 2011. 385 [I-D.ietf-opsawg-oam-overview] 386 Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 387 Weingarten, "An Overview of Operations, Administration, 388 and Maintenance (OAM) Data Plane Tools", 389 draft-ietf-opsawg-oam-overview-10 (work in progress), 390 October 2013. 392 [1] 394 Authors' Addresses 396 Melinda Shore 397 No Mountain Software 398 PO Box 16271 399 Two Rivers, AK 99716 400 US 402 Phone: +1 907 322 9522 403 Email: melinda.shore@nomountain.net 405 Carlos Pignataro 406 Cisco Systems, Inc. 407 7200-12 Kit Creek Road 408 Research Triangle Park, NC 27709 409 US 411 Email: cpignata@cisco.com