idnits 2.17.1 draft-ioametal-ippm-6man-ioam-ipv6-options-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 : ---------------------------------------------------------------------------- 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 28, 2019) is 1849 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 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,6man S. Bhandari 3 Internet-Draft F. Brockners 4 Intended status: Standards Track C. Pignataro 5 Expires: September 29, 2019 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 21 S. Krishnan 22 Kaloom 23 R. Asati 24 Cisco 25 March 28, 2019 27 In-situ OAM IPv6 Options 28 draft-ioametal-ippm-6man-ioam-ipv6-options-02 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 http://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 29, 2019. 54 Copyright Notice 56 Copyright (c) 2019 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 (http://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 4. Security Considerations 225 This document describes the encapsulation of IOAM data fields in 226 IPv6. Security considerations of the specific IOAM data fields for 227 each case (i.e., Trace, Proof of Transit, and E2E) are described in 228 defined in [I-D.ietf-ippm-ioam-data]. 230 As this document describes new options for IPv6 , these are similar 231 to the security considerations of [RFC8200] and the new weakness 232 documented in [RFC8250]. 234 5. IANA Considerations 236 This draft requests the following IPv6 Option Type assignments from 237 the Destination Options and Hop-by-Hop Options sub-registry of 238 Internet Protocol Version 6 (IPv6) Parameters. 240 http://www.iana.org/assignments/ipv6-parameters/ipv6- 241 parameters.xhtml#ipv6-parameters-2 243 Hex Value Binary Value Description Reference 244 act chg rest 245 ---------------------------------------------------------------- 246 TBD_1_0 00 0 TBD_1 IOAM [This draft] 247 TBD_1_1 00 1 TBD_1 IOAM [This draft] 249 6. Acknowledgements 251 The authors would like to thank Tom Herbert, Eric Vyncke, Nalini 252 Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu Harichandra 253 Babu, Akshaya Nadahalli, Stefano Previdi, Hemant Singh, Erik 254 Nordmark, LJ Wobker, Mark Smith, and Andrew Yourtchenko for the 255 comments and advice. For the IPv6 encapsulation, this document 256 leverages concepts described in [I-D.kitamura-ipv6-record-route]. 257 The authors would like to acknowledge the work done by the author 258 Hiroshi Kitamura and people involved in writing it. 260 7. References 262 7.1. Normative References 264 [I-D.ietf-ippm-ioam-data] 265 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 266 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 267 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 268 for In-situ OAM", draft-ietf-ippm-ioam-data-01 (work in 269 progress), October 2017. 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, . 276 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 277 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 278 May 2017, . 280 7.2. Informative References 282 [I-D.kitamura-ipv6-record-route] 283 Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop 284 Option Extension", draft-kitamura-ipv6-record-route-00 285 (work in progress), November 2000. 287 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 288 (IPv6) Specification", STD 86, RFC 8200, 289 DOI 10.17487/RFC8200, July 2017, . 292 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 293 Performance and Diagnostic Metrics (PDM) Destination 294 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 295 . 297 Authors' Addresses 299 Shwetha Bhandari 300 Cisco Systems, Inc. 301 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 302 Bangalore, KARNATAKA 560 087 303 India 305 Email: shwethab@cisco.com 307 Frank Brockners 308 Cisco Systems, Inc. 309 Kaiserswerther Str. 115, 310 RATINGEN, NORDRHEIN-WESTFALEN 40880 311 Germany 313 Email: fbrockne@cisco.com 315 Carlos Pignataro 316 Cisco Systems, Inc. 317 7200-11 Kit Creek Road 318 Research Triangle Park, NC 27709 319 United States 321 Email: cpignata@cisco.com 322 Hannes Gredler 323 RtBrick Inc. 325 Email: hannes@rtbrick.com 327 John Leddy 328 Comcast 330 Email: John_Leddy@cable.comcast.com 332 Stephen Youell 333 JP Morgan Chase 334 25 Bank Street 335 London E14 5JP 336 United Kingdom 338 Email: stephen.youell@jpmorgan.com 340 Tal Mizrahi 341 Huawei Network.IO Innovation Lab 342 Israel 344 Email: tal.mizrahi.phd@gmail.com 346 Aviv Kfir 347 Mellanox Technologies, Inc. 348 350 Oakmead Parkway, Suite 100 349 Sunnyvale, CA 94085 350 U.S.A. 352 Email: avivk@mellanox.com 354 Barak Gafni 355 Mellanox Technologies, Inc. 356 350 Oakmead Parkway, Suite 100 357 Sunnyvale, CA 94085 358 U.S.A. 360 Email: gbarak@mellanox.com 361 Petr Lapukhov 362 Facebook 363 1 Hacker Way 364 Menlo Park, CA 94025 365 US 367 Email: petr@fb.com 369 Mickey Spiegel 370 Barefoot Networks 371 4750 Patrick Henry Drive 372 Santa Clara, CA 95054 373 US 375 Email: mspiegel@barefootnetworks.com 377 Suresh Krishnan 378 Kaloom 380 Email: suresh@kaloom.com 382 Rajiv Asati 383 Cisco Systems, Inc. 384 7200 Kit Creek Road 385 Research Triangle Park , NC 27709 386 US 388 Email: rajiva@cisco.com