idnits 2.17.1 draft-ioametal-ippm-6man-ioam-ipv6-deployment-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 28, 2019) is 1856 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) == Unused Reference: 'RFC8250' is defined on line 351, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-04 == Outdated reference: A later version (-02) exists of draft-ioametal-ippm-6man-ioam-ipv6-options-01 Summary: 0 errors (**), 0 flaws (~~), 4 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 Cisco 5 Expires: September 29, 2019 T. Mizrahi 6 Huawei Network.IO Innovation Lab 7 A. Kfir 8 B. Gafni 9 Mellanox Technologies, Inc. 10 M. Spiegel 11 Barefoot Networks 12 S. Krishnan 13 Kaloom 14 M. Smith 15 March 28, 2019 17 Deployment Considerations for In-situ OAM with IPv6 Options 18 draft-ioametal-ippm-6man-ioam-ipv6-deployment-01 20 Abstract 22 In-situ Operations, Administration, and Maintenance (IOAM) records 23 operational and telemetry information in the packet while the packet 24 traverses a path between two points in the network. This document 25 outlines how IOAM can be enabled in an IPv6 network. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 29, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Considerations for IOAM deployment in IPv6 networks . . . . . 3 66 4. IOAM domains bounded by hosts . . . . . . . . . . . . . . . . 4 67 5. IOAM domains bounded by network devices . . . . . . . . . . . 4 68 5.1. Deployment options . . . . . . . . . . . . . . . . . . . 5 69 5.1.1. IPv6-in-IPv6 encapsulation . . . . . . . . . . . . . 5 70 5.1.2. IP-in-IPv6 encapsulation with ULA . . . . . . . . . . 5 71 5.1.3. x-in-IPv6 Encapsulation that is used Independently . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 9.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 In-situ Operations, Administration, and Maintenance (IOAM) records 83 operational and telemetry information in the packet while the packet 84 traverses a path between two points in the network. 85 [I-D.ioametal-ippm-6man-ioam-ipv6-options] defines how IOAM data 86 fields are encapsulated in the IPv6 [RFC8200]. This document 87 discusses deployment options for networks which leverage IOAM data 88 fields encapsulated in the IPv6 protocol. 90 Deployment considerations differ, whether the IOAM domain starts and 91 ends on hosts or whether the IOAM encapsulating and decapsulating 92 nodes are network devices that forward traffic, such as routers. 94 2. Conventions 96 2.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 2.2. Abbreviations 106 Abbreviations used in this document: 108 E2E: Edge-to-Edge 110 IOAM: In-situ Operations, Administration, and Maintenance 112 ION: IOAM Overlay Network 114 OAM: Operations, Administration, and Maintenance 116 POT: Proof of Transit 118 3. Considerations for IOAM deployment in IPv6 networks 120 IOAM deployment in an IPv6 network should take the following 121 considerations and requirements into account: 123 C1 It is desirable that the addition of IOAM data fields neither 124 changes the way routers forward the packets, nor the forwarding 125 decision the routers takes. The packet with the added OAM 126 information should follow the same path within the domain that the 127 same packet without the OAM information would follow within the 128 domain even in the presence of ECMP. Such a behavior is 129 particularly interesting for deployments where IOAM data fields 130 are only added "on-demand", e.g. to provide further insights in 131 case of undesired network behavior for certain flows. 132 Implementations of IOAM should ensure that ECMP behavior for 133 packets with and without IOAM data fields is the same. 135 C2 Given that IOAM data fields increase the total size of the packet, 136 the size of the packet including the IOAM data could exceed the 137 PMTU. In particular, the incremental trace IOAM HbH Option, which 138 is proposed to support hardware implementations of IOAM, changes 139 Option Data Length en-route. Operators of an IOAM domain are to 140 ensure that the addition of OAM information does not lead to 141 fragmentation of the packet, e.g. by configuring the MTU of 142 transit routers and switches to a sufficiently high value. 143 Careful control of the MTU in a network is one of the reasons why 144 IOAM is considered a domain specific feature, see also 145 [I-D.ietf-ippm-ioam-data]. In addition, the PMTU tolerance range 146 in the IOAM domain should be identified (e.g. through 147 configuration) and IOAM encapsulation operations and/or IOAM data 148 field insertion (in case of incremental tracing) should not be 149 performed if it exceeds the packet size beyond PMTU. 151 C3 Packets with IOAM data or associated ICMP errors, should not 152 arrive at destinations which have no knowledge of IOAM. Consider 153 using IOAM in transit devices; misleading ICMP errors due to 154 addition and/or presence of OAM data in the packet can confuse a 155 source of the packet that did not insert the OAM information. 157 C4 OAM data leaks may affect the forwarding behavior and state of 158 network elements outside an IOAM domain. IOAM domains SHOULD 159 provide a mechanism to prevent data leaks or be able to assure 160 that upon leak network elements outside the domain are not 161 affected i.e they continue to process other valid packets. 163 C5 The source of that inserted and leaked the IOAM data must be easy 164 to identify for the purpose of troubleshooting, due to the high 165 complexity of troubleshooting a source that inserted the IOAM data 166 and did not remove it when the packet traversed across an AS. 167 Such a troubleshooting process may require coordination between 168 multiple operators, complicated configuration verification, packet 169 capture analysis, etc. 171 C6 Compliance with [RFC8200] would require OAM data to be 172 encapsulated instead of header/option insertion directly into in- 173 flight packets using the original IPv6 header. 175 4. IOAM domains bounded by hosts 177 For deployments where the IOAM domain is bounded by hosts, hosts will 178 perform the operation of IOAM data field encapsulation and 179 decapsulation. IOAM data is carried in IPv6 packets as Hop-by-Hop or 180 Destination options, see [I-D.ioametal-ippm-6man-ioam-ipv6-options]. 182 5. IOAM domains bounded by network devices 184 For deployments where the IOAM domain is bounded by network devices, 185 network devices such as routers form the edge of an IOAM domain. 186 Network devices will perform the operation of IOAM data field 187 encapsulation and decapsulation. 189 5.1. Deployment options 191 This section lists out possible deployment options that can be 192 employed to meet the requirements listed in Section 3. 194 5.1.1. IPv6-in-IPv6 encapsulation 196 Leverage an IPv6-in-IPv6 approach: Preserve the original IP packet 197 and add an IPv6 header including IOAM data fields in an extension 198 header in front of it, to forward traffic within and across the IOAM 199 domain. The overlay network formed by the additional IPv6 header 200 with the IOAM data fields included in an extension header is referred 201 to as IOAM Overlay Network (ION) in this document. 203 1. Perform an IPv6-in-IPv6 approach. The source address of the 204 outer IPv6 header is that of the IOAM encapsulating node. The 205 destination address of the outer IPv6 header is the same as the 206 inner IPv6 destination address, i.e. the destination address of 207 the packet does not change. 209 2. To simplify debugging in case of leaked IOAM data fields in 210 packets, consider a new IOAM E2E destination option to identify 211 the Source IOAM domain (AS, v6 prefix). Insert this option into 212 the IOAM destination options EH attached to the outer IPv6 213 header. This additional information would allow for easy 214 identification of an AS operator that is the source of packets 215 with leaked IOAM information. Note that leaked packets with IOAM 216 data fields would only occur in case a router would be 217 misconfigured. [I-D.ioametal-ippm-6man-ioam-ipv6-options] 218 requires that by default, packets with extension headers which 219 carry IOAM data fields are dropped unless the router's interfaces 220 are explicitly configured for IOAM. 222 3. All the IOAM options are defined with type "00 - skip over this 223 option and continue processing the header. So presence of the 224 options must not cause packet drop in the network elements that 225 do not understand the option. In addition 226 [I-D.ietf-6man-hbh-header-handling] should be considered. 228 5.1.2. IP-in-IPv6 encapsulation with ULA 230 The "IP-in-IPv6 encapsulation with ULA" [RFC4193] approach can be 231 used to apply IOAM to an IPv6 as well as an IPv4 network. In 232 addition, it fulfills requirement C4 (avoid leaks) by using ULA for 233 the ION. Similar to the IPv6-in-IPv6 encapsulation approach above, 234 the original IP packet is preserved. An IPv6 header including IOAM 235 data fields in an extension header is added in front of it, to 236 forward traffic within and across the IOAM domain. IPv6 addresses 237 for the ION, i.e. the outer IPv6 addresses are assigned from the ULA 238 space. Addressing and routing in the ION are to be configured so 239 that the IP-in-IPv6 encapsulated packets follow the same path as the 240 original, non-encapsulated packet would have taken. This would 241 create an internal IPv6 forwarding topology using the IOAM domain's 242 interior ULA address space which is parallel with the forwarding 243 topology that exists with the non-IOAM address space (the topology 244 and address space that would be followed by packets that do not have 245 supplemental IOAM information). Establishment and maintenance of the 246 parallel IOAM ULA forwarding topology could be automated, e.g. 247 similar to how LDP [RFC5036] is used in MPLS to establish and 248 maintain an LSP forwarding topology that is parallel to the network's 249 IGP forwarding topology. 251 Transit across the ION could leverage the transit approach for 252 traffic between BGP border routers, as described in [RFC1772], "A.2.3 253 Encapsulation". Assuming that the operational guidelines specified 254 in Section 4 of [RFC4193] are properly followed, the probability of 255 leaks in this approach will be almost close to zero. If the packets 256 do leak through IOAM egress device misconfiguration or partial IOAM 257 egress device failure, the packets' ULA destination address is 258 invalid outside of the IOAM domain. There is no exterior destination 259 to be reached, and the packets will be dropped when they encounter 260 either a router external to the IOAM domain that has a packet filter 261 that drops packets with ULA destinations, or a router that does not 262 have a default route. 264 5.1.3. x-in-IPv6 Encapsulation that is used Independently 266 In some cases it is desirable to monitor a domain that uses an 267 overlay network that is deployed independently of the need for IOAM, 268 e.g., an overlay network that runs Geneve-in-IPv6, or VXLAN-in-IPv6. 269 In this case IOAM can be encapsulated in as an extension header in 270 the tunnel (outer) IPv6 header. Thus, the tunnel encapsulating node 271 is also the IOAM encapsulating node, and the tunnel end point is also 272 the IOAM decapsulating node. 274 6. Security Considerations 276 This document discusses the deployment of IOAM with IPv6 options. 277 Security considerations of the specific IOAM data fields are 278 described in [I-D.ietf-ippm-ioam-data]. 280 7. IANA Considerations 282 There are no IANA considerations that apply to this document. 284 8. Acknowledgements 286 The authors would like to thank Mark Smith, Tom Herbert, Eric Vyncke, 287 Nalini Elkins, Srihari Raghavan, Ranganathan T S, Karthik Babu 288 Harichandra Babu, Akshaya Nadahalli, Stefano Previdi, Hemant Singh, 289 Erik Nordmark, LJ Wobker, and Andrew Yourtchenko for the comments and 290 advice. For the IPv6 encapsulation, this document leverages concepts 291 described in [I-D.kitamura-ipv6-record-route]. The authors would 292 like to acknowledge the work done by the author Hiroshi Kitamura and 293 people involved in writing it. 295 9. References 297 9.1. Normative References 299 [I-D.ietf-ippm-ioam-data] 300 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 301 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 302 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 303 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 304 data-04 (work in progress), October 2018. 306 [I-D.ioametal-ippm-6man-ioam-ipv6-options] 307 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 308 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 309 Lapukhov, P., Spiegel, M., and S. Krishnan, "In-situ OAM 310 IPv6 Options", draft-ioametal-ippm-6man-ioam- 311 ipv6-options-01 (work in progress), October 2018. 313 [RFC1772] Rekhter, Y. and P. Gross, "Application of the Border 314 Gateway Protocol in the Internet", RFC 1772, 315 DOI 10.17487/RFC1772, March 1995, . 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, 320 DOI 10.17487/RFC2119, March 1997, . 323 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 324 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 325 May 2017, . 327 9.2. Informative References 329 [I-D.ietf-6man-hbh-header-handling] 330 Baker, F. and R. Bonica, "IPv6 Hop-by-Hop Options 331 Extension Header", March 2016. 333 [I-D.kitamura-ipv6-record-route] 334 Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop 335 Option Extension", draft-kitamura-ipv6-record-route-00 336 (work in progress), November 2000. 338 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 339 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 340 . 342 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 343 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 344 October 2007, . 346 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 347 (IPv6) Specification", STD 86, RFC 8200, 348 DOI 10.17487/RFC8200, July 2017, . 351 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 352 Performance and Diagnostic Metrics (PDM) Destination 353 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 354 . 356 Authors' Addresses 358 Shwetha Bhandari 359 Cisco Systems, Inc. 360 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 361 Bangalore, KARNATAKA 560 087 362 India 364 Email: shwethab@cisco.com 366 Frank Brockners 367 Cisco Systems, Inc. 368 Kaiserswerther Str. 115, 369 RATINGEN, NORDRHEIN-WESTFALEN 40880 370 Germany 372 Email: fbrockne@cisco.com 374 Tal Mizrahi 375 Huawei Network.IO Innovation Lab 376 Israel 378 Email: tal.mizrahi.phd@gmail.com 379 Aviv Kfir 380 Mellanox Technologies, Inc. 381 350 Oakmead Parkway, Suite 100 382 Sunnyvale, CA 94085 383 U.S.A. 385 Email: avivk@mellanox.com 387 Barak Gafni 388 Mellanox Technologies, Inc. 389 350 Oakmead Parkway, Suite 100 390 Sunnyvale, CA 94085 391 U.S.A. 393 Email: gbarak@mellanox.com 395 Mickey Spiegel 396 Barefoot Networks 397 4750 Patrick Henry Drive 398 Santa Clara, CA 95054 399 US 401 Email: mspiegel@barefootnetworks.com 403 Suresh Krishnan 404 Kaloom 406 Email: suresh@kaloom.com 408 Mark Smith 409 PO BOX 521 410 HEIDELBERG, VIC 3084 411 AU 413 Email: markzzzsmith+id@gmail.com