-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-shore-icmp-aup-02.xml
330 lines (292 loc) · 14 KB
/
draft-shore-icmp-aup-02.xml
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
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="no"?>
<!DOCTYPE rfc
SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<rfc ipr='trust200902' docName='draft-shore-icmp-aup-02' category='bcp'>
<front>
<title abbrev='ICMP AUP'>
An Acceptable Use Policy for New ICMP Types and Codes
</title>
<author initials='M.' surname='Shore' fullname='Melinda Shore'>
<organization>No Mountain Software</organization>
<address>
<postal>
<street>PO Box 16271</street>
<city>Two Rivers</city>
<region>AK</region>
<code>99716</code>
<country>US</country>
</postal>
<phone>+1 907 322 9522</phone>
<email>[email protected]</email>
</address>
</author>
<author initials='C.' surname='Pignataro' fullname='Carlos Pignataro'>
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200-12 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date month='February' year='2013' />
<area>Operations</area>
<abstract>
<t>Some recent proposals to add new Internet Control Message
Protocol (ICMP) types and/or codes
have highlighted a need to describe policies for when adding
new features to ICMP is desirable and when it is not. In
this document we provide a basic description of ICMP's
role in the IP stack and some guidelines for the future.</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>There have been some recent proposals to add new message
types and codes to ICMP, including <xref target='RFC792'>ICMPv4</xref>
and <xref target='RFC4443'>ICMPv6</xref>. Not all
of these proposals are consistent with the design and intent
of ICMP, and so we attempt to lay out a description of when
(and when not) to move functionality into ICMP.</t>
<t>This document is the result of discussions among ICMP
experts within the OPS area's
<eref target='https://svn.tools.ietf.org/area/ops/trac/wiki/TIG_DIAGNOSTICS'>IP
Diagnostics Technical Interest Group</eref> and concerns
expressed by the OPS area leadership.</t>
</section>
<section title='Acceptable use policy' anchor='aup'>
<t>In this document we describe a proposed acceptable use
policy for new ICMP message types and codes, and provide
some background behind the proposed policy.</t>
<t>In summary, we propose that any future message
types added to ICMP should be limited to two broad
categories:</t>
<t><list style='numbers'>
<t>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</t>
<t>to discover on-link routers and hosts</t>
</list></t>
<section title='Classification of existing message types'>
<t>This section provides a rough breakdown of existing message
types according to the taxonomy described in <xref target='aup' />.</t>
<t><list>
<t>IPV4 forwarding plane anomaly reporting</t>
<t><list style='hanging'>
<t hangText='3: '>Destination unreachable</t>
<t hangText='4: '>Source quench (deprecated)</t>
<t hangText='5: '>Redirect</t>
<t hangText='6: '>Alternate host address</t>
<t hangText='11 '>Time exceeded</t>
<t hangText='12 '>Parameter problem</t>
<t hangText='31: '>Datagram converson error</t>
<t hangText='32: '>Mobile host redirect</t>
<t hangText='41: '>ICMP messages utilized by experimental
mobility protocols, such as Seamoby</t>
</list></t>
<t>IPv4 router or host discovery</t>
<t><list style='hanging'>
<t hangText='0: '>Echo reply</t>
<t hangText='8: '>Echo</t>
<t hangText='9: '>Router advertisement</t>
<t hangText='10: '> Router solicitation</t>
<t hangText='13: '> Timestamp</t>
<t hangText='14: '> Timestamp reply</t>
<t hangText='15: '> Information request</t>
<t hangText='16: '> Information reply</t>
<t hangText='17: '> Address mask request</t>
<t hangText='18: '> Address mask reply</t>
<t hangText='30: '> Traceroute</t>
<t hangText='33: '> IPv6 Where-Are-You</t>
<t hangText='34: '> IPv6 I-Am-Here</t>
<t hangText='35: '> Mobile registration request</t>
<t hangText='36: '> Mobile registration reply</t>
<t hangText='37: '> Domain name request</t>
<t hangText='38: '> Domain name reply</t>
<t hangText='39: '> SKIP</t>
<t hangText='40: '> Photuris</t>
<t hangText='41: '> ICMP messages utilized by experimental
mobility protocols, such as Seamoby</t>
</list></t>
<t>IPv6 forwarding plane anomaly reporting</t>
<t><list style='hanging'>
<t hangText='1: '>Destination unreachable</t>
<t hangText='2: '>Packet too big</t>
<t hangText='3: '>Time exceeded</t>
<t hangText='4: '>Parameter problem</t>
<t hangText='137: '>Redirect message</t>
<t hangText='150: '>ICMP messages utilized by experimental
mobility protocols, such as Seamoby</t>
</list></t>
<t>IPv6 router or host discovery</t>
<t><list style='hanging'>
<t hangText='128: '>Echo request</t>
<t hangText='129: '>Echo reply</t>
<t hangText='130: '>Multicast listener query</t>
<t hangText='131: '>Multicast listener report</t>
<t hangText='132: '>Multicast listener done</t>
<t hangText='133: '>Router solicitation</t>
<t hangText='134: '>Router advertisement</t>
<t hangText='135: '>Neighbor solicitation</t>
<t hangText='136: '>Neighbor advertisement</t>
<t hangText='138: '>Router renumbering</t>
<t hangText='139: '>ICMP node information query</t>
<t hangText='140: '>ICMP node information response</t>
<t hangText='141: '>Inverse neighbor discovery solicitation message</t>
<t hangText='142: '>Inverse neighbor discovery advertisement message</t>
<t hangText='143: '>Version 2 multicast listener report</t>
<t hangText='144: '>Home agent address discovery request message</t>
<t hangText='145: '>Home agent address discovery reply message</t>
<t hangText='146: '>Mobile prefix solicitation</t>
<t hangText='147: '>Mobile prefix advertisement </t>
<t hangText='148: '>Certification path solicitation message</t>
<t hangText='149: '>Certification path advertisement message</t>
<t hangText='150: '>ICMP messages utilized by experimental
mobility protocols, such as Seamoby</t>
<t hangText='151: '>Multicast router advertisement</t>
<t hangText='152: '>Multicast router solicitation</t>
<t hangText='153: '>Multicast router termination</t>
<t hangText='154: '>FMIPv6 messages</t>
<t hangText='155: '>RPL control message</t>
</list></t>
</list></t>
<section title="A few notes on RPL">
<t>RPL, the IPv6 Routing protocol for low-power and
lossy networks (see <xref target='RFC6550' />)
appears to be
something of an outlier among the existing ICMP
message types, as the expansion of its acronym appears to be an actual routing
protocol using ICMP for transport.</t>
<t>This should be considered anomalous and is not a
model for future ICMP message types. Our
understanding is that the working group initially
defined a discovery protocol extending existing
ICMPv6 ND messages before moving to its own
native ICMP type.</t>
</section>
</section> <!-- classification of existing message types -->
</section> <!-- acceptable use policy -->
<section title="ICMP's role in the internet">
<t>ICMP was originally intended to be a mechanism for routers
to report error conditions back to hosts <xref target='RFC792' />.
The word "control" in the protocol name did not describe
ICMP's function (i.e. it did not "control" the internet), but
rather that it was used to communicate about the control
functions in the internet. For example, even though ICMP
included a redirect message type, it was and is not used as a
routing protocol.</t>
<t>Most likely because of the presence of the word
"control" in the protocol name, ICMP is often
understood to be a control protocol, borrowing some
terminology from circuit networks and the PSTN. That
is probably not correct - it might be more correct to
describe it as being closer to a management plane
protocol, given the data plane/control plane/
management plane taxonomy often used in describing
telephony protocols. However, layering in IP networks
is not very clean and there's often some intermingling
of function that can tend to lead to confusion about
where to place new functions.</t>
<t>In following sections we provide some background on the differences
between control and management traffic.</t>
</section>
<section title='Management vs. control'>
<t>In this section we attempt to draw a distinction
between management and control planes, acknowledging
in advance that this may serve to muddle the
differences even further. Ultimately the difference
may not matter that much for the purpose of creating a
policy for adding new types to ICMP, but because that
terminology has become ubiquitous, even in IETF
discussions, and because it has come up in prior
discussions of ICMP policies, it seems worthwhile
to take a few paragraph to describe what they are
and what they are not.</t>
<t>The terms "management plane" and "control plane"
came into use to describe one aspect of layering in
telecommunications networks. It is particularly
important, in the context of this discussion, to understand
that "control plane" in telecomm networks almost always
refers to 'signaling,' or call control and network
control information. This includes "call"
establishment and teardown, route establishment and
teardown, requesting QoS or other parameters, and so
on. </t>
<t>"Management," on the other hand, tends to fall under the
rubric "OAM," or "Operations, Administration, and Management."
typical functions include fault management and performance
monitoring (Service Level Agreement [SLA] compliance),
discovery, etc.</t>
</section> <!-- management vs control -->
<t>The correct answer to the question of where ICMP fits into
the management/control/data taxonomy is that it doesn't,
at least not neatly. While some of the message types
are unambiguously management message (ICMP type 3, or
"unreachable" messages), others are less clearly
identifiable. For example, the "redirect" (ICMP type 5)
message can be construed to contain control (in this
case, routing) information, even though it is in some
very real sense an error message.</t>
<t>At this time,
<list style='symbols'>
<t>there are many, many other protocols that can be (and
are) used for control traffic, whether they're routing
protocols, telephony signaling protocols, QoS protocols,
middlebox protocols, AAA protocols, etc.</t>
<t>the transport characteristics needed by control traffic
can be incompatible with the ICMP protocol standard --
for example, they may require reliable delivery, very
large payloads, or have security requirements that cannot
be met.</t>
</list>
and because of this we propose that any future message
types added to ICMP must conform to the policy proposed in
<xref target='aup' />. ICMP should not be used as a routing
or network management protocol.</t>
<section title='Security considerations'>
<t>This document attempts to describe 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, specific security considerations
are outside the scope of this paper.</t>
</section> <!-- security considerations -->
<section title='IANA considerations'>
<t>There are no actions required by IANA.</t>
</section>
<section title='Acknowledgments'>
<t>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.</t>
</section> <!-- acknowledgements -->
</middle>
<back>
<references title='Informative references'>
<reference anchor="RFC792">
<front>
<title>INTERNET CONTROL MESSAGE PROTOCOL</title>
<author initials="J" surname="Postel" fullname="J. Postel">
<organization>ISI</organization>
</author>
<date month="September" year="1981" />
</front>
<seriesInfo name="RFC" value="792" />
</reference>
<?rfc include='reference.RFC.4443.xml'?>
<?rfc include="reference.RFC.6550.xml"?>
</references>
</back>
</rfc>