idnits 2.17.1 draft-han-6man-enhanced-source-routing-header-01.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 15, 2020) is 1251 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'N' is mentioned on line 490, but not defined == Unused Reference: 'I-D.ietf-lsr-flex-algo' is defined on line 576, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-04 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-04 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L H. Jie 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track November 15, 2020 5 Expires: May 15, 2021 7 An Enhanced Source Routing Header Based on RH3 8 draft-han-6man-enhanced-source-routing-header-01 10 Abstract 12 IPv6 Routing header type 3 (termed as RH3) is defined and used in 13 Low-Power and Lossy Networks (LLNs) that are typically constrained in 14 resources (limited communication data rate, processing power, energy 15 capacity, memory). Based on the mechanisms introduced by RH3, this 16 document specifies an new IPv6 Routing Header type that provides 17 encapsulation capability of segments with various lengths and can be 18 applied to more scenarios. 20 Status of This Memo 22 This Internet-Draft is submitted 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on May 16, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Format of the Source Routing Header . . . . . . . . . . . . . 3 57 4. Format of the Enhanced Source Routing Header . . . . . . . . 3 58 5. Generating E-SRH . . . . . . . . . . . . . . . . . . . . . . 7 59 6. Processing E-SRH . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 61 7.1. Heterogeneous Segment List . . . . . . . . . . . . . . . 9 62 7.2. Independent Arguments in E-SRH . . . . . . . . . . . . . 9 63 7.3. ICMP Error Processing . . . . . . . . . . . . . . . . . . 9 64 7.4. Repair Path . . . . . . . . . . . . . . . . . . . . . . . 10 65 7.5. Binding to Outer Segment List . . . . . . . . . . . . . . 10 66 7.6. In-situ OAM . . . . . . . . . . . . . . . . . . . . . . . 10 67 7.7. NAT Service Funtion . . . . . . . . . . . . . . . . . . . 11 68 7.8. Operation and Maintenance . . . . . . . . . . . . . . . . 11 69 7.9. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 11 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 72 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 Routing headers are defined in [RFC8200]. [RFC6554] specifies the 78 Source Routing Header (SRH), i.e., IPv6 Routing header type 3 (termed 79 as RH3), for use strictly between RPL routers in the Low-Power and 80 Lossy Networks (LLNs) [RFC6550], which are typically constrained in 81 resources (limited communication data rate, processing power, energy 82 capacity, memory). It introduces mechanisms to compact the source 83 route entries when all entries share the same prefix with the IPv6 84 Destination Address of a packet carrying an RH3, a typical scenario 85 in LLNs using source routing. The compaction mechanism reduces 86 consumption of scarce resources such as channel capacity. However, 87 it is challenging when all entries do not have the same prefix, for 88 example, only a part of entries share the same prefix, but still want 89 to encode all routries in a single routing header and reduce the 90 overhead. 92 This document specifies an enhanced Source Routing Header (termed as 93 E-SRH) to enhance the encapsulation capability of segments with 94 various lengths and different types, and attempt to apply to more 95 scenarios that using source routing mechanism. 97 2. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 3. Format of the Source Routing Header 107 The Source Routing Header defined in [RFC6554] has the following 108 format: 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | CmprI | CmprE | Pad | Reserved | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | | 118 . . 119 . Addresses[1..n] . 120 . . 121 | | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Figure 1: Source Routing Header format 126 Where CmprI, CmprE, and Pad fields allow compaction of the 127 Address[1..n] vector when all entries share the same prefix as the 128 IPv6 Destination Address field of the packet carrying the RH3. The 129 CmprI and CmprE fields indicate the number of prefix octets that are 130 shared with the IPv6 Destination Address of the packet carrying the 131 RH3. The shared prefix octets are not carried within the Routing 132 header and each entry in Address[1..n-1] has size (16 - CmprI) octets 133 and Address[n] has size (16 - CmprE) octets. 135 4. Format of the Enhanced Source Routing Header 137 To provide the encapsulation capability of segments with various 138 lengths, this section defines the Enhanced Source Routing Header 139 (E-SRH). The basic idea is to place the CmprI or CmprE information 140 with each segment element. The E-SRH has the following format: 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | List Len | Offset | Flags | Reserved | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type | Cmpr | Segment 1 // 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 // Type | Cmpr | Segment 2 // 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 // ... ... // 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 // Type | Cmpr | Segment N // 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 // Padding | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 // // 160 // Optional Type Length Value objects (variable) // 161 // // 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 2: Enhanced Source Routing Header format 166 where: 168 Next Header: Defined in [RFC8200], Section 4.4. It identifies the 169 type of header immediately following the Routing header. 171 Hdr Ext Len: Defined in [RFC8200], Section 4.4. It represents the 172 length of the Routing header in 8-octet units, not including the 173 first 8 octets. 175 Routing Type: TBA. 177 Segments Left: Defined in [RFC8200], Section 4.4. It represents the 178 number of route segments remaining, i.e., number of explicitly listed 179 intermediate nodes still to be visited before reaching the final 180 destination. Note that it represents the count of intermediate 181 nodes, instead of the count of segments always in constant 128-bit 182 units in the routing header. Both this document and [RFC6554] may 183 take segments less than 128 bits, for example, 32 bits, in the 184 routing header. 186 List Len: 8-bit unsigned integer. It represents the length of the 187 Segment List field in 8-octet units. Note that the size of the 188 entire Segment List must be aligned to 8 bytes. For this purpose, it 189 may be necessary to pad meaningless zeros after the last segment 190 (i.e., segment N). List Len field must be less than Hdr Ext Len, or 191 equal to Hdr Ext Len when E-SRH does not contain optional TLVs. 193 Offset: 12-bit unsigned integer. It represents the index of 194 currently active segment in segment list, when the segment list 195 contained in E-SRH is regarded as an array in bytes. When an element 196 in a segment list array is accessed according to Offset field, its 197 access range must not exceed the range represented by List Len * 8. 199 Flags: 4 bits of flags. No flags are defined currently. 201 Reserved: This field is unused. It MUST be initialized to zero by 202 the sender and MUST be ignored by the receiver. 204 Each tuple provide the information of each 205 segment element in the segment list, and it has variable length. 207 Type: 4 bits. It represents the type of the segment. The following 208 types are defined: 210 0: Indicates that the corresponding Segment field is a complete 211 IPv6 address. Note that the corresponding Segment field does not 212 necessarily occupy 16 bytes, and its length is given by Cmpr 213 field. This is because the low-order position of many IPv6 214 addresses is 0, and it is not necessary to store the entire 16 215 bytes in the Segment field. The IPv6 address may be a normal 216 address that identify node or interface, or an SRv6 SID 217 ([RFC8402]) that has further functions. 219 1: Indicates that the corresponding Segment field is 1-octet of 220 IPv6 address fragment. Similar with [RFC6554], the value of 221 Segment field can be stiched with the prefix contained in the IPv6 222 Destination Address to form a complete IPv6 address. The Cmpr 223 field indicates the number of prefix octets that are shared with 224 the IPv6 Destination Address. For the stiched IPv6 address, the 225 high-order position is the prefix, immediately following the value 226 of the Segment field, and the low-order position is filled with 227 zeros. 229 2: Indicates that the corresponding Segment field is 2-octet of 230 IPv6 address fragment. The stiching method is the same as Type-1. 232 3: Indicates that the corresponding Segment field is 3-octet of 233 IPv6 address fragment. The stiching method is the same as Type-1. 235 4: Indicates that the corresponding Segment field is 4-octet of 236 IPv6 address fragment. The stiching method is the same as Type-1. 238 5: Indicates that the corresponding Segment field is 5-octet of 239 IPv6 address fragment. The stiching method is the same as Type-1. 241 6: Indicates that the corresponding Segment field is 6-octet of 242 IPv6 address fragment. The stiching method is the same as Type-1. 244 7: Indicates that the corresponding Segment field is 7-octet of 245 IPv6 address fragment. The stiching method is the same as Type-1. 247 8: Indicates that the corresponding Segment field is 8-octet of 248 IPv6 address fragment. The stiching method is the same as Type-1. 250 9: Indicates that the corresponding Segment field is 3-octet of 251 MPLS Label. The MPLS Label can be mapped to a complete IPv6 252 address. 254 10: Indicates that the corresponding Segment field is 4 bytes of 255 SR-MPLS SID index([RFC8402]). The index can be mapped to a 256 complete IPv6 address. 258 11: Indicates that the corresponding Segment field is 4 bytes of 259 BIER index([RFC8279]). The index can be mapped to a complete IPv6 260 address. 262 15: Indicates that the corresponding Segment field is an argument 263 that is used by the previous Segment element in E-SRH. The 264 segment's length is given by Cmpr field. Note that Segment with 265 argument types is not counted in the count represented by the 266 segment left field. 268 Cmpr: 4 bits. It represents the length of the prefix in octet units 269 for Type-1 to Type-8. For Type-0, it represents the actual length of 270 the Segment field, For Type-9, Type-10 and Type-11, it has no meaning 271 and can be set to 0. 273 Segment: Represents the nth segment in the Segment List. Similar 274 with [RFC6554], the Segment List is encoded in E-SRH in positive 275 order. The Segment field has variable length. 277 Padding: Optional padding field immediately following Segment N 278 field. It is used to pad the Segment List to a multiple of 8 octets. 279 If the Segment List is already 8-byte aligned, there is no need to 280 have a Padding field. 282 Optional TLVs: To be defined in future. 284 5. Generating E-SRH 286 For a segment list , the headend can encode it in 287 E-SRH. S1 is placed to DA field of IPv6 header, and S1 to Sn can be 288 also placed in the Segment 1 to Segment N fields respectively. 289 Because S1 is also placed in the Segment 1 field, Offset field needs 290 to be set to the value that point to tuple, 291 i.e., Offset = sizeof . In addition, Segment 292 Left field is set to n-1, which means there are n-1 Segments left to 293 be processed in the Segment List. 295 For the above segment list , the headend may not 296 place S1 in E-SRH again, then E-SRH only needs to contain n-1 297 segments. In this case, S2 to Sn will be placed in the Segment 1 to 298 Segment N-1 fields respectively. Offset needs to be set to the value 299 that point to , i.e., Offset = 0. In 300 addition, Segment Left field is still set to n-1, which means there 301 are n-1 segments left to be processed in the Segment List. 303 6. Processing E-SRH 305 E-SRH is examined and processed when the IPv6 packet reaches the node 306 identified in the Destination Address field of the IPv6 header. In 307 that node, dispatching on the Next Header field of the immediately 308 preceding header causes the Routing header module to be invoked. 310 The following describes the algorithm performed when processing an 311 E-SRH: 313 If next argument item is needed in the current segment processing { 314 Read the next tuple which is pointed by 315 current Offset field: 316 Type 15(Arg), Segment's length is determined by Cmpr field; 318 If Type is not 15 { 319 Send an ICMP Parameter Problem, Code 0, message to the Source 320 Address, pointing to the Offset field, and discard the packet; 321 } 323 Offset += sizeof (next ); 324 if Offset > List Len * 8 { 325 Send an ICMP Parameter Problem, Code 0, message to the Source 326 Address, pointing to the Offset field, and discard the packet; 327 } 329 Continues the remaining processing of the current element with 330 additional aruguments (note: long argument if necessary, instead 331 of using multiple arguments); 333 } 335 if Segments Left = 0 { 336 proceed to process the next header in the packet, whose type is 337 identified by the Next Header field in the Routing header; 338 } 339 else { 340 Read the next tuple which is pointed by 341 current Offset field, in detailed: 342 For Type 0, Segment's length is determined by Cmpr field; 343 For Type 1-8, Segment's length is 1-8 bytes respectively; 344 For Type 9(MPLS), Segment's length is 3 bytes; 345 For Type 10-11(index), Segment's length is 4 bytes; 347 If Type is 15 or unknown { 348 Send an ICMP Parameter Problem, Code 0, message to the Source 349 Address, pointing to the Offset field, and discard the packet; 350 } 352 Offset += sizeof (next ); 354 if Offset > List Len * 8 { 355 Send an ICMP Parameter Problem, Code 0, message to the Source 356 Address, pointing to the Offset field, and discard the packet; 357 } 359 decrement Segments Left by 1; 360 Copy the stiched/mapped IPv6 address to the destination address 361 of the IPv6 header; 363 if the IPv6 Hop Limit is less than or equal to 1 { 364 send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit 365 message to the Source Address and discard the packet; 366 } 367 else { 368 decrement the IPv6 Hop Limit by 1; 369 resubmit the packet to the IPv6 module for transmission to the 370 new destination; 371 } 372 } 374 7. Deployment Considerations 376 This section analyzes some deployment considerations faced by E-SRH. 378 7.1. Heterogeneous Segment List 380 E-SRH can support a combination of various type of segments in a 381 single Segment List to reduce encapsulation size. This can be used 382 in scenarios that an E2E Segment List may across multiple domains and 383 each domain has different segment encapsulation style. 385 It is important for the border node that connected multiple domains 386 to use Segment sharing the same prefix with each domain as much as 387 possible, otherwise, a Segment that is 128 bit of IPv6 address may be 388 inserted in the Segment List, to provide new prefix information for 389 the next domain. 391 7.2. Independent Arguments in E-SRH 393 E-SRH can store independent elements as argument that has local 394 meaning and is used by the the immediately preceding segment. 395 Because the argument type of segment has only local meaning, it does 396 not consume the global address resources. This is very helpful for 397 supporting a large number of services in some networks with limited 398 address space. 400 Note that in E-SRH a Segment can also directly contain the argument 401 with it, i.e, in the same field. How to distinguish where the 402 argument exist depends on the behavior of the Segment. 404 7.3. ICMP Error Processing 406 The invoking packet in the ICMP error message may contain an E-SRH. 407 Since the destination address of a packet with an E-SRH changes as 408 each segment is processed, it may not be the destination used by the 409 socket or application that generated the invoking packet. 411 For the source of an invoking packet to process the ICMP error 412 message, the ultimate destination address of the IPv6 header may be 413 required. The following logic is used to determine the destination 414 address for use by protocol-error handlers. 416 Walk all extension headers of the invoking IPv6 packet to the 417 routing extension header preceding the upper-layer header. 419 If routing header is type E-SRH 421 Walk to the Segment List[N] (should not be an argument or 422 index) which may be used as the destination address of the 423 invoking packet. 425 7.4. Repair Path 427 The mechanism defined in [I-D.ietf-rtgwg-segment-routing-ti-lfa] can 428 be used to provide protection of nodes and links within an IGP area. 429 The repair path can be representd as a Segment List which can be 430 encoded in a separate E-SRH. The Point of Local Repair (PLR) maybe 431 the headend or midpoint of the original path. According to 432 [RFC8200], E-SRH must also not be processed, inserted, or deleted by 433 any node along a packet's delivery path, until the packet reaches the 434 node identified in the Destination Address field of the IPv6 header. 435 Thus, for midpoint an outer IPv6 header with its own E-SRH need to be 436 added to the received IPv6 packet, when the packet is delivered along 437 a repair path. However, it is possible for headend to encode 438 multiple E-SRHs within a single IPv6 header when it initiates a 439 packet that is delivered along a repair pat. In any case, when the 440 outer E-SRH is finished, the inner E-SRH is continued to be 441 processed. Whether it's the inner E-SRH or the outer E-SRH, in order 442 to achieve better compression efficiency, the first Segment (similar 443 to RH3) is compressed as much as possible. 445 [I-D.ietf-rtgwg-segment-routing-ti-lfa] also described in some cases 446 when the failure node or link is just the active segment, and the 447 method is to ignore the active segment and continue to get next 448 segment to keep as much as possible the traffic on the pre-failure 449 path. E-SRH can do this easily by simply reading the next tuple from the list. 452 7.5. Binding to Outer Segment List 454 Any nodes (headend or midpoint) along the original Segment List may 455 also bind the packets to an outer Segment List based on local policy. 456 For example, the headend may steer packets along an outer Segment 457 List to the first Segment, and multiple E-SRHs may be encoded within 458 a single IPv6 header in the initated packets. A midpoint may also 459 steer packets along an outer Segment List to the next Segment, and an 460 outer IPv6 header with its own E-SRH need to be added to the received 461 IPv6 packet. In any case, when the outer E-SRH is finished, the 462 inner E-SRH is continued to be processed. 464 7.6. In-situ OAM 466 OAM and PM information from the segment endpoints can be piggybacked 467 in the data packet. The OAM and PM information piggybacking in the 468 data packets is also known as In-situ OAM (IOAM). IOAM records 469 operational and telemetry information in the data packet while the 470 packet traverses a path between two points in the network. 471 [I-D.ietf-ippm-ioam-data] defines the IOAM data, and 472 [I-D.ietf-ippm-ioam-ipv6-options] defines how to carry IOAM data in 473 "option data" fields using two types of extension headers in IPv6 474 packets - either Hop-by-Hop Options header or Destination options 475 header. Next version of this document will define how IOAM data 476 fields are transported as part of E-SRH. 478 E-SRH complies with [RFC8200], and the Segment Left field strictly 479 represents the number of explicitly listed intermediate nodes still 480 to be visited before reaching the final destination. Thus, Segment 481 Left can be used as local index at which it is expected to record 482 endpoint's data in the IOAM data space. 484 7.7. NAT Service Funtion 486 A NAT service funtion SR-MPLS or SRv6 SID can be encoded in the 487 Segment List field of the E-SRH. The related NAT Service entity may 488 modify the destination address in the packets they process. At the 489 endpoint that associated with NAT service entity, the updated 490 Destination Address need to be copied back into the Segment List[N] 491 (i.e, the final destination) of the E-SRH. Although E-SRH contains 492 compressed Segments, it can walk to the last 493 tuple and write the updated address. Note that in this case the type 494 of last Segment must not be an argument or index, and must share 495 prefix with the updated address. 497 7.8. Operation and Maintenance 499 To be convenient for operation and maintenance, E-SRH provide 500 necessary information to enable offline tools to parse the IPv6 501 header and analysis Segment List, without the help of states of the 502 control plane. No matter how the state of the control plane vibrates 503 and changes, for example, the purpose of a Segment may be changed 504 from service A to service B, but the parsing of the packet itself is 505 stable and not affected. This is very convenient for network 506 debugging, operators can clearly know the specific Segment List 507 information encapsulated in E-SRH, check problems and locate them. 509 7.9. Upper-Layer Checksums 511 [RFC8200] specifies that any transport or other upper-layer protocol 512 that includes the addresses from the IP header in its checksum 513 computation must be modified for use over IPv6, to include the 514 128-bit IPv6 addresses. If the IPv6 packet contains a Routing 515 header, the Destination Address used in the pseudo-header is that of 516 the final destination. At the originating node, that address will be 517 in the last element of the Routing header; at the recipient(s), that 518 address will be in the Destination Address field of the IPv6 header. 520 For E-SRH, at the headend, the Destination Address used in the 521 pseudo-header is the final destination that is before uncompression. 523 8. Security Considerations 525 The E-SRH domain is treated as a trusted domain, and the nodes 526 outside the E-SRH domain are not trusted. This is enforced by two 527 levels of access control lists: 529 On the ingress of E-SRH domain, any packet entering the E-SRH 530 domain and destined to an IPv6 address within the E-SRH domain, is 531 dropped. 533 On the transit or egress of E-SRH domain, any packet with a 534 destination address within the E-SRH domain but the source address 535 not within, is dropped. 537 It will block the attacks documented in [RFC5095] from outside the 538 E-SRH domain, including bypassing filtering devices, reaching 539 otherwise-unreachable Internet systems, network topology discovery, 540 bandwidth exhaustion, and defeating anycast. 542 Additionally, domains deny traffic with spoofed addresses by 543 implementing the recommendations in BCP 84 [RFC3704]. 545 [RFC6554] requires RPL routers to check for loops in the SRH and drop 546 datagrams that contain such loops. However, for the flexibility of 547 Segment List programming for any scenario, E-SRH doesn't do this 548 check, but relevant security mechanisms to avoid tampering with 549 Segment List should be adopted, such as HMAC mechanism introduced in 550 [RFC8754]. 552 The generation of ICMPv6 error messages may be used to attempt 553 denial-of-service attacks by sending an error-causing E-SRH in back- 554 to-back datagrams. An implementation that correctly follows 555 Section 2.4 of [RFC4443] would be protected by the ICMPv6 rate- 556 limiting mechanism. 558 9. Acknowledgements 560 TBD 562 10. Normative References 564 [I-D.ietf-ippm-ioam-data] 565 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 566 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 567 progress), July 2020. 569 [I-D.ietf-ippm-ioam-ipv6-options] 570 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 571 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 572 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 573 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 574 ipv6-options-04 (work in progress), November 2020. 576 [I-D.ietf-lsr-flex-algo] 577 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 578 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 579 algo-13 (work in progress), October 2020. 581 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 582 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 583 Francois, P., Voyer, D., Clad, F., and P. Camarillo, 584 "Topology Independent Fast Reroute using Segment Routing", 585 draft-ietf-rtgwg-segment-routing-ti-lfa-04 (work in 586 progress), August 2020. 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, 590 DOI 10.17487/RFC2119, March 1997, 591 . 593 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 594 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 595 2004, . 597 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 598 Control Message Protocol (ICMPv6) for the Internet 599 Protocol Version 6 (IPv6) Specification", STD 89, 600 RFC 4443, DOI 10.17487/RFC4443, March 2006, 601 . 603 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 604 of Type 0 Routing Headers in IPv6", RFC 5095, 605 DOI 10.17487/RFC5095, December 2007, 606 . 608 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 609 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 610 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 611 Low-Power and Lossy Networks", RFC 6550, 612 DOI 10.17487/RFC6550, March 2012, 613 . 615 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 616 Routing Header for Source Routes with the Routing Protocol 617 for Low-Power and Lossy Networks (RPL)", RFC 6554, 618 DOI 10.17487/RFC6554, March 2012, 619 . 621 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 622 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 623 May 2017, . 625 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 626 (IPv6) Specification", STD 86, RFC 8200, 627 DOI 10.17487/RFC8200, July 2017, 628 . 630 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 631 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 632 Explicit Replication (BIER)", RFC 8279, 633 DOI 10.17487/RFC8279, November 2017, 634 . 636 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 637 Decraene, B., Litkowski, S., and R. Shakir, "Segment 638 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 639 July 2018, . 641 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 642 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 643 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 644 . 646 Author's Address 648 Han Jie 649 ZTE Corporation 650 China 652 Email: han.jie1@zte.com.cn