idnits 2.17.1 draft-bonica-6man-oam-03.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 (March 23, 2019) is 1861 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 N. So 5 Expires: September 24, 2019 F. Xu 6 Reliance Jio 7 G. Chen 8 Baidu 9 Y. Zhu 10 G. Yang 11 China Telecom 12 Y. Zhou 13 ByteDance 14 March 23, 2019 16 OAM Capabilities for IPv6 17 draft-bonica-6man-oam-03 19 Abstract 21 This document defines new IPv6 Operations and Management (OAM) 22 capabilities. In order to support these new capabilities, this 23 document defines an IPv6 OAM Option and an ICMPv6 OAM message. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 24, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 61 3. The OAM Option . . . . . . . . . . . . . . . . . . . . . . . 2 62 3.1. Processing . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. The ICMPv6 OAM Message . . . . . . . . . . . . . . . . . . . 4 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Problem Statement 72 This document defines new IPv6 [RFC8200] Operations and Management 73 (OAM) capabilities. In order to support these new capabilities, this 74 document defines an IPv6 OAM Option and an ICMPv6 [RFC4443] OAM 75 message. 77 2. Requirements Language 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in BCP 82 14 [RFC2119] [RFC8174] when, and only when, they appear in all 83 capitals, as shown here. 85 3. The OAM Option 87 IPv6 source nodes use the OAM option to invoke one or more OAM 88 actions on downstream devices. The OAM option can be included in any 89 of the following: 91 o A Hop-by-hop header. 93 o A Destination Options header that precedes a Routing header. 95 o A Destination Options header that precedes an upper-layer header. 97 If a Hop-by-hop header includes an OAM option, OAM actions MAY be 98 invoked on every node along the path to the destination, including 99 the destination. If a Destination Options header that precedes a 100 Routing header includes an OAM option, OAM actions are invoked by the 101 first node that appears in the IPv6 Destination Address field plus 102 subsequent nodes listed in the Routing header. If a Destination 103 Options header that precedes an upper-layer header includes an OAM 104 option, OAM actions are invoked on the destination node only. 106 The OAM option includes the following fields: 108 o Option Type (8 bits): OAM. Value TBD by IANA. See Note 1 and 109 Note 2. 111 o Opt Data Len (8 bits): Length of Option Data, in bytes. Value 112 MUST be equal to 2. 114 o Option Data (16 bits): A bit mask indicating which OAM actions are 115 to be invoked. 117 +------+-----------+------------------------------------------------+ 118 | Bit | Action | Notes | 119 +------+-----------+------------------------------------------------+ 120 | 0 | Log the | The processing node creates a log entry. The | 121 | | packet | log entry reflects the time at which it was | 122 | | | created. It also reflects the time at which | 123 | | | the packet arrived. | 124 | | | | 125 | 1 | Count the | The processing node increments a counter. | 126 | | packet | | 127 | | | | 128 | 2 | Send an | The processing node sends an ICMP OAM message | 129 | | ICMPv6 | to the packet's source. The OAM message | 130 | | OAM | indicates the time at which the packet | 131 | | | arrived. | 132 | | | | 133 | 3 | Send | The processing node sends telemetry to a | 134 | | telemetry | monitoring station. Telemetry includes the | 135 | | | packet and the time at which the packet | 136 | | | arrived. | 137 | | | | 138 | 4-15 | Reserved | | 139 +------+-----------+------------------------------------------------+ 141 Table 1: Option Data Bits Mapped to OAM Actions 143 Table 1 maps Option Data bits to OAM actions. 145 NOTE 1: As per [RFC8200], the highest-order two bits of the Option 146 Type (i.e., the "act" bits) specify the action taken by a processing 147 node that does not recognize Option Type. The required action is 148 skip over this option and continue processing the header. Therefore, 149 IANA is requested to assign this Option Type with "act" bits "00". 151 NOTE 2: As per [RFC8200], the third-highest-order bit (i.e., the 152 "chg" bit) of the Option Type specifies whether Option Data can 153 change on route to the packet's destination. Because option data 154 MUST NOT be changed, IANA is requested to assign this Option Type 155 with "chg" bit "0". 157 3.1. Processing 159 The processing of OAM actions is optional. If a node does not 160 support particular OAM action, it can ignore the corresponding bit in 161 Option Data. 163 Having processed an OAM option, the processing node should continue 164 to process the packet. If possible, the OAM action should be 165 executed in parallel with the processing of the rest of the packet. 167 The processing node SHOULD execute the OAM action, even if it can not 168 process the packet further. For example, assume the following: 170 o A node receives a packet. 172 o The packet contains a Hop-by-hop Options header and the Hop-by-hop 173 Options header includes the OAM option. 175 o The node does not maintain a route to the packet's Destination 176 Address 178 In this case, the node SHOULD execute the requested OAM action. 179 Because the node does not maintain a route to the packet's 180 Destination Address, it should also send an ICMPv6 Destination 181 Unreachable message to the source node and discard the packet. 183 4. The ICMPv6 OAM Message 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type | Code | Checksum | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Length | Reserved | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Timestamp (seconds) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Timestamp (fraction) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | | 196 + Original Datagram + 197 | | 199 Figure 1 201 Figure 1 depicts the ICMPv6 OAM message. The ICMPv6 OAM message 202 contains the following fields: 204 o Type - OAM. Value TBD by IANA. 206 o Code - MUST be set to (0) No Error. 208 o Checksum - See [RFC4443] 210 o Reserved - MUST be set to 0 and MUST be ignored upon receipt. 212 o Length - Represents the length of the padded "original datagram" 213 field, measured in 32-bit words. 215 o Timestamp (seconds) - Represents the time at which the original 216 packet arrived in Network Time Protocol (NTP) [RFC5905] format. 218 o Timestamp (fraction) - Represents the time at which the original 219 packet arrived in NTP [RFC5905] format. 221 o Original Datagram - As much of invoking packet as possible without 222 the ICMPv6 packet exceeding the minimum IPv6 MTU (1280 bytes). 223 The original datagram MUST be zero padded to the nearest 32-bit 224 boundary. 226 ICMPv6 OAM messages SHOULD be rate limited by the sender. 228 The Timestamp fields SHOULD be as accurate as possible. They SHOULD 229 reflect the time at which the original packet arrived, not the time 230 at which the ICMPv6 OAM message was sent. 232 5. IANA Considerations 234 IANA is requested to perform the following actions: 236 o Allocate a codepoint from the Destination Options and Hop-by-hop 237 Options registry (https://www.iana.org/assignments/ipv6- 238 parameters/ipv6-parameters.xhtml#ipv6-parameters-2). This option 239 is called "OAM". The "act" bits are 00 and the "chg" bit is 0. 241 o Create a subregistry in the Destination Options and Hop-by-hop 242 Options registry (https://www.iana.org/assignments/ipv6- 243 parameters/ipv6-parameters.xhtml#ipv6-parameters-2). This 244 subregistry is called OAM Option Data Bit Mask. Its contents are 245 defined in Table 1 of this document. 247 o Allocate a codepoint from the "ICMPv6 'type' Numbers" registry 248 (https://www.iana.org/assignments/icmpv6-parameters/ 249 icmpv6-parameters.xml). This type is called "OAM". As it 250 represents an informational message, its value should be greater 251 than 128. 253 o Create a "Type x - OAM" subregistry in the "ICMPv6 'type' Numbers" 254 registry (https://www.iana.org/assignments/icmpv6-parameters/ 255 icmpv6-parameters.xml) registry. This subregistry contains the 256 Code entry (0) No Error. 258 6. Security Considerations 260 The OAM option can also be used in denial of service attacks. 261 Network devices SHOULD protect themselves against such attacks by 262 limiting the number of OAM options that they process per unit time. 263 If the rate limit is exceeded, the network device MAY either discard 264 the packet or continue to process the packet, ignoring the OAM 265 option. 267 7. Acknowledgements 269 The authors acknowledge Fred Baker, Shizhang Bi, Ross Callon, Brian 270 Carpenter and Tom Herbert for their helpful comments. 272 8. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 280 Control Message Protocol (ICMPv6) for the Internet 281 Protocol Version 6 (IPv6) Specification", STD 89, 282 RFC 4443, DOI 10.17487/RFC4443, March 2006, 283 . 285 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 286 "Network Time Protocol Version 4: Protocol and Algorithms 287 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 288 . 290 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 291 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 292 May 2017, . 294 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 295 (IPv6) Specification", STD 86, RFC 8200, 296 DOI 10.17487/RFC8200, July 2017, 297 . 299 Authors' Addresses 301 Ron Bonica 302 Juniper Networks 303 Herndon, Virginia 20171 304 USA 306 Email: rbonica@juniper.net 308 Ning So 309 Reliance Jio 310 3010 Gaylord PKWY, Suite 150 311 Frisco, Texas 75034 312 USA 314 Email: Ning.So@ril.com 316 Fengman Xu 317 Reliance Jio 318 3010 Gaylord PKWY, Suite 150 319 Frisco, Texas 75034 320 USA 322 Email: Fengman.Xu@ril.com 323 Gang Chen 324 Baidu 325 No.10 Xibeiwang East Road Haidian District 326 Beijing 100193 327 P.R. China 329 Email: phdgang@gmail.com 331 Yongqing Zhu 332 China Telecom 333 109 West Zhongshan Ave, Tianhe District 334 Guangzhou 335 P.R. China 337 Email: zhuyq.gd@chinatelecom.cn 339 Guangming Yang 340 China Telecom 341 109 West Zhongshan Ave, Tianhe District 342 Guangzhou 343 P.R. China 345 Email: yanggm.gd@chinatelecom.cn 347 Yifeng Zhou 348 ByteDance 349 Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian District 350 Beijing 100000 351 P.R. China 353 Email: yifeng.zhou@bytedance.com