idnits 2.17.1 draft-ali-6man-spring-srv6-oam-03.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 7 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 24, 2019) is 1737 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 838, but not defined == Missing Reference: 'RFC 8403' is mentioned on line 804, but not defined == Unused Reference: 'RFC0792' is defined on line 954, but no explicit reference was found in the text == Unused Reference: 'RFC8403' is defined on line 974, 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 25, 2020 S. Matsushima 6 Softbank 7 D. Voyer 8 Bell Canada 9 M. Chen 10 Huawei 11 July 24, 2019 13 Operations, Administration, and Maintenance (OAM) in Segment Routing 14 Networks with IPv6 Data plane (SRv6) 15 draft-ali-6man-spring-srv6-oam-03 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 25, 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, Ref2 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. 288 Ref2: An implementation should not generate further ICMP error during 289 local SID S processing. If local SID S processing requires generation 290 of an ICMP error, the error is generated by the local OAM process. 292 Please note that in an SRH containing END.OTP SID, it is RECOMMENDED 293 to set the SRH.Flags.O-flag = 0. 295 3.5. SRH TLV 297 [I-D.ietf-6man-segment-routing-header] defines TLVs of the Segment 298 Routing Header. 300 SRH TLV plays an important role in carrying OAM and Performance 301 Management (PM) metadata. 303 4. OAM Mechanisms 305 This section describes how OAM mechanisms can be implemented using 306 the OAM building blocks described in the previous section. 307 Additional OAM mechanisms will be added in a future revision of the 308 document. 310 [RFC4443] describes Internet Control Message Protocol for IPv6 311 (ICMPv6) that is used by IPv6 devices for network diagnostic and 312 error reporting purposes. As Segment Routing with IPv6 data plane 313 (SRv6) simply adds a new type of Routing Extension Header, existing 314 ICMPv6 ping mechanisms can be used in an SRv6 network. This section 315 describes the applicability of ICMPv6 in the SRv6 network and how the 316 existing ICMPv6 mechanisms can be used for providing OAM 317 functionality. 319 The document does not propose any changes to the standard ICMPv6 320 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. 322 4.1. Ping 324 There is no hardware or software change required for ping operation 325 at the classic IPv6 nodes in an SRv6 network. That includes the 326 classic IPv6 node with ingress, egress or transit roles. 327 Furthermore, no protocol changes are required to the standard ICMPv6 328 [RFC4443], [RFC4884] or standard ICMPv4 [RFC792]. In other words, 329 existing ICMP ping mechanisms work seamlessly in the SRv6 networks. 331 The following subsections outline some use cases of the ICMP ping in 332 the SRv6 networks. 334 4.1.1. Classic Ping 336 The existing mechanism to ping a remote IP prefix, along the shortest 337 path, continues to work without any modification. The initiator may 338 be an SRv6 node or a classic IPv6 node. Similarly, the egress or 339 transit may be an SRv6 capable node or a classic IPv6 node. 341 If an SRv6 capable ingress node wants to ping an IPv6 prefix via an 342 arbitrary segment list , it needs to initiate ICMPv6 ping 343 with an SR header containing the SID list . This is 344 illustrated using the topology in Figure 1. Assume all the links 345 have IGP metric 10 except both links between node2 and node3, which 346 have IGP metric set to 100. User issues a ping from node N1 to a 347 loopback of node 5, via segment list . 349 Figure 2 contains sample output for a ping request initiated at node 350 N1 to the loopback address of node N5 via a segment list . 353 > ping A:5:: via segment-list B:2:C31, B:4:C52 355 Sending 5, 100-byte ICMP Echos to B5::, timeout is 2 seconds: 356 !!!!! 357 Success rate is 100 percent (5/5), round-trip min/avg/max = 0.625 358 /0.749/0.931 ms 360 Figure 2 A sample ping output at an SRv6 capable node 362 All transit nodes process the echo request message like any other 363 data packet carrying SR header and hence do not require any change. 364 Similarly, the egress node (IPv6 classic or SRv6 capable) does not 365 require any change to process the ICMPv6 echo request. For example, 366 in the ping example of Figure 2: 368 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 369 (A:1::, B:2:C31)(A:5::, B:4:C52, B:2:C31, SL=2, NH = 370 ICMPv6)(ICMPv6 Echo Request). 372 o Node N2, which is an SRv6 capable node, performs the standard SRH 373 processing. Specifically, it executes the END.X function 374 (B:2:C31) and forwards the packet on link3 to N3. 376 o Node N3, which is a classic IPv6 node, performs the standard IPv6 377 processing. Specifically, it forwards the echo request based on 378 DA B:4:C52 in the IPv6 header. 380 o Node N4, which is an SRv6 capable node, performs the standard SRH 381 processing. Specifically, it observes the END.X function 382 (B:4:C52) with PSP (Penultimate Segment POP) on the echo request 383 packet and removes the SRH and forwards the packet across link10 384 to N5. 386 o The echo request packet at N5 arrives as an IPv6 packet without an 387 SRH. Node N5, which is a classic IPv6 node, performs the standard 388 IPv6/ ICMPv6 processing on the echo request and responds, 389 accordingly. 391 4.1.2. Pinging a SID Function 393 The classic ping described in the previous section cannot be used to 394 ping a remote SID function, as explained using an example in the 395 following. 397 Consider the case where the user wants to ping the remote SID 398 function B:4:C52, via B:2:C31, from node N1. Node N1 constructs the 399 ping packet (A:1::, B:2:C31)(B:4:C52, B:2:C31, SL=1; 400 NH=ICMPv6)(ICMPv6 Echo Request). The ping fails because the node N4 401 receives the ICMPv6 echo request with DA set to B:4:C52 but the next 402 header is ICMPv6, instead of SRH. To solve this problem, the 403 initiator needs to mark the ICMPv6 echo request as an OAM packet. 405 The OAM packets are identified either by setting the O-flag in SRH or 406 by inserting the END.OP/ END.OTP SIDs at an appropriate place in the 407 SRH. The following illustration uses END.OTP SID but the procedures 408 are equally applicable to the END.OP SID. 410 In an SRv6 network, the user can exercise two flavors of the ping: 411 end-to-end ping or segment-by-segment ping, as outlined in the 412 following subsection. 414 4.1.2.1. End-to-end ping using END.OP/ END.OTP 416 The end-to-end ping illustration uses the END.OTP SID but the 417 procedures are equally applicable to the END.OP SID. 419 Consider the same example where the user wants to ping a remote SID 420 function B:4:C52, via B:2:C31, from node N1. To force a punt of the 421 ICMPv6 echo request at the node N4, node N1 inserts the END.OTP SID 422 just before the target SID B:4:C52 in the SRH. The ICMPv6 echo 423 request is processed at the individual nodes along the path as 424 follows: 426 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 427 (A:1::, B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; 428 NH=ICMPv6)(ICMPv6 Echo Request). 430 o Node N2, which is an SRv6 capable node, performs the standard SRH 431 processing. Specifically, it executes the END.X function 432 (B:2:C31) on the echo request packet. 434 o Node N3 receives the packet as follows (A:1::, B:4:OTP)(B:4:C52, 435 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request). Node 436 N3, which is a classic IPv6 node, performs the standard IPv6 437 processing. Specifically, it forwards the echo request based on 438 DA B:4:OTP in the IPv6 header. 440 o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 441 B:4:OTP, B:2:C31 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it 442 processes the END.OTP SID, as described in the pseudocode in 443 Section 3. The packet gets punted to the ICMPv6 process for 444 processing. The ICMPv6 process checks if the next SID in SRH (the 445 target SID B:4:C52) is locally programmed. 447 o If the target SID is not locally programmed, N4 responses with the 448 ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally 449 implemented (TBA)"); otherwise a success is returned. 451 4.1.2.2. Segment-by-segment ping using O-flag (Proof of Transit) 453 Consider the same example where the user wants to ping a remote SID 454 function B:4:C52, via B:2:C31, from node N1. However, in this ping, 455 the node N1 wants to get a response from each segment node in the SRH 456 as a "proof of transit". In other words, in the segment-by-segment 457 ping case, the node N1 expects a response from node N2 and node N4 458 for their respective local SID function. When a response to O-bit is 459 desired from the last SID in a SID-list, it is the responsibility of 460 the ingress node to use USP as the last SID. E.g., in this example, 461 the target SID B:4:C52 is a USP SID. 463 To force a punt of the ICMPv6 echo request at node N2 and node N4, 464 node N1 sets the O-flag in SRH. The ICMPv6 echo request is processed 465 at the individual nodes along the path as follows: 467 o Node N1 initiates an ICMPv6 ping packet with SRH as follows 468 (A:1::, B:2:C31)(B:4:C52, B:2:C31; SL=1, Flags.O=1; 469 NH=ICMPv6)(ICMPv6 Echo Request). 471 o When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 472 B:2:C31; SL=1, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request) packet, 473 it processes the O-flag in SRH, as described in the pseudocode in 474 Section 3. A time-stamped copy of the packet gets punted to the 475 ICMPv6 process for processing. Node N2 continues to apply the 476 B:2:C31 SID function on the original packet and forwards it, 477 accordingly. As B:4:C52 is a USP SID, N2 does not remove the SRH. 478 The ICMPv6 process at node N2 checks if its local SID (B:2:C31) is 479 locally programmed or not and responds to the ICMPv6 Echo Request. 481 o If the target SID is not locally programmed, N4 responses with the 482 ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not locally 483 implemented (TBA)"); otherwise a success is returned. Please note 484 that, as mentioned in Section 3, if node N2 does not support the 485 O-flag, it simply ignores it and process the local SID, B:2:C31. 487 o Node N3, which is a classic IPv6 node, performs the standard IPv6 488 processing. Specifically, it forwards the echo request based on 489 DA B:4:C52 in the IPv6 header. 491 o When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 492 B:2:C31; SL=0, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request), it 493 processes the O-flag in SRH, as described in the pseudocode in 494 Section 3. A time-stamped copy of the packet gets punted to the 495 ICMPv6 process for processing. The ICMPv6 process at node N4 496 checks if its local SID (B:2:C31) is locally programmed or not and 497 responds to the ICMPv6 Echo Request. If the target SID is not 498 locally programmed, N4 responses with the ICMPv6 message (Type: 499 "SRv6 OAM (TBA)", Code: "SID not locally implemented (TBA)"); 500 otherwise a success is returned. 502 Support for O-flag is part of node capability advertisement. That 503 enables node N1 to know which segment nodes are capable of responding 504 to the ICMPv6 echo request. Node N1 processes the echo responses and 505 presents data to the user, accordingly. 507 Please note that segment-by-segment ping can be used to address proof 508 of transit use-case. 510 4.1.3. Error Reporting 512 Any IPv6 node can use ICMPv6 control messages to report packet 513 processing errors to the host that originated the datagram packet. 514 To name a few such scenarios: 516 o If the router receives an undeliverable IP datagram, or 518 o If the router receives a packet with a Hop Limit of zero, or 520 o If the router receives a packet such that if the router decrements 521 the packet's Hop Limit it becomes zero, or 523 o If the router receives a packet with problem with a field in the 524 IPv6 header or the extension headers such that it cannot complete 525 processing the packet, or 527 o If the router cannot forward a packet because the packet is larger 528 than the MTU of the outgoing link. 530 In the scenarios listed above, the ICMPv6 response also contains the 531 IP header, IP extension headers and leading payload octets of the 532 "original datagram" to which the ICMPv6 message is a response. 533 Specifically, the "Destination Unreachable Message", "Time Exceeded 534 Message", "Packet Too Big Message" and "Parameter Problem Message" 535 ICMPV6 messages can contain as much of the invoking packet as 536 possible without the ICMPv6 packet exceeding the minimum IPv6 MTU 537 [RFC4443], [RFC4884]. In an SRv6 network, the copy of the invoking 538 packet contains the SR header. The packet originator can use this 539 information for diagnostic purposes. For example, traceroute can use 540 this information as detailed in the following subsection. 542 4.2. Traceroute 544 There is no hardware or software change required for traceroute 545 operation at the classic IPv6 nodes in an SRv6 network. That 546 includes the classic IPv6 node with ingress, egress or transit roles. 547 Furthermore, no protocol changes are required to the standard 548 traceroute operations. In other words, existing traceroute 549 mechanisms work seamlessly in the SRv6 networks. 551 The following subsections outline some use cases of the traceroute in 552 the SRv6 networks. 554 4.2.1. Classic Traceroute 556 The existing mechanism to traceroute a remote IP prefix, along the 557 shortest path, continues to work without any modification. The 558 initiator may be an SRv6 node or a classic IPv6 node. Similarly, the 559 egress or transit may be an SRv6 node or a classic IPv6 node. 561 If an SRv6 capable ingress node wants to traceroute to IPv6 prefix 562 via an arbitrary segment list , it needs to initiate 563 traceroute probe with an SR header containing the SID list . That is illustrated using the topology in Figure 1. Assume all 565 the links have IGP metric 10 except both links between node2 and 566 node3, which have IGP metric set to 100. User issues a traceroute 567 from node N1 to a loopback of node 5, via segment list . Figure 3 contains sample output for the traceroute 569 request. 571 > traceroute A:5:: via segment-list B:2:C31, B:4:C52 573 Tracing the route to B5:: 574 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 575 SRH: (A:5::, B:4:C52, B:2:C31, SL=2) 576 2 2001:DB8:2:3:31:: 0.721 msec 0.810 msec 0.795 msec 577 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 578 3 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 579 SRH: (A:5::, B:4:C52, B:2:C31, SL=1) 580 4 2001:DB8:4:5::52:: 0.879 msec 0.916 msec 1.024 msec 582 Figure 3 A sample traceroute output at an SRv6 capable node 584 Please note that information for hop2 is returned by N3, which is a 585 classic IPv6 node. Nonetheless, the ingress node is able to display 586 SR header contents as the packet travels through the IPv6 classic 587 node. This is because the "Time Exceeded Message" ICMPv6 message can 588 contain as much of the invoking packet as possible without the ICMPv6 589 packet exceeding the minimum IPv6 MTU [RFC4443]. The SR header is 590 also included in these ICMPv6 messages initiated by the classic IPv6 591 transit nodes that are not running SRv6 software. Specifically, a 592 node generating ICMPv6 message containing a copy of the invoking 593 packet does not need to understand the extension header(s) in the 594 invoking packet. 596 The segment list information returned for hop1 is returned by N2, 597 which is an SRv6 capable node. Just like for hop2, the ingress node 598 is able to display SR header contents for hop1. 600 There is no difference in processing of the traceroute probe at an 601 IPv6 classic node and an SRv6 capable node. Similarly, both IPv6 602 classic and SRv6 capable nodes may use the address of the interface 603 on which probe was received as the source address in the ICMPv6 604 response. ICMP extensions defined in [RFC5837] can be used to also 605 display information about the IP interface through which the datagram 606 would have been forwarded had it been forwardable, and the IP next 607 hop to which the datagram would have been forwarded, the IP interface 608 upon which a datagram arrived, the sub-IP component of an IP 609 interface upon which a datagram arrived. 611 The information about the IP address of the incoming interface on 612 which the traceroute probe was received by the reporting node is very 613 useful. This information can also be used to verify if SID functions 614 B:2:C31 and B:4:C52 are executed correctly by N2 and N4, 615 respectively. Specifically, the information displayed for hop2 616 contains the incoming interface address 2001:DB8:2:3:31:: at N3. 617 This matches with the expected interface bound to END.X function 618 B:2:C31 (link3). Similarly, the information displayed for hop5 619 contains the incoming interface address 2001:DB8:4:5::52:: at N5. 620 This matches with the expected interface bound to the END.X function 621 B:4:C52 (link10). 623 4.2.2. Traceroute to a SID Function 625 The classic traceroute described in the previous section cannot be 626 used to traceroute a remote SID function, as explained using an 627 example in the following. 629 Consider the case where the user wants to traceroute the remote SID 630 function B:4:C52, via B:2:C31, from node N1. The trace route fails 631 at N4. This is because the node N4 trace route probe where next 632 header is UDP or ICMPv6, instead of SRH (even though the hop limit is 633 set to 1). To solve this problem, the initiator needs to mark the 634 ICMPv6 echo request as an OAM packet. 636 The OAM packets are identified either by setting the O-flag in SRH or 637 by inserting the END.OP or END.OTP SID at an appropriate place in the 638 SRH. 640 In an SRv6 network, the user can exercise two flavors of the 641 traceroute: hop-by-hop traceroute or overlay traceroute. 643 o In hop-by-hop traceroute, user gets responses from all nodes 644 including classic IPv6 transit nodes, SRv6 capable transit nodes 645 as well as SRv6 capable segment endpoints. E.g., consider the 646 example where the user wants to traceroute to a remote SID 647 function B:4:C52, via B:2:C31, from node N1. The traceroute 648 output will also display information about node3, which is a 649 transit (underlay) node. 651 o The overlay traceroute, on the other hand, does not trace the 652 underlay nodes. In other words, the overlay traceroute only 653 displays the nodes that acts as SRv6 segments along the route. 654 I.e., in the example where the user wants to traceroute to a 655 remote SID function B:4:C52, via B:2:C31, from node N1, the 656 overlay traceroute would only display the traceroute information 657 from node N2 and node N4; it will not display information from 658 node 3. 660 4.2.2.1. Hop-by-hop traceroute using END.OP/ END.OTP 662 In this section, hop-by-hop traceroute to a SID function is 663 exemplified using UDP probes. However, the procedure is equally 664 applicable to other implementation of traceroute mechanism. 665 Furthermore, the illustration uses the END.OTP SID but the procedures 666 are equally applicable to the END.OP SID. 668 Consider the same example where the user wants to traceroute to a 669 remote SID function B:4:C52, via B:2:C31, from node N1. To force a 670 punt of the traceroute probe only at the node N4, node N1 inserts the 671 END.OTP SID just before the target SID B:4:C52 in the SRH. The 672 traceroute probe is processed at the individual nodes along the path 673 as follows: 675 o Node N1 initiates a traceroute probe packet with a monotonically 676 increasing value of hop count and SRH as follows (A:1::, 677 B:2:C31)(B:4:C52, B:4:OTP, B:2:C31; SL=2; NH=UDP)(Traceroute 678 probe). 680 o When node N2 receives the packet with hop-count = 1, it processes 681 the hop count expiry. Specifically, the node N2 responses with 682 the ICMPv6 message (Type: "Time Exceeded", Code: "Time to Live 683 exceeded in Transit"). 685 o When Node N2 receives the packet with hop-count > 1, it performs 686 the standard SRH processing. Specifically, it executes the END.X 687 function (B:2:C31) on the traceroute probe. 689 o When node N3, which is a classic IPv6 node, receives the packet 690 (A:1::, B:4:OTP)(B:4:C52, B:4:OTP, B:2:C31 ; HC=1, SL=1; 691 NH=UDP)(Traceroute probe) with hop-count = 1, it processes the hop 692 count expiry. Specifically, the node N3 responses with the ICMPv6 693 message (Type: "Time Exceeded", Code: "Time to Live exceeded in 694 Transit"). 696 o When node N3, which is a classic IPv6 node, receives the packet 697 with hop-count > 1, it performs the standard IPv6 processing. 698 Specifically, it forwards the traceroute probe based on DA B:4:OTP 699 in the IPv6 header. 701 o When node N4 receives the packet (A:1::, B:4:OTP)(B:4:C52, 702 B:4:OTP, B:2:C31 ; SL=1; HC=1, NH=UDP)(Traceroute probe), it 703 processes the END.OTP SID, as described in the pseudocode in 704 Section 3. The packet gets punted to the traceroute process for 705 processing. The traceroute process checks if the next SID in SRH 706 (the target SID B:4:C52) is locally programmed. If the target SID 707 B:4:C52 is locally programmed, node N4 responses with the ICMPv6 708 message (Type: Destination unreachable, Code: Port Unreachable). 709 If the target SID B:4:C52 is not a local SID, node N4 silently 710 drops the traceroute probe. 712 Figure 4 displays a sample traceroute output for this example. 714 > traceroute srv6 B:4:C52 via segment-list B:2:C31 716 Tracing the route to SID function B:4:C52 717 1 2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec 718 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 719 2 2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec 720 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 721 3 2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec 722 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 724 Figure 4 A sample output for hop-by-hop traceroute to a SID function 726 4.2.2.2. Tracing SRv6 Overlay 728 The overlay traceroute does not trace the underlay nodes, i.e., only 729 displays the nodes that acts as SRv6 segments along the path. This 730 is achieved by setting the SRH.Flags.O bit. 732 In this section, overlay traceroute to a SID function is exemplified 733 using UDP probes. However, the procedure is equally applicable to 734 other implementation of traceroute mechanism. 736 Consider the same example where the user wants to traceroute to a 737 remote SID function B:4:C52, via B:2:C31, from node N1. 739 o Node N1 initiates a traceroute probe with SRH as follows (A:1::, 740 B:2:C31)(B:4:C52, B:2:C31; HC=64, SL=1, Flags.O=1; 741 NH=UDP)(Traceroute Probe). Please note that the hop-count is set 742 to 64 to skip the underlay nodes from tracing. The O-flag in SRH 743 is set to make the overlay nodes (nodes processing the SRH) 744 respond. 746 o When node N2 receives the packet (A:1::, B:2:C31)(B:4:C52, 747 B:2:C31; SL=1, HC=64, Flags.O=1; NH=UDP)(Traceroute Probe), it 748 processes the O-flag in SRH, as described in the pseudocode in 749 Section 3. A time-stamped copy of the packet gets punted to the 750 traceroute process for processing. Node N2 continues to apply the 751 B:2:C31 SID function on the original packet and forwards it, 752 accordingly. The traceroute process at node N2 checks if its 753 local SID (B:2:C31) is locally programmed. If the SID is not 754 locally programmed, it silently drops the packet. Otherwise, it 755 performs the egress check by looking at the SL value in SRH. 757 o As SL is not equal to zero (i.e., it's not egress node), node N2 758 responses with the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: 759 "O-flag punt at Transit (TBA)"). Please note that, as mentioned 760 in Section 3, if node N2 does not support the O-flag, it simply 761 ignores it and processes the local SID, B:2:C31. 763 o When node N3 receives the packet (A:1::, B:4:C52)(B:4:C52, 764 B:2:C31; SL=0, HC=63, Flags.O=1; NH=UDP)(Traceroute Probe), 765 performs the standard IPv6 processing. Specifically, it forwards 766 the traceroute probe based on DA B:4:C52 in the IPv6 header. 767 Please note that there is no hop-count expiration at the transit 768 nodes. 770 o When node N4 receives the packet (A:1::, B:4:C52)(B:4:C52, 771 B:2:C31; SL=0, HC=62, Flags.O=1; NH=UDP)(Traceroute Probe), it 772 processes the O-flag in SRH, as described in the pseudocode in 773 Section 3. A time-stamped copy of the packet gets punted to the 774 traceroute process for processing. The traceroute process at node 775 N4 checks if its local SID (B:2:C31) is locally programmed. If 776 the SID is not locally programmed, it silently drops the packet. 777 Otherwise, it performs the egress check by looking at the SL value 778 in SRH. As SL is equal to zero (i.e., N4 is the egress node), 779 node N4 tries to consume the UDP probe. As UDP probe is set to 780 access an invalid port, the node N4 responses with the ICMPv6 781 message (Type: Destination unreachable, Code: Port Unreachable) 783 Figure 5 displays a sample overlay traceroute output for this 784 example. Please note that the underlay node N3 does not appear in 785 the output. 787 Tracing the route to SID function B:4:C52 788 1 2001:DB8:1:2:21:: 0.512 msec 0.425 msec 0.374 msec 789 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2) 790 2 2001:DB8:3:4::41:: 0.921 msec 0.816 msec 0.759 msec 791 SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1) 793 Figure 5 A sample output for overlay traceroute to a SID function 795 4.3. Monitoring of SRv6 Paths 797 In the recent past, network operators are interested in performing 798 network OAM functions in a centralized manner. Various data models 799 like YANG are available to collect data from the network and manage 800 it from a centralized entity. 802 SR technology enables a centralized OAM entity to perform path 803 monitoring from centralized OAM entity without control plane 804 intervention on monitored nodes. [RFC 8403] describes such a 805 centralized OAM mechanism. Specifically, the draft describes a 806 procedure that can be used to perform path continuity check between 807 any nodes within an SR domain from a centralized monitoring system, 808 with minimal or no control plane intervene on the nodes. However, 809 the draft focuses on SR networks with MPLS data plane. The same 810 concept applies to the SRv6 networks. This document describes how 811 the concept can be used to perform path monitoring in an SRv6 812 network. This document describes how the concept can be used to 813 perform path monitoring in an SRv6 network as follows. 815 In the above reference topology, N100 is the centralized monitoring 816 system implementing an END function B:100:1::. In order to verify a 817 segment list , N100 generates a probe packet with 818 SRH set to (B:100:1::, B:4:C52, B:2:C31, SL=2). The controller 819 routes the probe packet towards the first segment, which is B:2:C31. 820 N2 performs the standard SRH processing and forward it over link3 821 with the DA of IPv6 packet set to B:4:C52. N4 also performs the 822 normal SRH processing and forward it over link10 with the DA of IPv6 823 packet set to B:100:1::. This makes the probe loops back to the 824 centralized monitoring system. 826 In the reference topology in Figure 1, N100 uses an IGP protocol like 827 OSPF or ISIS to get the topology view within the IGP domain. N100 828 can also use BGP-LS to get the complete view of an inter-domain 829 topology. In other words, the controller leverages the visibility of 830 the topology to monitor the paths between the various endpoints 831 without control plane intervention required at the monitored nodes. 833 5. Security Considerations 835 This document does not define any new protocol extensions and relies 836 on existing procedures defined for ICMP. This document does not 837 impose any additional security challenges to be considered beyond 838 security considerations described in [RFC4884], [RFC4443], [RFC792], 839 RFCs that updates these RFCs, [I-D.ietf-6man-segment-routing-header] 840 and [I-D.ietf-spring-srv6-network-programming]. 842 6. IANA Considerations 844 6.1. ICMPv6 type Numbers RegistrySEC 846 This document defines one ICMPv6 Message, a type that has been 847 allocated from the "ICMPv6 'type' Numbers" registry of [RFC4443]. 848 Specifically, it requests to add the following to the "ICMPv6 Type 849 Numbers" registry: 851 TBA (suggested value: 162) SRv6 OAM Message. 853 The document also requests the creation of a new IANA registry to the 854 "ICMPv6 'Code' Fields" against the "ICMPv6 Type Numbers TBA - SRv6 855 OAM Message" with the following codes: 857 Code Name Reference 858 -------------------------------------------------------- 859 0 No Error This document 860 1 SID is not locally implemented This document 861 2 O-flag punt at Transit This document 863 6.2. SRv6 OAM Endpoint Types 865 This I-D requests to IANA to allocate, within the "SRv6 Endpoint 866 Behaviors Registry" sub-registry belonging to the top-level "Segment- 867 routing with IPv6 dataplane (SRv6) Parameters" registry [I-D.ietf- 868 spring- srv6-network-programming], the following allocations: 870 +------------------+-------------------+-----------+ 871 | Value (Suggested | Endpoint Behavior | Reference | 872 | Value) | | | 873 +------------------+-------------------+-----------+ 874 | TBA (40) | End.OP | [This.ID] | 875 | TBA (41) | End.OTP | [This.ID] | 876 +------------------+-------------------+-----------+ 878 7. Acknowledgements 880 The authors would like to thank Gaurav Naik for his review comments. 882 8. Contributors 884 The following people have contributed to this document: 886 Robert Raszuk 887 Bloomberg LP 888 Email: robert@raszuk.net 890 John Leddy 891 Individual 892 Email: john@leddy.net 894 Gaurav Dawra 895 LinkedIn 896 Email: gdawra.ietf@gmail.com 898 Bart Peirens 899 Proximus 900 Email: bart.peirens@proximus.com 902 Nagendra Kumar 903 Cisco Systems, Inc. 904 Email: naikumar@cisco.com 906 Carlos Pignataro 907 Cisco Systems, Inc. 908 Email: cpignata@cisco.com 910 Rakesh Gandhi 911 Cisco Systems, Inc. 912 Canada 913 Email: rgandhi@cisco.com 914 Frank Brockners 915 Cisco Systems, Inc. 916 Germany 917 Email: fbrockne@cisco.com 919 Darren Dukes 920 Cisco Systems, Inc. 921 Email: ddukes@cisco.com 923 Cheng Li 924 Huawei 925 Email: chengli13@huawei.com 927 Faisal Iqbal 928 Individual 929 Email: faisal.ietf@gmail.com 931 9. References 933 9.1. Normative References 935 [I-D.ietf-6man-segment-routing-header] 936 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 937 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 938 Routing Header (SRH)", draft-ietf-6man-segment-routing- 939 header-21 (work in progress), June 2019. 941 [I-D.ietf-spring-srv6-network-programming] 942 Filsfils, C., Camarillo, P., Leddy, J., 943 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 944 Network Programming", draft-ietf-spring-srv6-network- 945 programming-01 (work in progress), July 2019. 947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 948 Requirement Levels", BCP 14, RFC 2119, 949 DOI 10.17487/RFC2119, March 1997, 950 . 952 9.2. Informative References 954 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 955 RFC 792, DOI 10.17487/RFC0792, September 1981, 956 . 958 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 959 Control Message Protocol (ICMPv6) for the Internet 960 Protocol Version 6 (IPv6) Specification", STD 89, 961 RFC 4443, DOI 10.17487/RFC4443, March 2006, 962 . 964 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 965 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 966 DOI 10.17487/RFC4884, April 2007, 967 . 969 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 970 N., and JR. Rivers, "Extending ICMP for Interface and 971 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 972 April 2010, . 974 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 975 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 976 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 977 2018, . 979 Authors' Addresses 981 Zafar Ali 982 Cisco Systems 984 Email: zali@cisco.com 986 Clarence Filsfils 987 Cisco Systems 989 Email: cfilsfil@cisco.com 991 Satoru Matsushima 992 Softbank 994 Email: satoru.matsushima@g.softbank.co.jp 996 Daniel Voyer 997 Bell Canada 999 Email: daniel.voyer@bell.ca 1000 Mach Chen 1001 Huawei 1003 Email: mach.chen@huawei.com