idnits 2.17.1 draft-shore-icmp-aup-05.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 (October 21, 2013) is 3839 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-09 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: April 24, 2014 Cisco Systems, Inc. 6 October 21, 2013 8 An Acceptable Use Policy for New ICMP Types and Codes 9 draft-shore-icmp-aup-05 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 April 24, 2014. 39 Copyright Notice 41 Copyright (c) 2013 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 3. ICMP's role in the internet . . . . . . . . . . . . . . . . . . 6 62 4. Management vs. control . . . . . . . . . . . . . . . . . . . . 7 63 5. Security considerations . . . . . . . . . . . . . . . . . . . . 8 64 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Informative references . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 There has been some recent concern expressed about a lack of clarity 72 around when to add new message types and codes to ICMP (including 73 ICMPv4 [RFC0792] and ICMPv6 [RFC4443]). We attempt to lay out a 74 description of when (and when not) to move functionality into ICMP. 76 This document is the result of discussions among ICMP experts within 77 the OPS area's IP Diagnostics Technical Interest Group [1] and 78 concerns expressed by the OPS area leadership. 80 Note that this document does not supercede the IANA Allocation 81 Guidelines for Values in the Internet Protocol and Related Headers, 82 RFC 2880. [RFC2780] That document specifies best practices and 83 processes for the allocation of values in the IANA registries but 84 does not describe the policies to be applied in the standards 85 process. 87 2. Acceptable use policy 89 In this document we describe a proposed acceptable use policy for new 90 ICMP message types and codes, and provide some background behind the 91 proposed policy. 93 In summary, we propose that any future message types added to ICMP 94 should be limited 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 on-link routers and hosts, and network-specific 101 parameters 103 While ICMP's role is not to be a general-purpose network management 104 protocol, it does have a role to play in conveying dynamic 105 information about a network. 107 2.1. Classification of existing message types 109 This section provides a rough breakdown of existing message types 110 according to the taxonomy described in Section 2 at the time of 111 publication. 113 IPv4 forwarding plane anomaly reporting: 115 3: Destination unreachable 116 4: Source quench (deprecated) 117 5: Redirect 118 6: Alternate host address (deprecated) 119 11: Time exceeded 120 12: Parameter problem 121 31: Datagram conversion error (deprecated) 122 32: Mobile host redirect (deprecated) 123 41: ICMP messages utilized by experimental mobility protocols, 124 such as Seamoby 126 IPv4 router or host discovery: 128 0: Echo reply 129 8: Echo 130 9: Router advertisement 131 10: Router solicitation 132 13: Timestamp 133 14: Timestamp reply 134 15: Information request (deprecated) 135 16: Information reply (deprecated) 136 17: Address mask request (deprecated) 137 18: Address mask reply (deprecated) 138 30: Traceroute (deprecated) 139 33: IPv6 Where-Are-You (deprecated) 140 34: IPv6 I-Am-Here (deprecated) 141 35: Mobile registration request (deprecated) 142 36: Mobile registration reply (deprecated) 143 37: Domain name request (deprecated) 144 38: Domain name reply (deprecated) 145 39: SKIP (deprecated) 146 40: Photuris 147 41: ICMP messages utilized by experimental mobility protocols, 148 such as Seamoby 150 Please note that some ICMP message types were formally deprecated by 151 [RFC6918]. 153 IPv6 forwarding plane anomaly reporting: 155 1: Destination unreachable 156 2: Packet too big 157 3: Time exceeded 158 4: Parameter problem 159 137: Redirect message 160 150: ICMP messages utilized by experimental mobility protocols, 161 such as Seamoby 163 IPv6 router or host discovery: 165 128: Echo request 166 129: Echo reply 167 130: Multicast listener query 168 131: Multicast listener report 169 132: Multicast listener done 170 133: Router solicitation 171 134: Router advertisement 172 135: Neighbor solicitation 173 136: Neighbor advertisement 174 138: Router renumbering 175 139: ICMP node information query 176 140: ICMP node information response 177 141: Inverse neighbor discovery solicitation message 178 142: Inverse neighbor discovery advertisement message 179 143: Version 2 multicast listener report 180 144: Home agent address discovery request message 181 145: Home agent address discovery reply message 182 146: Mobile prefix solicitation 183 147: Mobile prefix advertisement 184 148: Certification path solicitation message 185 149: Certification path advertisement message 186 150: ICMP messages utilized by experimental mobility protocols, 187 such as Seamoby 188 151: Multicast router advertisement 189 152: Multicast router solicitation 190 153: Multicast router termination 191 154: FMIPv6 messages 192 155: RPL control message 194 2.1.1. A few notes on RPL 196 RPL, the IPv6 Routing protocol for low-power and lossy networks (see 197 [RFC6550]) appears to be something of an outlier among the existing 198 ICMP message types, as the expansion of its acronym appears to be an 199 actual routing protocol using ICMP for transport. 201 This should be considered anomalous and is not a model for future 202 ICMP message types. Our understanding is that the working group 203 initially defined a discovery protocol extending existing ICMPv6 204 Neighbor Discovery messages before moving to its own native ICMP 205 type. 207 It is typically the case that routing protocols have transport 208 requirements that are not met by ICMP. For example, there will be 209 reliability guarantees and security guarantees that are not provided 210 by ICMP, forcing protocol developers to design their own mechanisms. 211 Given the availability of other IETF standard transports for routing, 212 this reinvention should be avoided. 214 2.2. Extending ICMP 216 ICMP multi-part messages are specified in [RFC4884] by defining an 217 extension mechanism for selected ICMP messages. This mechanism 218 addresses a fundamental problem in ICMP extensibility. An ICMP 219 multi-part message carries all of the information that ICMP messages 220 carried previously, as well as additional information that 221 applications may require. 223 Some currently defined ICMP extensions include ICMP extensions for 224 Multiprotocol Label Switching [RFC4950] and ICMP extensions for 225 interface and next-hop identification [RFC5837]. 227 Extensions to ICMP should follow [RFC4884]. 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 in ICMPv4 [RFC0792], and ICMPv6 233 [RFC4443] models after it. The word "control" in the protocol name 234 did not describe ICMP's function (i.e. it did not "control" the 235 internet), but rather that it was used to communicate about the 236 control functions in the internet. For example, even though ICMP 237 included a redirect message type that affects routing behavior in the 238 context of a LAN segment, it was and is not used as a generic routing 239 protocol. 241 Most likely because of the presence of the word "control" in the 242 protocol name, ICMP is often understood to be a control protocol, 243 borrowing some terminology from circuit networks and the PSTN. That 244 is probably not correct - it might be more correct to describe it as 245 being closer to a management plane protocol, given the data plane/ 246 control plane/ management plane taxonomy often used in describing 247 telephony protocols. However, layering in IP networks is not very 248 clean and there's often some intermingling of function that can tend 249 to lead to confusion about where to place new functions. 251 In following sections we provide some background on the differences 252 between control and management traffic. 254 4. Management vs. control 256 In this section we attempt to draw a distinction between management 257 and control planes, acknowledging in advance that this may serve to 258 muddle the differences even further. Ultimately the difference may 259 not matter that much for the purpose of creating a policy for adding 260 new types to ICMP, but because that terminology has become 261 ubiquitous, even in IETF discussions, and because it has come up in 262 prior discussions of ICMP policies, it seems worthwhile to take a few 263 paragraph to describe what they are and what they are not. 265 The terms "management plane" and "control plane" came into use to 266 describe one aspect of layering in telecommunications networks. 267 "Management plane" is described in [I-D.ietf-opsawg-oam-overview], 268 and "control plane" is defined in [RFC6192]. 270 It is particularly important, in the context of this discussion, to 271 understand that "control plane" in telecomm networks almost always 272 refers to 'signaling,' or call control and network control 273 information. This includes "call" establishment and teardown, route 274 establishment and teardown, requesting QoS or other parameters, and 275 so on. 277 "Management," on the other hand, involves an exchange between a 278 management application and managed entities such as network nodes, 279 and includes "inline management" and "management" per se. Typical 280 "inline management" functions include fault management and 281 performance monitoring (Service Level Agreement (SLA) compliance), 282 discovery, and typical "management" include protocols such as SNMP 283 and NETCONF. 285 The correct answer to the question of where ICMP fits into the 286 management/control/data taxonomy is that it doesn't, at least not 287 neatly. While some of the message types are unambiguously management 288 message, at least within the narrow confines of a management/control 289 dichotomy (ICMP type 3, or "unreachable" messages), others are less 290 clearly identifiable. For example, the "redirect" (ICMP type 5) 291 message can be construed to contain control (in this case, routing) 292 information, even though it is in some very real sense an error 293 message. 295 At this time, 296 o there are many, many other protocols that can be (and are) used 297 for control traffic, whether they're routing protocols, telephony 298 signaling protocols, QoS protocols, middlebox protocols, AAA 299 protocols, etc. 301 o the transport characteristics needed by control traffic can be 302 incompatible with the ICMP protocol standard -- for example, they 303 may require reliable delivery, very large payloads, or have 304 security requirements that cannot be met. 305 and because of this we propose that any future message types added to 306 ICMP should conform to the policy proposed in Section 2. ICMP should 307 not be used as a routing or network management protocol. 309 5. Security considerations 311 This document attempts to describe a high-level policy for adding 312 ICMP types and codes. While special attention must be paid to the 313 security implications of any particular new ICMP type or code, this 314 recommendation presents no security considerations. 316 6. IANA considerations 318 There are no actions required by IANA. 320 7. Acknowledgments 322 This document was originally proposed by, and received substantial 323 review and suggestions from, Ron Bonica. Discussions with Pascal 324 Thubert helped clarify the history of RPL's use of ICMP. We are 325 grateful for feedback from Joe Clarke and Wen Zhang. 327 8. Informative references 329 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 330 RFC 792, September 1981. 332 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 333 Values In the Internet Protocol and Related Headers", 334 BCP 37, RFC 2780, March 2000. 336 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 337 Message Protocol (ICMPv6) for the Internet Protocol 338 Version 6 (IPv6) Specification", RFC 4443, March 2006. 340 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 341 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 342 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 343 Lossy Networks", RFC 6550, March 2012. 345 [RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some 346 ICMPv4 Message Types", RFC 6918, April 2013. 348 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 349 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 350 April 2007. 352 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 353 Extensions for Multiprotocol Label Switching", RFC 4950, 354 August 2007. 356 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 357 Rivers, "Extending ICMP for Interface and Next-Hop 358 Identification", RFC 5837, April 2010. 360 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 361 Router Control Plane", RFC 6192, March 2011. 363 [I-D.ietf-opsawg-oam-overview] 364 Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 365 Weingarten, "An Overview of Operations, Administration, 366 and Maintenance (OAM) Mechanisms", 367 draft-ietf-opsawg-oam-overview-09 (work in progress), 368 July 2013. 370 [1] 372 Authors' Addresses 374 Melinda Shore 375 No Mountain Software 376 PO Box 16271 377 Two Rivers, AK 99716 378 US 380 Phone: +1 907 322 9522 381 Email: melinda.shore@nomountain.net 383 Carlos Pignataro 384 Cisco Systems, Inc. 385 7200-12 Kit Creek Road 386 Research Triangle Park, NC 27709 387 US 389 Email: cpignata@cisco.com