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
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
|
<pre>Network Working Group R. Bonica
Request for Comments: 4884 Juniper Networks
Updates: <a href="./rfc792">792</a>, <a href="./rfc4443">4443</a> D. Gan
Category: Standards Track Consultant
D. Tappan
Consultant
C. Pignataro
Cisco Systems, Inc.
April 2007
<span class="h1">Extended ICMP to Support Multi-Part Messages</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document redefines selected ICMP messages to support multi-part
operation. A multi-part ICMP message carries all of the information
that ICMP messages carried previously, as well as additional
information that applications may require.
Multi-part messages are supported by an ICMP extension structure.
The extension structure is situated at the end of the ICMP message.
It includes an extension header followed by one or more extension
objects. Each extension object contains an object header and object
payload. All object headers share a common format.
This document further redefines the above mentioned ICMP messages by
specifying a length attribute. All of the currently defined ICMP
messages to which an extension structure can be appended include an
"original datagram" field. The "original datagram" field contains
the initial octets of the datagram that elicited the ICMP error
message. Although the original datagram field is of variable length,
the ICMP message does not include a field that specifies its length.
Therefore, in order to facilitate message parsing, this document
allocates eight previously reserved bits to reflect the length of the
"original datagram" field.
<span class="grey">Bonica, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
The proposed modifications change the requirements for ICMP
compliance. The impact of these changes on compliant implementations
is discussed, and new requirements for future implementations are
presented.
This memo updates <a href="./rfc792">RFC 792</a> and <a href="./rfc4443">RFC 4443</a>.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Summary of Changes to ICMP ......................................<a href="#page-4">4</a>
<a href="#section-4">4</a>. ICMP Extensibility ..............................................<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. ICMPv4 Destination Unreachable .............................<a href="#page-7">7</a>
<a href="#section-4.2">4.2</a>. ICMPv4 Time Exceeded .......................................<a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. ICMPv4 Parameter Problem ...................................<a href="#page-8">8</a>
<a href="#section-4.4">4.4</a>. ICMPv6 Destination Unreachable .............................<a href="#page-9">9</a>
<a href="#section-4.5">4.5</a>. ICMPv6 Time Exceeded .......................................<a href="#page-9">9</a>
<a href="#section-4.6">4.6</a>. ICMP Messages That Can Be Extended ........................<a href="#page-10">10</a>
<a href="#section-5">5</a>. Backwards Compatibility ........................................<a href="#page-10">10</a>
5.1. Classic Application Receives ICMP Message with
Extensions ................................................<a href="#page-12">12</a>
5.2. Non-Compliant Application Receives ICMP Message
with No Extensions ........................................<a href="#page-12">12</a>
5.3. Non-Compliant Application Receives ICMP Message
with Compliant Extensions .................................<a href="#page-13">13</a>
5.4. Compliant Application Receives ICMP Message with
No Extensions .............................................<a href="#page-14">14</a>
5.5. Compliant Application Receives ICMP Message with
Non-Compliant Extensions ..................................<a href="#page-14">14</a>
<a href="#section-6">6</a>. Interaction with Network Address Translation ...................<a href="#page-14">14</a>
<a href="#section-7">7</a>. The ICMP Extension Structure ...................................<a href="#page-15">15</a>
<a href="#section-8">8</a>. ICMP Extension Objects .........................................<a href="#page-16">16</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-16">16</a>
<a href="#section-10">10</a>. IANA Considerations ...........................................<a href="#page-17">17</a>
<a href="#section-11">11</a>. Acknowledgments ...............................................<a href="#page-17">17</a>
<a href="#section-12">12</a>. References ....................................................<a href="#page-17">17</a>
<a href="#section-12.1">12.1</a>. Normative References .....................................<a href="#page-17">17</a>
<a href="#section-12.2">12.2</a>. Informative References ...................................<a href="#page-17">17</a>
<span class="grey">Bonica, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document redefines selected 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>] messages to include an extension structure and a length
attribute. The extension structure supports multi-part ICMP
operation. Protocol designers can make an ICMP message carry
additional information by encoding that information in the extension
structure.
This document also addresses a fundamental problem in ICMP
extensibility. All of the ICMP messages addressed by this memo
include an "original datagram" field. The "original datagram" field
contains the initial octets of the datagram that elicited the ICMP
error message. Although the "original datagram" field is of variable
length, the ICMP message does not include a field that specifies its
length.
Application software infers the length of the "original datagram"
field from the total length of the ICMP message. If an extension
structure were appended to the message without adding a length
attribute for the "original datagram" field, the message would become
unparsable. Specifically, application software would not be able to
determine where the "original datagram" field ends and where the
extension structure begins. Therefore, this document proposes a
length attribute as well as an extension structure that is appended
to the ICMP message.
The current memo also addresses backwards compatibility with existing
ICMP implementations that either do not implement the extensions
defined herein or implement them without adding the required length
attributes. In particular, this document addresses backwards
compatibility with certain, widely deployed, MPLS-aware ICMPv4
implementations that send the extensions defined herein without
adding the required length attribute.
The current memo does not define any ICMP extension objects. It
defines only the extension header and a common header that all
extension objects share. [<a href="#ref-UNNUMBERED" title=""ICMP Extensions for Unnumbered Interfaces"">UNNUMBERED</a>], [<a href="#ref-ROUTING-INST" title=""ICMP Extensions for Routing Instances"">ROUTING-INST</a>], and
[<a href="#ref-MPLS-ICMP" title=""ICMP Extensions for MultiProtocol Label Switching"">MPLS-ICMP</a>] provide sample applications of the ICMP Extension Object.
The above mentioned memos share a common characteristic. They all
append information to the ICMP Time Expired message for consumption
by TRACEROUTE. In this case, as in many others, appending
information to the existing ICMP Time Expired Message is preferable
to defining a new message and emitting two messages whenever a packet
is dropped due to TTL expiration.
<span class="grey">Bonica, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
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-3" href="#section-3">3</a>. Summary of Changes to ICMP</span>
The following is a summary of changes to ICMP that are introduced by
this memo:
An ICMP Extension Structure MAY be appended to ICMPv4 Destination
Unreachable, Time Exceeded, and Parameter Problem messages.
An ICMP Extension Structure MAY be appended to ICMPv6 Destination
Unreachable, and Time Exceeded messages.
The above mentioned messages include an "original datagram" field,
and the message formats are updated to specify a length attribute
for the "original datagram" field.
When the ICMP Extension Structure is appended to an ICMP message
and that ICMP message contains an "original datagram" field, the
"original datagram" field MUST contain at least 128 octets.
When the ICMP Extension Structure is appended to an ICMPv4 message
and that ICMPv4 message contains an "original datagram" field, the
"original datagram" field MUST be zero padded to the nearest
32-bit boundary.
When the ICMP Extension Structure is appended to an ICMPv6 message
and that ICMPv6 message contains an "original datagram" field, the
"original datagram" field MUST be zero padded to the nearest
64-bit boundary.
ICMP messages defined in the future SHOULD indicate whether or not
they support the extension mechanism defined in this
specification. It is recommended that all new messages support
extensions.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. ICMP Extensibility</span>
<a href="./rfc792">RFC 792</a> defines the following ICMPv4 message types:
- Destination Unreachable
- Time Exceeded
<span class="grey">Bonica, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
- Parameter Problem
- Source Quench
- Redirect
- Echo Request/Reply
- Timestamp/Timestamp Reply
- Information Request/Information Reply
[<a id="ref-RFC1191">RFC1191</a>] reserves bits for the "Next-Hop MTU" field in the
Destination Unreachable message.
<a href="./rfc4443">RFC 4443</a> defines the following ICMPv6 message types:
- Destination Unreachable
- Packet Too Big
- Time Exceeded
- Parameter Problem
- Echo Request/Reply
Many ICMP messages are extensible as currently defined. Protocol
designers can extend ICMP messages by simply appending fields or data
structures to them.
However, the following ICMP messages are not extensible as currently
defined:
- ICMPv4 Destination Unreachable (type = 3)
- ICMPv4 Time Exceeded (type = 11)
- ICMPv4 Parameter Problem (type = 12)
- ICMPv6 Destination Unreachable (type = 1)
- ICMPv6 Packet Too Big (type = 2)
- ICMPv6 Time Exceeded (type = 3)
- ICMPv6 Parameter Problem (type = 4)
<span class="grey">Bonica, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
These messages contain an "original datagram" field which represents
the leading octets of the datagram to which the ICMP message is a
response. <a href="./rfc792">RFC 792</a> defines the "original datagram" field for ICMPv4
messages. In <a href="./rfc792">RFC 792</a>, the "original datagram" field includes the IP
header plus the next eight octets of the original datagram.
[<a href="./rfc1812" title=""Requirements for IP Version 4 Routers"">RFC1812</a>] extends the "original datagram" field to contain as many
octets as possible without causing the ICMP message to exceed the
minimum IPv4 reassembly buffer size (i.e., 576 octets). <a href="./rfc4443">RFC 4443</a>
defines the "original datagram" field for ICMPv6 messages. In <a href="./rfc4443">RFC</a>
<a href="./rfc4443">4443</a>, the "original datagram" field always contained as many octets
as possible without causing the ICMP message to exceed the minimum
IPv6 MTU (i.e., 1280 octets).
Unfortunately, the "original datagram" field lacks a length
attribute. Application software infers the length of this field from
the total length of the ICMP message. If an extension structure were
appended to the message without adding a length attribute for the
"original datagram" field, the message would become unparsable.
Specifically, application software would not be able to determine
where the "original datagram" field ends and where the extension
structure begins.
In order to solve this problem, this memo introduces an 8-bit length
attribute to the following ICMPv4 messages.
- Destination Unreachable (type = 3)
- Time Exceeded (type = 11)
- Parameter Problem (type = 12)
It also introduces an 8-bit length attribute to the following ICMPv6
messages.
- Destination Unreachable (type = 1)
- Time Exceeded (type = 3)
The length attribute MUST be specified when the ICMP Extension
Structure is appended to the above mentioned ICMP messages.
The length attribute represents the length of the "original datagram"
field. Space for the length attribute is claimed from reserved
octets, whose value was previously required to be zero.
For ICMPv4 messages, the length attribute represents 32-bit words.
When the length attribute is specified, the "original datagram" field
MUST be zero padded to the nearest 32-bit boundary. Because the
<span class="grey">Bonica, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
sixth octet of each of the impacted ICMPv4 messages was reserved for
future use, this octet was selected as the location of the length
attribute in ICMPv4.
For ICMPv6 messages, the length attribute represents 64-bit words.
When the length attribute is specified, the "original datagram" field
MUST be zero padded to the nearest 64-bit boundary. Because the
fifth octet of each of the impacted ICMPv6 messages was reserved for
future use, this octet was selected as the location of the length
attribute in ICMPv6.
In order to achieve backwards compatibility, when the ICMP Extension
Structure is appended to an ICMP message and that ICMP message
contains an "original datagram" field, the "original datagram" field
MUST contain at least 128 octets. If the original datagram did not
contain 128 octets, the "original datagram" field MUST be zero padded
to 128 octets. (See <a href="#section-5.1">Section 5.1</a> for rationale.)
The following sub-sections depict length attribute as it has been
introduced to selected ICMP messages.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. ICMPv4 Destination Unreachable</span>
Figure 1 depicts the ICMPv4 Destination Unreachable Message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | Next-Hop MTU* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ICMPv4 Destination Unreachable
The syntax and semantics of all fields are unchanged from <a href="./rfc792">RFC 792</a>.
However, a length attribute is added to the second word. The length
attribute represents length of the padded "original datagram" field,
measured in 32-bit words.
* The Next-Hop MTU field is not required in all cases. It is
depicted only to demonstrate that those bits are not available for
assignment in this memo.
<span class="grey">Bonica, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. ICMPv4 Time Exceeded</span>
Figure 2 depicts the ICMPv4 Time Exceeded Message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ICMPv4 Time Exceeded
The syntax and semantics of all fields are unchanged from <a href="./rfc792">RFC 792</a>,
except for a length attribute which is added to the second word. The
length attribute represents length of the padded "original datagram"
field, measured in 32-bit words.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. ICMPv4 Parameter Problem</span>
Figure 3 depicts the ICMPv4 Parameter Problem Message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ICMPv4 Parameter Problem
The syntax and semantics of all fields are unchanged from <a href="./rfc792">RFC 792</a>,
except for a length attribute which is added to the second word. The
length attribute represents length of the padded "original datagram"
field, measured in 32-bit words.
<span class="grey">Bonica, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. ICMPv6 Destination Unreachable</span>
Figure 4 depicts the ICMPv6 Destination Unreachable Message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [<a href="./rfc4443" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">RFC4443</a>] |
Figure 4: ICMPv6 Destination Unreachable
The syntax and semantics of all fields are unchanged from <a href="./rfc4443">RFC 4443</a>.
However, a length attribute is added to the second word. The length
attribute represents length of the padded "original datagram" field,
measured in 64-bit words.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. ICMPv6 Time Exceeded</span>
Figure 5 depicts the ICMPv6 Time Exceeded Message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [<a href="./rfc4443" title=""Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"">RFC4443</a>] |
Figure 5: ICMPv6 Time Exceeded
The syntax and semantics of all fields are unchanged from <a href="./rfc4443">RFC 4443</a>,
except for a length attribute which is added to the second word. The
length attribute represents length of the padded "original datagram"
field, measured in 64-bit words.
<span class="grey">Bonica, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. ICMP Messages That Can Be Extended</span>
The ICMP Extension Structure MAY be appended to messages of the
following types:
- ICMPv4 Destination Unreachable
- ICMPv4 Time Exceeded
- ICMPv4 Parameter Problem
- ICMPv6 Destination Unreachable
- ICMPv6 Time Exceeded
The ICMP Extension Structure MUST NOT be appended to any of the other
ICMP messages mentioned in <a href="#section-4">Section 4</a>. Extensions were not defined
for the ICMPv6 "Packet Too Big" and "Parameter Problem" messages
because these messages lack space for a length attribute.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Backwards Compatibility</span>
ICMP messages can be categorized as follows:
- Messages that do not include any ICMP extensions
- Messages that include non-compliant ICMP extensions
- Messages that includes compliant ICMP extensions
Any ICMP implementation can send a message that does not include
extensions. ICMP implementations produced prior to 1999 are not
known to send ICMP extensions.
Some ICMP implementations, produced between 1999 and the time of this
publication, may send a non-compliant version of ICMP extensions
described in this memo. Specifically, these implementations may
append the ICMP Extension Structure to the Time Exceeded and
Destination Unreachable messages. When they do this, they send
exactly 128 octets representing the original datagram, zero padding
if required. They also calculate checksums as described in this
document. However, they do not specify a length attribute to be
associated with the "original datagram" field.
It is assumed that ICMP implementations produced in the future will
send ICMP extensions that are compliant with this specification.
<span class="grey">Bonica, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
Likewise, applications that consume ICMP messages can be categorized
as follows:
- Classic applications
- Non-compliant applications
- Compliant applications
Classic applications do not parse extensions defined in this memo.
They are insensitive to the length attribute that is associated with
the "original datagram" field.
Non-compliant implementations parse the extensions defined in this
memo, but only in conjunction with the Time Expired and Destination
Unreachable messages. They require the "original datagram" field to
contain exactly 128 octets and are insensitive to the length
attribute that is associated with the "original datagram" field.
Non-compliant applications were produced between 1999 and the time of
publication of this memo.
Compliant applications comply fully with the specifications of this
document.
In order to demonstrate backwards compatibility, Table 1 describes
how members of each application category would parse each category of
ICMP message.
+----------------+----------------+----------------+----------------+
| | No Extensions | Non-compliant | Compliant |
| | | Extensions | Extensions |
+----------------+----------------+----------------+----------------+
| Classic | - | <a href="#section-5.1">Section 5.1</a> | <a href="#section-5.1">Section 5.1</a> |
| Application | | | |
| | | | |
| Non-compliant | <a href="#section-5.2">Section 5.2</a> | - | <a href="#section-5.3">Section 5.3</a> |
| Application | | | |
| | | | |
| Compliant | <a href="#section-5.4">Section 5.4</a> | <a href="#section-5.5">Section 5.5</a> | - |
| Application | | | |
+----------------+----------------+----------------+----------------+
Table 1
In the table above, cells that contain a dash represent the nominal
case and require no explanation. In the following sections, we
assume that the ICMP message type is "Time Exceeded".
<span class="grey">Bonica, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Classic Application Receives ICMP Message with Extensions</span>
When a classic application receives an ICMP message that includes
extensions, it will incorrectly interpret those extensions as being
part of the "original datagram" field. Fortunately, the extensions
are guaranteed to begin at least 128 octets beyond the beginning of
the "original datagram" field. So, only those ICMP applications that
process the 129th octet of the "original datagram" field will be
adversely effected. To date, only two applications falling into this
category have been identified, and the degree to which they are
effected is minimal.
Some TCP stacks, when they receive an ICMP message, verify the
checksum in the original datagram field [<a href="#ref-ATTACKS" title=""ICMP attacks against TCP"">ATTACKS</a>]. If the checksum
is incorrect, the TCP stack discards the ICMP message for security
reasons. If the trailing octets of the original datagram field are
overwritten by ICMP extensions, the TCP stack will discard an ICMP
message that it would not otherwise have discarded. The impact of
this issue is considered to be minimal because many ICMP messages are
discarded for other reasons (e.g., ICMP filtering, network
congestion, checksum was incorrect because original datagram field
was truncated.)
Another theoretically possible, but highly improbably scenario occurs
when ICMP extensions overwrite the portion of the original datagram
field that represents the TCP header, causing the TCP stack to
operate upon the wrong TCP connection. This scenario is highly
unlikely because it occurs only when the TCP header appears at or
beyond the 128th octet of the original datagram field and then only
when the extensions approximate a valid TCP header.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Non-Compliant Application Receives ICMP Message with No Extensions</span>
When a non-compliant ICMPv4 application receives a message that
contains no extensions, the application examines the total length of
the ICMPv4 message. If the total ICMPv4 message length is less than
the length of its IP header plus 144 octets, the application
correctly determines that the message does not contain any
extensions.
The 144-octet sum is derived from 8 octets for the first two words of
the ICMPv4 Time Exceeded message, 128 octets for the "original
datagram" field, 4 octets for the ICMP Extension Header, and 4 octets
for a single ICMP Object header. All of these octets would be
required if extensions were present.
<span class="grey">Bonica, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
If the ICMPv4 payload contains 144 octets or more, the application
must examine the 137th octet to determine whether it represents a
valid ICMPv4 Extension Header. In order to represent a valid
Extension Header, it must contain a valid version number and
checksum. If it does not contain a valid version number and
checksum, the application correctly determines that the message does
not contain any extensions.
Non-compliant applications assume that the ICMPv4 Extension Structure
begins on the 137th octet of the Time Exceeded message, after a
128-octet field representing the padded "original datagram" message.
It is possible that a non-compliant application will parse an ICMPv4
message incorrectly under the following conditions:
- the message does not contain extensions
- the original datagram field contains 144 octets or more
- selected octets of the original datagram field represent the
correct values for an extension header version number and
checksum
Although this is possible, it is very unlikely.
A similar analysis can be performed for ICMPv6. However, the numeric
constants would change as appropriate.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Non-Compliant Application Receives ICMP Message with Compliant</span>
<span class="h3"> Extensions</span>
When a non-compliant application receives a message that contains
compliant ICMP extensions, it will parse those extensions correctly
only if the "original datagram" field contains exactly 128 octets.
This is because non-compliant applications are insensitive to the
length attribute that is associated with the "original datagram"
field. (They assume its value to be 128.)
Provided that the entire ICMP message does not exceed the minimum
reassembly buffer size (576 octets for ICMPv4 or 1280 octets for
ICMPv6), there is no upper limit upon the length of the "original
datagram" field. However, each implementation will decide how many
octets to include. Those wishing to be backward compatible with non-
compliant TRACEROUTE implementations will include exactly 128 octets.
Those not requiring compatibility with non-compliant TRACEROUTE
applications may include more octets.
<span class="grey">Bonica, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Compliant Application Receives ICMP Message with No Extensions</span>
When a compliant application receives an ICMP message, it examines
the length attribute that is associated with the "original datagram"
field. If the length attribute is zero, the compliant application
MUST determine that the message contains no extensions.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Compliant Application Receives ICMP Message with Non-Compliant</span>
<span class="h3"> Extensions</span>
When a compliant application receives an ICMP message, it examines
the length attribute that is associated with the "original datagram"
field. If the length attribute is zero, the compliant application
MUST determine that the message contains no extensions. In this
case, that determination is technically correct, but not backwards
compatible with the non-compliant implementation that originated the
ICMP message.
So, to ease transition yet encourage compliant implementation,
compliant TRACEROUTE implementations MUST include a non-default
operation mode to also interpret non-compliant responses.
Specifically, when a TRACEROUTE application operating in non-
compliant mode receives a sufficiently long ICMP message that does
not specify a length attribute, it will parse for a valid extension
header at a fixed location, assuming a 128-octet "original datagram"
field. If the application detects a valid version and checksum, it
will treat the octets that follow as an extension structure.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Interaction with Network Address Translation</span>
The ICMP extensions defined in this memo do not interfere with
Network Address Translation. [<a href="./rfc3022" title=""Traditional IP Network Address Translator (Traditional NAT)"">RFC3022</a>] permits traditional NAT
devices to modify selected fields within ICMP messages. These fields
include the "original datagram" field mentioned above. However, if a
NAT device modifies the "original datagram" field, it should modify
only the leading octets of that field, which represent the outermost
IP header. Because the outermost IP header is guaranteed to be
contained by the first 128 octets of the "original datagram" field,
ICMP extensions and NAT will not interfere with one another.
It is conceivable that a NAT implementation might overstep the
restrictions of <a href="./rfc3022">RFC 3022</a> and overwrite the length attribute specified
by this memo. If a NAT implementation were to overwrite the length
attribute with zeros, the resulting packet will be indistinguishable
from a packet that was generated by a non-compliant ICMP
implementation. See <a href="#section-5.5">Section 5.5</a> for packet details and a discussion
of backwards compatibility.
<span class="grey">Bonica, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. The ICMP Extension Structure</span>
This memo proposes an optional ICMP Extension Structure that can be
appended to the ICMP messages referenced in <a href="#section-4.6">Section 4.6</a> of this
document.
The Extension Structure contains exactly one Extension Header
followed by one or more objects. Having received an ICMP message
with extensions, application software MAY process selected objects
while ignoring others. The presence of an unrecognized object does
not imply that an ICMP message is malformed.
As stated above, the total length of the ICMP message, including
extensions, MUST NOT exceed the minimum reassembly buffer size.
Figure 6 depicts the ICMP Extension Header.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| (Reserved) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ICMP Extension Header
The fields of the ICMP Extension Header are as follows:
Version: 4 bits
ICMP extension version number. This is version 2.
Reserved: 12 bits
Must be set to 0.
Checksum: 16 bits
The one's complement of the one's complement sum of the data
structure, with the checksum field replaced by zero for the
purpose of computing the checksum. An all-zero value means that
no checksum was transmitted. See <a href="#section-5.2">Section 5.2</a> for a description of
how this field is used.
<span class="grey">Bonica, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. ICMP Extension Objects</span>
Each extension object contains one or more 32-bit words, representing
an object header and payload. All object headers share a common
format. Figure 7 depicts the object header and payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| // (Object payload) // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Object Header and Payload
An object header has the following fields:
Length: 16 bits
Length of the object, measured in octets, including the object
header and object payload.
Class-Num: 8 bits
Identifies object class.
C-Type: 8 bits
Identifies object sub-type.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
Upon receipt of an ICMP message, application software must check it
for syntactic correctness. The extension checksum must be verified.
Improperly specified length attributes and other syntax problems may
result in buffer overruns.
This memo does not define the conditions under which a router sends
an ICMP message. Therefore, it does not expose routers to any new
denial-of-service attacks. Routers may need to limit the rate at
which ICMP messages are sent.
<span class="grey">Bonica, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IANA Considerations</span>
The ICMP Extension Object header contains two 8-bit fields: The
Class-Num identifies the object class, and the C-Type identifies the
class sub-type. Sub-type values are defined relative to a specific
object class value, and are defined per class.
IANA has established a registry of ICMP extension objects classes and
class sub-types. There are no values assigned within this document
to maintain. Object classes 0xF7 - 0xFF are reserved for private
use. Object class values are assignable on a first-come-first-serve
basis. The policy for assigning sub-type values should be defined in
the document defining new class values.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgments</span>
Thanks to Pekka Nikander, Mark Doll, Fernando Gont, Joe Touch,
Christian Voiqt, and Sharon Chrisholm for their comments regarding
this document.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.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-RFC1191">RFC1191</a>] Mogul, J. and S. Deering, "Path MTU discovery", <a href="./rfc1191">RFC</a>
<a href="./rfc1191">1191</a>, November 1990.
[<a id="ref-RFC1812">RFC1812</a>] Baker, F., "Requirements for IP Version 4 Routers",
<a href="./rfc1812">RFC 1812</a>, June 1995.
[<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.
[<a id="ref-RFC4443">RFC4443</a>] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", <a href="./rfc4443">RFC 4443</a>,
March 2006.
<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>
[<a id="ref-UNNUMBERED">UNNUMBERED</a>] Atlas, A., Bonica, R., Rivers, JR., Shen, N., and E.
Chen, "ICMP Extensions for Unnumbered Interfaces",
Work in Progress, March 2007.
<span class="grey">Bonica, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
[<a id="ref-MPLS-ICMP">MPLS-ICMP</a>] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"ICMP Extensions for MultiProtocol Label Switching",
Work in Progress, January 2007.
[<a id="ref-ATTACKS">ATTACKS</a>] Gont, F., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22ICMP+attacks+against+TCP%22'>"ICMP attacks against TCP"</a>, Work in
Progress, October 2006.
[<a id="ref-ROUTING-INST">ROUTING-INST</a>] Shen, N. and E. Chen, "ICMP Extensions for Routing
Instances", Work in Progress, November 2006.
[<a id="ref-RFC3022">RFC3022</a>] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", <a href="./rfc3022">RFC 3022</a>,
January 2001.
Authors' Addresses
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
US
EMail: rbonica@juniper.net
Der-Hwa Gan
Consultant
EMail: derhwagan@yahoo.com
Daniel C. Tappan
Consultant
EMail: Dan.Tappan@gmail.com
Carlos Pignataro
Cisco Systems, Inc.
7025 Kit Creek Road
Research Triangle Park, NC 27709
US
EMail: cpignata@cisco.com
<span class="grey">Bonica, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4884">RFC 4884</a> Multi-Part ICMP Messages April 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bonica, et al. Standards Track [Page 19]
</pre>
|
