idnits 2.17.1 draft-ietf-intarea-probe-06.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 (September 26, 2017) is 2402 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: 0 errors (**), 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: March 30, 2018 Google 7 C. Lenart 8 Verizon 9 M. Boucadair 10 Orange 11 September 26, 2017 13 PROBE: A Utility For Probing Interfaces 14 draft-ietf-intarea-probe-06 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 test 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. Alternatively, 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 March 30, 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 . . . . . . . . . . . . . . . . . 14 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 message from 87 the probing interface to the probed interface. The probing interface 88 resides on a probing node while the probed interface resides on a 89 probed node. 91 If the probed interface receives the ICMP Echo message, it returns an 92 ICMP Echo Reply. When the probing interface receives the ICMP Echo 93 Reply, it has verified bidirectional connectivity between the probing 94 and probed interfaces. Specifically, it has verified that: 96 o The probing node can reach the probed interface 98 o The probed interface is active 100 o The probed node can reach the probing interface 102 o The probing interface is active 104 This document describes a network diagnostic tool called PROBE. 105 PROBE is similar to PING, in that it can be used to test the status 106 of a probed interface. It differs from PING in that it does not 107 require bidirectional connectivity between the probing and probed 108 interfaces. Alternatively, PROBE requires bidirectional connectivity 109 between the probing interface and a proxy interface. The proxy 110 interface can reside on the same node as the probed interface or it 111 can reside on a node to which the probed interface is directly 112 connected. Section 5 of this document describes scenarios in which 113 this characteristic is useful. 115 Like PING, PROBE executes on a probing node. It sends an ICMP 116 Extended Echo message from a local interface, called the probing 117 interface, to a proxy interface. The proxy interface resides on a 118 probed node. 120 The ICMP Extended Echo Request contains an ICMP Extension Structure 121 and the ICMP Extension Structure contains an Interface Identification 122 Object. The Interface Identification Object identifies the probed 123 interface. The probed interface can reside on the probed node or it 124 can be directly connected to the probed node. 126 When the proxy interface receives the ICMP Extended Echo Request, it 127 executes access control procedures. If access is granted, the probed 128 node determines the status of the probed interface and returns an 129 ICMP Extended Echo Reply Message. The ICMP Extended Echo Reply 130 indicates the status of the probed interface. 132 If the probed interface resides on the probed node, PROBE determines 133 the status of the probed interface as it would determine its MIB-II 134 [RFC2863] ifOperStatus. If ifOperStatus is equal to up (1), PROBE 135 reports that the probed interface is active. Otherwise, PROBE 136 reports that the probed interface is inactive. 138 If the probed interface resides on a node that is directly connected 139 to the probed node, PROBE reports that the interface is up if it 140 appears in the IPv4 Address Resolution Protocol (ARP) table or the 141 IPv6 Neighbor Cache. Otherwise, it reports that the interface does 142 not exist. 144 1.1. Terminology 146 This document uses the following terms: 148 o Probing node - The node upon which PROBE executes 150 o Probing interface - The interface from which an ICMP Extended Echo 151 originates 153 o Proxy interface - The interface to which the ICMP Extended Echo 154 message is sent 156 o Probed node - The node upon which the proxy interface resides 158 o Probed interface - The interface whose status is being queried 160 1.2. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 2. ICMP Extended Echo Request 168 The ICMP Extended Echo Request message is defined for both ICMPv4 and 169 ICMPv6. Like any ICMP message, the ICMP Extended Echo Request 170 message is encapsulated in an IP header. The ICMPv4 version of the 171 Extended Echo Request message is encapsulated in an IPv4 header, 172 while the ICMPv6 version is encapsulated in an IPv6 header. 174 Figure 1 depicts the ICMP Extended Echo Request message. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type | Code | Checksum | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Identifier |Sequence Number| Reserved |L| 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | ICMP Extension Structure 185 Figure 1: ICMP Extended Echo Request Message 187 IP Header fields: 189 o Source Address: The Source Address identifies the probing 190 interface. It MUST be valid IPv4 or IPv6 unicast address. 192 o Destination Address: The Destination Address identifies the proxy 193 interface. It can be a unicast, multicast or anycast address. 195 ICMP fields: 197 o Type: Extended Echo Request. The value for ICMPv4 is TTTT0. . The value for ICMPv6 is TTT1. . 203 o Code: 0 205 o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443. 207 o Identifier: An identifier to aid in matching Extended Echo Replies 208 to Extended Echo Requests. May be zero. 210 o Sequence Number: A sequence number to aid in matching Extended 211 Echo Replies to Extended Echo Requests. May be zero. 213 o Reserved: This field MUST be set to zero and ignored upon receipt. 215 o L (local) - The L-bit is set of the probed interface resides on 216 the probed node. The L-bit is clear if the probed interface is 217 directly connected to the probed node. 219 o ICMP Extension Structure: The ICMP Extension Structure identifies 220 the probed interface. 222 Section 7 of [RFC4884] defines the ICMP Extension Structure. As per 223 RFC 4884, the Extension Structure contains exactly one Extension 224 Header followed by one or more objects. When applied to the ICMP 225 Extended Echo Request message, the ICMP Extension Structure MUST 226 contain one or two instances of the Interface Identification Object 227 (Section 2.1). 229 In most cases, a single instance of the Interface Identification 230 Object identifies the probed interface. However, in some cases, a 231 second instance is required for disambiguation. 233 If the L-bit is set, the Interface Identification Object identifies 234 the probed interface by name, index or address. It the L-bit is 235 clear, the Interface Identification Object identifies the probed 236 interface by address. 238 If the Interface Identification Object identifies the probed 239 interface by address, that address can be a member of any address 240 family. For example, an ICMPv4 Extended Echo Request message can 241 carry an Interface Identification Object that identifies the probed 242 interface by IPv4, IPv6 or IEEE 802 address. Likewise, an ICMPv6 243 Extended Echo Request message can carry an Interface Identification 244 Object that identifies the probed interface by IPv4, IPv6 or IEEE 802 245 address. 247 2.1. Interface Identification Object 249 The Interface Identification Object identifies the probed interface 250 by name, index, or address. Like any other ICMP Extension Object, it 251 contains an Object Header and Object Payload. The Object Header 252 contains the following fields: 254 o Class-Num: Interface Identification Object. Value is TTT2. 258 o C-type: Values are: (1) Identifies Interface By Name, (2) 259 Identifies Interface By Index, and (3) Identifies Interface By 260 Address 262 o Length: Length of the object, measured in octets, including the 263 object header and object payload. 265 If the Interface Identification Object identifies the probed 266 interface by name, the object payload MUST be the MIB-II [RFC2863] 267 ifName. If the object payload would not otherwise terminate on a 268 32-bit boundary, it MUST be padded with ASCII NULL characters. 270 If the Interface Identification Object identifies the probed 271 interface by index, the length is equal to 8 and the payload contains 272 the MIB-II ifIndex [RFC2863]. 274 If the Interface Identification Object identifies the probed 275 interface by address, the payload is as depicted in Figure 2. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | AFI | Address Length| Reserved | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Address .... 284 Figure 2: Interface Identification Object - C-type 3 Payload 286 Payload fields are defined as follows: 288 o Address Family Identifier (AFI): This 16-bit field identifies the 289 type of address represented by the Address field. All values 290 found in the IANA registry of Address Family Numbers (available 291 from ) are valid in this field. 294 o Reserved: This field MUST be set to zero and ignored upon receipt. 296 o Address Len - Number of significant bytes contained by the Address 297 field. (The address field contains significant bytes and padding 298 bytes) 300 o Address: This variable-length field represents an address 301 associated with the probed interface. If the address field would 302 not otherwise terminate on a 32-bit boundary, it MUST be padded 303 with zeros. 305 3. ICMP Extended Echo Reply 307 The ICMP Extended Echo Reply message is defined for both ICMPv4 and 308 ICMPv6. Like any ICMP message, the ICMP Extended Echo Reply message 309 is encapsulated in an IP header. The ICMPv4 version of the Extended 310 Echo Reply message is encapsulated in an IPv4 header, while the 311 ICMPv6 version is encapsulated in an IPv6 header. 313 Figure 3 depicts the ICMP Extended Echo Reply message. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Code | Checksum | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Identifier |Sequence Number| Resvd |A|F|S|E| 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 3: ICMP Extened Echo Reply Message 325 IP Header fields: 327 o Source address: Copied from the Destination Address field of the 328 invoking Extended Echo Request message 330 o Destination address: Copied from the Source Address field of the 331 invoking Extended Echo Request message 333 ICMP fields: 335 o Type: Extended Echo Reply. The value for ICMPv4 is TTT3. . The value for ICMPv6 is TTT4. . 341 o Code: (0) No Error, (1) Malformed Query, (2) No Such Interface, 342 (3) Multiple Interfaces Satisfy Query 344 o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443 346 o Identifier: Copied from the Identifier field of the invoking 347 Extended Echo Request packet 349 o Sequence Number: Copied from the Sequence Number field of the 350 invoking Extended Echo Request packet 352 o Resvd - This field MUST be set to zero and ignored upon receipt 354 o A (Active) - The A-bit is set if Code is equal to zero and the 355 probed interface is active. Otherwise, the A-bit is clear. 357 o F (IPv4) - The F-bit is set if the A-bit is also set and IPv4 is 358 running on the probed interface. Otherwise, the F-bit is clear. 360 o S (IPv6) - The S-bit is set if the A-bit is also set and IPv6 is 361 running on the probed interface. Otherwise, the S-bit is clear. 363 o E (Ethernet) - The E-bit is set if the A-bit is also set and IPv4 364 is running on the probed interface. Otherwise, the E-bit is 365 clear. 367 4. ICMP Message Processing 369 When a node receives an ICMP Extended Echo Request message and any of 370 the following conditions apply, the node MUST silently discard the 371 incoming message: 373 o The node does not recognize ICMP Extended Echo Request messages 375 o The node has not explicitly enabled ICMP Extended Echo 376 functionality 378 o The incoming ICMP Extend Echo Request carries a source address 379 that is not explicitly authorized for the incoming ICMP Extended 380 Echo Request L-bit setting 382 o The incoming ICMP Extend Echo Request carries a source address 383 that is not explicitly authorized for the incoming ICMP Extended 384 Echo Request type (i.e., by ifName, by IfIndex, by Address) 386 o The Source Address of the incoming messages is not a unicast 387 address 389 Otherwise, when a node receives an ICMPv4 Extended Echo Request, it 390 MUST format an ICMP Extended Echo Reply as follows: 392 o Don't Fragment flag (DF) is 1 394 o More Fragments flag is 0 396 o Fragment Offset is 0 398 o TTL is 255 400 o Protocol is ICMP 402 When a node receives an ICMPv6 Extended Echo Request, it MUST format 403 an ICMPv6 Extended Echo Reply as follows: 405 o Hop Limit is 255 407 o Next Header is ICMPv6 408 In either case, the responding node MUST: 410 o Copy the source address from the Extended Echo Request message to 411 the destination address of the Extended Echo Reply 413 o Copy the destination address from the Extended Echo Request 414 message to the source address of the Extended Echo Reply 416 o Set the DiffServ codepoint to CS0 [RFC4594] 418 o Set the ICMP Type to Extended Echo Reply 420 o Copy the Identifier from the Extended Echo Request message to the 421 Extended Echo Reply 423 o Copy the Sequence Number from the Extended Echo Request message to 424 the Extended Echo Reply 426 o Set the Code field as described Section 4.1 428 o If the Code Field is equal to No Error (0) and the L-bit is clear, 429 set the A-Bit. 431 o If the Code Field is equal to No Error (0) and the L-bit is set 432 and the probed interface is active, set the A-bit. 434 o If the A-bit is set, set the F-bit, S-bit and E-bit as 435 appropriate. Otherwise, clear the F, S and E bits. 437 o Set the checksum appropriately 439 o Forward the ICMP Extended Echo Reply to its destination 441 4.1. Code Field Processing 443 The Code field MUST be set to Malformed Query (1) if any of the 444 following conditions apply: 446 o The ICMP Extended Echo Request does not include an ICMP Extension 447 Structure 449 o The ICMP Extension Structure does not include an Interface 450 Identification Object 452 o The ICMP Extension Structure contains more than two Interface 453 Identification Objects 455 o The L-bit is clear and the Interface Identification Object 456 identifies the probed interface by ifName or ifIndex 458 o The query is otherwise malformed 460 The Code field MUST be set to No Such Interface (2) if any of the 461 following conditions apply: 463 o The L-bit is set and the ICMP Extension Structure does not 464 identify any local interfaces 466 o The L-bit is clear and the address or addresses found in the 467 Interface Identification object appear in neither the IPv4 Address 468 Resolution Protocol (ARP) Table nor the IPv6 Neighbor Cache 470 The Code field MUST be set to Multiple Interfaces Satisfy Query (3) 471 if any of the following conditions apply: 473 o The L-bit is set and the ICMP Extension Structure identifies more 474 than one local interfaces 476 o The L-bit is clear and the address or addresses found in the 477 Interface Identification object map to multiple IPv4 ARP or IPv6 478 Neighbor Cache entries 480 Otherwise, the Code field MUST be set to No Error (0) 482 5. Use-Cases 484 In the scenarios listed below, network operators can use PROBE to 485 determine the status of a probed interface, but cannot use PING for 486 the same purpose. In all scenarios, assume bidirectional 487 connectivity between the probing and proxy interfaces. However, 488 bidirectional connectivity between the probing and probed interfaces 489 is lacking. 491 o The probed interface is unnumbered 493 o The probing and probed interfaces are not directly connected to 494 one another. The probed interface has an IPv6 link-local address, 495 but does not have a more globally scoped address 497 o The probing interface runs IPv4 only while the probed interface 498 runs IPv6 only 500 o The probing interface runs IPv6 only while the probed interface 501 runs IPv4 only 503 o For lack of a route, the probing node cannot reach the probed 504 interface. 506 6. Updates to RFC 4884 508 Section 4.6 of RFC 4884 provides a list of extensible ICMP messages 509 (i.e., messages that can carry the ICMP Extension Structure). This 510 document adds the ICMP Extended Echo message and the ICMP Extended 511 Echo Reply message to that list. 513 7. IANA Considerations 515 This document requests the following actions from IANA: 517 o Add an entry to the "ICMP Type Number" registry, representing the 518 Extended Echo Request. This entry has one code (0). 520 o Add an entry to the "Internet Control Message Protocol version 6 521 (ICMPv6) Parameters" registry, representing the Extended Echo 522 Request. This entry has one code (0). 524 o Add an entry to the "ICMP Type Number" registry, representing the 525 Extended Echo Reply. This entry has the following codes: (0) No 526 Error, (1) Malformed Query, (2) No Such Interface, (3) Multiple 527 Interfaces Satisfy Query. Protocol Flag Bit mappings are as 528 follows: Bit 0 (IPv4), Bit 1 (IPv6), Bit 2 (Ethernet), Bits 3-15 529 (Reserved). 531 o Add an entry to the "Internet Control Message Protocol version 6 532 (ICMPv6) Parameters" registry, representing the Extended Echo 533 Reply. This entry has the following codes: (0) No Error, (1) 534 Malformed Query, (2) No Such Interface, (3) Multiple Interfaces 535 Satisfy Query. Protocol Flag Bit mappings are as follows: Bit 0 536 (IPv4), Bit 1 (IPv6), Bit 2 (Ethernet), Bits 3-15 (Reserved). 538 o Add an entry to the "ICMP Extension Object Classes and Class Sub- 539 types" registry, representing the Interface Identification Object. 540 It has C-types Reserved (0), Identifies Interface By Name (1), 541 Identifies Interface By Index (2), Identifies Interface By Address 542 (3) 544 Note to RFC Editor: this section may be removed on publication as an 545 RFC. 547 8. Security Considerations 549 The following are legitimate uses of PROBE: 551 o to determine the operational status of an interface 553 o to determine which protocols (e.g., IPv4, IPv6) are active on an 554 interface 556 However, malicious parties can use PROBE to obtain additional 557 information. For example, a malicious party can use PROBE to 558 discover interface names. Having discovered an interface name, the 559 malicious party may be able to infer additional information. 560 Additional information may include: 562 o interface bandwidth 564 o the type of device that supports the interface (e.g., vendor 565 identity) 567 o the operating system version that the above-mentioned device 568 executes 570 Understanding this risk, network operators establish policies that 571 restrict access to ICMP Extended Echo functionality. In order to 572 enforce these polices, nodes that support ICMP Extended Echo 573 functionality MUST support the following configuration options: 575 o Enable/disable ICMP Extended Echo functionality. By default, ICMP 576 Extend Echo functionality is disabled. 578 o Define enabled L-bit settings. By default, L-bit set is enabled 579 and L-bit clear is disabled. 581 o Define enabled query types (i.e., by ifName, by ifIndex, by 582 Address). By default, all query types are disabled. 584 o For each enabled query type, define the prefixes from which ICMP 585 Extended Echo Request messages are permitted 587 o For each interface, determine whether ICMP Echo Request messages 588 are accepted 590 When a node receives an ICMP Extended Echo Request message that it is 591 not configured to support, it MUST silently discard the message. See 592 Section 4 for details. 594 PROBE MUST NOT leak information about one Virtual Private Network 595 (VPN) into another. Therefore, when a node receives an ICMP Extended 596 Echo Request and the proxy interface is in a different VPN than the 597 probed interface, the node MUST return an ICMP Extended Echo Reply 598 with error code equal to (2) No Such Interface. 600 In order to protect local resources, implementations SHOULD rate- 601 limit incoming ICMP Extended Echo Request messages. 603 9. References 605 9.1. Normative References 607 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 608 RFC 792, DOI 10.17487/RFC0792, September 1981, 609 . 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, 613 DOI 10.17487/RFC2119, March 1997, 614 . 616 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 617 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 618 . 620 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 621 Control Message Protocol (ICMPv6) for the Internet 622 Protocol Version 6 (IPv6) Specification", STD 89, 623 RFC 4443, DOI 10.17487/RFC4443, March 2006, 624 . 626 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 627 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 628 DOI 10.17487/RFC4884, April 2007, 629 . 631 9.2. Informative References 633 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ 634 IP Tools and Utilities", FYI 30, RFC 2151, 635 DOI 10.17487/RFC2151, June 1997, 636 . 638 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 639 Guidelines for DiffServ Service Classes", RFC 4594, 640 DOI 10.17487/RFC4594, August 2006, 641 . 643 Appendix A. The PROBE Application 645 The PROBE application accepts input parameters, sets a counter and 646 enters a loop to be exited when the counter is equal to zero. On 647 each iteration of the loop, PROBE emits an ICMP Extended Echo 648 Request, decrements the counter, sets a timer, waits for the timer to 649 expire. If an expected ICMP Extended Echo Reply arrives while PROBE 650 is waiting for the timer to expire, PROBE relays information returned 651 by that message to its user. However, on each iteration of the loop, 652 PROBE waits for the timer to expire, regardless of whether an 653 Extended Echo Reply message arrives. 655 PROBE accepts the following parameters: 657 o Count 659 o Wait 661 o Probing Interface Address 663 o Hop Count 665 o Proxy Interface Address 667 o Local 669 o Probed Interface Identifier 671 Count is a positive integer whose default value is 3. Count 672 determines the number of times that PROBE iterates through the above- 673 mentioned loop. 675 Wait is a positive integer whose minimum and default values are 1. 676 Wait determines the duration of the above-mentioned timer, measured 677 in seconds. 679 Probing Interface Address specifies the source address of ICMP 680 Extended Echo Request. The Probing Interface Address MUST be a 681 unicast address and MUST identify an interface that is local to the 682 probing node. 684 The Proxy Interface Address identifies the interface to which the 685 ICMP Extended Echo Request message is sent. It can be an IPv4 or 686 IPv6 address. If it is an IPv4 address, PROBE emits an ICMPv4 687 message. If it is an IPv6 address, PROBE emits an ICMPv6 message. 689 Local is a boolean value. It is TRUE if the proxy and probed 690 interfaces both reside on the probed node. It is FALSE if the proxy 691 interface resides on the probed node and the probed interface is 692 directly connected to the probed node. 694 The probed interface is the interface whose status is being queried. 695 It is identified by one of the following: 697 o an interface name 699 o an address from any address family (e.g., IPv4, IPv6, IEEE 802, 700 48-bit MAC, 64-bit MAC) 702 o an ifIndex 704 If the probed interface identifier is an address, it does not need to 705 be of the same address family as the proxy interface address. For 706 example, PROBE accepts an IPv4 destination interface address and an 707 IPv6 probed interface identifier 709 Acknowledgments 711 Thanks to Sowmini Varadhan, Jeff Haas, Carlos Pignataro, Jonathan 712 Looney, Dave Thaler, Mikio Hara and Joe Touch for their thoughtful 713 review of this document. 715 Authors' Addresses 717 Ron Bonica 718 Juniper Networks 719 2251 Corporate Park Drive 720 Herndon, Virginia 20171 721 USA 723 Email: rbonica@juniper.net 725 Reji Thomas 726 Juniper Networks 727 Elnath-Exora Business Park Survey 728 Bangalore, Karnataka 560103 729 India 731 Email: rejithomas@juniper.net 732 Jen Linkova 733 Google 734 1600 Amphitheatre Parkway 735 Mountain View, California 94043 736 USA 738 Email: furry@google.com 740 Chris Lenart 741 Verizon 742 22001 Loudoun County Parkway 743 Ashburn, Virginia 20147 744 USA 746 Email: chris.lenart@verizon.com 748 Mohamed Boucadair 749 Orange 750 Rennes 35000 751 France 753 Email: mohamed.boucadair@orange.com