idnits 2.17.1 draft-herbert-6man-eh-attrib-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 538 has weird spacing: '...llowing attri...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: - If the error was caused by inserted extension headers, then the node SHOULD take appropriate actions (minimally it SHOULD log the error). The filtering node SHOULD not forward the ICMP error to the source. -- The document date (December 16, 2019) is 1593 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) == Unused Reference: 'RFC4443' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC7045' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'RFC8504' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'RFC4890' is defined on line 668, but no explicit reference was found in the text ** Downref: Normative reference to an Proposed Standard RFC: RFC 7045 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-08 == Outdated reference: A later version (-02) exists of draft-smith-6man-in-flight-eh-insertion-harmful-01 Summary: 1 error (**), 0 flaws (~~), 9 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: June 2020 6 December 16, 2019 8 Attribution Option for Extension Header Insertion 9 draft-herbert-6man-eh-attrib-00 11 Abstract 13 This document defines an IPv6 Hop-by-Hop Option that provides 14 attribution for IPv6 extension headers inserted by intermediate nodes 15 in the delivery path of a packet. The purpose of this option is 16 twofold: first it identifies the extension headers that have been 17 inserted, secondly it attributes the inserted extension headers to 18 the node responsible for inserting them. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Motivation for extension header insertion . . . . . . . . . 3 60 1.2 Problems with extension header insertion . . . . . . . . . . 4 61 1.3 Inserting Hop-by-Hop Options . . . . . . . . . . . . . . . . 5 62 1.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.5 Requirements Language . . . . . . . . . . . . . . . . . . . 5 64 2 Attribution Option for extension header insertion . . . . . . . 6 65 2.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1.1 Attribution Option with short identifier . . . . . . . . 7 67 2.1.2 Attribution Option with IPv6 address identifier . . . . 7 68 2.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1 Insertion . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.1.1 Insertion of Hop-by-Hop options . . . . . . . . . . . . 9 72 3.1.2 Insertion of extension headers . . . . . . . . . . . . . 10 73 3.1.3 Errors during insertion . . . . . . . . . . . . . . . . 11 74 3.2 Removal . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 3.2.1 Removal of Hop-by-Hop options . . . . . . . . . . . . . 11 76 3.2.2 Removal of extension headers . . . . . . . . . . . . . . 12 77 3.2.3 Errors during removal . . . . . . . . . . . . . . . . . 12 78 3.3 Domain edge filtering . . . . . . . . . . . . . . . . . . . 13 79 3.4 ICMP processing . . . . . . . . . . . . . . . . . . . . . . 13 80 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 81 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 82 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 6.1 Normative References . . . . . . . . . . . . . . . . . . . 15 84 6.2 Informative References . . . . . . . . . . . . . . . . . . 15 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1 Introduction 89 Extension header insertion has been proposed as a mechanism to 90 annotate packets for transit across controlled, or limited, domains 91 ([SRHINS], [IOAM]). Presumably, before a packet egresses the 92 controlled domain, any inserted extension headers need to be removed. 94 Extension header insertion and removal at intermediate nodes is 95 currently prohibited by [RFC8200], and [INSHARM] provides the 96 rationale for why extension header insertion is harmful and thus is 97 prohibited. 99 This document addresses the main problem of extension header 100 insertion which is the loss of attribution to the source of packet 101 contents. A Hop-by-Hop option is defined to provide proper 102 attribution. There are two salient aspects to this: 104 * The Hop-by-Hop Option unambiguously identifies what extension 105 headers were inserted by intermediate nodes. 107 * The Hop-by-Hop Option includes an identification of the 108 intermediate node that inserted extension headers in a packet. 110 1.1 Motivation for extension header insertion 112 IP in IP encapsulation has been proposed as an alternative to 113 extension header insertion. While encapsulation may be functionally 114 equivalent to header insertion, there are merits to header insertion: 116 * Extension header insertion can result in less bytes of overhead 117 than encapsulation. 119 * The proper destination address to set in the encapsulating IP 120 header may be unknown. For instance, a node might insert an 121 extension header into an existing packet with the intent that 122 the packet is routed based on the original destination to an 123 egress node of the domain that will remove the inserted headers. 125 * Packets for a flow may require consistent routing whether or not 126 extension headers are inserted. In particular, to route flows 127 consistently in Equal Cost MultiPath (ECMP), the hash computed 128 for ECMP should be the same for all packets of the flow. Unlike 129 IP encapsulation, extension header insertion doesn't affect the 130 fields used in ECMP hash calculation (the source address, 131 destination address, flow label, and transport layer ports), so 132 the ECMP hash calculation consistently derives the same value 133 for all packets of a flow with or without inserted extension 134 headers. 136 1.2 Problems with extension header insertion 138 Extension header insertion and removal at intermediate nodes is 139 prohibited by [RFC8200]: 141 Extension headers (except for the Hop-by-Hop Options header) are 142 not processed, inserted, or deleted by any node along a packet's 143 delivery path, until the packet reaches the node (or each of the 144 set of nodes, in the case of multicast) identified in the 145 Destination Address field of the IPv6 header. 147 The rationale for this prohibition is articulated in [INSHARM]. A 148 summary of cited problems with extension header insertion are: 150 * It breaks the attribution model of IP in that the contents of a 151 packet are no longer attributable to the source node identified 152 by the source address of a packet (exceptions include data that 153 a source node sets in a packet that is explicitly specified to 154 be modifiable). 156 * It breaks PMTU discovery since extension header insertion 157 increases the packet size in flight. 159 * It breaks ICMP since inserted extension headers may themselves 160 cause ICMP errors that are sent to the source address. If the 161 source node receives such an ICMP error it cannot take any 162 action to resolve the error since it's not the source of the 163 data that caused the error. 165 * Use of extension header insertion is generally assumed to be 166 confined to a controlled domain where the domain is a walled 167 garden such that inserted extension headers are always removed 168 before packets would exit a domain. It is conceivable that 169 configuration or implementation errors may allow packets with 170 inserted extension headers to leak out of the controlled domain. 172 * It potentially violates the recommendation in [RFC8200] that 173 extension headers appear only once in a packet as well as the 174 recommended ordering for extension headers. 176 This proposal primarily addresses the attribution of packet contents 177 problem. A solution to the attribution problem addresses or at least 178 can mitigate some of the other problems with extension header 179 insertion. 181 1.3 Inserting Hop-by-Hop Options 183 Inserting Hop-by-Hop Options is considered a special case of 184 extension header insertion since per [RFC8200] there can only be one 185 Hop-by-Hop Options extension header in a packet, and if present it 186 must be the first extension header after the IPv6 header. If Hop-by- 187 Hop Options are to be inserted into a packet with an existing Hop-by- 188 Hop Options extension header, the the options must be inserted into 189 the options list for the existing extension header. 191 1.4 Scope 193 This document describes a mechanism for providing attribution in 194 extension header insertion and procedures to use the mechanism. With 195 the exception of inserting Hop-by-Hop Options, requirements and 196 semantics for inserting specific types of extension headers are out 197 of scope. Similar, security aspects, including potential leakage of 198 inserted headers outside of a controlled domain, is not in scope. 200 1.5 Requirements Language 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 2 Attribution Option for extension header insertion 208 2.1 Format 210 The format of the Hop-by-Hop Attribution Option is: 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Option Type | Opt Data Len | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Num_opts | Num_EHs | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 219 | | 220 ~ Identification ~ 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Fields are: 226 * Option Type: value is TBA. The first three bits of the option 227 type should be 000 to indicate that the option is to be skipped 228 over when processed as an unknown option and that the option 229 data is unmodifiable. 231 * Opt Data Len: data length for the option. The minimal data 232 length is two. If the data length equals twenty-two then the 233 Identification is an IPv6 address (see section 2.1.2). 235 * Num_opts: indicates the number of non-padding Hop-by-Hop options 236 following the Attribution Option that are attributed as being 237 inserted. If the value of this field is 255 then this indicates 238 that the Hop-by-Hop Options extension header was itself inserted 239 and all the following options are attributed to the insertion. 241 * Num_EHs: indicates the number of extension headers following the 242 Hop-by-Hop extension header that have been inserted. 244 * Identification: indicates the source node responsible for the 245 inserted extension headers. This can either be the IPv6 address 246 of the responsible node or a local identifier value that is 247 interpreted by the local network domain (see examples below). 249 Alignment of the Attribution Option is 4n+2. When the Attribution 250 Option is used, it MUST be set as the first option in the Hop-by-Hop 251 options; hence, there is no need for padding to align the Attribution 252 Option. There may be multiple instances of the Attribution Option in 253 a packet as described below. 255 2.1.1 Attribution Option with short identifier 257 Below is the short format of the Attribution Option. 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type | 4 | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Num opts | Num EHs | Short_ID | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Short_ID is interpreted locally. For instance, it may be used as an 268 index to a table to map a value to an IPv6 address. 270 2.1.2 Attribution Option with IPv6 address identifier 272 Below is the format of the Attribution Option that contains an IPv6 273 address for attribution of the inserted extension headers. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | 22 | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Num opts | Num EH | Local_ID | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 + + 284 | | 285 + IPv6 address + 286 | | 287 + + 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Local_ID contains supplemental identification that is interpreted by 292 the local network. This MAY be the AS of network corresponding to the 293 node identified by the IPv6 address. 295 2.2 Model 297 The Attribution Option indicates both inserted Hop-by-Hop Options and 298 inserted extension headers. Note that at most one Hop-by-Hop 299 Extension header MUST be in a packet, and if the Hop-by-Hop Extension 300 header is present it MUST be the first extension header following the 301 IPv6 header. If Hop-by-Hop Options are to be inserted into a packet 302 with an existing Hop-by-Hop extension header then the options MUST be 303 inserted into the existing header. 305 Multiple extension headers insertions may occur during the lifetime 306 of a packet. Insertions are treated as a stack. Extension headers 307 MUST be inserted before any existing extension headers, and Hop-by- 308 Hop options MUST be inserted before any existing Hop-by-Hop options. 309 Inserted extension headers and inserted Hop-by-Hop options MUST be 310 removed in the reverse order of insertion (i.e. inserted headers are 311 "popped" to remove them). 313 The logical structure of an IPv6 packet with inserted extension 314 headers and IP options, and the relationship between Attribution 315 Options and inserted extension headers and Hop-by-Hop options, is 316 shown below: 318 +-+-+-+-+-+-+-+-+-+ 319 | IPv6 header | 320 +-+-+-+-+-+-+-+-+-+ 321 | Hop-by-Hop EH | 322 +-+-+-+-+-+-+-+-+-+-+-+-+\ 323 | Attribution Opt | | 324 +-+-+-+-+-+-+-+-+-+-+ |-------+ 325 | Inserted options | | | 326 +-+-+-+-+-+-+-+-+-+-+/ | 327 ... | 328 +-+-+-+-+-+-+-+-+-+-+\ | 329 | Attribution Opt | | | 330 +-+-+-+-+-+-+-+-+-+-+ |--+ | 331 | Inserted options | | | | 332 +-+-+-+-+-+-+-+-+-+-+/ | | 333 | Original options | | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+ | | 335 | Inserted EHs |<--------------+ 336 +-+-+-+-+-+-+-+-+-+ | 337 ... | 338 +-+-+-+-+-+-+-+-+-+ | 339 | Inserted EHs |<---------+ 340 +-+-+-+-+-+-+-+-+-+ 341 | Original EHs | 342 +-+-+-+-+-+-+-+-+-+ 344 3 Operation 346 This section describes operations for extension header insertion and 347 removal at intermediate nodes. 349 3.1 Insertion 351 An extension header chain MAY be inserted into a packet. The packet's 352 size will increase, and if Hop-by-Hop Options are already present 353 then the size of the Hop-by-Hop extension header will increase. 355 3.1.1 Insertion of Hop-by-Hop options 357 Hop-by-Hop options, including the attribution option, may be inserted 358 into a packet. 360 Procedure is: 362 * If a Hop-by-Hop extension header does not exist in the packet: 364 1) Create a Hop-by-Hop extension header. This contains the 365 Attribution Option, followed by any Hop-by-Hop options being 366 inserted. Num_opts is set to 255 to indicate that the Hop- 367 by-Hop extension header was inserted. Num_EHs is set to the 368 number of extension headers being inserted not including the 369 Hop-by-Hop extension header. 371 2) The new Hop-by-Hop extension header is prepended to the 372 chain of extension headers being inserted. The nexthdr field 373 of the Hop-by-Hop option is set to the type of the first 374 extension header being inserted (after the Hop-by-Hop 375 extension header). 377 3) The resulting extension header chain is inserted into the 378 packet following procedures in section 3.1.2. 380 * Else, if Hop-by-Hop Options are already present then insert new 381 Hop-by-Hop options into the existing header: 383 1) Make first Hop-by-Hop option to be the Attribution Option. 384 Num_opts is set to the number of non-padding Hop-by-Hop 385 options being inserted not including the Attribution Option. 386 Num_EHs is set to the number of extension headers being 387 inserted. 389 2) Following the Attribution Option, set any other options 390 being inserted. Include padding before the options as 391 necessary to enforce any alignment requirements. 393 3) Following the last inserted option, add padding such that 394 the alignment of the first byte after the last padding byte 395 is 8n+2 from the start of the Hop-by-Hop extension header. 396 This is necessary to preserve alignment requirements of 397 existing options. The amount of padding needed is: 399 7 - (offset_last_inserted_byte % 8) 401 4) Following the last inserted option and inserted padding, 402 copy the original options from the packet. 404 5) Set length of the Hop-by-Hop extension header to reflect the 405 length with the inserted options and any inserted padding. 407 3.1.2 Insertion of extension headers 409 This section describes procedures for inserting extension headers 410 into a packet. 412 * If Hop-by-Hop options already exists in a packet, then extension 413 headers (as a chain) are inserted after the Hop-by-Hop extension 414 header. Note that the Attribution Option must be inserted in the 415 existing Hop-by-Hop extension header following the procedure in 416 section 3.1.1. 418 Procedure is: 420 1) The nexthdr field of the last inserted header is set to the 421 original nexthdr value in the Hop-by-Hop Options extension 422 header. 424 2) The nexthdr field of the Hop-by-Hop Options extension header 425 is set to the type of the first header being inserted. 427 3) Extension headers are inserted into packet following the 428 Hop-by-Hop extension header. 430 * Else, if Hop-by-Hop options don't exist in a packet, then 431 extension headers (as a chain) are inserted after the IPv6 432 header. Note that the inserted extension headers MUST include a 433 Hop-by-Hop extension header containing the Attribution Option 434 and the Hop-by-Hop extension is the first extension header being 435 inserted (see section 3.1.1). 437 Procedure is: 439 1) The nexthdr field of the last inserted header is set to the 440 original nexthdr value in the IPv6 header. 442 2) The nexthdr field of the IPv6 header is set to 0 (since the 443 first inserted header must be Hop-by-Hop Options). 445 3) Extension headers are inserted into packet following the 446 IPv6 header. 448 If more than one extension header is inserted then the relative 449 ordered amongst the inserted extension headers SHOULD follow the 450 recommended extension headers ordering in [RFC8200]). 452 3.1.3 Errors during insertion 454 Errors may occur in the process of inserting extension headers in a 455 packet. Error conditions would include the resultant packet size 456 exceeding MTU, and the size of Hop-by-Hop Options extension header 457 exceeding 1024 bytes (the maximum size of the Hop-by-Hop Options 458 extension header). 460 If an error occurs during insertion then the node performing 461 insertion MUST take an appropriate behavior per some configuration. 462 The packet MAY be discarded or the unmodified packet MAY be 463 forwarded. An error SHOULD be logged. 465 3.2 Removal 467 The top level inserted extension headers and Hop-by-Hop options, 468 referred to by the Attribution Option, which is precisely the first 469 option in the Hop-by-Hop Options for a packet, may be removed by an 470 intermediate node. 472 3.2.1 Removal of Hop-by-Hop options 474 The procedure is: 476 * If Num_opts equals 255 then the Hop-by-Hop extension header is 477 removed following procedures in section 3.2.2. 479 * If Num_opts is less than 255, then the inserted Hop-by-Hop 480 options must be removed from the existing header: 482 1) Locate the last inserted option. This done by the scanning 483 non-padding options after the Attribution Option for the 484 count in Num_opts. 486 2) Compute the amount of padding that was inserted. The amount 487 of padding that should have been inserted is: 489 7 - (offset_last_option_byte % 8) 490 where offset_last_byte is the offset of the last byte of 491 the last inserted option located in step #1. 493 3) Remove the bytes in the packet from first byte of the Hop- 494 by-Hop Options data (first byte of the Attribution option) 495 through the last byte of inserted padding as computed in 496 step #2. 498 4) set the length of the Hop-by-Hop Options extension header to 499 account for the removed bytes. 501 3.2.2 Removal of extension headers 503 The procedure is: 505 * If Num_opts equal 255 then the Hop-by-Hop extension header is 506 removed along with any other inserted headers: 508 1) Locate the last inserted extension header. This done by the 509 scanning extension headers after the Hop-by-Hop Options 510 extension header for the count in Num_EHs. 512 2) Set nexthdr of the IPv6 header the nexthdr field value of 513 the last extension header being removed. 515 3) Remove the Hop-by-Hop Options extension header and any 516 additional inserted extension headers from packet. 518 * Else, if Num_opts less than 255 then extension headers after the 519 Hop-by-Hop extension header are removed. 521 1) Locate the last inserted extension header. This done by the 522 scanning extension headers after the Hop-by-Hop Options 523 extension header for the count in Num_EHs. If Num_EHs is 524 zero, then no extension headers are removed. 526 2) Set nexthdr of the Hop-by-Hop Option extension header to the 527 nexthdr field value of the last extension header being 528 removed. 530 3) Remove any inserted extension headers after the Hop-by-Hop 531 Options extension header. 533 3.2.3 Errors during removal 535 A node performing extension header removal MUST validate packet 536 contents. 538 The following attributes MUST be validated before removal: 540 * If Num_opts is not equal to 255 then number of non-padding 541 options following Attribution Option MUST be greater than or 542 equal to Num_opts. 544 * Necessary padding after the last inserted Hop-by-Hop option MUST 545 be present. The amount of padding MUST be equal to the expected 546 amount. 548 * The Num_opts options following the Attribution Option MUST NOT 549 contain another Attribution Option. 551 * The number of extension headers following the Hop-by-Hop Options 552 extension header MUST be greater than or equal to Num_EHs. 554 If any of the above validations fail, or an error is otherwise 555 encountered in the removal process, then the processing node MUST 556 take action. The packet SHOULD be discarded and error message SHOULD 557 be logged. 559 3.3 Domain edge filtering 561 Filtering packets with inserted extension headers or Hop-by-Hop 562 options is straightforward: a packet contains inserted extension 563 headers if it contains Hop-by-Hop options where the first option is 564 the Attribution Option. Note that the Attribution Option MUST be at 565 fixed location in the IPv6 packet if it is present, hence it should 566 be amenable to match such packets with inserted extension headers in 567 hardware implementations. 569 3.4 ICMP processing 571 At described in [INSHARM], it is possible for a source node to 572 receive ICMP errors caused by inserted headers, thus the source node 573 has no recourse to address the error. 575 This section proposes some ways to apply the Attribution Option to 576 mitigate the ICMP breakage for extension header insertion: 578 * ICMP errors can be filtered by nodes in the network before 579 reaching a source node outside of the domain (at the domain edge 580 for instance). The packet headers in the ICMP data will include 581 the Hop-by-Hop Options extension header containing the 582 Attribution Option at a fixed offset in the data. The filtering 583 node MAY analyze the error to determine if it was caused by the 584 inserted headers: 586 - If the error was caused by inserted extension headers, then 587 the node SHOULD take appropriate actions (minimally it 588 SHOULD log the error). The filtering node SHOULD not forward 589 the ICMP error to the source. 591 - If the error was not caused by inserted headers, the 592 filtering node MAY create an new ICMP error with the data 593 packet that would be reflect the packet contents prior to 594 extension header insertion (i.e. attempt set the packet in 595 ICMP to be that which the source would have sent). This is 596 done by removing the inserted extension headers of the 597 packet in the ICMP data, and adjusting the Pointer field in 598 an ICMP error if necessary. The revised ICMP error can then 599 be forwarded to the source. 601 * If ICMP errors are not filtered and the source node receives an 602 ICMP error for a packet containing inserted extension headers: 604 - If the source node is a legacy implementation that does not 605 understand the Attribution Option then it will attempt to 606 process the error under the assumption that it was the 607 source of the packet and the data that caused the error. If 608 the node logs the contents of the ICMP error, which should 609 be common, then external out-of-band analysis can be done by 610 network administrators to troubleshoot the ICMP errors and 611 identify culprit if the error was caused by inserted 612 extension headers. 614 - If the source node understands the Attribution Option then 615 it can perform more analysis. The node MAY attempt to 616 ascertain if the error was caused by inserted headers or 617 not, and if not it can then attempt to fix the problem with 618 the assumption the it was responsible for the data in error. 620 4 Security Considerations 622 The Attribution Option does not in itself introduce any new security 623 considerations. The security of containing inserted extension headers 624 within a controlled domain is out of scope for this document. 626 5 IANA Considerations 628 IANA is requested to assigned the following Hop-By-Hop option: 630 +-----------+---------------+-------------+---------------+ 631 | Hex Value | Binary value | Description | Reference | 632 | | act chg rest | | | 633 +-----------+---------------+-------------+---------------+ 634 | TBD | 00 0 TBD | Attribution | This document | 635 | | | Option | | 636 +-----------+---------------+-------------+---------------+ 638 6 References 640 6.1 Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, DOI 644 10.17487/RFC2119, March 1997, . 647 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 648 Control Message Protocol (ICMPv6) for the Internet Protocol 649 Version 6 (IPv6) Specification", RFC 4443, DOI 650 10.17487/RFC4443, March 2006, . 653 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 654 (IPv6) Specification", STD 86, RFC 8200, DOI 655 10.17487/RFC8200, July 2017, . 658 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of 659 IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, 660 December 2013, . 662 6.2 Informative References 664 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 665 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 666 January 2019, . 668 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 669 ICMPv6 Messages in Firewalls", RFC 4890, DOI 670 10.17487/RFC4890, May 2007, . 673 [SRHINS] Voyer, D. Ed., Filsfils, C.,Dukes, D., Ed., Matsushima, S., 674 Leddy, J., Li, Z., and Guichard, J., "Deployments With 675 Insertion of IPv6 Segment Routing Headers", draft-voyer- 676 6man-extension-header-insertion-08, November 2019 678 [IOAM] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 679 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 680 Lpaukhov, P., Spiegel, M., Krishnan, S., Asati, R., "In- 681 situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam-ipv6- 682 options-02, March 2018 684 [INSHARM] Smith, M., Kottapalli, N., Bonica, R., Gont, F., and 685 Herbert, T., "In-Flight IPv6 Extension Header Insertion 686 Considered Harmful", draft-smith-6man-in-flight-eh- 687 insertion-harmful-01, October 2018 689 Author's Address 691 Tom Herbert 692 Intel 693 San Jose, CA 694 USA 696 Email: tom@herbertland.com