idnits 2.17.1 draft-ietf-6man-icmp-limits-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 221: '... This code SHOULD be sent by an inte...' RFC 2119 keyword, line 235: '... SHOULD be sent when a node discards...' RFC 2119 keyword, line 243: '... long" SHOULD be sent when a node di...' RFC 2119 keyword, line 258: '...xtension header" SHOULD be sent when a...' RFC 2119 keyword, line 272: '...rocessing limit, a node SHOULD send an...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 6, 2019) is 1724 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPv6' is mentioned on line 187, but not defined ** Downref: Normative reference to an Proposed Standard RFC: RFC 7045 ** Downref: Normative reference to an Proposed Standard RFC: RFC 4884 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Intel 4 Expires: February 2020 6 August 6, 2019 8 ICMPv6 errors for discarding packets due to processing limits 9 draft-ietf-6man-icmp-limits-04 11 Abstract 13 Network nodes may discard packets if they are unable to process 14 protocol headers of packets due to processing constraints or limits. 15 When such packets are dropped, the sender receives no indication so 16 it cannot take action to address the cause of discarded packets. This 17 specification defines ICMPv6 errors that can be sent by a node that 18 discards packets because it is unable to process the protocol 19 headers. A node that receives such an ICMPv6 error may be able to 20 modify what it sends in future packets to avoid subsequent packet 21 discards. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1 Extension header limits . . . . . . . . . . . . . . . . . . 4 63 1.2 Aggregate header limits . . . . . . . . . . . . . . . . . . 5 64 2 ICMPv6 errors for extension header limits . . . . . . . . . . . 5 65 2.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2 Unrecognized Next Header type encountered (code 1) . . . . . 6 67 2.3 Extension header too big (code 4) . . . . . . . . . . . . . 6 68 2.4 Extension header chain too long (code 5) . . . . . . . . . . 7 69 2.5 Too many options in extension header (code 6) . . . . . . . 7 70 2.6 Option too big (code 7) . . . . . . . . . . . . . . . . . . 7 71 3 ICMPv6 error for aggregate header limits . . . . . . . . . . . 8 72 3.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1 Priority of reporting . . . . . . . . . . . . . . . . . . . 9 76 4.2 Host response . . . . . . . . . . . . . . . . . . . . . . . 10 77 5 Applicability and use cases . . . . . . . . . . . . . . . . . . 11 78 5.1 Nonconformant packet discard . . . . . . . . . . . . . . . . 11 79 5.2 Reliability of ICMP . . . . . . . . . . . . . . . . . . . . 11 80 5.3 Processing limits . . . . . . . . . . . . . . . . . . . . . 11 81 5.3.1 Long headers and header chains . . . . . . . . . . . . . 11 82 5.3.2 At end nodes . . . . . . . . . . . . . . . . . . . . . . 12 83 5.3.3 At intermediate nodes . . . . . . . . . . . . . . . . . 12 84 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 85 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 86 7.1 Parameter Problem codes . . . . . . . . . . . . . . . . . . 14 87 7.2 Destination Unreachable codes . . . . . . . . . . . . . . . 14 88 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14 89 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 91 9.2 Informative References . . . . . . . . . . . . . . . . . . 15 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 1 Introduction 96 This document specifies ICMPv6 errors that can be sent when a node 97 discards a packet due to it being unable to process the necessary 98 protocol headers because of processing constraints or limits. New 99 ICMPv6 code points are defined as an update to [RFC4443]. Five of the 100 errors are specific to processing of extension headers; another error 101 is used when the aggregate protocol headers in a packet exceed the 102 processing limits of a node. 104 1.1 Extension header limits 106 In IPv6, optional internet-layer information is carried in one or 107 more IPv6 Extension Headers [RFC8200]. Extension Headers are placed 108 between the IPv6 header and the Upper-Layer Header in a packet. The 109 term "Header Chain" refers collectively to the IPv6 header, Extension 110 Headers, and Upper-Layer Headers occurring in a packet. Individual 111 extension headers may have a length of 2048 octets and must fit into 112 one MTU. Destination Options and Hop-by-Hop Options contain a list of 113 options in Type-length-value (TLV) format. Each option includes a 114 length of the data field in octets: the minimum size of an option 115 (non-pad type) is two octets and the maximum size is 257 octets. The 116 number of options in an extension header is only limited by the 117 length of the extension header and MTU. Options may be skipped over 118 by a receiver if they are unknown and the Option Type indicates to 119 skip (first two high order bits are 00). 121 Per [RFC8200], except for Hop by Hop options, extension headers are 122 not examined or processed by intermediate nodes. Many intermediate 123 nodes, however, do examine extension header for various purposes. For 124 instance, a node may examine all extension headers to locate the 125 transport header of a packet in order to implement transport layer 126 filtering or to track connections to implement a stateful firewall. 128 Destination hosts are expected to process all extension headers and 129 options in Hop-by-Hop and Destination Options. 131 Due to the variable lengths, high maximum lengths, or potential for 132 Denial of Service attack of extension headers, many devices impose 133 operational limits on extension headers in packets they process. 134 [RFC7045] discusses the requirements of intermediate nodes that 135 discard packets because of unrecognized extension headers. [RFC8504] 136 discusses limits that may be applied to the number of options in Hop- 137 by-Hop or Destination Options extension headers. Both intermediate 138 nodes and end hosts may apply limits to extension header processing. 139 When a limit is exceeded, the typical behavior is to silently discard 140 the packet. 142 This specification defines four Parameter Problem codes and extends 143 the applicably of an existing code that may be sent by a node that 144 discards a packet due to processing limits of extension headers being 145 exceeded. A source host that receives an ICMPv6 error may modify its 146 use of extension headers in subsequent packets sent to the 147 destination in order to avoid further occurrences of packets being 148 discarded. 150 1.2 Aggregate header limits 152 Many hardware devices implement a parsing buffer of a fixed size to 153 process packets. The parsing buffer is expected to contain all the 154 headers (often up to a transport layer header for filtering) that a 155 device needs to examine. If the aggregate length of headers in a 156 packet exceeds the size of the parsing buffer, a device will either 157 discard the packet or defer processing to a software slow path. In 158 any case, no indication of a problem is sent back to the sender. 160 This document defines one code for ICMPv6 Destination Unreachable 161 that is sent by a node that is unable to process the headers of a 162 packet due to the aggregate size of the packet headers exceeding a 163 processing limit. A source host that receives an ICMPv6 error can 164 modify the headers used in subsequent packets to try to avoid further 165 occurrences of packets being discarded or relegated to a slow path. 167 2 ICMPv6 errors for extension header limits 169 Four new codes are defined for the Parameter Problem type and 170 applicability of one existing code is extended for ICMPv6 errors for 171 extension header limits. 173 2.1 Format 175 The format of the ICMPv6 message for an extension header limit 176 exceeded error is: 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type | Code | Checksum | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Pointer | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | As much of invoking packet | 186 + as possible without the ICMPv6 packet + 187 | exceeding the minimum IPv6 MTU [IPv6] | 188 IPv6 Fields: 190 Destination Address 191 Copied from the Source Address field of the invoking packet. 193 ICMPv6 Fields: 195 Type 196 4 (Parameter Problem type) 198 Code (pertinent to this specification) 199 1 - Unrecognized Next Header type encountered 200 4 - Extension header too big 201 5 - Extension header chain too long 202 6 - Too many options in extension header 203 7 - Option too big 205 Pointer 206 Identifies the octet offset within the invoking packet where 207 the problem occurred. 209 The pointer will point beyond the end of the ICMPv6 packet if 210 the field having a problem is beyond what can fit in the 211 maximum size of an ICMPv6 error message. 213 2.2 Unrecognized Next Header type encountered (code 1) 215 [RFC8200] specifies that a destination host should send an 216 "unrecognized next header type" when a Next Header value is 217 unrecognized in a packet. This document extends this to allow 218 intermediate nodes to send this same error for a packet that is 219 discarded because the node does not recognize a Next Header type. 221 This code SHOULD be sent by an intermediate node that discards a 222 packet because it encounters a Next Header type that is unknown in 223 its examination. The ICMPv6 Pointer field is set to the offset of the 224 unrecognized next header value within the original packet. 226 Note that when the original sender receives the ICMPv6 error it can 227 differentiate between the message being sent by a destination host, 228 per [RFC4443], and an error sent by an intermediate host based on 229 matching the source address of the ICMPv6 packet and the destination 230 address of the packet in the ICMPv6 data. 232 2.3 Extension header too big (code 4) 234 An ICMPv6 Parameter Problem with code for "extension header too big" 235 SHOULD be sent when a node discards a packet because the size of an 236 extension header exceeds its processing limit. The ICMPv6 Pointer 237 field is set to the offset of the first octet in the extension header 238 that exceeds the limit. 240 2.4 Extension header chain too long (code 5) 242 An ICMPv6 Parameter Problem with code for "extension header chain too 243 long" SHOULD be sent when a node discards a packet with an extension 244 header chain that exceeds its processing limits. 246 There are two different limits that might be applied: a limit on the 247 total size in octets of the header chain, and a limit on the number 248 of extension headers in the chain. This error code is used in both 249 cases. In the case that the size limit is exceeded, the ICMPv6 250 Pointer is set to first octet beyond the limit. In the case that the 251 number of extension headers is exceeded, the ICMPv6 Pointer is set to 252 the offset of first octet of the first extension header that is 253 beyond the limit. 255 2.5 Too many options in extension header (code 6) 257 An ICMPv6 Parameter Problem with code for "too many options in 258 extension header" SHOULD be sent when a node discards a packet with 259 an extension header that has a number of options that exceed the 260 processing limits of the node. This code is applicable for 261 Destination options and Hop-by-Hop options. The ICMPv6 Pointer field 262 is set to the first octet of the first option that exceeds the limit. 264 2.6 Option too big (code 7) 266 An ICMPv6 Parameter Problem with code for "option too big" is sent in 267 two different cases: when the length of an individual option exceeds 268 a limit, or when the length or number of consecutive padding options 269 exceeds a limit. 271 If a packet is discarded because the length of a Hop-by-Hop or 272 Destination option exceeds a processing limit, a node SHOULD send an 273 ICMPv6 Parameter Problem with code equal to 7. The ICMPv6 Pointer 274 field is set to the offset of the first octet of the option that 275 exceeds the limit. 277 If a packet is discarded because the length or number of consecutive 278 padding options (PAD1 and PADN) exceeds a limit, a node SHOULD send 279 and an ICMPv6 Parameter Problem with code equal to 7. The ICMPv6 280 Pointer field is set to the offset of first octet of the padding 281 option that exceeds the limit. 283 Possible limits related to padding include: 285 * The number of consecutive PAD1 options in destination options or 286 hop-by-hop options is limited to seven octets [RFC8504]. 288 * The length of a PADN options in destination options or hop-by- 289 hop options is limited seven octets [RFC8504]. 291 * The aggregate length of a set of consecutive PAD1 or PADN 292 options in destination options or hop-by-hop options is limited 293 to seven octets. 295 3 ICMPv6 error for aggregate header limits 297 One code is defined for Destination Unreachable type for aggregate 298 header limits. 300 3.1 Format 302 The error for aggregate header limits employs a multi-part ICMPv6 303 message format as defined in [RFC4884]. The extended structure 304 contains a pointer to the first octet beyond the limit. 306 The format of the ICMPv6 message for an aggregate header limit 307 exceeded is: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Code | Checksum | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | unused | Length | unused | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Internet Header + leading octets of original datagram | 317 | | 318 | // | 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Pointer | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 IPv6 Fields: 326 Destination Address 327 Copied from the Source Address field of the invoking packet. 329 ICMPv6 Fields: 331 Type 332 1 (Destination Unreachable type) 334 Code (pertinent to this specification) 335 8 - Headers too long 337 Length 338 Length of the "original datagram" measured in 64 bit words 340 Pointer 341 Identifies the octet offset within the invoking packet where a 342 limit was exceeded. 344 The pointer will point beyond the end of the original datagram 345 if the field exceeding the limit is beyond what can fit in the 346 maximum size of an ICMPv6 error message. 348 3.2 Usage 350 An ICMPv6 Destination Unreachable error with code for "headers too 351 long" SHOULD be sent when a node discards a packet because the 352 aggregate length of headers in the packet exceeds the processing 353 limits of the node. The Pointer in the extended ICMPv6 structure is 354 set to the offset of the first octet that exceeds the limit. 356 4 Operation 358 Nodes that send or receive ICMPv6 errors due to header processing 359 limits MUST generally comply with ICMPv6 processing as specified in 360 [RFC4443]. 362 4.1 Priority of reporting 364 More than one ICMPv6 error may be applicable to report for a packet. 365 For instance, the number of extension headers in a packet might 366 exceed a limit and the aggregate length of protocol headers might 367 also exceed a limit. Only one ICMPv6 error SHOULD be sent for a 368 packet, so a priority is defined to determine which error to report. 370 The RECOMMENDED reporting priority of ICMPv6 errors for processing 371 limits is from highest to lowest priority: 373 1) Real error (existing codes) 375 2) "Unrecognized Next Header type" encountered by an intermediate 376 node 378 3) "Extension header too big" 380 4) "Option too big" for length or number of consecutive padding 381 options exceeding a limit 383 5) "Option too big" for the length of an option exceeding a limit 385 6) "Too many options in an extension header" 387 7) "Extension header chain too long" for number of extension 388 headers exceeding a limit 390 8) "Extension header chain too long" for size of an extension 391 header chain exceeding a limit 393 9) "Headers too long" 395 4.2 Host response 397 When a source host receives an ICMPv6 error for a processing limit 398 being exceeded, it SHOULD verify the ICMPv6 error is valid and take 399 an appropriate action. 401 The general validations for ICMP as described in [RFC4443] are 402 applicable. The packet in the ICMP data SHOULD be validated to match 403 the upper layer process or connection that generated the original 404 packet. Other validation checks that are specific to the upper layers 405 may be performed and are out of the scope of this specification. 407 The ICMPv6 error SHOULD be logged with sufficient detail for 408 debugging packet loss. The details of the error, including the 409 addresses and the offending extension header or data, should be 410 retained. This, for instance, would be useful for debugging when a 411 node is mis-configured and unexpectedly discarding packets, or when a 412 new extension header is being deployed. 414 A host MAY modify its usage of protocol headers in subsequent packets 415 to avoid repeated occurrences of the same error. 417 For ICMPv6 errors caused by extension header limits being exceeded: 419 * An error SHOULD be reported to an application if the application 420 enabled extension headers for its traffic. In response, the 421 application may terminate communications if extension headers 422 are required, stop using extension headers in packets to the 423 destination indicated by the ICMPv6 error, or attempt modify its 424 use of extension headers or headers to avoid further packet 425 discards. 427 * A host system SHOULD take appropriate action if it is 428 automatically inserting extension headers into packets on behalf 429 of the application. If the offending extension header is not 430 required for communication, the host may either stop sending it 431 or otherwise modify its use in subsequent packets sent to the 432 destination indicated in the ICMPv6 error. 434 5 Applicability and use cases 436 5.1 Nonconformant packet discard 438 The ICMP errors defined in this specification may be applicable to 439 scenarios for which a node is dropping packets outside the auspices 440 of any standard specification. For instance, an intermediate node 441 might send a "Headers too long" code in the case that it drops a 442 packet because it is unable to parse deep enough to extract transport 443 layer information needed for packet filtering. Such behavior might be 444 considered nonconformant (with respect to [RFC8200] for instance). 446 This specification does not advocate behaviors that might be 447 considered nonconformant. However, packet discard does occur in real 448 deployments and the intent of this specification is provide 449 visibility as to why packets are being discarded. In the spirit that 450 providing some reason is better than silent drop, this specification 451 RECOMMENDS the sending of ICMP errors even in cases where a node 452 might be discarding packets per a nonconformant behavior. 454 5.2 Reliability of ICMP 456 ICMP is fundamentally an unreliable protocol and in real deployment 457 it may consistently fail over some paths. As with any other use of 458 ICMP, it is assumed that the errors defined in this document are only 459 best effort to be delivered. No protocol should be implemented that 460 relies on reliable delivery of ICMP messages. If necessary, 461 alternative or additional mechanisms may used to augment the 462 processes used to to deduce the reason that packets are being 463 discarded. Such alternative mechanisms are out of scope of this 464 specification. 466 5.3 Processing limits 468 This sections discusses the trends and motivations of processing 469 limits that warrant ICMP errors. 471 5.3.1 Long headers and header chains 473 Historically, packet headers have been relatively simple and 474 straightforward. For instance, the majority of packets in the 475 Internet are plain TCP or UDP carried in IPv4 or IPv6. The trend 476 towards more complex headers, and hence the need to process longer 477 headers, is driven by: 479 * Increasing prevalence of deep packet inspection in middleboxes. 480 In particular, many intermediate nodes now parse into network 481 layer encapsulation protocols. 483 * Deployment of routing headers. For instance, [SRH] defines an 484 extension header format that includes a list of IPv6 addresses 485 which may consume a considerable number of bytes. 487 * Development of In-situ OAM headers that allow a rich set of 488 measurements to be gathered in the data path at the cost of 489 additional header overhead which may be significant [IOAM]. 491 * Other emerging use cases of Hop-by-Hop options. 493 5.3.2 At end nodes 495 End node hosts may implement limits on processing extension headers 496 as described in [RFC8504]. Host implementations are usually software 497 stacks that typically don't have inherent processing limitations. 498 Limits imposed by a software stack are more likely to be for denial 499 of service mitigation or performance. 501 5.3.3 At intermediate nodes 503 Hardware devices that process packet headers may have limits as to 504 how many headers or bytes of headers they can process. For instance, 505 a middlebox hardware implementation might have a parsing buffer that 506 contains some number of bytes of packet headers to process. Parsing 507 buffers typically have a fixed size such as sixty-four, 128, or 256 508 bytes. In addition, hardware implementations (and some software 509 implementations) often don't have loop constructs. So for instance, 510 processing of a TLV list might be implemented as an unrolled loop so 511 that the number of TLVs that can be processed is limited. For 512 instance, an implementation might unroll a TLV parsing loop to 513 process at most eight TLVs. 515 6 Security Considerations 517 The security considerations for ICMPv6 described in [RFC4443] are 518 applicable. The ICMP errors described in this document MAY be 519 filtered by firewalls in accordance with [RFC4890]. 521 In some circumstances, the sending of ICMP errors might conceptually 522 be exploited for denial of service attack or as a means to covertly 523 deduce processing capabilities of nodes as a precursor to denial of 524 service attack. As such, an implementation SHOULD allow configurable 525 policy to withhold sending of the ICMP errors described in this 526 specification in environments where security of ICMP errors is a 527 concern. 529 7 IANA Considerations 531 7.1 Parameter Problem codes 533 IANA is requested to assign the following codes for ICMPv6 type 4 534 "Parameter Problem": 536 4 - Extension header too big 538 5 - Extension header chain too long 540 6 - Too many options in extension header 542 7 - Option too big 544 7.2 Destination Unreachable codes 546 IANA is requested to assign the following codes for ICMPv6 type 1 547 "Destination Unreachable": 549 8 - Headers too long 551 8 Acknowledgments 553 The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard, 554 Michael Richardson, Mark Smith, and Suresh Krishnan for their 555 comments and suggestions that improved this document. 557 9 References 559 9.1 Normative References 561 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 562 Control Message Protocol (ICMPv6) for the Internet Protocol 563 Version 6 (IPv6) Specification", RFC 4443, DOI 564 10.17487/RFC4443, March 2006, . 567 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 568 (IPv6) Specification", STD 86, RFC 8200, DOI 569 10.17487/RFC8200, July 2017, . 572 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of 573 IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, 574 December 2013, . 576 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 577 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 578 DOI 10.17487/RFC4884, April 2007, . 581 9.2 Informative References 583 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 584 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 585 January 2019, . 587 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 588 ICMPv6 Messages in Firewalls", RFC 4890, DOI 589 10.17487/RFC4890, May 2007, . 592 [SRH] Filsfils, C., Ed.. Dukes, D., Ed., Previdi, S., Leddy, J., 593 Matsushima, S., Voyer, D., "IPv6 Segment Routing Header 594 (SRH)", draft-ietf-6man-segment-routing-header-21 (work in 595 progress), August 2019. February 597 [IOAM] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 598 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 599 Lpaukhov, P., Spiegel, M., Krishnan, S., Asati, R., "In- 600 situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam-ipv6- 601 options-02, March 2018 603 Author's Address 605 Tom Herbert 606 Intel 607 Santa Clara, CA 608 USA 610 Email: tom@quantonium.net