idnits 2.17.1 draft-liu-6man-icmp-verification-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 : ---------------------------------------------------------------------------- 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 (22 September 2021) is 945 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) ** Downref: Normative reference to an Informational RFC: RFC 4594 == Outdated reference: A later version (-05) exists of draft-dskc-bess-bgp-car-problem-statement-03 == Outdated reference: A later version (-07) exists of draft-hegde-spring-mpls-seamless-sr-05 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-07 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-17 == Outdated reference: A later version (-17) exists of draft-ietf-lsr-ip-flexalgo-03 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-05 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Liu 3 Internet-Draft ZTE 4 Intended status: Standards Track 22 September 2021 5 Expires: 26 March 2022 7 Extending ICMP for IP-related Information Validation 8 draft-liu-6man-icmp-verification-00 10 Abstract 12 This document introduces the mechanism to verify the data plane 13 against the control plane in IP/SRv6 networks by extending ICMP 14 messages. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 26 March 2022. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 51 2. ICMPv6 Validation Request . . . . . . . . . . . . . . . . . . 3 52 2.1. Validation Information Object . . . . . . . . . . . . . . 4 53 2.1.1. SRv6 Endpoint Behavior . . . . . . . . . . . . . . . 5 54 2.1.2. IPv6 Prefix IGP Algorithm . . . . . . . . . . . . . . 6 55 2.1.3. SRv6 IGP-Adjacency Segment . . . . . . . . . . . . . 6 56 2.1.4. VPN IPv4 Prefix . . . . . . . . . . . . . . . . . . . 8 57 2.1.5. VPN IPv6 Prefix . . . . . . . . . . . . . . . . . . . 9 58 3. ICMPv6 Validation Reply . . . . . . . . . . . . . . . . . . . 10 59 4. ICMP Validation Message Processing . . . . . . . . . . . . . 10 60 4.1. Sending a Validation Request . . . . . . . . . . . . . . 11 61 4.2. Receiving a Validation Request . . . . . . . . . . . . . 11 62 4.3. Sending a Validation Reply . . . . . . . . . . . . . . . 12 63 4.3.1. Return Code . . . . . . . . . . . . . . . . . . . . . 13 64 4.4. Receiving a Validation Reply . . . . . . . . . . . . . . 13 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 69 7.2. Informative References . . . . . . . . . . . . . . . . . 15 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 72 1. Introduction 74 An MPLS label can be related with various FEC information, e.g, VPN 75 IP prefix [RFC4365], LDP IP prefix[RFC5036], flex 76 algorithms[I-D.ietf-lsr-flex-algo] and etc. Most of these 77 information can be advertised via control plane protocols(e.g, IGP, 78 BGP, etc). 80 Procedures for simple and efficient mechanisms to verify the data 81 plane against the control plane using LSP Ping in MPLS network are 82 well defined in [RFC8029]. Normally, when a new feature is 83 introduced and the MPLS label is associated with new information, the 84 LSP Ping mechanism is still applicable by defining new FEC sub-TLV 85 with the new information encoded in it. 87 On the other hand, IP addresses, especially the IPv6 address/SRv6 88 SID, can be related with extra information/function besides basic 89 forwarding/routing semantics. 91 Below is a non-exhaustive list of the information that can be related 92 with IP addresses/SRv6 SIDs and propagated to the control plane. 94 * VPN/EVPN Services [I-D.ietf-bess-srv6-services] 95 * SRv6 Endpoint Behaviors for Network Programming [RFC8986] 97 * Flex Algorithms [I-D.ietf-lsr-flex-algo] 98 [I-D.ietf-lsr-ip-flexalgo] 100 * Service Functions [I-D.ietf-spring-sr-service-programming] 102 * End-to-end Intent of a Path [I-D.hegde-spring-mpls-seamless-sr] 103 [I-D.dskc-bess-bgp-car-problem-statement] 105 In IP networks, there're requirements to check the consistency 106 between the control plane and the data plane to localize faults. 108 Take IPv4 VPN as an example, in MPLS, an MPLS label is allocated for 109 the VPN prefix, the label is advertised together with the VPN prefix 110 via BGP [RFC4365]. To verify this information, VPN IPv4 Prefix FEC 111 sub-TLV is defined which carries the VPN prefix to be verified via 112 LSP ping[RFC8029]. Similarly, in SRv6, an SRv6 SID is associated 113 with a VPN prefix, and they are advertised together via 114 BGP[I-D.ietf-bess-srv6-services]. One may want to verify the SID- 115 related VPN prefix just like what is done in MPLS-VPN. 117 This document introduces the mechanism to verify the data plane 118 against the control plane in IP networks by extending ICMP messages. 119 Currently this document focuses on the extensions of ICMPv6 and the 120 related processing procedures, considering that the requirements are 121 stronger for IPv6/SRv6 networks. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2. ICMPv6 Validation Request 131 The Validation Request message is defined for ICMPv6[RFC4443]. Like 132 any ICMPv6 message, the ICMPv6 Validation Request message is 133 encapsulated in an IPv6 header. 135 The structure of ICMP Validation Request is shown in Figure 1, where: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Type | Code | Checksum | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Identifier |Sequence Number| Reserved | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | ICMP Extension Structure 146 Figure 1: Validation Request 148 * Type: The value is TBD1. 150 * Code: MUST be set to 0 and MUST be ignored upon receipt. 152 * Checksum: For ICMPv6, see [RFC4443]. 154 * Identifier: An Identifier to aid in matching Validation Replies to 155 Validation Requests. May be zero. 157 * Sequence Number: A Sequence Number to aid in matching Validation 158 Replies to Validation Requests. May be zero. 160 * Reserved: This field MUST be set to 0 and ignored upon receipt. 162 * ICMP Extension Structure: The ICMP Extension Structure carries the 163 information that needs to be verified. Section 7 of [RFC4884] 164 defines the ICMP Extension Structure. As per [RFC4884], the 165 Extension Structure contains one Extension Header followed by one 166 or more objects. When applied to the ICMP Validation Request 167 message, the ICMP Extension Structure MUST only contain one or 168 more instance of the Validation Information Objects as defined in 169 section 2.1. 171 2.1. Validation Information Object 173 The Validation Information Object is shown in Figure 2, where: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Length | Class-Num | C-Type | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 | // (Object payload) // | 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 2: Validation Information Object 187 * Length: Length of the object, measured in octets, including the 188 Object Header and Object Payload. 190 * Class-Num: Validation Information Object. The value is TBD2. 192 * Object payload: Variable-length field. C-Type-specific data. 194 * C-Type: For this object, the C-Type is used to indicate the type 195 of the information that needs to be verified. The values of 196 C-Type and the corresponding object payload are given below: 198 C-Type Object Payload 199 -------- ----------- 200 1 Endpoint Behavior 201 2 IPv6 Prefix IGP Algorithm 202 3 SRv6 IGP-Adjacency Segment 203 4 VPN IPv4 Prefix 204 5 VPN IPv6 Prefix 206 Other C-Type values and the corresponding information carried in 207 object payload will be defined as needed. 209 2.1.1. SRv6 Endpoint Behavior 211 When the endpoint behavior[RFC8986] of an SRv6 SID needs to be 212 verified, the following format of object payload is used. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Endpoint Behavior | Must Be Zero | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Endpoint Behavior: 2 octets. The codepoints for the Endpoint 221 behaviors are defined in the "SRv6 Endpoint Behaviors" registry 222 defined in [RFC8986]. 224 2.1.2. IPv6 Prefix IGP Algorithm 226 IGP Flex-Algorithm can be used with both Segment Routing data 227 planes(i.e, SR-MPLS and SRv6) [I-D.ietf-lsr-flex-algo] and for 228 regular IPv4 and IPv6 prefixes [I-D.ietf-lsr-ip-flexalgo] . 230 When the algorithm of an SRv6 SID or IPv6 prefix needs to be 231 verified, the following format of object payload is used. 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Protocol | Algorithm | Reserved | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Protocol 240 Set to 1 if the responder MUST perform validation using OSPF 241 as the IGP protocol. Set to 2 if the responder MUST perform 242 validation using IS-IS as the IGP protocol. Set to 0 if the 243 responder can use any IGP protocol for validation. 245 Algorithm 246 Set to 0 if the default algorithm is used. Set to 1 if 247 Strict Shortest Path First (Strict-SPF) algorithm is used. 248 For Flex-Algo, the Algorithm field MUST be set with the 249 algorithm value (values can be 128-255). 251 SRv6 End SIDs inherit the algorithm from the parent locator. 253 Reserved 254 MUST be 0 when originated and MUST be ignored when received. 256 2.1.3. SRv6 IGP-Adjacency Segment 258 This object payload is applicable for SRv6 IGP-Adjacency defined in 259 [RFC8402]. The format is as specified below: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Adj. Type | Protocol | Algorithm | Reserved | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 ~ ~ 267 | Local Interface ID (4 or 16 octets) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 ~ ~ 270 | Remote Interface ID (4 or 16 octets) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 ~ ~ 273 | Advertising Node Identifier (4 or 6 octets) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 ~ ~ 276 | Receiving Node Identifier (4 or 6 octets) | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Adj. Type (Adjacency Type) 280 Set to 1 when the Adjacency Segment is a Parallel Adjacency 281 as defined in [RFC8402]. Set to 4 when the Adjacency Segment 282 is IPv4 based and is not a Parallel Adjacency. Set to 6 when 283 the Adjacency Segment is IPv6 based and is not a Parallel 284 Adjacency. Set to 0 when the Adjacency Segment is over an 285 unnumbered interface. 287 Protocol 288 Set to 1 if the responder MUST perform validation using OSPF 289 as the IGP protocol. Set to 2 if the responder MUST perform 290 validation using IS-IS as the IGP protocol. Set to 0 if the 291 responder can use any IGP protocol for validation. 293 Algorithm 294 Set to 0 if the default algorithm is used. Set to 1 if 295 Strict Shortest Path First (Strict-SPF) algorithm is used. 296 For Flex-Algo, the Algorithm field MUST be set with the 297 algorithm value (values can be 128-255). 299 The algorithm is specified in the individual SRv6 Adjacency 300 SID. 302 Local Interface ID 303 An identifier that is assigned by the local node for a link 304 to which the Adjacency Segment ID is bound. This field is 305 set to a local link address (IPv4 or IPv6). For IPv4, this 306 field is 4 octets; for IPv6, this field is 16 octets. If 307 unnumbered, this field is 4 octets and includes a 32-bit link 308 identifier as defined in [RFC4203] and [RFC5307]. If the 309 Adjacency Segment ID represents Parallel Adjacencies, this 310 field is 4 octets and MUST be set to 4 octets of zeroes. 312 Remote Interface ID 313 An identifier that is assigned by the remote node for a link 314 on which the Adjacency Segment ID is bound. This field is 315 set to the remote (downstream neighbor) link address (IPv4 or 316 IPv6). For IPv4, this field is 4 octets; for IPv6, this 317 field is 16 octets. If unnumbered, this field is 4 octets 318 and includes a 32-bit link identifier as defined in [RFC4203] 319 and [RFC5307]. If the Adjacency Segment ID represents 320 Parallel Adjacencies, this field is 4 octets and MUST be set 321 to 4 octets of zeroes. 323 Advertising Node Identifier 324 This specifies the Advertising Node Identifier. When the 325 Protocol field is set to 1, then this field is 4 octets and 326 carries the 32-bit OSPF Router ID. If the Protocol field is 327 set to 2, then this field is 6 octets and carries the 48-bit 328 IS-IS System ID. If the Protocol field is set to 0, then 329 this field is 4 octets and MUST be set to zero. 331 Receiving Node Identifier 332 This specifies the downstream node identifier. When the 333 Protocol field is set to 1, then this field is 4 octets and 334 carries the 32-bit OSPF Router ID. If the Protocol field is 335 set to 2, then this field is 6 octets and carries the 48-bit 336 IS-IS System ID. If the Protocol field is set to 0, then 337 this field is 4 octets and MUST be set to zero. 339 2.1.4. VPN IPv4 Prefix 341 IPv4 VPN Over SRv6 Core is introduced in 342 [I-D.ietf-bess-srv6-services], where an SRv6 service SID is 343 associated with a VPN IPv4 prefix at the egress PE. 345 When the related VPN IPv4 prefix of an SRv6 service SID needs to be 346 verified, the following format of object payload is used. The Value 347 field consists of the RD advertised with the VPN IPv4 prefix, the 348 IPv4 prefix (with trailing 0 bits to make 32 bits in all), and a 349 prefix length, as follows: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Route Distinguisher | 355 | (8 octets) | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | IPv4 prefix | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Prefix Length | Must Be Zero | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 The RD is an 8-octet identifier, it does not contain any inherent 363 information. The purpose of the RD is solely to allow one to create 364 distinct routes to a common IPv4 address prefix. The encoding of the 365 RD is not important here. When matching this field to the local 366 information, it is treated as an opaque value. 368 2.1.5. VPN IPv6 Prefix 370 IPv6 VPN Over SRv6 Core is introduced in 371 [I-D.ietf-bess-srv6-services], where an SRv6 service SID is 372 associated with a VPN IPv6 prefix at the egress PE. 374 When the related VPN IPv6 prefix of an SRv6 service SID needs to be 375 verified, the following format of object payload is used. 377 The object payload field consists of the RD advertised with the VPN 378 IPv6 prefix, the IPv6 prefix (with trailing 0 bits to make 128 bits 379 in all), and a prefix length, as follows: 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Route Distinguisher | 385 | (8 octets) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | IPv6 prefix | 388 | | 389 | | 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Prefix Length | Must Be Zero | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 The RD is an 8-octet identifier, it does not contain any inherent 396 information. The purpose of the RD is solely to allow one to create 397 distinct routes to a common IPv4 address prefix. The encoding of the 398 RD is not important here. When matching this field to the local 399 information, it is treated as an opaque value. 401 3. ICMPv6 Validation Reply 403 The Validation Reply message is defined for ICMPv6. Like any ICMPv6 404 message, the ICMP Extended Echo Reply message is encapsulated in an 405 IPv6 header. Figure 3 describes the ICMPv6 Validation Reply message. 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type | Code | Checksum | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Identifier |Sequence Number| Reserved | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Figure 3: Validation Reply 417 ICMP fields: 419 * Type: Validation Reply. The value is TBD3. 421 * Code: Values are 423 (0) Validation passed 425 (1) Malformed request received 427 (2) One or more of the objects were not understood 429 (3) Information mismatch 431 * Checksum: For ICMPv6, see [RFC4443]. 433 * Identifier: Copied from the Identifier field of the invoking 434 Validation Request packet. 436 * Sequence Number: Copied from the Sequence Number field of the 437 invoking Validation Request packet. 439 4. ICMP Validation Message Processing 440 4.1. Sending a Validation Request 442 A node that originates an ICMP validation request message SHOULD 443 first determine which IP address needs to be verified with what 444 information. How the sender node get the information is out of scope 445 of the document. 447 An ICMPv6 validation request contains one or more Validation 448 Information objects, depending on how the user wants to do the 449 validation. For example, an SRv6 service SID is related with an 450 endpoint behavior and an IPv4 VPN prefix, if one wants to verify both 451 information of the SID via one request message, an ICMPv6 validation 452 request is sent with two validation information objects in it. Or 453 one may choose to send two individual ICMPv6 validation requests, 454 each carries one validation information object to verify these two 455 information separately. 457 The target IP is the IP address/SRv6 SID to be verified and MUST be a 458 unicast address. The ICMPv6 validation request is sent with the 459 target IP address/SRv6 SID set as the destination address of the IP 460 header field without SRH, or set as the last segment with SRH. The 461 Source Address of the ICMPv6 packet MUST be a unicast address 462 belonging to the node. 464 The Hop Limit SHOULD be set to 255 to prevent transit nodes from 465 processing the validation request. 467 4.2. Receiving a Validation Request 469 All transit nodes process the validation request message like any 470 other IPv6 data packet and hence do not require any change. 472 As specified in [RFC4443], if a router receives a packet with a Hop 473 Limit of zero, or if a router decrements a packet's Hop Limit to 474 zero, it MUST discard the packet and originate an ICMPv6 Time 475 Exceeded message with Code 0 to the source of the packet. The source 476 address SHOULD be set as a local address of the router. 478 The target node is a node receiving an validation request where the 479 target IP of that message is locally configured as a segment or local 480 interface. 482 When the validation request packet arrives at the target node, and 483 any of the following conditions apply, the node MUST silently discard 484 the incoming message: 486 * The node does not recognize ICMP Validation Request messages. 488 * The node has not explicitly enabled ICMP Validation functionality. 490 * The incoming ICMP Validation Request carries a Source Address that 491 is not explicitly authorized for the incoming ICMP Validation 492 Request type. 494 * The Source Address of the incoming message is not a unicast 495 address. 497 * The Destination Address of the incoming message is not a unicast 498 address. 500 Otherwise, if the packet is well formed, the target node verifies the 501 information encoded in the Validation Information Object against the 502 corresponding local information. 504 4.3. Sending a Validation Reply 506 When a node receives an ICMPv6 Validation Request, it MUST format an 507 ICMPv6 Validation Reply as follows: 509 * Copy the Source Address from the Validation Request message to the 510 Destination Address of the Validation Reply. 512 * Copy the Destination Address from the Validation Request message 513 to the Source Address of the Validation Reply. 515 * Set the Hop Limit to 255 517 * Set the Next Header to ICMPv6. 519 * Set the DiffServ codepoint to CS0 [RFC4594]. 521 * Set the ICMP Type to Validation Reply. 523 * Copy the Identifier from the Validation Request message to the 524 Validation Reply. 526 * Copy the Sequence Number from the Validation Request message to 527 the Validation Reply. 529 * Set the Code field as described in Section 4.3.1 531 * Set the Checksum appropriately. 533 * Forward the ICMP Validation Reply to its destination. 535 4.3.1. Return Code 537 The Code field MUST be set to 0 if all the the information encoded in 538 the Validation Information Object is consistent with the the 539 corresponding local information on the target node. 541 The Code field MUST be set to 1 if any of the following conditions 542 apply: 544 * The ICMP Request does not include an ICMP Extension Structure. 546 * The ICMP Extension Structure does not only include the Validation 547 Information Object(s). 549 * The query is otherwise malformed. 551 The Code field MUST be set to 2 if one or more of the objects are not 552 understood by the node. 554 The Code field MUST be set to 3 if the information in the Validation 555 Information Object(s) is not consistent with the local information 556 and validation is not passed. 558 4.4. Receiving a Validation Reply 560 A node should only receive a validation reply in response to a 561 validation request that it sent. Thus, on receipt of a validation 562 reply, the node should parse the packet to ensure that it is well- 563 formed, then attempt to match up the validation reply with a 564 validation request that it had previously sent, using the Identifier 565 and Sequence Number. If no match is found, the node ignores the echo 566 reply. 568 5. IANA Considerations 570 This document requests the following actions from IANA: 572 * Add an entry to the "ICMPv6 "type" Numbers" registry, representing 573 the Validation Request. This entry has one code 0. 575 * Add an entry to the "ICMPv6 "type" Numbers" registry, representing 576 the Validation Reply. This entry has the following codes: 578 (0) Validation passed 580 (1) Malformed request received 582 (2) One or more of the objects were not understood 583 (3) Information mismatch 585 * Add an entry to the "Validation Information Object Classes and 586 Class Sub-types" registry, representing the Validation Information 587 Object with C-types: 589 (1) Endpoint Behavior 591 (2) IPv6 Prefix IGP Algorithm 593 (3) SRv6 IGP-Adjacency Segment 595 (4) VPN IPv4 Prefix 597 (5) VPN IPv6 Prefix 599 C-Type values are assignable on a first-come-first-serve (FCFS) 600 basis with a range of 0-255. 602 All codes mentioned above are assigned on a First Come First Serve 603 (FCFS) basis with a range of 0-255. 605 6. Security Considerations 607 Security considerations discussed in [RFC4443] and[RFC4884] apply to 608 this document. 610 To protect against unauthorized sources using validation request 611 messages to obtain network information, it is RECOMMENDED that 612 implementations provide a means of checking the source addresses of 613 validation request messages against an access list before accepting 614 the message. 616 The validation mechanism SHOULD be only used in the limited domain. 617 The validation request contains the control plane information, 618 policies should be implemented on the edge devices of the domain to 619 prevent the information from being leaked into other domains. 621 In order to protect local resources, implementations SHOULD rate- 622 limit incoming ICMP Request messages. 624 7. References 626 7.1. Normative References 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, 630 DOI 10.17487/RFC2119, March 1997, 631 . 633 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 634 Support of Generalized Multi-Protocol Label Switching 635 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 636 . 638 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 639 Control Message Protocol (ICMPv6) for the Internet 640 Protocol Version 6 (IPv6) Specification", STD 89, 641 RFC 4443, DOI 10.17487/RFC4443, March 2006, 642 . 644 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 645 Guidelines for DiffServ Service Classes", RFC 4594, 646 DOI 10.17487/RFC4594, August 2006, 647 . 649 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 650 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 651 DOI 10.17487/RFC4884, April 2007, 652 . 654 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 655 in Support of Generalized Multi-Protocol Label Switching 656 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 657 . 659 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 660 Decraene, B., Litkowski, S., and R. Shakir, "Segment 661 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 662 July 2018, . 664 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 665 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 666 (SRv6) Network Programming", RFC 8986, 667 DOI 10.17487/RFC8986, February 2021, 668 . 670 7.2. Informative References 672 [I-D.dskc-bess-bgp-car-problem-statement] 673 Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K., 674 Decraene, B., Steinberg, D., Jalil, L., Guichard, J., 675 Patel, K., and W. Henderickx, "BGP Color-Aware Routing 676 Problem Statement", Work in Progress, Internet-Draft, 677 draft-dskc-bess-bgp-car-problem-statement-03, 23 May 2021, 678 . 681 [I-D.hegde-spring-mpls-seamless-sr] 682 Hegde, S., Bowers, C., Xu, X., Gulko, A., Bogdanov, A., 683 Uttaro, J., Jalil, L., Khaddam, M., Alston, A., and L. M. 684 Contreras, "Seamless SR Problem Statement", Work in 685 Progress, Internet-Draft, draft-hegde-spring-mpls- 686 seamless-sr-05, 22 February 2021, 687 . 690 [I-D.ietf-bess-srv6-services] 691 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 692 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 693 Overlay Services", Work in Progress, Internet-Draft, 694 draft-ietf-bess-srv6-services-07, 11 April 2021, 695 . 698 [I-D.ietf-lsr-flex-algo] 699 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 700 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 701 Internet-Draft, draft-ietf-lsr-flex-algo-17, 6 July 2021, 702 . 705 [I-D.ietf-lsr-ip-flexalgo] 706 Britto, W., Hegde, S., Kaneriya, P., Shetty, R., Bonica, 707 R., and P. Psenak, "IGP Flexible Algorithms (Flex- 708 Algorithm) In IP Networks", Work in Progress, Internet- 709 Draft, draft-ietf-lsr-ip-flexalgo-03, 14 May 2021, 710 . 713 [I-D.ietf-spring-sr-service-programming] 714 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 715 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 716 S. Salsano, "Service Programming with Segment Routing", 717 Work in Progress, Internet-Draft, draft-ietf-spring-sr- 718 service-programming-05, 10 September 2021, 719 . 722 [RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP 723 Virtual Private Networks (VPNs)", RFC 4365, 724 DOI 10.17487/RFC4365, February 2006, 725 . 727 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 728 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 729 October 2007, . 731 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 732 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 733 Switched (MPLS) Data-Plane Failures", RFC 8029, 734 DOI 10.17487/RFC8029, March 2017, 735 . 737 Author's Address 739 Yao Liu 740 ZTE 741 Nanjing 742 China 744 Email: liu.yao71@zte.com.cn