idnits 2.17.1 draft-shore-icmp-aup-07.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 (December 5, 2013) is 3794 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: June 8, 2014 Cisco Systems, Inc. 6 December 5, 2013 8 An Acceptable Use Policy for New ICMP Types and Codes 9 draft-shore-icmp-aup-07 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 June 8, 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 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 attempt to lay out a 75 description of 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 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 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 are not advisable. While ICMP's role is not to 106 be a general-purpose network management protocol, it does have a role 107 to play in conveying dynamic information about a network. 109 2.1. Classification of existing message types 111 This section provides a rough breakdown of existing message types 112 according to the taxonomy described in Section 2 at the time of 113 publication. 115 IPv4 forwarding plane anomaly reporting: 117 3: Destination unreachable 118 4: Source quench (deprecated) 119 5: Redirect 120 6: Alternate host address (deprecated) 121 11: Time exceeded 122 12: Parameter problem 123 31: Datagram conversion error (deprecated) 124 32: Mobile host redirect (deprecated) 125 41: ICMP messages utilized by experimental mobility protocols, 126 such as Seamoby 128 IPv4 router or host discovery: 130 0: Echo reply 131 8: Echo 132 9: Router advertisement 133 10: Router solicitation 134 13: Timestamp 135 14: Timestamp reply 136 15: Information request (deprecated) 137 16: Information reply (deprecated) 138 17: Address mask request (deprecated) 139 18: Address mask reply (deprecated) 140 30: Traceroute (deprecated) 141 33: IPv6 Where-Are-You (deprecated) 142 34: IPv6 I-Am-Here (deprecated) 143 35: Mobile registration request (deprecated) 144 36: Mobile registration reply (deprecated) 145 37: Domain name request (deprecated) 146 38: Domain name reply (deprecated) 147 39: SKIP (deprecated) 148 40: Photuris 149 41: ICMP messages utilized by experimental mobility protocols, 150 such as Seamoby 152 Please note that some ICMP message types were formally deprecated by 153 [RFC6918]. 155 IPv6 forwarding plane anomaly reporting: 157 1: Destination unreachable 158 2: Packet too big 159 3: Time exceeded 160 4: Parameter problem 161 137: Redirect message 162 150: ICMP messages utilized by experimental mobility protocols, 163 such as Seamoby 165 IPv6 router or host discovery: 167 128: Echo request 168 129: Echo reply 169 130: Multicast listener query 170 131: Multicast listener report 171 132: Multicast listener done 172 133: Router solicitation 173 134: Router advertisement 174 135: Neighbor solicitation 175 136: Neighbor advertisement 176 138: Router renumbering 177 139: ICMP node information query 178 140: ICMP node information response 179 141: Inverse neighbor discovery solicitation message 180 142: Inverse neighbor discovery advertisement message 181 143: Version 2 multicast listener report 182 144: Home agent address discovery request message 183 145: Home agent address discovery reply message 184 146: Mobile prefix solicitation 185 147: Mobile prefix advertisement 186 148: Certification path solicitation message 187 149: Certification path advertisement message 188 150: ICMP messages utilized by experimental mobility protocols, 189 such as Seamoby 190 151: Multicast router advertisement 191 152: Multicast router solicitation 192 153: Multicast router termination 193 154: FMIPv6 messages 194 155: RPL control message 196 2.1.1. A few notes on RPL 198 RPL, the IPv6 Routing protocol for low-power and lossy networks (see 199 [RFC6550]) appears to be something of an outlier among the existing 200 ICMP message types, as the expansion of its acronym appears to be an 201 actual routing protocol using ICMP for transport. 203 This should be considered anomalous and is not a model for future 204 ICMP message types. Our understanding is that the working group 205 initially defined a discovery protocol extending existing ICMPv6 206 Neighbor Discovery messages before moving to its own native ICMP 207 type. 209 It is typically the case that routing protocols have transport 210 requirements that are not met by ICMP. For example, there will be 211 reliability guarantees and security guarantees that are not provided 212 by ICMP, forcing protocol developers to design their own mechanisms. 213 Given the availability of other IETF standard transports for routing, 214 this reinvention should be avoided. 216 2.2. Extending ICMP 218 ICMP multi-part messages are specified in [RFC4884] by defining an 219 extension mechanism for selected ICMP messages. This mechanism 220 addresses a fundamental problem in ICMP extensibility. An ICMP 221 multi-part message carries all of the information that ICMP messages 222 carried previously, as well as additional information that 223 applications may require. 225 Some currently defined ICMP extensions include ICMP extensions for 226 Multiprotocol Label Switching [RFC4950] and ICMP extensions for 227 interface and next-hop identification [RFC5837]. 229 Extensions to ICMP should follow [RFC4884]. 231 2.3. ICMPv4 vs. ICMPv6 233 Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6 234 routers, IPv6-capable security gateways, and IPv6-capable firewalls 235 normally support administrator configuration of how specific ICMPv6 236 message types are handled. By contrast, deployed IPv4 routers, IPv4- 237 capable security gateways, and IPv4-capable firewalls are less likely 238 to allow an administrator to configure how specific ICMPv4 message 239 types are handled. So, at present, ICMPv6 messages usually have a 240 higher probability of travelling end-to-end than ICMPv4 messages. 242 3. ICMP's role in the internet 244 ICMP was originally intended to be a mechanism for routers to report 245 error conditions back to hosts in ICMPv4 [RFC0792], and ICMPv6 246 [RFC4443] is modeled after it. The word "control" in the protocol 247 name did not describe ICMP's function (i.e. it did not "control" the 248 internet), but rather that it was used to communicate about the 249 control functions in the internet. For example, even though ICMP 250 included a redirect message type that affects routing behavior in the 251 context of a LAN segment, it was and is not used as a generic routing 252 protocol. 254 Most likely because of the presence of the word "control" in the 255 protocol name, ICMP is often understood to be a control protocol, 256 borrowing some terminology from circuit networks and the PSTN. That 257 is probably not correct - it might be more correct to describe it as 258 being closer to a management plane protocol, given the data plane/ 259 control plane/ management plane taxonomy often used in describing 260 telephony protocols. However, layering in IP networks is not very 261 clean and there's often some intermingling of function that can tend 262 to lead to confusion about where to place new functions. 264 In following sections we provide some background on the differences 265 between control and management traffic. 267 4. Management vs. control 269 In this section we attempt to draw a distinction between management 270 and control planes, acknowledging in advance that this may serve to 271 muddle the differences even further. Ultimately the difference may 272 not matter that much for the purpose of creating a policy for adding 273 new types to ICMP, but because the terminology of "management and 274 control planes" has become ubiquitous, even in IETF discussions, and 275 because it has come up in prior discussions of ICMP policies, it 276 seems worthwhile to take a few paragraph to describe what management 277 and control plane are and what they are not. 279 The terms "management plane" and "control plane" came into use to 280 describe one aspect of layering in telecommunications networks. 281 "Management plane" is described in [I-D.ietf-opsawg-oam-overview], 282 and "control plane" is defined in [RFC6192]. 284 It is particularly important, in the context of this discussion, to 285 understand that "control plane" in telecommunications networks almost 286 always 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 other similar artifacts. 291 "Management," on the other hand, involves an exchange between a 292 management application and managed entities such as network nodes, 293 and includes "inline management" and "management" per se. Typical 294 "inline management" functions include fault management and 295 performance monitoring (Service Level Agreement (SLA) compliance), 296 discovery, and typical "management" include protocols such as SNMP 297 and NETCONF. 299 The correct answer to the question of where ICMP fits into the 300 management/control/data taxonomy is that it doesn't, at least not 301 neatly. While some of the message types are unambiguously management 302 messages, at least within the narrow confines of a management/control 303 dichotomy (ICMP type 3, or "unreachable" messages), others are less 304 clearly identifiable. For example, the "redirect" (ICMP type 5) 305 message can be construed to contain control (in this case, routing) 306 information, even though it is in some very real sense an error 307 message. 309 At this time, 310 o there are plethora of other protocols that can be (and are) used 311 for control traffic, whether they're routing protocols, telephony 312 signaling protocols, QoS protocols, middlebox protocols, AAA 313 protocols, etc. 314 o the transport characteristics needed by control traffic can be 315 incompatible with the ICMP protocol standard -- for example, they 316 may require reliable delivery, very large payloads, or have 317 security requirements that cannot be met. 318 and because of this we propose that any future message types added to 319 ICMP should 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, this 327 recommendation presents no new security considerations. 329 From a security perspective, ICMP plays a part in the Photuris 330 protocol. But more generally, ICMP is not a secure protocol, and 331 does not include features to be used to discover network security 332 parameters or to report on network security anomalies in the 333 forwarding plane. 335 6. IANA considerations 337 There are no actions required by IANA. 339 7. Acknowledgments 341 This document was originally proposed by, and received substantial 342 review and suggestions from, Ron Bonica. Discussions with Pascal 343 Thubert helped clarify the history of RPL's use of ICMP. We are 344 grateful for feedback from Joe Clarke and Wen Zhang. 346 8. Informative references 348 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 349 RFC 792, September 1981. 351 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 352 Values In the Internet Protocol and Related Headers", 353 BCP 37, RFC 2780, March 2000. 355 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 356 Message Protocol (ICMPv6) for the Internet Protocol 357 Version 6 (IPv6) Specification", RFC 4443, March 2006. 359 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 360 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 361 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 362 Lossy Networks", RFC 6550, March 2012. 364 [RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some 365 ICMPv4 Message Types", RFC 6918, April 2013. 367 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 368 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 369 April 2007. 371 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP 372 Extensions for Multiprotocol Label Switching", RFC 4950, 373 August 2007. 375 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 376 Rivers, "Extending ICMP for Interface and Next-Hop 377 Identification", RFC 5837, April 2010. 379 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 380 Router Control Plane", RFC 6192, March 2011. 382 [I-D.ietf-opsawg-oam-overview] 383 Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 384 Weingarten, "An Overview of Operations, Administration, 385 and Maintenance (OAM) Data Plane Tools", 386 draft-ietf-opsawg-oam-overview-10 (work in progress), 387 October 2013. 389 [1] 391 Authors' Addresses 393 Melinda Shore 394 No Mountain Software 395 PO Box 16271 396 Two Rivers, AK 99716 397 US 399 Phone: +1 907 322 9522 400 Email: melinda.shore@nomountain.net 402 Carlos Pignataro 403 Cisco Systems, Inc. 404 7200-12 Kit Creek Road 405 Research Triangle Park, NC 27709 406 US 408 Email: cpignata@cisco.com