idnits 2.17.1 draft-bonica-6man-oam-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 16, 2019) is 1677 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group R. Bonica 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Y. Kamite 5 Expires: March 19, 2020 NTT Communications Corporation 6 N. So 7 F. Xu 8 Reliance Jio 9 G. Chen 10 Baidu 11 Y. Zhu 12 G. Yang 13 China Telecom 14 Y. Zhou 15 ByteDance 16 September 16, 2019 18 OAM Capabilities for IPv6 19 draft-bonica-6man-oam-04 21 Abstract 23 This document defines new IPv6 Operations and Management (OAM) 24 capabilities. In order to support these new capabilities, this 25 document defines an IPv6 OAM Option and an ICMPv6 OAM message. 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 https://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 March 19, 2020. 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 (https://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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 63 3. The OAM Option . . . . . . . . . . . . . . . . . . . . . . . 2 64 3.1. Processing . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. The ICMPv6 OAM Message . . . . . . . . . . . . . . . . . . . 4 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Problem Statement 74 This document defines new IPv6 [RFC8200] Operations and Management 75 (OAM) capabilities. In order to support these new capabilities, this 76 document defines an IPv6 OAM Option and an ICMPv6 [RFC4443] OAM 77 message. 79 2. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in BCP 84 14 [RFC2119] [RFC8174] when, and only when, they appear in all 85 capitals, as shown here. 87 3. The OAM Option 89 IPv6 source nodes use the OAM option to invoke one or more OAM 90 actions on downstream devices. The OAM option can be included in any 91 of the following: 93 o A Hop-by-hop header. 95 o A Destination Options header that precedes a Routing header. 97 o A Destination Options header that precedes an upper-layer header. 99 If a Hop-by-hop header includes an OAM option, OAM actions MAY be 100 invoked on every node along the path to the destination, including 101 the destination. If a Destination Options header that precedes a 102 Routing header includes an OAM option, OAM actions are invoked by the 103 first node that appears in the IPv6 Destination Address field plus 104 subsequent nodes listed in the Routing header. If a Destination 105 Options header that precedes an upper-layer header includes an OAM 106 option, OAM actions are invoked on the destination node only. 108 The OAM option includes the following fields: 110 o Option Type (8 bits): OAM. Value TBD by IANA. See Note 1 and 111 Note 2. 113 o Opt Data Len (8 bits): Length of Option Data, in bytes. Value 114 MUST be equal to 2. 116 o Option Data (16 bits): A bit mask indicating which OAM actions are 117 to be invoked. 119 +------+-----------+------------------------------------------------+ 120 | Bit | Action | Notes | 121 +------+-----------+------------------------------------------------+ 122 | 0 | Log the | The processing node creates a log entry. The | 123 | | packet | log entry reflects the time at which it was | 124 | | | created. It also reflects the time at which | 125 | | | the packet arrived. | 126 | | | | 127 | 1 | Count the | The processing node increments a counter. | 128 | | packet | | 129 | | | | 130 | 2 | Send an | The processing node sends an ICMP OAM message | 131 | | ICMPv6 | to the packet's source. The OAM message | 132 | | OAM | indicates the time at which the packet | 133 | | | arrived. | 134 | | | | 135 | 3 | Send | The processing node sends telemetry to a | 136 | | telemetry | monitoring station. Telemetry includes the | 137 | | | packet and the time at which the packet | 138 | | | arrived. | 139 | | | | 140 | 4-15 | Reserved | | 141 +------+-----------+------------------------------------------------+ 143 Table 1: Option Data Bits Mapped to OAM Actions 145 Table 1 maps Option Data bits to OAM actions. 147 NOTE 1: As per [RFC8200], the highest-order two bits of the Option 148 Type (i.e., the "act" bits) specify the action taken by a processing 149 node that does not recognize Option Type. The required action is 150 skip over this option and continue processing the header. Therefore, 151 IANA is requested to assign this Option Type with "act" bits "00". 153 NOTE 2: As per [RFC8200], the third-highest-order bit (i.e., the 154 "chg" bit) of the Option Type specifies whether Option Data can 155 change on route to the packet's destination. Because option data 156 MUST NOT be changed, IANA is requested to assign this Option Type 157 with "chg" bit "0". 159 3.1. Processing 161 The processing of OAM actions is optional. If a node does not 162 support particular OAM action, it can ignore the corresponding bit in 163 Option Data. 165 Having processed an OAM option, the processing node should continue 166 to process the packet. If possible, the OAM action should be 167 executed in parallel with the processing of the rest of the packet. 169 The processing node SHOULD execute the OAM action, even if it can not 170 process the packet further. For example, assume the following: 172 o A node receives a packet. 174 o The packet contains a Hop-by-hop Options header and the Hop-by-hop 175 Options header includes the OAM option. 177 o The node does not maintain a route to the packet's Destination 178 Address 180 In this case, the node SHOULD execute the requested OAM action. 181 Because the node does not maintain a route to the packet's 182 Destination Address, it should also send an ICMPv6 Destination 183 Unreachable message to the source node and discard the packet. 185 4. The ICMPv6 OAM Message 186 0 1 2 3 187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Code | Checksum | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Length | Reserved | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Timestamp (seconds) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Timestamp (fraction) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | 198 + Original Datagram + 199 | | 201 Figure 1 203 Figure 1 depicts the ICMPv6 OAM message. The ICMPv6 OAM message 204 contains the following fields: 206 o Type - OAM. Value TBD by IANA. 208 o Code - MUST be set to (0) No Error. 210 o Checksum - See [RFC4443] 212 o Reserved - MUST be set to 0 and MUST be ignored upon receipt. 214 o Length - Represents the length of the padded "original datagram" 215 field, measured in 32-bit words. 217 o Timestamp (seconds) - Represents the time at which the original 218 packet arrived in Network Time Protocol (NTP) [RFC5905] format. 220 o Timestamp (fraction) - Represents the time at which the original 221 packet arrived in NTP [RFC5905] format. 223 o Original Datagram - As much of invoking packet as possible without 224 the ICMPv6 packet exceeding the minimum IPv6 MTU (1280 bytes). 225 The original datagram MUST be zero padded to the nearest 32-bit 226 boundary. 228 ICMPv6 OAM messages SHOULD be rate limited by the sender. 230 The Timestamp fields SHOULD be as accurate as possible. They SHOULD 231 reflect the time at which the original packet arrived, not the time 232 at which the ICMPv6 OAM message was sent. 234 5. IANA Considerations 236 IANA is requested to perform the following actions: 238 o Allocate a codepoint from the Destination Options and Hop-by-hop 239 Options registry (https://www.iana.org/assignments/ipv6- 240 parameters/ipv6-parameters.xhtml#ipv6-parameters-2). This option 241 is called "OAM". The "act" bits are 00 and the "chg" bit is 0. 243 o Create a subregistry in the Destination Options and Hop-by-hop 244 Options registry (https://www.iana.org/assignments/ipv6- 245 parameters/ipv6-parameters.xhtml#ipv6-parameters-2). This 246 subregistry is called OAM Option Data Bit Mask. Its contents are 247 defined in Table 1 of this document. 249 o Allocate a codepoint from the "ICMPv6 'type' Numbers" registry 250 (https://www.iana.org/assignments/icmpv6-parameters/ 251 icmpv6-parameters.xml). This type is called "OAM". As it 252 represents an informational message, its value should be greater 253 than 128. 255 o Create a "Type x - OAM" subregistry in the "ICMPv6 'type' Numbers" 256 registry (https://www.iana.org/assignments/icmpv6-parameters/ 257 icmpv6-parameters.xml) registry. This subregistry contains the 258 Code entry (0) No Error. 260 6. Security Considerations 262 The OAM option can also be used in denial of service attacks. 263 Network devices SHOULD protect themselves against such attacks by 264 limiting the number of OAM options that they process per unit time. 265 If the rate limit is exceeded, the network device MAY either discard 266 the packet or continue to process the packet, ignoring the OAM 267 option. 269 7. Acknowledgements 271 The authors acknowledge Fred Baker, Shizhang Bi, Ross Callon, Brian 272 Carpenter and Tom Herbert for their helpful comments. 274 8. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, 278 DOI 10.17487/RFC2119, March 1997, 279 . 281 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 282 Control Message Protocol (ICMPv6) for the Internet 283 Protocol Version 6 (IPv6) Specification", STD 89, 284 RFC 4443, DOI 10.17487/RFC4443, March 2006, 285 . 287 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 288 "Network Time Protocol Version 4: Protocol and Algorithms 289 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 290 . 292 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 293 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 294 May 2017, . 296 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 297 (IPv6) Specification", STD 86, RFC 8200, 298 DOI 10.17487/RFC8200, July 2017, 299 . 301 Authors' Addresses 303 Ron Bonica 304 Juniper Networks 305 Herndon, Virginia 20171 306 USA 308 Email: rbonica@juniper.net 310 Yuji Kamite 311 NTT Communications Corporation 312 3-4-1 Shibaura, Minato-ku 313 Tokyo 108-8118 314 Japan 316 Email: : y.kamite@ntt.com 318 Ning So 319 Reliance Jio 320 3010 Gaylord PKWY, Suite 150 321 Frisco, Texas 75034 322 USA 324 Email: Ning.So@ril.com 325 Fengman Xu 326 Reliance Jio 327 3010 Gaylord PKWY, Suite 150 328 Frisco, Texas 75034 329 USA 331 Email: Fengman.Xu@ril.com 333 Gang Chen 334 Baidu 335 No.10 Xibeiwang East Road Haidian District 336 Beijing 100193 337 P.R. China 339 Email: phdgang@gmail.com 341 Yongqing Zhu 342 China Telecom 343 109 West Zhongshan Ave, Tianhe District 344 Guangzhou 345 P.R. China 347 Email: zhuyq.gd@chinatelecom.cn 349 Guangming Yang 350 China Telecom 351 109 West Zhongshan Ave, Tianhe District 352 Guangzhou 353 P.R. China 355 Email: yanggm.gd@chinatelecom.cn 357 Yifeng Zhou 358 ByteDance 359 Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian District 360 Beijing 100000 361 P.R. China 363 Email: yifeng.zhou@bytedance.com