idnits 2.17.1 draft-ietf-ippm-ioam-ipv6-options-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (March 08, 2020) is 1503 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 (-17) exists of draft-ietf-ippm-ioam-data-01 == Outdated reference: A later version (-03) exists of draft-ioametal-ippm-6man-ioam-ipv6-deployment-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm S. Bhandari 3 Internet-Draft F. Brockners 4 Intended status: Standards Track C. Pignataro 5 Expires: September 9, 2020 Cisco 6 H. Gredler 7 RtBrick Inc. 8 J. Leddy 9 Comcast 10 S. Youell 11 JMPC 12 T. Mizrahi 13 Huawei Network.IO Innovation Lab 14 A. Kfir 15 B. Gafni 16 Mellanox Technologies, Inc. 17 P. Lapukhov 18 Facebook 19 M. Spiegel 20 Barefoot Networks, an Intel company 21 S. Krishnan 22 Kaloom 23 R. Asati 24 Cisco 25 March 08, 2020 27 In-situ OAM IPv6 Options 28 draft-ietf-ippm-ioam-ipv6-options-01 30 Abstract 32 In-situ Operations, Administration, and Maintenance (IOAM) records 33 operational and telemetry information in the packet while the packet 34 traverses a path between two points in the network. This document 35 outlines how IOAM data fields are encapsulated in IPv6. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 9, 2020. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 74 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 75 3. In-situ OAM Metadata Transport in IPv6 . . . . . . . . . . . 3 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 81 7.2. Informative References . . . . . . . . . . . . . . . . . 7 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 84 1. Introduction 86 In-situ Operations, Administration, and Maintenance (IOAM) records 87 operational and telemetry information in the packet while the packet 88 traverses a path between two points in the network. This document 89 outlines how IOAM data fields are encapsulated in the IPv6 [RFC8200]. 91 2. Conventions 92 2.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 2.2. Abbreviations 102 Abbreviations used in this document: 104 E2E: Edge-to-Edge 106 IOAM: In-situ Operations, Administration, and Maintenance 108 OAM: Operations, Administration, and Maintenance 110 POT: Proof of Transit 112 3. In-situ OAM Metadata Transport in IPv6 114 In-situ OAM in IPv6 is used to enhance diagnostics of IPv6 networks. 115 It complements other mechanisms proposed to enhance diagnostics of 116 IPv6 networks, such as the IPv6 Performance and Diagnostic Metrics 117 Destination Option described in [RFC8250]. 119 IOAM data fields are encapsulated in "option data" fields of two 120 types of extension headers in IPv6 packets - either Hop-by-Hop 121 Options header or Destination options header. The selection of a 122 particular extension header type depends on IOAM usage, as described 123 in section 4 of [I-D.ietf-ippm-ioam-data]. Multiple options with the 124 same Option Type MAY appear in the same Hop-by-Hop Options or 125 Destination Options header, with varying content. 127 In order for IOAM to work in IPv6 networks, IOAM MUST be explicitly 128 enabled per interface on every node within the IOAM domain. Unless a 129 particular interface is explicitly enabled (i.e. explicitly 130 configured) for IOAM, a router MUST drop packets which contain 131 extension headers carrying IOAM data-fields. This is the default 132 behavior and is independent of whether the Hop-by-Hop options or 133 Destination options are used to encode the IOAM data. This ensures 134 that IOAM data does not unintentionally get forwarded outside the 135 IOAM domain. 137 An IPv6 packet carrying IOAM data in an Extension header can have 138 other extension headers, compliant with [RFC8200]. 140 IPv6 Hop-by-Hop and Destination Option format for carrying in-situ 141 OAM data fields: 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Option Type | Opt Data Len | Reserved | IOAM Type | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 146 | | | 147 . . I 148 . Option Data . O 149 . . A 150 . . M 151 . . . 152 . . O 153 . . P 154 . . T 155 . . I 156 . . O 157 . . N 158 . . | 159 | | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ 162 Option Type: 8-bit identifier of the type of option. 164 Opt Data Len: 8-bit unsigned integer. Length of the Reserved and 165 Option Data field of this option, in octets. 167 Reserved: 8-bit field MUST be set to zero upon transmission and 168 ignored upon reception. 170 IOAM Type: 8-bit field as defined in section 7.2 in 171 [I-D.ietf-ippm-ioam-data]. 173 Option Data: Variable-length field. Option-Type-specific data. 175 In-situ OAM Options are inserted as Option data as follows: 177 1. Pre-allocated Tracing Option: The in-situ OAM Preallocated 178 Tracing option defined in [I-D.ietf-ippm-ioam-data] is 179 represented as a IPv6 option in hop by hop extension header: 181 Option Type: 001xxxxx 8-bit identifier of the IOAM type of 182 option. xxxxx=TBD. 184 IOAM Type: IOAM Pre-allocated Trace Option Type. 186 2. Incremental Tracing Option: The in-situ OAM Incremental Tracing 187 option defined in [I-D.ietf-ippm-ioam-data] is represented as a 188 IPv6 option in hop by hop extension header: 190 Option Type: 001xxxxx 8-bit identifier of the IOAM type of 191 option. xxxxx=TBD. 193 IOAM Type: IOAM Incremental Trace Option Type. 195 3. Proof of Transit Option: The in-situ OAM POT option defined in 196 [I-D.ietf-ippm-ioam-data] is represented as a IPv6 option in hop 197 by hop extension header: 199 Option Type: 001xxxxx 8-bit identifier of the IOAM type of 200 option. xxxxx=TBD. 202 IOAM Type: IOAM POT Option Type. 204 4. Edge to Edge Option: The in-situ OAM E2E option defined in 205 [I-D.ietf-ippm-ioam-data] is represented as a IPv6 option in IPv6 206 option in destination options extension header: 208 Option Type: 000xxxxx 8-bit identifier of the IOAM type of 209 option. xxxxx=TBD. 211 IOAM Type: IOAM E2E Option Type. 213 All the in-situ OAM IPv6 options defined here have alignment 214 requirements. Specifically, they all require 4n alignment. This 215 ensures that 4 octet fields specified in [I-D.ietf-ippm-ioam-data] 216 such as transit delay are aligned at a multiple-of-4 offset from the 217 start of the Hop-by-Hop Options header. In addition, to maintain 218 IPv6 extension header 8-octet alignment and avoid the need to add or 219 remove padding at every hop, the Trace-Type for Incremental Tracing 220 Option in IPv6 MUST be selected such that the IOAM node data length 221 is a multiple of 8-octets. 223 An outline of how the options defined here can be enabled and used in 224 an IPv6 network is provided in 225 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment]. 227 4. Security Considerations 229 This document describes the encapsulation of IOAM data fields in 230 IPv6. Security considerations of the specific IOAM data fields for 231 each case (i.e., Trace, Proof of Transit, and E2E) are described in 232 defined in [I-D.ietf-ippm-ioam-data]. 234 As this document describes new options for IPv6 , these are similar 235 to the security considerations of [RFC8200] and the new weakness 236 documented in [RFC8250]. 238 5. IANA Considerations 240 This draft requests the following IPv6 Option Type assignments from 241 the Destination Options and Hop-by-Hop Options sub-registry of 242 Internet Protocol Version 6 (IPv6) Parameters. 244 http://www.iana.org/assignments/ipv6-parameters/ipv6- 245 parameters.xhtml#ipv6-parameters-2 247 Hex Value Binary Value Description Reference 248 act chg rest 249 ---------------------------------------------------------------- 250 TBD_1_0 00 0 TBD_1 IOAM [This draft] 251 TBD_1_1 00 1 TBD_1 IOAM [This draft] 253 6. Acknowledgements 255 The authors would like to thank Tom Herbert, Eric Vyncke, Nalini 256 Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu Harichandra 257 Babu, Akshaya Nadahalli, Stefano Previdi, Hemant Singh, Erik 258 Nordmark, LJ Wobker, Mark Smith, and Andrew Yourtchenko for the 259 comments and advice. For the IPv6 encapsulation, this document 260 leverages concepts described in [I-D.kitamura-ipv6-record-route]. 261 The authors would like to acknowledge the work done by the author 262 Hiroshi Kitamura and people involved in writing it. 264 7. References 266 7.1. Normative References 268 [I-D.ietf-ippm-ioam-data] 269 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 270 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 271 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 272 for In-situ OAM", draft-ietf-ippm-ioam-data-01 (work in 273 progress), October 2017. 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 281 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 282 May 2017, . 284 7.2. Informative References 286 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment] 287 Bhandari, S., Brockners, F., Mizrahi, T., Kfir, A., Gafni, 288 B., Spiegel, M., Krishnan, S., and M. Smith, "Deployment 289 Considerations for In-situ OAM with IPv6 Options", draft- 290 ioametal-ippm-6man-ioam-ipv6-deployment-01 (work in 291 progress), March 2019. 293 [I-D.kitamura-ipv6-record-route] 294 Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop 295 Option Extension", draft-kitamura-ipv6-record-route-00 296 (work in progress), November 2000. 298 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 299 (IPv6) Specification", STD 86, RFC 8200, 300 DOI 10.17487/RFC8200, July 2017, 301 . 303 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 304 Performance and Diagnostic Metrics (PDM) Destination 305 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 306 . 308 Authors' Addresses 310 Shwetha Bhandari 311 Cisco Systems, Inc. 312 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 313 Bangalore, KARNATAKA 560 087 314 India 316 Email: shwethab@cisco.com 318 Frank Brockners 319 Cisco Systems, Inc. 320 Kaiserswerther Str. 115, 321 RATINGEN, NORDRHEIN-WESTFALEN 40880 322 Germany 324 Email: fbrockne@cisco.com 325 Carlos Pignataro 326 Cisco Systems, Inc. 327 7200-11 Kit Creek Road 328 Research Triangle Park, NC 27709 329 United States 331 Email: cpignata@cisco.com 333 Hannes Gredler 334 RtBrick Inc. 336 Email: hannes@rtbrick.com 338 John Leddy 339 Comcast 341 Email: John_Leddy@cable.comcast.com 343 Stephen Youell 344 JP Morgan Chase 345 25 Bank Street 346 London E14 5JP 347 United Kingdom 349 Email: stephen.youell@jpmorgan.com 351 Tal Mizrahi 352 Huawei Network.IO Innovation Lab 353 Israel 355 Email: tal.mizrahi.phd@gmail.com 357 Aviv Kfir 358 Mellanox Technologies, Inc. 359 350 Oakmead Parkway, Suite 100 360 Sunnyvale, CA 94085 361 U.S.A. 363 Email: avivk@mellanox.com 364 Barak Gafni 365 Mellanox Technologies, Inc. 366 350 Oakmead Parkway, Suite 100 367 Sunnyvale, CA 94085 368 U.S.A. 370 Email: gbarak@mellanox.com 372 Petr Lapukhov 373 Facebook 374 1 Hacker Way 375 Menlo Park, CA 94025 376 US 378 Email: petr@fb.com 380 Mickey Spiegel 381 Barefoot Networks, an Intel company 382 4750 Patrick Henry Drive 383 Santa Clara, CA 95054 384 US 386 Email: mickey.spiegel@intel.com 388 Suresh Krishnan 389 Kaloom 391 Email: suresh@kaloom.com 393 Rajiv Asati 394 Cisco Systems, Inc. 395 7200 Kit Creek Road 396 Research Triangle Park, NC 27709 397 US 399 Email: rajiva@cisco.com