idnits 2.17.1 draft-ietf-intarea-probe-10.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 (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 (December 15, 2017) is 2318 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) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA R. Bonica 3 Internet-Draft R. Thomas 4 Updates: 4884 (if approved) Juniper Networks 5 Intended status: Standards Track J. Linkova 6 Expires: June 18, 2018 Google 7 C. Lenart 8 Verizon 9 M. Boucadair 10 Orange 11 December 15, 2017 13 PROBE: A Utility For Probing Interfaces 14 draft-ietf-intarea-probe-10 16 Abstract 18 This document describes a network diagnostic tool called PROBE. 19 PROBE is similar to PING, in that it can be used to query the status 20 of a probed interface. It differs from PING in that it does not 21 require bidirectional connectivity between the probing and probed 22 interfaces. Instead, PROBE requires bidirectional connectivity 23 between the probing interface and a proxy interface. The proxy 24 interface can reside on the same node as the probed interface or it 25 can reside on a node to which the probed interface is directly 26 connected. This document updates RFC 4884. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 18, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. ICMP Extended Echo Request . . . . . . . . . . . . . . . . . 4 66 2.1. Interface Identification Object . . . . . . . . . . . . . 6 67 3. ICMP Extended Echo Reply . . . . . . . . . . . . . . . . . . 7 68 4. ICMP Message Processing . . . . . . . . . . . . . . . . . . . 9 69 4.1. Code Field Processing . . . . . . . . . . . . . . . . . . 10 70 5. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6. Updates to RFC 4884 . . . . . . . . . . . . . . . . . . . . . 12 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 9.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Appendix A. The PROBE Application . . . . . . . . . . . . . . . 15 78 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Network operators use PING [RFC2151] to test bidirectional 84 connectivity between two interfaces. For the purposes of this 85 document, we will call these interfaces the probing and probed 86 interfaces. PING sends an ICMP [RFC0792] [RFC4443] Echo Request 87 message from the probing interface to the probed interface. The 88 probing interface resides on a probing node while the probed 89 interface resides on a probed node. 91 If the probed interface receives the ICMP Echo Request message, it 92 returns an ICMP Echo Reply. When the probing interface receives the 93 ICMP Echo Reply, it has verified bidirectional connectivity between 94 the probing and probed interfaces. Specifically, it has verified 95 that: 97 o The probing node can reach the probed interface 99 o The probed interface is active 101 o The probed node can reach the probing interface 103 o The probing interface is active 105 This document describes a network diagnostic tool called PROBE. 106 PROBE is similar to PING, in that it can be used to query the status 107 of a probed interface. It differs from PING in that it does not 108 require bidirectional connectivity between the probing and probed 109 interfaces. Instead, PROBE requires bidirectional connectivity 110 between the probing interface and a proxy interface. The proxy 111 interface can reside on the same node as the probed interface or it 112 can reside on a node to which the probed interface is directly 113 connected. Section 5 of this document describes scenarios in which 114 this characteristic is useful. 116 Like PING, PROBE executes on a probing node. It sends an ICMP 117 Extended Echo Request message from a local interface, called the 118 probing interface, to a proxy interface. The proxy interface resides 119 on a proxy node. 121 The ICMP Extended Echo Request contains an ICMP Extension Structure 122 and the ICMP Extension Structure contains an Interface Identification 123 Object. The Interface Identification Object identifies the probed 124 interface. The probed interface can reside on the proxy node or it 125 can be directly connected to the proxy node. 127 When the proxy interface receives the ICMP Extended Echo Request, the 128 proxy node executes access control procedures. If access is granted, 129 the proxy node determines the status of the probed interface and 130 returns an ICMP Extended Echo Reply Message. The ICMP Extended Echo 131 Reply indicates the status of the probed interface. 133 If the probed interface resides on the proxy node, PROBE determines 134 the status of the probed interface as it would determine its oper- 135 status [RFC7223]. If oper-status is equal to up (1), PROBE reports 136 that the probed interface is active. Otherwise, PROBE reports that 137 the probed interface is inactive. 139 If the probed interface resides on a node that is directly connected 140 to the probed node, and the probed interface appears in the IPv4 141 Address Resolution Protocol (ARP) table [RFC0826] or IPv6 Neighbor 142 Cache [RFC4861], PROBE reports interface reachability. Otherwise, 143 PROBE reports that the table entry does not exist. 145 1.1. Terminology 147 This document uses the following terms: 149 o Probing interface - The interface that sends the ICMP Extended 150 Echo Request 152 o Probing node - The node upon which the probing interface resides 154 o Proxy interface - The interface to which the ICMP Extended Echo 155 Request message is sent 157 o Proxy node - The node upon which the proxy interface resides 159 o Probed interface - The interface whose status is being queried 161 o Probed node - The node upon which the probed interface resides. 162 If the proxy interface and the probed interface reside upon the 163 same node, the proxy node is also the probed node. Otherwise, the 164 proxy node is directly connected to the probed node. 166 1.2. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 2. ICMP Extended Echo Request 176 The ICMP Extended Echo Request message is defined for both ICMPv4 and 177 ICMPv6. Like any ICMP message, the ICMP Extended Echo Request 178 message is encapsulated in an IP header. The ICMPv4 version of the 179 Extended Echo Request message is encapsulated in an IPv4 header, 180 while the ICMPv6 version is encapsulated in an IPv6 header. 182 Figure 1 depicts the ICMP Extended Echo Request 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 | Identifier |Sequence Number| Reserved |L| 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | ICMP Extension Structure 193 Figure 1: ICMP Extended Echo Request Message 195 IP Header fields: 197 o Source Address: The Source Address identifies the probing 198 interface. It MUST be valid IPv4 or IPv6 unicast address. 200 o Destination Address: The Destination Address identifies the proxy 201 interface. It can be a unicast, multicast or anycast address. 203 ICMP fields: 205 o Type: Extended Echo Request. The value for ICMPv4 is TTT0. . The value for ICMPv6 is TTT1. . 211 o Code: MUST be set to 0 and MUST be ignored upon receipt. 213 o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443. 215 o Identifier: An identifier to aid in matching Extended Echo Replies 216 to Extended Echo Requests. May be zero. 218 o Sequence Number: A sequence number to aid in matching Extended 219 Echo Replies to Extended Echo Requests. May be zero. 221 o Reserved: This field MUST be set to zero and ignored upon receipt. 223 o L (local) - The L-bit is set if the probed interface resides on 224 the proxy node. The L-bit is clear if the probed interface is 225 directly connected to the proxy node. 227 o ICMP Extension Structure: The ICMP Extension Structure identifies 228 the probed interface. 230 Section 7 of [RFC4884] defines the ICMP Extension Structure. As per 231 RFC 4884, the Extension Structure contains exactly one Extension 232 Header followed by one or more objects. When applied to the ICMP 233 Extended Echo Request message, the ICMP Extension Structure MUST 234 contain exactly one instance of the Interface Identification Object 235 (Section 2.1). 237 If the L-bit is set, the Interface Identification Object can identify 238 the probed interface by name, index or address. It the L-bit is 239 clear, the Interface Identification Object MUST identify the probed 240 interface by address. 242 If the Interface Identification Object identifies the probed 243 interface by address, that address can be a member of any address 244 family. For example, an ICMPv4 Extended Echo Request message can 245 carry an Interface Identification Object that identifies the probed 246 interface by IPv4, IPv6 or IEEE 802 address. Likewise, an ICMPv6 247 Extended Echo Request message can carry an Interface Identification 248 Object that identifies the probed interface by IPv4, IPv6 or IEEE 802 249 address. 251 2.1. Interface Identification Object 253 The Interface Identification Object identifies the probed interface 254 by name, index, or address. Like any other ICMP Extension Object, it 255 contains an Object Header and Object Payload. The Object Header 256 contains the following fields: 258 o Class-Num: Interface Identification Object. Value is TTT2. 262 o C-type: Values are: (1) Identifies Interface By Name, (2) 263 Identifies Interface By Index, and (3) Identifies Interface By 264 Address 266 o Length: Length of the object, measured in octets, including the 267 object header and object payload. 269 If the Interface Identification Object identifies the probed 270 interface by name, the object payload MUST be the interface name as 271 defined in [RFC7223]. If the object payload would not otherwise 272 terminate on a 32-bit boundary, it MUST be padded with ASCII NULL 273 characters. 275 If the Interface Identification Object identifies the probed 276 interface by index, the length is equal to 8 and the payload contains 277 the if-index [RFC7223]. 279 If the Interface Identification Object identifies the probed 280 interface by address, the payload is as depicted in Figure 2. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | AFI | Address Length| Reserved | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Address .... 289 Figure 2: Interface Identification Object - C-type 3 Payload 291 Payload fields are defined as follows: 293 o Address Family Identifier (AFI): This 16-bit field identifies the 294 type of address represented by the Address field. All values 295 found in the IANA registry of Address Family Numbers (available 296 from ) are valid in this field. 299 o Address Length - Number of significant bytes contained by the 300 Address field. (The address field contains significant bytes and 301 padding bytes) 303 o Reserved: This field MUST be set to zero and ignored upon receipt. 305 o Address: This variable-length field represents an address 306 associated with the probed interface. If the address field would 307 not otherwise terminate on a 32-bit boundary, it MUST be padded 308 with zeros. 310 3. ICMP Extended Echo Reply 312 The ICMP Extended Echo Reply message is defined for both ICMPv4 and 313 ICMPv6. Like any ICMP message, the ICMP Extended Echo Reply message 314 is encapsulated in an IP header. The ICMPv4 version of the Extended 315 Echo Reply message is encapsulated in an IPv4 header, while the 316 ICMPv6 version is encapsulated in an IPv6 header. 318 Figure 3 depicts the ICMP Extended Echo Reply message. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Code | Checksum | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Identifier |Sequence Number|State|Res|A|4|6| 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 3: ICMP Extened Echo Reply Message 330 IP Header fields: 332 o Source address: Copied from the Destination Address field of the 333 invoking Extended Echo Request message 335 o Destination address: Copied from the Source Address field of the 336 invoking Extended Echo Request message 338 ICMP fields: 340 o Type: Extended Echo Reply. The value for ICMPv4 is TTT3. . The value for ICMPv6 is TTT4. . 346 o Code: (0) No Error, (1) Malformed Query, (2) No Such Interface, 347 (3) No Such Table Entry, (4) Multiple Interfaces Satisfy Query 349 o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443 351 o Identifier: Copied from the Identifier field of the invoking 352 Extended Echo Request packet 354 o Sequence Number: Copied from the Sequence Number field of the 355 invoking Extended Echo Request packet 357 o State - If Code is not equal to 0, this field MUST be set to 0 and 358 ignored upon receipt. Likewise, if the probed interface resides 359 upon the proxy node, this field MUST be set to 0 and ignored upon 360 receipt. Otherwise, this field reflects the state of the ARP 361 Table or Neighbor Cache entry associated with the probed 362 interface. Values are (0) Reserved (1) Incomplete (2) Reachable 363 (3) Stale (4) Delay (5) Probe (6) Failed 365 o Res - This field MUST be set to 0 and ignored upon receipt. 367 o A (Active) - The A-bit is set if Code is equal to zero, the probed 368 interface resides on the proxy node, and the probed interface is 369 active. Otherwise, the A-bit is clear. 371 o 4 (IPv4) - The 4-bit is set if the A-bit is also set and IPv4 is 372 running on the probed interface. Otherwise, the 4-bit is clear. 374 o 6 (IPv6) - The 6-bit is set if the A-bit is also set and IPv6 is 375 running on the probed interface. Otherwise, the 6-bit is clear. 377 4. ICMP Message Processing 379 When a node receives an ICMP Extended Echo Request message and any of 380 the following conditions apply, the node MUST silently discard the 381 incoming message: 383 o The node does not recognize ICMP Extended Echo Request messages 385 o The node has not explicitly enabled ICMP Extended Echo 386 functionality 388 o The incoming ICMP Extend Echo Request carries a source address 389 that is not explicitly authorized for the incoming ICMP Extended 390 Echo Request L-bit setting 392 o The incoming ICMP Extend Echo Request carries a source address 393 that is not explicitly authorized for the incoming ICMP Extended 394 Echo Request type (i.e., by ifName, by IfIndex, by Address) 396 o The Source Address of the incoming messages is not a unicast 397 address 399 Otherwise, when a node receives an ICMPv4 Extended Echo Request, it 400 MUST format an ICMP Extended Echo Reply as follows: 402 o Don't Fragment flag (DF) is 1 404 o More Fragments flag is 0 406 o Fragment Offset is 0 408 o TTL is 255 410 o Protocol is ICMP 411 When a node receives an ICMPv6 Extended Echo Request, it MUST format 412 an ICMPv6 Extended Echo Reply as follows: 414 o Hop Limit is 255 416 o Next Header is ICMPv6 418 In either case, the responding node MUST: 420 o Copy the source address from the Extended Echo Request message to 421 the destination address of the Extended Echo Reply 423 o Copy the destination address from the Extended Echo Request 424 message to the source address of the Extended Echo Reply 426 o Set the DiffServ codepoint to CS0 [RFC4594] 428 o Set the ICMP Type to Extended Echo Reply 430 o Copy the Identifier from the Extended Echo Request message to the 431 Extended Echo Reply 433 o Copy the Sequence Number from the Extended Echo Request message to 434 the Extended Echo Reply 436 o Set the Code field as described Section 4.1 438 o Set the State field to 0. 440 o Clear the A-bit, the 4-bit and the 6-bit. 442 o If the Code Field is equal to (0) No Error and the L-bit is set 443 and the probed interface is active, set the A-bit. Also set the 444 4-bit and the 6-bit as appropriate. 446 o If the Code Field is equal to (0) No Error and the L-bit is clear, 447 set the State field to reflect the state of the ARP Table or 448 Neighbor Cache entry that represents the probed interface. 450 o Set the checksum appropriately 452 o Forward the ICMP Extended Echo Reply to its destination 454 4.1. Code Field Processing 456 The Code field MUST be set to (1) Malformed Query if any of the 457 following conditions apply: 459 o The ICMP Extended Echo Request does not include an ICMP Extension 460 Structure 462 o The ICMP Extension Structure does not include exactly one 463 Interface Identification Object 465 o The L-bit is clear and the Interface Identification Object 466 identifies the probed interface by ifName or ifIndex 468 o The query is otherwise malformed 470 The Code field MUST be set to (2) No Such Interface if the L-bit is 471 set and the ICMP Extension Structure does not identify an interface 472 that resides on the proxy node. 474 The Code field MUST be set to (3) No Such Table Entry if the L-bit is 475 clear and the address found in the Interface Identification Object 476 does not appear in the IPv4 Address Resolution Protocol (ARP) 477 Table or the IPv6 Neighbor Cache. 479 The Code field MUST be set to (4) Multiple Interfaces Satisfy Query 480 if any of the following conditions apply: 482 o The L-bit is set and the ICMP Extension Structure identifies more 483 than one interface that resides in the proxy node 485 o The L-bit is clear and the address found in the Interface 486 Identification Object maps to multiple IPv4 ARP or IPv6 Neighbor 487 Cache entries 489 Otherwise, the Code field MUST be set to (0) No Error 491 5. Use-Cases 493 In the scenarios listed below, network operators can use PROBE to 494 determine the status of a probed interface, but cannot use PING for 495 the same purpose. In all scenarios, assume bidirectional 496 connectivity between the probing and proxy interfaces. However, 497 bidirectional connectivity between the probing and probed interfaces 498 is lacking. 500 o The probed interface is unnumbered 502 o The probing and probed interfaces are not directly connected to 503 one another. The probed interface has an IPv6 link-local address, 504 but does not have a more globally scoped address 506 o The probing interface runs IPv4 only while the probed interface 507 runs IPv6 only 509 o The probing interface runs IPv6 only while the probed interface 510 runs IPv4 only 512 o For lack of a route, the probing node cannot reach the probed 513 interface. 515 6. Updates to RFC 4884 517 Section 4.6 of RFC 4884 provides a list of extensible ICMP messages 518 (i.e., messages that can carry the ICMP Extension Structure). This 519 document adds the ICMP Extended Echo Request message and the ICMP 520 Extended Echo Reply message to that list. 522 7. IANA Considerations 524 This document requests the following actions from IANA: 526 o Add an entry to the "ICMP Type Number" registry, representing the 527 Extended Echo Request. This entry has one code (0) No Error. 529 o Add an entry to the "ICMPv6 "type" Numbers" registry, representing 530 the Extended Echo Request. This entry has one code (0) No Error. 531 As ICMPv6 distinguishes between informational and error messages, 532 and this is an informational message, the value must be assigned 533 from the range 128-255. 535 o Add an entry to the "ICMP Type Number" registry, representing the 536 Extended Echo Reply. This entry has the following codes: (0) No 537 Error, (1) Malformed Query, (2) No Such Interface, (3) No Such 538 Table Entry, (4) Multiple Interfaces Satisfy Query. 540 o Add an entry to the "ICMPv6 "type" Numbers" registry, representing 541 the Extended Echo Reply. This entry has the following codes: (0) 542 No Error, (1) Malformed Query, (2) No Such Interface, (3) No Such 543 Table Entry, (4) Multiple Interfaces Satisfy Query. 545 o Add an entry to the "ICMP Extension Object Classes and Class Sub- 546 types" registry, representing the Interface Identification Object. 547 It has C-types Reserved (0), Identifies Interface By Name (1), 548 Identifies Interface By Index (2), Identifies Interface By Address 549 (3). C-Type values are assignable on a first-come-first-serve 550 (FCFS) basis with a range of 0-255. 552 All codes mentioned above are assigned on a First Come First Serve 553 (FCFS) basis with a range of 0 -255. 555 8. Security Considerations 557 The following are legitimate uses of PROBE: 559 o to determine the operational status of an interface 561 o to determine which protocols (e.g., IPv4, IPv6) are active on an 562 interface 564 However, malicious parties can use PROBE to obtain additional 565 information. For example, a malicious party can use PROBE to 566 discover interface names. Having discovered an interface name, the 567 malicious party may be able to infer additional information. 568 Additional information may include: 570 o interface bandwidth 572 o the type of device that supports the interface (e.g., vendor 573 identity) 575 o the operating system version that the above-mentioned device 576 executes 578 Understanding this risk, network operators establish policies that 579 restrict access to ICMP Extended Echo functionality. In order to 580 enforce these polices, nodes that support ICMP Extended Echo 581 functionality MUST support the following configuration options: 583 o Enable/disable ICMP Extended Echo functionality. By default, ICMP 584 Extend Echo functionality is disabled. 586 o Define enabled L-bit settings. By default, L-bit set is enabled 587 and L-bit clear is disabled. 589 o Define enabled query types (i.e., by name, by index, by address). 590 By default, all query types are disabled. 592 o For each enabled query type, define the prefixes from which ICMP 593 Extended Echo Request messages are permitted 595 o For each interface, determine whether ICMP Echo Request messages 596 are accepted 598 When a node receives an ICMP Extended Echo Request message that it is 599 not configured to support, it MUST silently discard the message. See 600 Section 4 for details. 602 PROBE must not leak information about one Virtual Private Network 603 (VPN) into another. Therefore, when a node receives an ICMP Extended 604 Echo Request and the proxy interface is in a different VPN than the 605 probed interface, the node MUST return an ICMP Extended Echo Reply 606 with error code equal to (2) No Such Interface. 608 In order to protect local resources, implementations SHOULD rate- 609 limit incoming ICMP Extended Echo Request messages. 611 9. References 613 9.1. Normative References 615 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 616 RFC 792, DOI 10.17487/RFC0792, September 1981, 617 . 619 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 620 Converting Network Protocol Addresses to 48.bit Ethernet 621 Address for Transmission on Ethernet Hardware", STD 37, 622 RFC 826, DOI 10.17487/RFC0826, November 1982, 623 . 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, 627 DOI 10.17487/RFC2119, March 1997, 628 . 630 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 631 Control Message Protocol (ICMPv6) for the Internet 632 Protocol Version 6 (IPv6) Specification", STD 89, 633 RFC 4443, DOI 10.17487/RFC4443, March 2006, 634 . 636 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 637 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 638 DOI 10.17487/RFC4861, September 2007, 639 . 641 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 642 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 643 DOI 10.17487/RFC4884, April 2007, 644 . 646 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 647 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 648 . 650 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 651 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 652 May 2017, . 654 9.2. Informative References 656 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ 657 IP Tools and Utilities", FYI 30, RFC 2151, 658 DOI 10.17487/RFC2151, June 1997, 659 . 661 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 662 Guidelines for DiffServ Service Classes", RFC 4594, 663 DOI 10.17487/RFC4594, August 2006, 664 . 666 Appendix A. The PROBE Application 668 The PROBE application accepts input parameters, sets a counter and 669 enters a loop to be exited when the counter is equal to zero. On 670 each iteration of the loop, PROBE emits an ICMP Extended Echo 671 Request, decrements the counter, sets a timer and waits. The ICMP 672 Extended Echo Request includes an Identifier and a Sequence Number. 674 If an ICMP Extended Echo Reply carrying the same Identifier and 675 Sequence Number arrives, PROBE relays information returned by that 676 message to its user. However, on each iteration of the loop, PROBE 677 waits for the timer to expire, regardless of whether an Extended Echo 678 Reply message arrives. 680 PROBE accepts the following parameters: 682 o Count 684 o Wait 686 o Probing Interface Address 688 o Hop Count 690 o Proxy Interface Address 692 o Local 694 o Probed Interface Identifier 695 Count is a positive integer whose default value is 3. Count 696 determines the number of times that PROBE iterates through the above- 697 mentioned loop. 699 Wait is a positive integer whose minimum and default values are 1. 700 Wait determines the duration of the above-mentioned timer, measured 701 in seconds. 703 Probing Interface Address specifies the source address of ICMP 704 Extended Echo Request. The Probing Interface Address MUST be a 705 unicast address and MUST identify an interface that resides on the 706 probing node. 708 The Proxy Interface Address identifies the interface to which the 709 ICMP Extended Echo Request message is sent. It can be an IPv4 or 710 IPv6 address. If it is an IPv4 address, PROBE emits an ICMPv4 711 message. If it is an IPv6 address, PROBE emits an ICMPv6 message. 713 Local is a boolean value. It is TRUE if the proxy and probed 714 interfaces both reside on the same node. Otherwise, it is FALSE. 716 The Probed Interface Identifier identifies the probed interface. It 717 is one of the following: 719 o an interface name 721 o an address from any address family (e.g., IPv4, IPv6, IEEE 802, 722 48-bit MAC, 64-bit MAC) 724 o an if-index 726 If the Probed Interface Identifier is an address, it does not need to 727 be of the same address family as the proxy interface address. For 728 example, PROBE accepts an IPv4 Proxy Interface Address and an IPv6 729 Probed Interface Identifier 731 Acknowledgments 733 Thanks to Sowmini Varadhan, Jeff Haas, Carlos Pignataro, Jonathan 734 Looney, Dave Thaler, Mikio Hara, Joel Halpern, Yaron Sheffer, Stefan 735 Winter, Jean-Michel Combes, Amanda Barber and Joe Touch for their 736 thoughtful review of this document. 738 Authors' Addresses 739 Ron Bonica 740 Juniper Networks 741 2251 Corporate Park Drive 742 Herndon, Virginia 20171 743 USA 745 Email: rbonica@juniper.net 747 Reji Thomas 748 Juniper Networks 749 Elnath-Exora Business Park Survey 750 Bangalore, Karnataka 560103 751 India 753 Email: rejithomas@juniper.net 755 Jen Linkova 756 Google 757 1600 Amphitheatre Parkway 758 Mountain View, California 94043 759 USA 761 Email: furry@google.com 763 Chris Lenart 764 Verizon 765 22001 Loudoun County Parkway 766 Ashburn, Virginia 20147 767 USA 769 Email: chris.lenart@verizon.com 771 Mohamed Boucadair 772 Orange 773 Rennes 35000 774 France 776 Email: mohamed.boucadair@orange.com