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