idnits 2.17.1 draft-xiao-6man-icmpv6-ioam-conf-state-00.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 draft header indicates that this document updates RFC4884, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4884, updated by this document, for RFC5378 checks: 2005-09-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 October 2021) is 914 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 (-10) exists of draft-ietf-ippm-ioam-conf-state-01 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN Working Group X. Min 3 Internet-Draft ZTE Corp. 4 Updates: 4884 (if approved) G. Mirsky 5 Intended status: Standards Track Ericsson 6 Expires: 27 April 2022 24 October 2021 8 ICMPv6 Echo Request/Reply for Enabled In-situ OAM Capabilities 9 draft-xiao-6man-icmpv6-ioam-conf-state-00 11 Abstract 13 This document describes the ICMPv6 IOAM Echo functionality, which 14 uses the ICMPv6 IOAM Echo Request/Reply messages, allowing the IOAM 15 encapsulating node to discover the enabled IOAM capabilities of each 16 IOAM transit node and IOAM decapsulating node. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 27 April 2022. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 53 3. ICMPv6 IOAM Echo Request . . . . . . . . . . . . . . . . . . 3 54 4. ICMPv6 IOAM Echo Reply . . . . . . . . . . . . . . . . . . . 4 55 4.1. IOAM Capabilities Objects . . . . . . . . . . . . . . . . 5 56 4.2. Examples of IOAM Echo Reply . . . . . . . . . . . . . . . 7 57 5. ICMPv6 Message Processing . . . . . . . . . . . . . . . . . . 8 58 5.1. Code Field Processing . . . . . . . . . . . . . . . . . . 9 59 6. Updates to RFC 4884 . . . . . . . . . . . . . . . . . . . . . 10 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 65 10.2. Informative References . . . . . . . . . . . . . . . . . 14 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 68 1. Introduction 70 IPv6 encapsulation for In-situ OAM (IOAM) data is defined in 71 [I-D.ietf-ippm-ioam-ipv6-options], which uses IPv6 hop-by-hop options 72 and/or destination options to carry IOAM data. 74 As specified in [I-D.ietf-ippm-ioam-conf-state], echo request/reply 75 can be used for the IOAM encapsulating node to discover the enabled 76 IOAM capabilities at IOAM transit nodes and IOAM decapsulating node. 78 As specified in [RFC4443], the Internet Control Message Protocol for 79 IPv6 (ICMPv6) is an integral part of IPv6, and the base protocol MUST 80 be fully implemented by every IPv6 node. ICMPv6 messages include 81 error messages and informational messages, and the latter are 82 referred to as ICMPv6 Echo Request/Reply messages. [RFC4884] defines 83 ICMPv6 Extension Structure by which multi-part ICMPv6 error messages 84 are supported. [RFC8335] defines ICMPv6 Extended Echo Request/Reply 85 messages, and the ICMPv6 Extended Echo Request contains an ICMPv6 86 Extension Structure customized for this message. Both [RFC4884] and 87 [RFC8335] provide sound principles and examples on how to extend 88 ICMPv6 error messages and echo request/reply messages. 90 This document describes the ICMPv6 IOAM Echo functionality, which 91 uses the ICMPv6 IOAM Echo Request/Reply messages, allowing the IOAM 92 encapsulating node to discover the enabled IOAM capabilities of each 93 IOAM transit node and IOAM decapsulating node. 95 The IOAM encapsulating node sends an ICMPv6 IOAM Echo Request message 96 to each IOAM transit and decapsulating node, then each receiving node 97 executes access control procedures, and if access is granted, each 98 receiving node returns an ICMPv6 IOAM Echo Reply message which 99 indicates the enabled IOAM capabilities of the receiving node. The 100 ICMPv6 IOAM Echo Reply contains an ICMPv6 Extension Structure exactly 101 customized to this message, and the ICMPv6 Extension Structure 102 contains one or more IOAM Capabilities Objects. 104 Note that before the IOAM encapsulating node sends the ICMPv6 IOAM 105 Echo Request messages, it needs to know the IPv6 address of each node 106 along the transport path of a data packet. that can be achieved by 107 executing ICMPv6 traceroute or provisioning explicit path at the IOAM 108 encapsulating node. 110 2. Conventions Used in This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 3. ICMPv6 IOAM Echo Request 120 The ICMPv6 IOAM Echo Request message is encapsulated in an IPv6 121 header [RFC8200], like any ICMPv6 message. 123 The ICMPv6 IOAM Echo Request message has the following format: 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Type | Code | Checksum | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Identifier |Sequence Number| Num of NS-IDs | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 . IOAM Capabilities Query Container Payload . 133 . as specified in . 134 . Section 3.1 of draft-ietf-ippm-ioam-conf-state . 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 Figure 1: ICMPv6 IOAM Echo Request Message 139 IPv6 Header fields: 141 * Source Address: The Source Address identifies the IOAM 142 encapsulating node. It MUST be a valid IPv6 unicast address. 144 * Destination Address: The Destination Address identifies the IOAM 145 transit or decapsulating node. It MUST be a valid IPv6 unicast 146 address. 148 ICMPv6 fields: 150 * Type: IOAM Echo Request. The value is TBD1. 152 * Code: MUST be set to 0 and MUST be ignored upon receipt. 154 * Checksum: The same as defined in [RFC4443]. 156 * Identifier: An Identifier aids in matching IOAM Echo Replies to 157 IOAM Echo Requests. It may be zeroed. 159 * Sequence Number: A Sequence Number to aid in matching IOAM Echo 160 Replies to IOAM Echo Requests. It may be zeroed. 162 * Num of NS-IDs: Number of Namespace-IDs within the payload. 164 * Following the IOAM Echo Request header, it's a List of Namespace- 165 IDs, which is also called IOAM Capabilities Query Container 166 Payload in Section 3.1 of [I-D.ietf-ippm-ioam-conf-state]. If the 167 payload would not otherwise terminate on a 4-octet boundary, it 168 MUST be padded with zeroes. 170 4. ICMPv6 IOAM Echo Reply 172 The ICMPv6 IOAM Echo Reply message is encapsulated in an IPv6 header 173 [RFC8200], like any ICMPv6 message. 175 The ICMPv6 IOAM Echo Reply message has the following format: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type | Code | Checksum | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Identifier |Sequence Number| Num of NS-IDs | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 . IOAM Capabilities Response Container Payload . 185 . as specified in . 186 . Section 3.2 of draft-ietf-ippm-ioam-conf-state . 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 2: ICMPv6 IOAM Echo Reply Message 190 IPv6 Header fields: 192 * Source Address: Copied from the Destination Address field of the 193 invoking IOAM Echo Request packet. 195 * Destination Address: Copied from the Source Address field of the 196 invoking IOAM Echo Request packet. 198 ICMPv6 fields: 200 * Type: IOAM Echo Reply. The value is TBD2. 202 * Code: Values are (0) No Error, (1) Malformed Query, (2) No Matched 203 Namespace-ID, and (3) Exceed the minimum IPv6 MTU. 205 * Checksum: The same as defined in [RFC4443]. 207 * Identifier: Copied from the Identifier field of the invoking IOAM 208 Echo Request message. 210 * Sequence Number: Copied from the Sequence Number field of the 211 invoking IOAM Echo Request message. 213 * Num of NS-IDs: Number of different Namespace-IDs within the 214 payload, its value MUST be no more than the Num of NS-IDs field of 215 the invoking IOAM Echo Request message. 217 * Following the IOAM Echo Reply header, it's a List of IOAM 218 Capabilities Objects, which is also called IOAM Capabilities 219 Response Container Payload in Section 3.2 of 220 [I-D.ietf-ippm-ioam-conf-state]. 222 * Section 7 of [RFC4884] defines the ICMP Extension Structure. As 223 per RFC 4884, the Extension Structure contains exactly one 224 Extension Header followed by one or more objects. When applied to 225 the ICMPv6 IOAM Echo Reply message, the ICMP Extension Structure 226 SHOULD contain one or more IOAM Capabilities Objects. 228 4.1. IOAM Capabilities Objects 230 All ICMPv6 IOAM Capabilities Objects are encapsulated in an ICMPv6 231 IOAM Echo Reply message. 233 Each ICMPv6 IOAM Capabilities Object has the following format: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Length | Class-Num | C-Type | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 . IOAM Capabilities Object Payload . 241 . as specified in . 242 . Section 3.2.x of draft-ietf-ippm-ioam-conf-state . 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 3: IOAM Capabilities Object 247 Object fields: 249 * Class-Num: IOAM Capabilities Objects. The values are listed as 250 the following: 252 Value Object Name 253 ----- ----------- 254 TBD3 IOAM Tracing Capabilities Object 255 TBD4 IOAM Proof-of-Transit Capabilities Object 256 TBD5 IOAM Edge-to-Edge Capabilities Object 257 TBD6 IOAM DEX Capabilities Object 258 TBD7 IOAM End-of-Domain Object 260 * C-Type: Values are listed as the following: 262 Class-Num C-Type C-Type Name 263 --------- ------ ----------- 264 TBD3 0 Reserved 265 1 Pre-allocated Tracing 266 2 Incremental Tracing 267 TBD4 0 Reserved 268 TBD5 0 Reserved 269 TBD6 0 Reserved 270 TBD7 0 Reserved 272 * Length: Length of the object, measured in octets, including the 273 Object Header and Object Payload. 275 * Following the IOAM Capabilities Object Header, it's the IOAM 276 Capabilities Object Payload, which is defined respectively in 277 Section 3.2.1, Section 3.2.2, Section 3.2.3, Section 3.2.4, 278 Section 3.2.5 and Section 3.2.6 of 279 [I-D.ietf-ippm-ioam-conf-state]. 281 4.2. Examples of IOAM Echo Reply 283 The format of ICMPv6 IOAM Echo Reply can vary from deployment to 284 deployment. 286 In a deployment where only the default Namespace-ID is used, the IOAM 287 Pre-allocated Tracing Capabilities and IOAM Proof-of-Transit 288 Capabilities are enabled at the IOAM transit node that received 289 ICMPv6 IOAM Echo Request message, the ICMPv6 IOAM Echo Reply message 290 is depicted as the following: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Code | Checksum | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Identifier |Sequence Number| Num of NS-IDs | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Length | Class-Num | C-Type | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | IOAM-Trace-Type | Reserved |W| 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Namespace-ID | Egress_MTU | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Egress_if_id (short or wide format) ...... | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Length | Class-Num | C-Type | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Namespace-ID | IOAM-POT-Type |P|SoR|Reserved | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 In a deployment where only the default Namespace-ID is used, the IOAM 313 Pre-allocated Tracing Capabilities, IOAM Proof-of-Transit 314 Capabilities and IOAM Edge-to-Edge Capabilities are enabled at the 315 IOAM decapsulating node that received ICMPv6 IOAM Echo Request 316 message, the ICMPv6 IOAM Echo Reply message is depicted as the 317 following: 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Code | Checksum | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Identifier |Sequence Number| Num of NS-IDs | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Length | Class-Num | C-Type | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | IOAM-Trace-Type | Reserved |W| 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Namespace-ID | Egress_MTU | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Egress_if_id (short or wide format) ...... | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Length | Class-Num | C-Type | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Namespace-ID | IOAM-POT-Type |P|SoR|Reserved | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Length | Class-Num | C-Type | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Namespace-ID | IOAM-E2E-Type | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 |TSF|TSL| Reserved | MBZ | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Note that when an ICMPv6 IOAM Echo Request message or IOAM Echo Reply 346 message is received, the Payload Length field of IPv6 Header 347 [RFC8200] indicates the message length. 349 5. ICMPv6 Message Processing 351 When a node receives an ICMPv6 IOAM Echo Request message and any of 352 the following conditions apply, the node MUST silently discard the 353 incoming message: 355 * The node does not recognize the ICMPv6 IOAM Echo Request message. 357 * The node has not explicitly enabled ICMPv6 IOAM Echo 358 functionality. 360 * The incoming ICMPv6 IOAM Echo Request carries a Source Address 361 that is not explicitly authorized. 363 * The Source Address of the incoming message is not a unicast 364 address. 366 * The Destination Address of the incoming message is a multicast 367 address. 369 Otherwise, when a node receives an ICMPv6 IOAM Echo Request, it MUST 370 format an ICMPv6 IOAM Echo Reply as follows: 372 * Set the Hop Limit to 255. 374 * Set the DiffServ codepoint to CS0 [RFC4594]. 376 * Copy the Destination Address from the IOAM Echo Request to the 377 Source Address of the IOAM Echo Reply. 379 * Copy the Source Address from the IOAM Echo Request to the 380 Destination Address of the IOAM Echo Reply. 382 * Set the Next Header to (58) ICMPv6. 384 * Set the ICMPv6 Type to (TBD2) IOAM Echo Reply. 386 * Copy the Identifier from the IOAM Echo Request to the IOAM Echo 387 Reply. 389 * Copy the Sequence Number from the IOAM Echo Request to the IOAM 390 Echo Reply. 392 * Set the Code field as described in Section 5.1. 394 * If the Code field is equal to (0) No Error, then add one or more 395 objects as described in Section 4.1. 397 * Set the Checksum appropriately. 399 * Forward the ICMPv6 IOAM Echo Reply to its destination. 401 5.1. Code Field Processing 403 The Code field MUST be set to (1) Malformed Query if any of the 404 following conditions apply: 406 * The ICMPv6 IOAM Echo Request does not include any Namespace-ID. 408 * The value of Num of NS-IDs field does not match the contained list 409 of Namespace-IDs. 411 * The query is otherwise malformed. 413 The Code field MUST be set to (2) No Matched Namespace-ID if none of 414 the contained list of Namespace-IDs is recognized. 416 The Code field MUST be set to (3) Exceed the minimum IPv6 MTU if the 417 formatted ICMPv6 IOAM Echo Reply exceeds the minimum IPv6 MTU (i.e., 418 1280 octets). In this case, all objects MUST be stripped before 419 forwarding the ICMPv6 Echo Reply to its destination. 421 Otherwise, the Code field MUST be set to (0) No Error. 423 6. Updates to RFC 4884 425 Section 4.6 of [RFC4884] provides a list of extensible ICMP messages 426 (i.e., messages that can carry the ICMP Extension Structure). This 427 document adds the ICMPv6 IOAM Echo Request message and the ICMPv6 428 IOAM Echo Reply message to that list. 430 7. IANA Considerations 432 This document requests the following IANA actions: 434 * Add the following to the "ICMPv6 'type' Numbers" registry: 436 - TBD1 IOAM Echo Request 438 - As ICMPv6 distinguishes between informational and error 439 messages, and this is an informational message, the value must 440 be assigned from the range 128-255. 442 * Add the following to the "Type TBD1 - IOAM Echo Request" sub- 443 registry: 445 - (0) No Error 447 * Add the following to the "ICMPv6 'type' Numbers" registry: 449 - TBD2 IOAM Echo Reply 451 - As ICMPv6 distinguishes between informational and error 452 messages, and this is an informational message, the value must 453 be assigned from the range 128-255. 455 * Add the following to the "Type TBD2 - IOAM Echo Reply" sub- 456 registry: 458 - (0) No Error 460 - (1) Malformed Query 461 - (2) No Matched Namespace-ID 463 - (3) Exceed the minimum IPv6 MTU 465 * Add the following to the "ICMP Extension Object Classes and Class 466 Sub-types" registry: 468 - (TBD3) IOAM Tracing Capabilities Object 470 * Add the following C-types to the "Sub-types - Class TBD3 - IOAM 471 Tracing Capabilities Object" sub-registry: 473 - (0) Reserved 475 - (1) Pre-allocated Tracing 477 - (2) Incremental Tracing 479 - C-Type values are assigned on a First Come First Serve (FCFS) 480 basis with a range of 0-255. 482 * Add the following to the "ICMP Extension Object Classes and Class 483 Sub-types" registry: 485 - (TBD4) IOAM Proof-of-Transit Capabilities Object 487 * Add the following C-types to the "Sub-types - Class TBD4 - IOAM 488 Proof-of-Transit Capabilities Object" sub-registry: 490 - (0) Reserved 492 - C-Type values are assigned on an FCFS basis with a range of 493 0-255. 495 * Add the following to the "ICMP Extension Object Classes and Class 496 Sub-types" registry: 498 - (TBD5) IOAM Edge-to-Edge Capabilities Object 500 * Add the following C-types to the "Sub-types - Class TBD5 - IOAM 501 Edge-to-Edge Capabilities Object" sub-registry: 503 - (0) Reserved 505 - C-Type values are assigned on an FCFS basis with a range of 506 0-255. 508 * Add the following to the "ICMP Extension Object Classes and Class 509 Sub-types" registry: 511 - (TBD6) IOAM DEX Capabilities Object 513 * Add the following C-types to the "Sub-types - Class TBD6 - IOAM 514 DEX Capabilities Object" sub-registry: 516 - (0) Reserved 518 - C-Type values are assigned on an FCFS basis with a range of 519 0-255. 521 * Add the following to the "ICMP Extension Object Classes and Class 522 Sub-types" registry: 524 - (TBD7) IOAM End-of-Domain Object 526 * Add the following C-types to the "Sub-types - Class TBD7 - IOAM 527 End-of-Domain Object" sub-registry: 529 - (0) Reserved 531 - C-Type values are assigned on an FCFS basis with a range of 532 0-255. 534 All codes mentioned above are assigned on an FCFS basis with a range 535 of 0-255. 537 8. Security Considerations 539 Securiy issues discussed in [I-D.ietf-ippm-ioam-conf-state] apply to 540 this document. 542 This document recommends using IP Authentication Header [RFC4302] or 543 IP Encapsulating Security Payload Header [RFC4303] to provide 544 integrity protection for IOAM Capabilities info. 546 This document recommends using IP Encapsulating Security Payload 547 Header [RFC4303] to provide privacy protection for IOAM Capabilities 548 info. 550 This document recommends that the network operators establish 551 policies that restrict access to ICMPv6 IOAM Echo functionality. In 552 order to enforce these policies, nodes that support ICMPv6 IOAM Echo 553 functionality MUST support the following configuration options: 555 * Enable/disable ICMP IOAM Echo functionality. By default, ICMPv6 556 IOAM Echo functionality is disabled. 558 * Define enabled Namespace-IDs. By default, all Namespace-IDs 559 except the default one (i.e., Namespace-ID 0x0000) are disabled. 561 * For each enabled Namespace-ID, define the prefixes from which 562 ICMPv6 IOAM Echo Request messages are permitted. 564 When a node receives an ICMPv6 IOAM Echo Request message that it is 565 not configured to support, it MUST silently discard the message. See 566 Section 5 for details. 568 In order to protect local resources, implementations SHOULD rate- 569 limit incoming ICMPv6 IOAM Echo Request messages. 571 9. Acknowledgements 573 TBA. 575 10. References 577 10.1. Normative References 579 [I-D.ietf-ippm-ioam-conf-state] 580 Min, X., Mirsky, G., and L. Bo, "Echo Request/Reply for 581 Enabled In-situ OAM Capabilities", Work in Progress, 582 Internet-Draft, draft-ietf-ippm-ioam-conf-state-01, 24 583 October 2021, . 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, 588 DOI 10.17487/RFC2119, March 1997, 589 . 591 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 592 Control Message Protocol (ICMPv6) for the Internet 593 Protocol Version 6 (IPv6) Specification", STD 89, 594 RFC 4443, DOI 10.17487/RFC4443, March 2006, 595 . 597 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 598 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 599 DOI 10.17487/RFC4884, April 2007, 600 . 602 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 603 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 604 May 2017, . 606 10.2. Informative References 608 [I-D.ietf-ippm-ioam-ipv6-options] 609 Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", 610 Work in Progress, Internet-Draft, draft-ietf-ippm-ioam- 611 ipv6-options-06, 31 July 2021, 612 . 615 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 616 DOI 10.17487/RFC4302, December 2005, 617 . 619 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 620 RFC 4303, DOI 10.17487/RFC4303, December 2005, 621 . 623 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 624 Guidelines for DiffServ Service Classes", RFC 4594, 625 DOI 10.17487/RFC4594, August 2006, 626 . 628 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 629 (IPv6) Specification", STD 86, RFC 8200, 630 DOI 10.17487/RFC8200, July 2017, 631 . 633 [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. 634 Boucadair, "PROBE: A Utility for Probing Interfaces", 635 RFC 8335, DOI 10.17487/RFC8335, February 2018, 636 . 638 Authors' Addresses 640 Xiao Min 641 ZTE Corp. 642 Nanjing 643 China 645 Phone: +86 25 88013062 646 Email: xiao.min2@zte.com.cn 647 Greg Mirsky 648 Ericsson 649 United States of America 651 Email: gregimirsky@gmail.com