idnits 2.17.1 draft-ietf-ippm-ioam-ipv6-options-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 6, 2022) is 808 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) == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm S. Bhandari, Ed. 3 Internet-Draft Thoughtspot 4 Intended status: Standards Track F. Brockners, Ed. 5 Expires: August 10, 2022 Cisco 6 February 6, 2022 8 In-situ OAM IPv6 Options 9 draft-ietf-ippm-ioam-ipv6-options-07 11 Abstract 13 In-situ Operations, Administration, and Maintenance (IOAM) records 14 operational and telemetry information in the packet while the packet 15 traverses a path between two points in the network. This document 16 outlines how IOAM data fields are encapsulated in IPv6. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 10, 2022. 35 Copyright Notice 37 Copyright (c) 2022 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 57 4. In-situ OAM Metadata Transport in IPv6 . . . . . . . . . . . 3 58 5. IOAM Deployment In IPv6 Networks . . . . . . . . . . . . . . 6 59 5.1. Considerations for IOAM deployment in IPv6 networks . . . 6 60 5.2. IOAM domains bounded by hosts . . . . . . . . . . . . . . 7 61 5.3. IOAM domains bounded by network devices . . . . . . . . . 7 62 5.4. Deployment options . . . . . . . . . . . . . . . . . . . 8 63 5.4.1. IP-in-IPv6 encapsulation with ULA . . . . . . . . . . 8 64 5.4.2. x-in-IPv6 Encapsulation that is used Independently . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 9.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 In-situ Operations, Administration, and Maintenance (IOAM) records 77 operational and telemetry information in the packet while the packet 78 traverses a path between two points in the network. This document 79 outlines how IOAM data fields are encapsulated in the IPv6 [RFC8200] 80 and discusses deployment options for networks that use 81 IPv6-encapsulated IOAM data fields. These options have distinct 82 deployment considerations; for example, the IOAM domain can either be 83 between hosts, or be between IOAM encapsulating and decapsulating 84 network nodes that forward traffic, such as routers. 86 2. Contributors 88 This document was the collective effort of several authors. The text 89 and content were contributed by the editors and the co-authors listed 90 below. The contact information of the co-authors appears at the end 91 of this document. 93 o Carlos Pignataro 95 o Hannes Gredler 97 o John Leddy 98 o Stephen Youell 100 o Tal Mizrahi 102 o Aviv Kfir 104 o Barak Gafni 106 o Petr Lapukhov 108 o Mickey Spiegel 110 o Suresh Krishnan 112 o Rajiv Asati 114 o Mark Smith 116 3. Conventions 118 3.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 3.2. Abbreviations 128 Abbreviations used in this document: 130 E2E: Edge-to-Edge 132 IOAM: In-situ Operations, Administration, and Maintenance 134 ION: IOAM Overlay Network 136 OAM: Operations, Administration, and Maintenance 138 POT: Proof of Transit 140 4. In-situ OAM Metadata Transport in IPv6 142 In-situ OAM in IPv6 is used to enhance diagnostics of IPv6 networks. 143 It complements other mechanisms designed to enhance diagnostics of 144 IPv6 networks, such as the IPv6 Performance and Diagnostic Metrics 145 Destination Option described in [RFC8250]. 147 IOAM data fields can be encapsulated in "option data" fields using 148 two types of extension headers in IPv6 packets - either Hop-by-Hop 149 Options header or Destination options header. Deployments select one 150 of these extension header types depending on how IOAM is used, as 151 described in section 4 of [I-D.ietf-ippm-ioam-data]. Multiple 152 options with the same Option Type MAY appear in the same Hop-by-Hop 153 Options or Destination Options header, with distinct content. 155 In order for IOAM to work in IPv6 networks, IOAM MUST be explicitly 156 enabled per interface on every node within the IOAM domain. Unless a 157 particular interface is explicitly enabled (i.e., explicitly 158 configured) for IOAM, a router MUST ignore IOAM Options. As 159 additional security, IOAM domains SHOULD provide a mechanism to 160 prevent injections at ingress or leaks at egress. 162 An IPv6 packet carrying IOAM data in an Extension header can have 163 other extension headers, compliant with [RFC8200]. 165 IPv6 Hop-by-Hop and Destination Option format for carrying in-situ 166 OAM data fields: 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Option Type | Opt Data Len | Reserved | IOAM Type | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 171 | | | 172 . . I 173 . . O 174 . . A 175 . . M 176 . . . 177 . Option Data . O 178 . . P 179 . . T 180 . . I 181 . . O 182 . . N 183 | | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 186 Option Type: 8-bit option type identifier as defined inSection 7. 188 Opt Data Len: 8-bit unsigned integer. Length of this option, in 189 octets, not including the first 2 octets. 191 Reserved: 8-bit field MUST be set to zero upon transmission and 192 ignored upon reception. 194 IOAM Type: 8-bit field as defined in section 7.2 in 195 [I-D.ietf-ippm-ioam-data]. 197 Option Data: Variable-length field. Option-Type-specific data. 199 In-situ OAM Option-Types are inserted as Option data as follows: 201 1. Pre-allocated Trace Option: The in-situ OAM Preallocated Trace 202 Option-Type defined in [I-D.ietf-ippm-ioam-data] is represented 203 as an IPv6 option in the Hop-by-Hop extension header: 205 Option Type: 001xxxxx 8-bit identifier of the IOAM type of 206 option. xxxxx=TBD. 208 IOAM Option-Type: IOAM Pre-allocated Trace Option-Type. 210 2. Incremental Trace Option: The in-situ OAM Incremental Trace 211 Option-Type defined in [I-D.ietf-ippm-ioam-data] is represented 212 as an IPv6 option in the Hop-by-Hop extension header: 214 Option Type: 001xxxxx 8-bit identifier of the IOAM type of 215 option. xxxxx=TBD. 217 IOAM Option-Type: IOAM Incremental Trace Option-Type. 219 3. Proof of Transit Option: The in-situ OAM POT Option-Type defined 220 in [I-D.ietf-ippm-ioam-data] is represented as an IPv6 option in 221 the Hop-by-Hop extension header: 223 Option Type: 001xxxxx 8-bit identifier of the IOAM type of 224 option. xxxxx=TBD. 226 IOAM Option-Type: IOAM POT Option-Type. 228 4. Edge to Edge Option: The in-situ OAM E2E option defined in 229 [I-D.ietf-ippm-ioam-data] is represented as an IPv6 option in 230 Destination extension header: 232 Option Type: 000xxxxx 8-bit identifier of the IOAM type of 233 option. xxxxx=TBD. 235 IOAM Option-Type: IOAM E2E Option-Type. 237 5. Direct Export (DEX) Option: The in-situ OAM Direct Export Option- 238 Type defined in [I-D.ietf-ippm-ioam-direct-export] is represented 239 as an IPv6 option in the Hop-by-Hop extension header: 241 Option Type: 000xxxxx 8-bit identifier of the IOAM type of 242 option. xxxxx=TBD. 244 IOAM Option-Type: IOAM Direct Export (DEX) Option-Type. 246 All the in-situ OAM IPv6 options defined here have alignment 247 requirements. Specifically, they all require 4n alignment. This 248 ensures that fields specified in [I-D.ietf-ippm-ioam-data] are 249 aligned at a multiple-of-4 offset from the start of the Hop-by-Hop 250 and Destination Options header. In addition, to maintain IPv6 251 extension header 8-octet alignment and avoid the need to add or 252 remove padding at every hop, the Trace-Type for Incremental Trace 253 Option in IPv6 MUST be selected such that the IOAM node data length 254 is a multiple of 8-octets. 256 IPv6 options can have a maximum length of 255 octets. Consequently, 257 the total lenght of IOAM Option-Types including all data fields is 258 also limited to 255 octets when encapsulated into IPv6. 260 5. IOAM Deployment In IPv6 Networks 262 5.1. Considerations for IOAM deployment in IPv6 networks 264 IOAM deployments in IPv6 networks should take the following 265 considerations and requirements into account: 267 C1 It is desirable that the addition of IOAM data fields neither 268 changes the way routers forward packets nor the forwarding 269 decisions the routers take. Packets with added OAM information 270 should follow the same path within the domain that an identical 271 packet without OAM information would follow, even in the presence 272 of ECMP. Such behavior is particularly important for deployments 273 where IOAM data fields are only added "on-demand", e.g., to 274 provide further insights in case of undesired network behavior for 275 certain flows. Implementations of IOAM SHOULD ensure that ECMP 276 behavior for packets with and without IOAM data fields is the 277 same. 279 C2 Given that IOAM data fields increase the total size of a packet, 280 the size of a packet including the IOAM data could exceed the 281 PMTU. In particular, the incremental trace IOAM Hop-by-Hop (HbH) 282 Option, which is intended to support hardware implementations of 283 IOAM, changes Option Data Length en-route. Operators of an IOAM 284 domain SHOULD ensure that the addition of OAM information does not 285 lead to fragmentation of the packet, e.g., by configuring the MTU 286 of transit routers and switches to a sufficiently high value. 287 Careful control of the MTU in a network is one of the reasons why 288 IOAM is considered a domain-specific feature (see also 290 [I-D.ietf-ippm-ioam-data]). In addition, the PMTU tolerance range 291 in the IOAM domain should be identified (e.g., through 292 configuration) and IOAM encapsulation operations and/or IOAM data 293 field insertion (in case of incremental tracing) should not be 294 performed if it exceeds the packet size beyond PMTU. 296 C3 Packets with IOAM data or associated ICMP errors, should not 297 arrive at destinations that have no knowledge of IOAM. For 298 exmample, if IOAM is used in in transit devices, misleading ICMP 299 errors due to addition and/or presence of OAM data in a packet 300 could confuse the host that sent the packet if it did not insert 301 the OAM information. 303 C4 OAM data leaks can affect the forwarding behavior and state of 304 network elements outside an IOAM domain. IOAM domains SHOULD 305 provide a mechanism to prevent data leaks or be able to ensure 306 that if a leak occurs, network elements outside the domain are not 307 affected (i.e., they continue to process other valid packets). 309 C5 The source that inserts and leaks the IOAM data needs to be easy 310 to identify for the purpose of troubleshooting, due to the high 311 complexity of troubleshooting a source that inserted the IOAM data 312 and did not remove it when the packet traversed across an 313 Autonomous System (AS). Such a troubleshooting process might 314 require coordination between multiple operators, complex 315 configuration verification, packet capture analysis, etc. 317 C6 Compliance with [RFC8200] requires OAM data to be encapsulated 318 instead of header/option insertion directly into in-flight packets 319 using the original IPv6 header. 321 5.2. IOAM domains bounded by hosts 323 For deployments where the IOAM domain is bounded by hosts, hosts will 324 perform the operation of IOAM data field encapsulation and 325 decapsulation. IOAM data is carried in IPv6 packets as Hop-by-Hop or 326 Destination options as specified in this document. 328 5.3. IOAM domains bounded by network devices 330 For deployments where the IOAM domain is bounded by network devices, 331 network devices such as routers form the edge of an IOAM domain. 332 Network devices will perform the operation of IOAM data field 333 encapsulation and decapsulation. 335 5.4. Deployment options 337 This section lists out possible deployment options that can be 338 employed to meet the requirements listed in Section 5.1. 340 5.4.1. IP-in-IPv6 encapsulation with ULA 342 The "IP-in-IPv6 encapsulation with ULA" [RFC4193] approach can be 343 used to apply IOAM to either an IPv6 or an IPv4 network. In 344 addition, it fulfills requirement C4 (avoid leaks) by using ULA for 345 the ION. Similar to the IPv6-in-IPv6 encapsulation approach above, 346 the original IP packet is preserved. An IPv6 header including IOAM 347 data fields in an extension header is added in front of it, to 348 forward traffic within and across the IOAM domain. IPv6 addresses 349 for the ION, i.e. the outer IPv6 addresses are assigned from the ULA 350 space. Addressing and routing in the ION are to be configured so 351 that the IP-in-IPv6 encapsulated packets follow the same path as the 352 original, non-encapsulated packet would have taken. This would 353 create an internal IPv6 forwarding topology using the IOAM domain's 354 interior ULA address space which is parallel with the forwarding 355 topology that exists with the non-IOAM address space (the topology 356 and address space that would be followed by packets that do not have 357 supplemental IOAM information). Establishment and maintenance of the 358 parallel IOAM ULA forwarding topology could be automated, e.g., 359 similar to how LDP [RFC5036] is used in MPLS to establish and 360 maintain an LSP forwarding topology that is parallel to the network's 361 IGP forwarding topology. 363 Transit across the ION could leverage the transit approach for 364 traffic between BGP border routers, as described in [RFC1772], "A.2.3 365 Encapsulation". Assuming that the operational guidelines specified 366 in Section 4 of [RFC4193] are properly followed, the probability of 367 leaks in this approach will be almost close to zero. If the packets 368 do leak through IOAM egress device misconfiguration or partial IOAM 369 egress device failure, the packets' ULA destination address is 370 invalid outside of the IOAM domain. There is no exterior destination 371 to be reached, and the packets will be dropped when they encounter 372 either a router external to the IOAM domain that has a packet filter 373 that drops packets with ULA destinations, or a router that does not 374 have a default route. 376 5.4.2. x-in-IPv6 Encapsulation that is used Independently 378 In some cases it is desirable to monitor a domain that uses an 379 overlay network that is deployed independently of the need for IOAM, 380 e.g., an overlay network that runs Geneve-in-IPv6, or VXLAN-in-IPv6. 381 In this case IOAM can be encapsulated in as an extension header in 382 the tunnel (outer) IPv6 header. Thus, the tunnel encapsulating node 383 is also the IOAM encapsulating node, and the tunnel end point is also 384 the IOAM decapsulating node. 386 6. Security Considerations 388 This document describes the encapsulation of IOAM data fields in 389 IPv6. Security considerations of the specific IOAM data fields for 390 each case (i.e., Trace, Proof of Transit, and E2E) are described and 391 defined in [I-D.ietf-ippm-ioam-data]. 393 As this document describes new options for IPv6, these are similar to 394 the security considerations of [RFC8200] and the weakness documented 395 in [RFC8250]. 397 7. IANA Considerations 399 This draft requests the following IPv6 Option Type assignments from 400 the Destination Options and Hop-by-Hop Options sub-registry of 401 Internet Protocol Version 6 (IPv6) Parameters. 403 http://www.iana.org/assignments/ipv6-parameters/ipv6- 404 parameters.xhtml#ipv6-parameters-2 406 Hex Value Binary Value Description Reference 407 act chg rest 408 ---------------------------------------------------------------- 409 TBD_1_0 00 0 TBD_1 IOAM [This draft] 410 TBD_1_1 00 1 TBD_1 IOAM [This draft] 412 8. Acknowledgements 414 The authors would like to thank Tom Herbert, Eric Vyncke, Nalini 415 Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu Harichandra 416 Babu, Akshaya Nadahalli, Stefano Previdi, Hemant Singh, Erik 417 Nordmark, LJ Wobker, Mark Smith, Andrew Yourtchenko and Justin Iurman 418 for the comments and advice. For the IPv6 encapsulation, this 419 document leverages concepts described in 420 [I-D.kitamura-ipv6-record-route]. The authors would like to 421 acknowledge the work done by the author Hiroshi Kitamura and people 422 involved in writing it. 424 9. References 426 9.1. Normative References 428 [I-D.ietf-ippm-ioam-data] 429 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 430 for In-situ OAM", draft-ietf-ippm-ioam-data-17 (work in 431 progress), December 2021. 433 [I-D.ietf-ippm-ioam-direct-export] 434 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 435 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 436 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 437 export-07 (work in progress), October 2021. 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, 441 DOI 10.17487/RFC2119, March 1997, 442 . 444 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 445 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 446 May 2017, . 448 9.2. Informative References 450 [I-D.kitamura-ipv6-record-route] 451 Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop 452 Option Extension", draft-kitamura-ipv6-record-route-00 453 (work in progress), November 2000. 455 [RFC1772] Rekhter, Y. and P. Gross, "Application of the Border 456 Gateway Protocol in the Internet", RFC 1772, 457 DOI 10.17487/RFC1772, March 1995, 458 . 460 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 461 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 462 . 464 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 465 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 466 October 2007, . 468 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 469 (IPv6) Specification", STD 86, RFC 8200, 470 DOI 10.17487/RFC8200, July 2017, 471 . 473 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 474 Performance and Diagnostic Metrics (PDM) Destination 475 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 476 . 478 Contributors' Addresses 480 Carlos Pignataro 481 Cisco Systems, Inc. 482 7200-11 Kit Creek Road 483 Research Triangle Park, NC 27709 484 United States 485 Email: cpignata@cisco.com 487 Hannes Gredler 488 RtBrick Inc. 489 Email: hannes@rtbrick.com 491 John Leddy 492 Email: john@leddy.net 494 Stephen Youell 495 JP Morgan Chase 496 25 Bank Street 497 London E14 5JP 498 United Kingdom 499 Email: stephen.youell@jpmorgan.com 501 Tal Mizrahi 502 Huawei Network.IO Innovation Lab 503 Israel 504 Email: tal.mizrahi.phd@gmail.com 506 Aviv Kfir 507 Mellanox Technologies, Inc. 508 350 Oakmead Parkway, Suite 100 509 Sunnyvale, CA 94085 510 U.S.A. 511 Email: avivk@mellanox.com 513 Barak Gafni 514 Mellanox Technologies, Inc. 515 350 Oakmead Parkway, Suite 100 516 Sunnyvale, CA 94085 517 U.S.A. 518 Email: gbarak@mellanox.com 520 Petr Lapukhov 521 Facebook 522 1 Hacker Way 523 Menlo Park, CA 94025 524 US 525 Email: petr@fb.com 527 Mickey Spiegel 528 Barefoot Networks, an Intel company 529 4750 Patrick Henry Drive 530 Santa Clara, CA 95054 531 US 532 Email: mickey.spiegel@intel.com 534 Suresh Krishnan 535 Kaloom 536 Email: suresh@kaloom.com 538 Rajiv Asati 539 Cisco Systems, Inc. 540 7200 Kit Creek Road 541 Research Triangle Park, NC 27709 542 US 543 Email: rajiva@cisco.com 545 Mark Smith 546 PO BOX 521 547 HEIDELBERG, VIC 3084 548 AU 549 Email: markzzzsmith+id@gmail.com 551 Authors' Addresses 552 Shwetha Bhandari (editor) 553 Thoughtspot 554 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 555 Bangalore, KARNATAKA 560 102 556 India 558 Email: shwetha.bhandari@thoughtspot.com 560 Frank Brockners (editor) 561 Cisco Systems, Inc. 562 Hansaallee 249, 3rd Floor 563 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 564 Germany 566 Email: fbrockne@cisco.com