idnits 2.17.1 draft-ali-6man-spring-srv6-oam-02.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1726 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: 'SL' is mentioned on line 191, but not defined -- Looks like a reference, but probably isn't: '2' on line 192 -- Looks like a reference, but probably isn't: '1' on line 192 -- Looks like a reference, but probably isn't: '0' on line 193 == Missing Reference: 'I-D.ietf-idr-bgpls-srv6-ext' is mentioned on line 232, but not defined == Missing Reference: 'RFC792' is mentioned on line 835, but not defined == Missing Reference: 'RFC 8403' is mentioned on line 801, but not defined == Unused Reference: 'RFC0792' is defined on line 951, but no explicit reference was found in the text == Unused Reference: 'RFC8403' is defined on line 971, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Z. Ali 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems 5 Expires: January 9, 2020 S. Matsushima 6 Softbank 7 D. Voyer 8 Bell Canada 9 M. Chen 10 Huawei 11 July 8, 2019 13 Operations, Administration, and Maintenance (OAM) in Segment Routing 14 Networks with IPv6 Data plane (SRv6) 15 draft-ali-6man-spring-srv6-oam-02 17 Abstract 19 This document defines building blocks for Operations, Administration, 20 and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane 21 (SRv6). The document also describes some SRv6 OAM mechanisms. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 9, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 65 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Terminology and Reference Topology . . . . . . . . . . . 3 67 3. OAM Building Blocks . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. O-flag in Segment Routing Header . . . . . . . . . . . . 5 69 3.1.1. O-flag Processing . . . . . . . . . . . . . . . . . . 6 70 3.2. OAM Segments . . . . . . . . . . . . . . . . . . . . . . 6 71 3.3. End.OP: OAM Endpoint with Punt . . . . . . . . . . . . . 6 72 3.4. End.OTP: OAM Endpoint with Timestamp and Punt . . . . . . 7 73 3.5. SRH TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. OAM Mechanisms . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Ping . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.1.1. Classic Ping . . . . . . . . . . . . . . . . . . . . 8 77 4.1.2. Pinging a SID Function . . . . . . . . . . . . . . . 9 78 4.1.3. Error Reporting . . . . . . . . . . . . . . . . . . . 12 79 4.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.2.1. Classic Traceroute . . . . . . . . . . . . . . . . . 13 81 4.2.2. Traceroute to a SID Function . . . . . . . . . . . . 14 82 4.3. Monitoring of SRv6 Paths . . . . . . . . . . . . . . . . 18 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 6.1. ICMPv6 type Numbers RegistrySEC . . . . . . . . . . . . . 19 86 6.2. SRv6 OAM Endpoint Types . . . . . . . . . . . . . . . . . 19 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 88 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 91 9.2. Informative References . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 94 1. Introduction 96 This document defines building blocks for Operations, Administration, 97 and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane 98 (SRv6). The document also describes some SRv6 OAM mechanisms. 100 2. Conventions Used in This Document 102 2.1. Abbreviations 104 The following abbreviations are used in this document: 106 SID: Segment ID. 108 SL: Segment Left. 110 SR: Segment Routing. 112 SRH: Segment Routing Header. 114 SRv6: Segment Routing with IPv6 Data plane. 116 TC: Traffic Class. 118 ICMPv6: multi-part ICMPv6 messages [RFC4884]. 120 2.2. Terminology and Reference Topology 122 This document uses the terminology defined in [I-D.ietf- spring-srv6- 123 network-programming]. The readers are expected to be familiar with 124 the same. 126 Throughout the document, the following simple topology is used for 127 illustration. 129 +--------------------------| N100 |------------------------+ 130 | | 131 ====== link1====== link3------ link5====== link9------ 132 ||N1||======||N2||======| N3 |======||N4||======| N5 | 133 || ||------|| ||------| |------|| ||------| | 134 ====== link2====== link4------ link6======link10------ 135 | | 136 | ------ | 137 +-------| N6 |---------+ 138 link7 | | link8 139 ------ 141 Figure 1 Reference Topology 143 In the reference topology: 145 Nodes N1, N2, and N4 are SRv6 capable nodes. 147 Nodes N3, N5 and N6 are classic IPv6 nodes. 149 Node N100 is a controller. 151 Node k has a classic IPv6 loopback address A:k::/128. 153 A SID at node k with locator block B and function F is represented 154 by B:k:F::. 156 The IPv6 address of the nth Link between node X and Y at the X 157 side is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address 158 of link6 (the 2nd link) between N3 and N4 at N3 in Figure 1 is 159 2001:DB8:3:4:32::. Similarly, the IPv6 address of link5 (the 1st 160 link between N3 and N4) at node 3 is 2001:DB8:3:4:31::. 162 B:k:Cij:: is explicitly allocated as the END.X function at node k 163 towards neighbor node i via jth Link between node i and node j. 164 e.g., B:2:C31:: represents END.X at N2 towards N3 via link3 (the 165 1st link between N2 and N3). Similarly, B:4:C52:: represents the 166 END.X at N4 towards N5 via link10. 168 A SID list is represented as where S1 is the first 169 SID to visit, S2 is the second SID to visit and S3 is the last SID 170 to visit along the SR path. 172 (SA,DA) (S3, S2, S1; SL)(payload) represents an IPv6 packet with: 174 * IPv6 header with source address SA, destination addresses DA 175 and SRH as next-header 177 * SRH with SID list with SegmentsLeft = SL 179 * Note the difference between the < > and () symbols: represents a SID list where S1 is the first SID and S3 is 181 the last SID to traverse. (S3, S2, S1; SL) represents the same 182 SID list but encoded in the SRH format where the rightmost SID 183 in the SRH is the first SID and the leftmost SID in the SRH is 184 the last SID. When referring to an SR policy in a high-level 185 use-case, it is simpler to use the notation. When 186 referring to an illustration of the detailed packet behavior, 187 the (S3, S2, S1; SL) notation is more convenient. 189 * (payload) represents the the payload of the packet. 191 SRH[SL] represents the SID pointed by the SL field in the first 192 SRH. In our example, SRH[2] represents S1, SRH[1] represents S2 193 and SRH[0] represents S3. 195 3. OAM Building Blocks 197 This section defines the various building blocks for implementing OAM 198 mechanisms in SRv6 networks. 200 3.1. O-flag in Segment Routing Header 202 [I-D.ietf-6man-segment-routing-header] describes the Segment Routing 203 Header (SRH) and how SR capable nodes use it. The SRH contains an 204 8-bit "Flags" field [I-D.draft-ietf-6man-segment- routing-header]. 205 This document defines the following bit in the SRH.Flags to carry the 206 O-flag: 208 0 1 2 3 4 5 6 7 209 +-+-+-+-+-+-+-+-+ 210 | |O| | 211 +-+-+-+-+-+-+-+-+ 213 Where: 215 O-flag: OAM flag. When set, it indicates that this packet is an 216 operations and management (OAM) packet. This document defines the 217 usage of the O-flag in the SRH.Flags. 219 The document does not define any other flag in the SRH.Flags and 220 meaning and processing of any other bit in SRH.Flags is outside of 221 the scope of this document. 223 3.1.1. O-flag Processing 225 Implementation of the O-flag is OPTIONAL. A node MAY ignore 226 SRH.Flags.O-flag. It is also possible that a node is capable of 227 supporting the O-bit but based on a local decision it MAY ignore it 228 during processing on some local SIDs. If a node does not support the 229 O-flag, then upon reception it simply ignores it. If a node supports 230 the O-flag, it can optionally advertise its potential via node 231 capability advertisement in IGP [I-D.ietf-isis-srv6- extensions] and 232 BGP-LS [I-D.ietf-idr-bgpls-srv6-ext]. 234 The SRH.Flags.O-flag implements the "punt a timestamped copy and 235 forward" behavior. 237 When N receives a packet whose IPv6 DA is S and S is a local SID, N 238 executes the following pseudo-code, before the execution of the local 239 SID S. 241 1. IF SRH.Flags.O-flag is one and local configuration permits THEN 242 a. Make a copy of the packet. 243 b. Send the copied packet, along with an accurate timestamp 244 to the OAM process. ;; Ref1 245 Ref1: An implementation SHOULD copy and record the timestamp as soon as 246 possible during packet processing. Timestamp is not carried in the packet 247 forwarded to the next hop. 249 3.2. OAM Segments 251 OAM Segment IDs (SIDs) is another component of the SRv6 OAM building 252 Blocks. This document defines a couple of OAM SIDs. 254 3.3. End.OP: OAM Endpoint with Punt 256 Many scenarios require punting of SRv6 OAM packets at the desired 257 nodes in the network. The "OAM Endpoint with Punt" function (End.OP 258 for short) represents a particular OAM function to implement the punt 259 behavior for an OAM packet. It is described using the pseudocode as 260 follows: 262 When N receives a packet destined to S and S is a local End.OP SID, N 263 does: 265 1. Send the packet to the OAM process 267 Please note that in an SRH containing END.OP SID, it is RECOMMENDED 268 to set the SRH.Flags.O-flag = 0. 270 3.4. End.OTP: OAM Endpoint with Timestamp and Punt 272 Scenarios demanding performance management of an SR policy/ path 273 requires hardware timestamping before hardware punts the packet to 274 the software for OAM processing. The "OAM Endpoint with Timestamp 275 and Punt" function (End.OTP for short) represents an OAM SID function 276 to implement the timestamp and punt behavior for an OAM packet. It 277 is described using the pseudocode as follows: 279 When N receives a packet destined to S and S is a local End.OTP SID, 280 N does: 282 1. Timestamp the packet ;; Ref1 284 2. Send the packet, along with an accurate timestamp, to the OAM process. 286 Ref1: Timestamping SHOULD be done in hardware, as soon as possible 287 during the packet processing. 289 Please note that in an SRH containing END.OTP SID, it is RECOMMENDED 290 to set the SRH.Flags.O-flag = 0. 292 3.5. SRH TLV 294 [I-D.ietf-6man-segment-routing-header] defines TLVs of the Segment 295 Routing Header. 297 SRH TLV plays an important role in carrying OAM and Performance 298 Management (PM) metadata. 300 4. OAM Mechanisms 302 This section describes how OAM mechanisms can be implemented using 303 the OAM building blocks described in the previous section. 304 Additional OAM mechanisms will be added in a future revision of the 305 document. 307 [RFC4443] describes Internet Control Message Protocol for IPv6 308 (ICMPv6) that is used by IPv6 devices for network diagnostic and 309 error reporting purposes. As Segment Routing with IPv6 data plane 310 (SRv6) simply adds a new type of Routing Extension Header, existing 311 ICMPv6 ping mechanisms can be used in an SRv6 network. This section 312 describes the applicability of ICMPv6 in the SRv6 network and how the 313 existing ICMPv6 mechanisms can be used for providing OAM 314 functionality. 316 The document does not propose any changes to the standard ICMPv6 317 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. 319 4.1. Ping 321 There is no hardware or software change required for ping operation 322 at the classic IPv6 nodes in an SRv6 network. That includes the 323 classic IPv6 node with ingress, egress or transit roles. 324 Furthermore, no protocol changes are required to the standard ICMPv6 325 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. In other words, 326 existing ICMP ping mechanisms work seamlessly in the SRv6 networks. 328 The following subsections outline some use cases of the ICMP ping in 329 the SRv6 networks. 331 4.1.1. Classic Ping 333 The existing mechanism to ping a remote IP prefix, along the shortest 334 path, continues to work without any modification. The initiator may 335 be an SRv6 node or a classic IPv6 node. Similarly, the egress or 336 transit may be an SRv6 capable node or a classic IPv6 node. 338 If an SRv6 capable ingress node wants to ping an IPv6 prefix via an 339 arbitrary segment list , it needs to initiate ICMPv6 ping 340 with an SR header containing the SID list . This is 341 illustrated using the topology in Figure 1. Assume all the links 342 have IGP metric 10 except both links between node2 and node3, which 343 have IGP metric set to 100. User issues a ping from node N1 to a 344 loopback of node 5, via segment list . 346 Figure 2 contains sample output for a ping request initiated at node 347 N1 to the loopback address of node N5 via a segment list . 350 > ping A:5:: via segment-list B:2:C31, B:4:C52 352 Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: 353 !!!!! 354 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 355 /0.749/0.931 ms 357 Figure 2 A sample ping output at an SRv6 capable node 359 All transit nodes process the echo request message like any other 360 data packet carrying SR header and hence do not require any change. 361 Similarly, the egress node (IPv6 classic or SRv6 capable) does not 362 require any change to process the ICMPv6 echo request. For example, 363 in the ping example of Figure 2: 365 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 366 (A:1::, B:2:C31)(A:5::, B:4:C52, B:2:C31, SL=2, NH = 367 ICMPv6)(ICMPv6 Echo Request). 369 o Node N2, which is an SRv6 capable node, performs the standard SRH 370 processing. Specifically, it executes the END.X function 371 (B:2:C31) and forwards the packet on link3 to N3. 373 o Node N3, which is a classic IPv6 node, performs the standard IPv6 374 processing. Specifically, it forwards the echo request based on 375 DA B:4:C52 in the IPv6 header. 377 o Node N4, which is an SRv6 capable node, performs the standard SRH 378 processing. Specifically, it observes the END.X function 379 (B:4:C52) with PSP (Penultimate Segment POP) on the echo request 380 packet and removes the SRH and forwards the packet across link10 381 to N5. 383 o The echo request packet at N5 arrives as an IPv6 packet without an 384 SRH. Node N5, which is a classic IPv6 node, performs the standard 385 IPv6/ ICMPv6 processing on the echo request and responds, 386 accordingly. 388 4.1.2. Pinging a SID Function 390 The classic ping described in the previous section cannot be used to 391 ping a remote SID function, as explained using an example in the 392 following. 394 Consider the case where the user wants to ping the remote SID 395 function B:4:C52, via B:2:C31, from node N1. Node N1 constructs the 396 ping packet (A:1::, B:2:C31)(B:4:C52, B:2:C31, SL=1; 397 NH=ICMPv6)(ICMPv6 Echo Request). The ping fails because the node N4 398 receives the ICMPv6 echo request with DA set to B:4:C52 but the next 399 header is ICMPv6, instead of SRH. To solve this problem, the 400 initiator needs to mark the ICMPv6 echo request as an OAM packet. 402 The OAM packets are identified either by setting the O-flag in SRH or 403 by inserting the END.OP/ END.OTP SIDs at an appropriate place in the 404 SRH. The following illustration uses END.OTP SID but the procedures 405 are equally applicable to the END.OP SID. 407 In an SRv6 network, the user can exercise two flavors of the ping: 408 end-to-end ping or segment-by-segment ping, as outlined in the 409 following subsection. 411 4.1.2.1. End-to-end ping using END.OP/ END.OTP 413 The end-to-end ping illustration uses the END.OTP SID but the 414 procedures are equally applicable to the END.OP SID. 416 Consider the same example where the user wants to ping a remote SID 417 function B:4:C52, via B:2:C31, from node N1. To force a punt of the 418 ICMPv6 echo request at the node N4, node N1 inserts the END.OTP SID 419 just before the target SID B:4:C52 in the SRH. The ICMPv6 echo 420 request is processed at the individual nodes along the path as 421 follows: 423 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 424 (A:1::, B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; 425 NH=ICMPv6)(ICMPv6 Echo Request). 427 o Node N2, which is an SRv6 capable node, performs the standard SRH 428 processing. Specifically, it executes the END.X function 429 (B:2:C31) on the echo request packet. 431 o Node N3 receives the packet as follows (A:1::, B:4:OTP)(B:4:C52, 432 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request). Node 433 N3, which is a classic IPv6 node, performs the standard IPv6 434 processing. Specifically, it forwards the echo request based on 435 DA B:4:OTP in the IPv6 header. 437 o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 438 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it 439 processes the END.OTP SID, as described in the pseudocode in 440 Section 3. The packet gets punted to the ICMPv6 process for 441 processing. The ICMPv6 process checks if the next SID in SRH (the 442 target SID B:4:C52) is locally programmed. 444 o If the target SID is not locally programmed, N4 responses with the 445 ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally 446 implemented (TBA)"); otherwise a success is returned. 448 4.1.2.2. Segment-by-segment ping using O-flag (Proof of Transit) 450 Consider the same example where the user wants to ping a remote SID 451 function B:4:C52, via B:2:C31, from node N1. However, in this ping, 452 the node N1 wants to get a response from each segment node in the SRH 453 as a "proof of transit". In other words, in the segment-by-segment 454 ping case, the node N1 expects a response from node N2 and node N4 455 for their respective local SID function. When a response to O-bit is 456 desired from the last SID in a SID-list, it is the responsibility of 457 the ingress node to use USP as the last SID. E.g., in this example, 458 the target SID B:4:C52 is a USP SID. 460 To force a punt of the ICMPv6 echo request at node N2 and node N4, 461 node N1 sets the O-flag in SRH. The ICMPv6 echo request is processed 462 at the individual nodes along the path as follows: 464 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 465 (A:1::, B:2:C31)(B:4:C52, B:2:C31; SL=1, Flags.O=1; 466 NH=ICMPv6)(ICMPv6 Echo Request). 468 o When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 469 B:2:C31; SL=1, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request) packet, 470 it processes the O-flag in SRH, as described in the pseudocode in 471 Section 3. A time-stamped copy of the packet gets punted to the 472 ICMPv6 process for processing. Node N2 continues to apply the 473 B:2:C31 SID function on the original packet and forwards it, 474 accordingly. As B:4:C52 is a USP SID, N2 does not remove the SRH. 475 The ICMPv6 process at node N2 checks if its local SID (B:2:C31) is 476 locally programmed or not and responds to the ICMPv6 Echo Request. 478 o If the target SID is not locally programmed, N4 responses with the 479 ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally 480 implemented (TBA)"); otherwise a success is returned. Please note 481 that, as mentioned in Section 3, if node N2 does not support the 482 O-flag, it simply ignores it and process the local SID, B:2:C31. 484 o Node N3, which is a classic IPv6 node, performs the standard IPv6 485 processing. Specifically, it forwards the echo request based on 486 DA B:4:C52 in the IPv6 header. 488 o When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 489 B:2:C31; SL=0, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request), it 490 processes the O-flag in SRH, as described in the pseudocode in 491 Section 3. A time-stamped copy of the packet gets punted to the 492 ICMPv6 process for processing. The ICMPv6 process at node N4 493 checks if its local SID (B:2:C31) is locally programmed or not and 494 responds to the ICMPv6 Echo Request. If the target SID is not 495 locally programmed, N4 responses with the ICMPv6 message (Type: 496 "SRv6 OAM (TBA)", Code: "SID not locally implemented (TBA)"); 497 otherwise a success is returned. 499 Support for O-flag is part of node capability advertisement. That 500 enables node N1 to know which segment nodes are capable of responding 501 to the ICMPv6 echo request. Node N1 processes the echo responses and 502 presents data to the user, accordingly. 504 Please note that segment-by-segment ping can be used to address proof 505 of transit use-case. 507 4.1.3. Error Reporting 509 Any IPv6 node can use ICMPv6 control messages to report packet 510 processing errors to the host that originated the datagram packet. 511 To name a few such scenarios: 513 o If the router receives an undeliverable IP datagram, or 515 o If the router receives a packet with a Hop Limit of zero, or 517 o If the router receives a packet such that if the router decrements 518 the packet's Hop Limit it becomes zero, or 520 o If the router receives a packet with problem with a field in the 521 IPv6 header or the extension headers such that it cannot complete 522 processing the packet, or 524 o If the router cannot forward a packet because the packet is larger 525 than the MTU of the outgoing link. 527 In the scenarios listed above, the ICMPv6 response also contains the 528 IP header, IP extension headers and leading payload octets of the 529 "original datagram" to which the ICMPv6 message is a response. 530 Specifically, the "Destination Unreachable Message", "Time Exceeded 531 Message", "Packet Too Big Message" and "Parameter Problem Message" 532 ICMPV6 messages can contain as much of the invoking packet as 533 possible without the ICMPv6 packet exceeding the minimum IPv6 MTU 534 [RFC4443], [RFC4884]. In an SRv6 network, the copy of the invoking 535 packet contains the SR header. The packet originator can use this 536 information for diagnostic purposes. For example, traceroute can use 537 this information as detailed in the following subsection. 539 4.2. Traceroute 541 There is no hardware or software change required for traceroute 542 operation at the classic IPv6 nodes in an SRv6 network. That 543 includes the classic IPv6 node with ingress, egress or transit roles. 544 Furthermore, no protocol changes are required to the standard 545 traceroute operations. In other words, existing traceroute 546 mechanisms work seamlessly in the SRv6 networks. 548 The following subsections outline some use cases of the traceroute in 549 the SRv6 networks. 551 4.2.1. Classic Traceroute 553 The existing mechanism to traceroute a remote IP prefix, along the 554 shortest path, continues to work without any modification. The 555 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 556 egress or transit may be an SRv6 node or a classic IPv6 node. 558 If an SRv6 capable ingress node wants to traceroute to IPv6 prefix 559 via an arbitrary segment list , it needs to initiate 560 traceroute probe with an SR header containing the SID list . That is illustrated using the topology in Figure 1. Assume all 562 the links have IGP metric 10 except both links between node2 and 563 node3, which have IGP metric set to 100. User issues a traceroute 564 from node N1 to a loopback of node 5, via segment list . Figure 3 contains sample output for the traceroute 566 request. 568 > traceroute A:5:: via segment-list B:2:C31, B:4:C52 570 Tracing the route to B5:: 571 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 572 SRH: (A:5::, B:4:C52, B:2:C31, SL=2) 573 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec 574 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 575 3 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 576 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 577 4 2001:DB8:4:5::52:: 0.879 msec 0.916 msec 1.024 msec 579 Figure 3 A sample traceroute output at an SRv6 capable node 581 Please note that information for hop2 is returned by N3, which is a 582 classic IPv6 node. Nonetheless, the ingress node is able to display 583 SR header contents as the packet travels through the IPv6 classic 584 node. This is because the "Time Exceeded Message" ICMPv6 message can 585 contain as much of the invoking packet as possible without the ICMPv6 586 packet exceeding the minimum IPv6 MTU [RFC4443]. The SR header is 587 also included in these ICMPv6 messages initiated by the classic IPv6 588 transit nodes that are not running SRv6 software. Specifically, a 589 node generating ICMPv6 message containing a copy of the invoking 590 packet does not need to understand the extension header(s) in the 591 invoking packet. 593 The segment list information returned for hop1 is returned by N2, 594 which is an SRv6 capable node. Just like for hop2, the ingress node 595 is able to display SR header contents for hop1. 597 There is no difference in processing of the traceroute probe at an 598 IPv6 classic node and an SRv6 capable node. Similarly, both IPv6 599 classic and SRv6 capable nodes may use the address of the interface 600 on which probe was received as the source address in the ICMPv6 601 response. ICMP extensions defined in [RFC5837] can be used to also 602 display information about the IP interface through which the datagram 603 would have been forwarded had it been forwardable, and the IP next 604 hop to which the datagram would have been forwarded, the IP interface 605 upon which a datagram arrived, the sub-IP component of an IP 606 interface upon which a datagram arrived. 608 The information about the IP address of the incoming interface on 609 which the traceroute probe was received by the reporting node is very 610 useful. This information can also be used to verify if SID functions 611 B:2:C31 and B:4:C52 are executed correctly by N2 and N4, 612 respectively. Specifically, the information displayed for hop2 613 contains the incoming interface address 2001:DB8:2:3:31:: at N3. 614 This matches with the expected interface bound to END.X function 615 B:2:C31 (link3). Similarly, the information displayed for hop5 616 contains the incoming interface address 2001:DB8:4:5::52:: at N5. 617 This matches with the expected interface bound to the END.X function 618 B:4:C52 (link10). 620 4.2.2. Traceroute to a SID Function 622 The classic traceroute described in the previous section cannot be 623 used to traceroute a remote SID function, as explained using an 624 example in the following. 626 Consider the case where the user wants to traceroute the remote SID 627 function B:4:C52, via B:2:C31, from node N1. The trace route fails 628 at N4. This is because the node N4 trace route probe where next 629 header is UDP or ICMPv6, instead of SRH (even though the hop limit is 630 set to 1). To solve this problem, the initiator needs to mark the 631 ICMPv6 echo request as an OAM packet. 633 The OAM packets are identified either by setting the O-flag in SRH or 634 by inserting the END.OP or END.OTP SID at an appropriate place in the 635 SRH. 637 In an SRv6 network, the user can exercise two flavors of the 638 traceroute: hop-by-hop traceroute or overlay traceroute. 640 o In hop-by-hop traceroute, user gets responses from all nodes 641 including classic IPv6 transit nodes, SRv6 capable transit nodes 642 as well as SRv6 capable segment endpoints. E.g., consider the 643 example where the user wants to traceroute to a remote SID 644 function B:4:C52, via B:2:C31, from node N1. The traceroute 645 output will also display information about node3, which is a 646 transit (underlay) node. 648 o The overlay traceroute, on the other hand, does not trace the 649 underlay nodes. In other words, the overlay traceroute only 650 displays the nodes that acts as SRv6 segments along the route. 651 I.e., in the example where the user wants to traceroute to a 652 remote SID function B:4:C52, via B:2:C31, from node N1, the 653 overlay traceroute would only display the traceroute information 654 from node N2 and node N4; it will not display information from 655 node 3. 657 4.2.2.1. Hop-by-hop traceroute using END.OP/ END.OTP 659 In this section, hop-by-hop traceroute to a SID function is 660 exemplified using UDP probes. However, the procedure is equally 661 applicable to other implementation of traceroute mechanism. 662 Furthermore, the illustration uses the END.OTP SID but the procedures 663 are equally applicable to the END.OP SID. 665 Consider the same example where the user wants to traceroute to a 666 remote SID function B:4:C52, via B:2:C31, from node N1. To force a 667 punt of the traceroute probe only at the node N4, node N1 inserts the 668 END.OTP SID just before the target SID B:4:C52 in the SRH. The 669 traceroute probe is processed at the individual nodes along the path 670 as follows: 672 o Node N1 initiates a traceroute probe packet with a monotonically 673 increasing value of hop count and SRH as follows (A:1::, 674 B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; NH=UDP)(Traceroute 675 probe). 677 o When node N2 receives the packet with hop-count = 1, it processes 678 the hop count expiry. Specifically, the node N2 responses with 679 the ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live 680 exceeded in Transit"). 682 o When Node N2 receives the packet with hop-count > 1, it performs 683 the standard SRH processing. Specifically, it executes the END.X 684 function (B:2:C31) on the traceroute probe. 686 o When node N3, which is a classic IPv6 node, receives the packet 687 (A:1::, B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; HC=1, SL=1; 688 NH=UDP)(Traceroute probe) with hop-count = 1, it processes the hop 689 count expiry. Specifically, the node N3 responses with the ICMPv6 690 message (Type: "Time Exceeded", Code: "Time to Live exceeded in 691 Transit"). 693 o When node N3, which is a classic IPv6 node, receives the packet 694 with hop-count > 1, it performs the standard IPv6 processing. 695 Specifically, it forwards the traceroute probe based on DA B:4:OTP 696 in the IPv6 header. 698 o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 699 B:4:OTP, B:2:C31 ; SL=1; HC=1, NH=UDP)(Traceroute probe), it 700 processes the END.OTP SID, as described in the pseudocode in 701 Section 3. The packet gets punted to the traceroute process for 702 processing. The traceroute process checks if the next SID in SRH 703 (the target SID B:4:C52) is locally programmed. If the target SID 704 B:4:C52 is locally programmed, node N4 responses with the ICMPv6 705 message (Type: Destination unreachable, Code: Port Unreachable). 706 If the target SID B:4:C52 is not a local SID, node N4 silently 707 drops the traceroute probe. 709 Figure 4 displays a sample traceroute output for this example. 711 > traceroute srv6 B:4:C52 via segment-list B:2:C31 713 Tracing the route to SID function B:4:C52 714 1 2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec 715 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 716 2 2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec 717 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 718 3 2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec 719 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 721 Figure 4 A sample output for hop-by-hop traceroute to a SID function 723 4.2.2.2. Tracing SRv6 Overlay 725 The overlay traceroute does not trace the underlay nodes, i.e., only 726 displays the nodes that acts as SRv6 segments along the path. This 727 is achieved by setting the SRH.Flags.O bit. 729 In this section, overlay traceroute to a SID function is exemplified 730 using UDP probes. However, the procedure is equally applicable to 731 other implementation of traceroute mechanism. 733 Consider the same example where the user wants to traceroute to a 734 remote SID function B:4:C52, via B:2:C31, from node N1. 736 o Node N1 initiates a traceroute probe with SRH as follows (A:1::, 737 B:2:C31)(B:4:C52, B:2:C31; HC=64, SL=1, Flags.O=1; 738 NH=UDP)(Traceroute Probe). Please note that the hop-count is set 739 to 64 to skip the underlay nodes from tracing. The O-flag in SRH 740 is set to make the overlay nodes (nodes processing the SRH) 741 respond. 743 o When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 744 B:2:C31; SL=1, HC=64, Flags.O=1; NH=UDP)(Traceroute Probe), it 745 processes the O-flag in SRH, as described in the pseudocode in 746 Section 3. A time-stamped copy of the packet gets punted to the 747 traceroute process for processing. Node N2 continues to apply the 748 B:2:C31 SID function on the original packet and forwards it, 749 accordingly. The traceroute process at node N2 checks if its 750 local SID (B:2:C31) is locally programmed. If the SID is not 751 locally programmed, it silently drops the packet. Otherwise, it 752 performs the egress check by looking at the SL value in SRH. 754 o As SL is not equal to zero (i.e., it's not egress node), node N2 755 responses with the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: 756 "O-flag punt at Transit (TBA)"). Please note that, as mentioned 757 in Section 3, if node N2 does not support the O-flag, it simply 758 ignores it and processes the local SID, B:2:C31. 760 o When node N3 receives the packet (A:1::, B:4:C52)(B:4:C52, 761 B:2:C31; SL=0, HC=63, Flags.O=1; NH=UDP)(Traceroute Probe), 762 performs the standard IPv6 processing. Specifically, it forwards 763 the traceroute probe based on DA B:4:C52 in the IPv6 header. 764 Please note that there is no hop-count expiration at the transit 765 nodes. 767 o When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 768 B:2:C31; SL=0, HC=62, Flags.O=1; NH=UDP)(Traceroute Probe), it 769 processes the O-flag in SRH, as described in the pseudocode in 770 Section 3. A time-stamped copy of the packet gets punted to the 771 traceroute process for processing. The traceroute process at node 772 N4 checks if its local SID (B:2:C31) is locally programmed. If 773 the SID is not locally programmed, it silently drops the packet. 774 Otherwise, it performs the egress check by looking at the SL value 775 in SRH. As SL is equal to zero (i.e., N4 is the egress node), 776 node N4 tries to consume the UDP probe. As UDP probe is set to 777 access an invalid port, the node N4 responses with the ICMPv6 778 message (Type: Destination unreachable, Code: Port Unreachable) 780 Figure 5 displays a sample overlay traceroute output for this 781 example. Please note that the underlay node N3 does not appear in 782 the output. 784 Tracing the route to SID function B:4:C52 785 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 786 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 787 2 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 788 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 790 Figure 5 A sample output for overlay traceroute to a SID function 792 4.3. Monitoring of SRv6 Paths 794 In the recent past, network operators are interested in performing 795 network OAM functions in a centralized manner. Various data models 796 like YANG are available to collect data from the network and manage 797 it from a centralized entity. 799 SR technology enables a centralized OAM entity to perform path 800 monitoring from centralized OAM entity without control plane 801 intervention on monitored nodes. [RFC 8403] describes such a 802 centralized OAM mechanism. Specifically, the draft describes a 803 procedure that can be used to perform path continuity check between 804 any nodes within an SR domain from a centralized monitoring system, 805 with minimal or no control plane intervene on the nodes. However, 806 the draft focuses on SR networks with MPLS data plane. The same 807 concept applies to the SRv6 networks. This document describes how 808 the concept can be used to perform path monitoring in an SRv6 809 network. This document describes how the concept can be used to 810 perform path monitoring in an SRv6 network as follows. 812 In the above reference topology, N100 is the centralized monitoring 813 system implementing an END function B:100:1::. In order to verify a 814 segment list , N100 generates a probe packet with 815 SRH set to (B:100:1::, B:4:C52, B:2:C31, SL=2). The controller 816 routes the probe packet towards the first segment, which is B:2:C31. 817 N2 performs the standard SRH processing and forward it over link3 818 with the DA of IPv6 packet set to B:4:C52. N4 also performs the 819 normal SRH processing and forward it over link10 with the DA of IPv6 820 packet set to B:100:1::. This makes the probe loops back to the 821 centralized monitoring system. 823 In the reference topology in Figure 1, N100 uses an IGP protocol like 824 OSPF or ISIS to get the topology view within the IGP domain. N100 825 can also use BGP-LS to get the complete view of an inter-domain 826 topology. In other words, the controller leverages the visibility of 827 the topology to monitor the paths between the various endpoints 828 without control plane intervention required at the monitored nodes. 830 5. Security Considerations 832 This document does not define any new protocol extensions and relies 833 on existing procedures defined for ICMP. This document does not 834 impose any additional security challenges to be considered beyond 835 security considerations described in [RFC4884], [RFC4443], [RFC792], 836 RFCs that updates these RFCs, [I-D.ietf-6man-segment-routing-header] 837 and [I-D.ietf-spring-srv6-network-programming]. 839 6. IANA Considerations 841 6.1. ICMPv6 type Numbers RegistrySEC 843 This document defines one ICMPv6 Message, a type that has been 844 allocated from the "ICMPv6 'type' Numbers" registry of [RFC4443]. 845 Specifically, it requests to add the following to the "ICMPv6 Type 846 Numbers" registry: 848 TBA (suggested value: 162) SRv6 OAM Message. 850 The document also requests the creation of a new IANA registry to the 851 "ICMPv6 'Code' Fields" against the "ICMPv6 Type Numbers TBA - SRv6 852 OAM Message" with the following codes: 854 Code Name Reference 855 -------------------------------------------------------- 856 0 No Error This document 857 1 SID is not locally implemented This document 858 2 O-flag punt at Transit This document 860 6.2. SRv6 OAM Endpoint Types 862 This I-D requests to IANA to allocate, within the "SRv6 Endpoint 863 Behaviors Registry" sub-registry belonging to the top-level "Segment- 864 routing with IPv6 dataplane (SRv6) Parameters" registry [I-D.ietf- 865 spring- srv6-network-programming], the following allocations: 867 +------------------+-------------------+-----------+ 868 | Value (Suggested | Endpoint Behavior | Reference | 869 | Value) | | | 870 +------------------+-------------------+-----------+ 871 | TBA (40) | End.OP | [This.ID] | 872 | TBA (41) | End.OTP | [This.ID] | 873 +------------------+-------------------+-----------+ 875 7. Acknowledgements 877 The authors would like to thank Gaurav Naik for his review comments. 879 8. Contributors 881 The following people have contributed to this document: 883 Robert Raszuk 884 Bloomberg LP 885 Email: robert@raszuk.net 887 John Leddy 888 Individual 889 Email: john@leddy.net 891 Gaurav Dawra 892 LinkedIn 893 Email: gdawra.ietf@gmail.com 895 Bart Peirens 896 Proximus 897 Email: bart.peirens@proximus.com 899 Nagendra Kumar 900 Cisco Systems, Inc. 901 Email: naikumar@cisco.com 903 Carlos Pignataro 904 Cisco Systems, Inc. 905 Email: cpignata@cisco.com 907 Rakesh Gandhi 908 Cisco Systems, Inc. 909 Canada 910 Email: rgandhi@cisco.com 911 Frank Brockners 912 Cisco Systems, Inc. 913 Germany 914 Email: fbrockne@cisco.com 916 Darren Dukes 917 Cisco Systems, Inc. 918 Email: ddukes@cisco.com 920 Cheng Li 921 Huawei 922 Email: chengli13@huawei.com 924 Faisal Iqbal 925 Individual 926 Email: faisal.ietf@gmail.com 928 9. References 930 9.1. Normative References 932 [I-D.ietf-6man-segment-routing-header] 933 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 934 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 935 Routing Header (SRH)", draft-ietf-6man-segment-routing- 936 header-21 (work in progress), June 2019. 938 [I-D.ietf-spring-srv6-network-programming] 939 Filsfils, C., Camarillo, P., Leddy, J., 940 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 941 Network Programming", draft-ietf-spring-srv6-network- 942 programming-01 (work in progress), July 2019. 944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 945 Requirement Levels", BCP 14, RFC 2119, 946 DOI 10.17487/RFC2119, March 1997, 947 . 949 9.2. Informative References 951 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 952 RFC 792, DOI 10.17487/RFC0792, September 1981, 953 . 955 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 956 Control Message Protocol (ICMPv6) for the Internet 957 Protocol Version 6 (IPv6) Specification", STD 89, 958 RFC 4443, DOI 10.17487/RFC4443, March 2006, 959 . 961 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 962 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 963 DOI 10.17487/RFC4884, April 2007, 964 . 966 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 967 N., and JR. Rivers, "Extending ICMP for Interface and 968 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 969 April 2010, . 971 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 972 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 973 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 974 2018, . 976 Authors' Addresses 978 Zafar Ali 979 Cisco Systems 981 Email: zali@cisco.com 983 Clarence Filsfils 984 Cisco Systems 986 Email: cfilsfil@cisco.com 988 Satoru Matsushima 989 Softbank 991 Email: satoru.matsushima@g.softbank.co.jp 993 Daniel Voyer 994 Bell Canada 996 Email: daniel.voyer@bell.ca 997 Mach Chen 998 Huawei 1000 Email: mach.chen@huawei.com