1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Internet Engineering Task Force (IETF) M. Shore
Request for Comments: 7279 No Mountain Software
BCP: 189 C. Pignataro
Category: Best Current Practice Cisco Systems, Inc.
ISSN: 2070-1721 May 2014
<span class="h1">An Acceptable Use Policy for New ICMP Types and Codes</span>
Abstract
In this document we provide a basic description of ICMP's role in the
IP stack and some guidelines for future use.
This document is motivated by concerns about lack of clarity
concerning when to add new Internet Control Message Protocol (ICMP)
types and/or codes. These concerns have highlighted a need to
describe policies for when adding new features to ICMP is desirable
and when it is not.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7279">http://www.rfc-editor.org/info/rfc7279</a>.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Shore & Pignataro Best Current Practice [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7279">RFC 7279</a> ICMP AUP May 2014</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Acceptable Use Policy . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2.1">2.1</a>. Classification of Existing Message Types . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1.1">2.1.1</a>. ICMP Use as a Routing Protocol . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.1.2">2.1.2</a>. A Few Notes on RPL . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.2">2.2</a>. Applications Using ICMP . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.3">2.3</a>. Extending ICMP . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.4">2.4</a>. ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3">3</a>. ICMP's Role in the Internet . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6.1">6.1</a>. Normative references . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6.2">6.2</a>. Informative references . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
There has been some recent concern expressed about a lack of clarity
around when new message types and codes should be added to ICMP
(including ICMPv4 [<a href="./rfc0792" title=""Internet Control Message Protocol"">RFC0792</a>] and ICMPv6 [<a href="./rfc4443" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">RFC4443</a>]). We lay out a
policy regarding when (and when not) to move functionality into ICMP.
This document is the result of discussions among ICMP experts within
the Operations and Management (OPS) area's IP Diagnostics Technical
Interest Group [<a href="#ref-DIAGNOSTICS">DIAGNOSTICS</a>] and concerns expressed by the OPS area
leadership.
Note that this document does not supercede the "IANA Allocation
Guidelines For Values In the Internet Protocol and Related Headers"
[<a href="./rfc2780" title=""IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers"">RFC2780</a>], which specifies best practices and processes for the
allocation of values in the IANA registries but does not describe the
policies to be applied in the standards process.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Acceptable Use Policy</span>
In this document, we describe an acceptable use policy for new ICMP
message types and codes, and provide some background about the
policy.
<span class="grey">Shore & Pignataro Best Current Practice [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7279">RFC 7279</a> ICMP AUP May 2014</span>
In summary, any future message types added to ICMP should be limited
to two broad categories:
1. to inform a datagram's originator that a forwarding plane anomaly
has been encountered downstream. The datagram originator must be
able to determine whether or not the datagram was discarded by
examining the ICMP message.
2. to discover and convey dynamic information about a node (other
than information usually carried in routing protocols), to
discover and convey network-specific parameters, and to discover
on-link routers and hosts.
Normally, ICMP SHOULD NOT be used to implement a general-purpose
routing or network management protocol. However, ICMP does have a
role to play in conveying dynamic information about a network, which
would belong in category 2 above.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Classification of Existing Message Types</span>
This section provides a rough breakdown of existing message types
according to the taxonomy described in <a href="#section-2">Section 2</a> at the time of
publication.
IPv4 forwarding plane anomaly reporting:
3: Destination Unreachable
4: Source Quench (Deprecated)
6: Alternate Host Address (Deprecated)
11: Time Exceeded
12: Parameter Problem
31: Datagram Conversion Error (Deprecated)
IPv4 router or host discovery:
0: Echo Reply
5: Redirect
8: Echo
9: Router Advertisement
<span class="grey">Shore & Pignataro Best Current Practice [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7279">RFC 7279</a> ICMP AUP May 2014</span>
10: Router Solicitation
13: Timestamp
14: Timestamp Reply
15: Information Request (Deprecated)
16: Information Reply (Deprecated)
17: Address Mask Request (Deprecated)
18: Address Mask Reply (Deprecated)
30: Traceroute (Deprecated)
32: Mobile Host Redirect (Deprecated)
33: IPv6 Where-Are-You (Deprecated)
34: IPv6 I-Am-Here (Deprecated)
35: Mobile Registration Request (Deprecated)
36: Mobile Registration Reply (Deprecated)
37: Domain Name Request (Deprecated)
38: Domain Name Reply (Deprecated)
39: SKIP (Deprecated)
40: Photuris
41: ICMP messages utilized by experimental mobility protocols
such as Seamoby
Please note that some ICMP message types were formally deprecated by
[<a href="./rfc6918" title=""Formally Deprecating Some ICMPv4 Message Types"">RFC6918</a>].
IPv6 forwarding plane anomaly reporting:
1: Destination Unreachable
2: Packet Too Big
<span class="grey">Shore & Pignataro Best Current Practice [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7279">RFC 7279</a> ICMP AUP May 2014</span>
3: Time Exceeded
4: Parameter Problem
150: ICMP messages utilized by experimental mobility protocols
such as Seamoby
IPv6 router or host discovery:
128: Echo Request
129: Echo Reply
130: Multicast Listener Query
131: Multicast Listener Report
132: Multicast Listener Done
133: Router Solicitation
134: Router Advertisement
135: Neighbor Solicitation
136: Neighbor Advertisement
137: Redirect Message
138: Router Renumbering
139: ICMP Node Information Query
140: ICMP Node Information Response
141: Inverse Neighbor Discovery Solicitation Message
142: Inverse Neighbor Discovery Advertisement Message
143: Version 2 Multicast Listener Report
144: Home Agent Address Discovery Request Message
145: Home Agent Address Discovery Reply Message
146: Mobile Prefix Solicitation
<span class="grey">Shore & Pignataro Best Current Practice [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7279">RFC 7279</a> ICMP AUP May 2014</span>
147: Mobile Prefix Advertisement
148: Certification Path Solicitation Message
149: Certification Path Advertisement Message
150: ICMP messages utilized by experimental mobility protocols
such as Seamoby
151: Multicast Router Advertisement
152: Multicast Router Solicitation
153: Multicast Router Termination
154: FMIPv6 Messages
155: RPL Control Message
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. ICMP Use as a Routing Protocol</span>
As mentioned in <a href="#section-2">Section 2</a>, using ICMP as a general-purpose routing or
network management protocol is not advisable and SHOULD NOT be used
that way.
ICMP has a role in the Internet as an integral part of the IP layer;
it is not as a routing protocol or as a transport protocol for other
layers including routing information. From a more pragmatic
perspective, some of the key characteristics of ICMP make it a less-
than-ideal choice for a routing protocol. These key characteristics
include that ICMP is frequently filtered, is not authenticated, and
is easily spoofed. In addition, specialist hardware processing of
ICMP would disrupt the deployment of an ICMP-based routing or
management protocol.
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. A Few Notes on RPL</span>
RPL, the IPv6 routing protocol for low-power and lossy networks (see
[<a href="./rfc6550" title=""RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"">RFC6550</a>]) uses ICMP as a transport. In this regard, it is an
exception among the ICMP message types. Note that, although RPL is
an IP routing protocol, it is not deployed on the general Internet;
it is limited to specific, contained networks.
This should be considered anomalous and is not a model for future
ICMP message types. That is, ICMP is not intended as a transport for
other protocols and SHOULD NOT be used in that way in future
specifications. In particular, while it is adequate to use ICMP as a
discovery protocol, it does not extend to full routing capabilities.
<span class="grey">Shore & Pignataro Best Current Practice [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7279">RFC 7279</a> ICMP AUP May 2014</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Applications Using ICMP</span>
Some applications make use of ICMP error notifications, or even
deliberately create anomalous conditions in order to elicit ICMP
messages. These ICMP messages are then used to generate feedback to
the higher layer. Some of these applications include some of the
most widespread examples, such as PING, TRACEROUTE, and Path MTU
Discovery (PMTUD). These uses are considered acceptable because they
use existing ICMP message types and do not change ICMP functionality.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Extending ICMP</span>
ICMP multi-part messages are specified in [<a href="./rfc4884" title=""Extended ICMP to Support Multi-Part Messages"">RFC4884</a>] by defining an
extension mechanism for selected ICMP messages. This mechanism
addresses a fundamental problem in ICMP extensibility. An ICMP
multi-part message carries all of the information that ICMP messages
carried previously, as well as additional information that
applications may require.
Some currently defined ICMP extensions include ICMP extensions for
Multiprotocol Label Switching [<a href="./rfc4950" title=""ICMP Extensions for Multiprotocol Label Switching"">RFC4950</a>] and ICMP extensions for
interface and next-hop identification [<a href="./rfc5837" title=""Extending ICMP for Interface and Next-Hop Identification"">RFC5837</a>].
Extensions to ICMP SHOULD follow the requirements provided in
[<a href="./rfc4884" title=""Extended ICMP to Support Multi-Part Messages"">RFC4884</a>].
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. ICMPv4 vs. ICMPv6</span>
Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6
routers, IPv6-capable security gateways, and IPv6-capable firewalls
normally support administrator configuration of how specific ICMPv6
message types are handled. By contrast, deployed IPv4 routers,
IPv4-capable security gateways, and IPv4-capable firewalls are less
likely to allow an administrator to configure how specific ICMPv4
message types are handled. So, at present, ICMPv6 messages usually
have a higher probability of travelling end-to-end than ICMPv4
messages.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. ICMP's Role in the Internet</span>
ICMP was originally intended to be a mechanism for gateways or
destination hosts to report error conditions back to source hosts in
ICMPv4 [<a href="./rfc0792" title=""Internet Control Message Protocol"">RFC0792</a>]; ICMPv6 [<a href="./rfc4443" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">RFC4443</a>] is modeled after it. ICMP is also
used to perform IP-layer functions, such as diagnostics (e.g., PING).
ICMP is defined to be an integral part of IP and must be implemented
by every IP module. This is true for ICMPv4 as an integral part of
IPv4 (see the Introduction of [<a href="./rfc0792" title=""Internet Control Message Protocol"">RFC0792</a>]), and for ICMPv6 as an
<span class="grey">Shore & Pignataro Best Current Practice [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7279">RFC 7279</a> ICMP AUP May 2014</span>
integral part of IPv6 (see <a href="./rfc4443#section-2">Section 2 of [RFC4443]</a>). When first
defined, ICMP messages were thought of as IP messages that didn't
carry any higher-layer data. It could be conjectured that the term
"control" was used because ICMP messages were not "data" messages.
The word "control" in the protocol name did not describe ICMP's
function (i.e., it did not "control" the Internet); rather, it was
used to communicate about the control functions in the Internet. For
example, even though ICMP included a redirect message type that
affects routing behavior in the context of a LAN segment, it was not
and is not used as a generic routing protocol.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document describes a high-level policy for adding ICMP types and
codes. While special attention must be paid to the security
implications of any particular new ICMP type or code, this
recommendation presents no new security considerations.
From a security perspective, ICMP plays a part in the Photuris
protocol [<a href="./rfc2521" title=""ICMP Security Failures Messages"">RFC2521</a>]. But more generally, ICMP is not a secure
protocol and does not include features to be used to discover network
security parameters or to report on network security anomalies in the
forwarding plane.
Additionally, new ICMP functionality (e.g., ICMP extensions, or new
ICMP types or codes) needs to consider potential ways that ICMP can
be abused (e.g., Smurf IP DoS [<a href="#ref-CA-1998-01">CA-1998-01</a>]).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgments</span>
This document was originally proposed by, and received substantial
review and suggestions from, Ron Bonica. Discussions with Pascal
Thubert helped clarify the history of RPL's use of ICMP. We are very
grateful for the review, feedback, and comments from Ran Atkinson,
Tim Chown, Joe Clarke, Adrian Farrel, Ray Hunter, Hilarie Orman, Eric
Rosen, JINMEI Tatuya, and Wen Zhang, which resulted in a much
improved document.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative references</span>
[<a id="ref-RFC0792">RFC0792</a>] Postel, J., "Internet Control Message Protocol", STD 5,
<a href="./rfc792">RFC 792</a>, September 1981.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="grey">Shore & Pignataro Best Current Practice [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7279">RFC 7279</a> ICMP AUP May 2014</span>
[<a id="ref-RFC4443">RFC4443</a>] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", <a href="./rfc4443">RFC 4443</a>, March 2006.
[<a id="ref-RFC4884">RFC4884</a>] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", <a href="./rfc4884">RFC 4884</a>,
April 2007.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative references</span>
[<a id="ref-CA-1998-01">CA-1998-01</a>]
CERT, "Smurf IP Denial-of-Service Attacks", CERT Advisory
CA-1998-01, January 1998,
<<a href="http://www.cert.org/advisories/CA-1998-01.html">http://www.cert.org/advisories/CA-1998-01.html</a>>.
[<a id="ref-DIAGNOSTICS">DIAGNOSTICS</a>]
"IP Diagnostics Technical Interest Group", ,
<<a href="https://svn.tools.ietf.org/area/ops/trac/wiki/TIG_DIAGNOSTICS">https://svn.tools.ietf.org/area/ops/trac/wiki/</a>
<a href="https://svn.tools.ietf.org/area/ops/trac/wiki/TIG_DIAGNOSTICS">TIG_DIAGNOSTICS</a>>.
[<a id="ref-RFC2521">RFC2521</a>] Karn, P. and W. Simpson, "ICMP Security Failures
Messages", <a href="./rfc2521">RFC 2521</a>, March 1999.
[<a id="ref-RFC2780">RFC2780</a>] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", <a href="https://www.rfc-editor.org/bcp/bcp37">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp37">37</a>, <a href="./rfc2780">RFC 2780</a>, March 2000.
[<a id="ref-RFC4950">RFC4950</a>] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
Extensions for Multiprotocol Label Switching", <a href="./rfc4950">RFC 4950</a>,
August 2007.
[<a id="ref-RFC5837">RFC5837</a>] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.
Rivers, "Extending ICMP for Interface and Next-Hop
Identification", <a href="./rfc5837">RFC 5837</a>, April 2010.
[<a id="ref-RFC6550">RFC6550</a>] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", <a href="./rfc6550">RFC 6550</a>, March 2012.
[<a id="ref-RFC6918">RFC6918</a>] Gont, F. and C. Pignataro, "Formally Deprecating Some
ICMPv4 Message Types", <a href="./rfc6918">RFC 6918</a>, April 2013.
<span class="grey">Shore & Pignataro Best Current Practice [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7279">RFC 7279</a> ICMP AUP May 2014</span>
Authors' Addresses
Melinda Shore
No Mountain Software
PO Box 16271
Two Rivers, AK 99716
US
Phone: +1 907 322 9522
EMail: melinda.shore@nomountain.net
Carlos Pignataro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
EMail: cpignata@cisco.com
Shore & Pignataro Best Current Practice [Page 10]
</pre>
|
