idnits 2.17.1 draft-bonica-intarea-eping-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC4884, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4884, updated by this document, for RFC5378 checks: 2005-09-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2017) is 2611 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) == Missing Reference: 'RFC 2863' is mentioned on line 279, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: RFC 4884 (if approved) Juniper Networks 5 Intended status: Standards Track J. Linkova 6 Expires: September 3, 2017 Google 7 C. Lenart 8 Verizon 9 March 2, 2017 11 Extended Ping (Xping) 12 draft-bonica-intarea-eping-04 14 Abstract 16 This document describes a new diagnostic tool called Extended Ping 17 (Xping). Network operators execute Xping to determine the status of 18 a remote interface. In this respect, Xping is similar to Ping. 19 Xping differs from Ping in that it does not require network 20 reachability between itself and remote interface whose status is 21 being queried. 23 Xping relies on two new ICMP messages, called Extended Echo Request 24 and Extended Echo Reply. Both ICMP messages are defined herein. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 3, 2017. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 67 2. ICMP Extended Echo Request . . . . . . . . . . . . . . . . . 4 68 2.1. Interface Identification Object . . . . . . . . . . . . . 6 69 3. ICMP Extended Echo Reply . . . . . . . . . . . . . . . . . . 7 70 4. ICMP Extended Echo and Extended Echo Reply Processing . . . . 9 71 4.1. Code Field Processing . . . . . . . . . . . . . . . . . . 10 72 5. The Xping Application . . . . . . . . . . . . . . . . . . . . 10 73 6. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.1. Unnumbered Interfaces . . . . . . . . . . . . . . . . . . 12 75 6.2. Link-local Interfaces . . . . . . . . . . . . . . . . . . 12 76 6.3. Unadvertised Interfaces . . . . . . . . . . . . . . . . . 13 77 7. Updates to RFC 4884 . . . . . . . . . . . . . . . . . . . . . 13 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 11.2. Informative References . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Problem Statement 88 Network operators use Ping [RFC2151] to determine whether a remote 89 interface is operational. Ping sends an ICMP [RFC0792] [RFC4443] 90 Echo message to the interface being probed and waits for an ICMP Echo 91 Reply. If Ping receives the expected ICMP Echo Reply, it reports 92 that the probed interface is operational. 94 In order for the ICMP Echo message to reach the probed interface, the 95 probed interface must be addressed appropriately. IP addresses are 96 scoped as follows: 98 o Global [RFC4291] 100 o Private [RFC1918] 102 o Link-local [RFC3927] [RFC4291] 104 Global addresses are the most widely scoped. A globally addressed 105 interface can be reached from any node on the Internet. By contrast, 106 link-local addresses are the least widely scoped. An interface whose 107 only address is link-local can be reached from on-link interfaces 108 only. 110 Network operators seek to decrease their dependence on widely-scoped 111 interface addressing. For example: 113 o The operator of an IPv4 network currently assigns global addresses 114 to all interfaces. In order to conserve scarce IPv4 address 115 space, this operator seeks to renumber selected interfaces with 116 private addresses. 118 o The operator of an IPv4 network currently assigns private 119 addresses to all interfaces. In order to achieve operational 120 efficiencies, this operator seeks to leave selected interfaces 121 unnumbered. 123 o The operator of an IPv6 network currently assigns global addresses 124 to all interfaces. In order to achieve operational efficiencies, 125 this operator seeks to number selected interfaces with link-local 126 addresses only [RFC7404] 128 When a network operator renumbers an interface, replacing a more 129 widely scoped address with one that is less widely scoped, the 130 operator also reduces the number of nodes from which Ping can probe 131 the interface. Therefore, many network operators who rely on Ping 132 remain dependant upon widely scoped interface addressing. 134 This document describes a new diagnostic tool called Extended Ping 135 (Xping). Network operators use Xping to determine the status of a 136 remote interface. In this respect, Xping is similar to Ping. Xping 137 differs from Ping in that it does not require reachability between 138 the probing node and the probed interface. Or, said another way, 139 Xping does not require reachability between the node upon which it 140 executes and the interface whose status is being queried. 142 Xping relies on two new informational ICMP messages, called Extended 143 Echo Request and Extended Echo Reply. The Extended Echo Request 144 message makes a semantic distinction between the destination 145 interface and the probed interface. The destination interface is the 146 interface to which the Extended Echo Request message is delivered. 147 It must be reachable from the probing node. The probed interface is 148 the interface whose status is being queried. It does not need to be 149 reachable from the probing node. However, the destination and probed 150 interfaces must be local to one another (i.e., both interfaces must 151 belong to the same node). 153 Because the Extended Echo Request message makes a distinction between 154 the destination and probed interfaces, Xping can probe every 155 interface on a node if it can reach any interface on the node. In 156 many cases, this allows network operators to decrease their 157 dependence on widely scoped interface addressing. 159 Network operators can use Xping to determine the operational status 160 of the probed interface. They can also use Xping to determine which 161 protocols (e.g., IPv4, IPv6) are active on the interface. However, 162 they cannot use Xping to obtain other information regarding the 163 interface (e.g., bandwidth, MTU). In order to obtain such 164 information, they should use other network management protocols 165 (e.g., SNMP, Netconf). 167 This document is divided into sections, with Section 2 describing the 168 Extended Echo Request message and Section 3 describing the Extended 169 Echo Reply message. Section 4 describes how the probed node 170 processes the Extended Echo Request message and Section 5 describes 171 the Xping application. Section 6 describes uses cases. 173 2. ICMP Extended Echo Request 175 The ICMP Extended Echo Request message is defined for both ICMPv4 and 176 ICMPv6. Like any ICMP message, the ICMP Extended Echo Request 177 message is encapsulated in an IP header. The ICMPv4 version of the 178 Extended Echo Request message is encapsulated in an IPv4 header, 179 while the ICMPv6 version is encapsulated in an IPv6 header. 181 Figure 1 depicts the ICMP Extended Echo Request message. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Code | Checksum | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Identifier | Sequence Number | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | ICMP Extension Structure 192 Figure 1: ICMP Extended Echo Request Message 194 IP Header fields: 196 o Source Address: The Source Address MUST be valid IPv4 or IPv6 197 unicast address belonging to the sending node. 199 o Destination Address: Identifies the destination interface (i.e., 200 the interface to which this message will be delivered). 202 ICMP fields: 204 o Type: Extended Echo Request. The value for ICMPv4 is TBD by IANA. 205 The value for ICMPv6 is also TBD by IANA. 207 o Code: 0 209 o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443. 211 o Identifier: An identifier to aid in matching Extended Echo Replies 212 to Extended Echo Requests. May be zero. 214 o Sequence Number: A sequence number to aid in matching Extended 215 Echo Replies to Extended Echo Requests. May be zero. 217 o ICMP Extension Structure: Identifies the probed interface, by 218 name, index or address. 220 If the ICMP Extension Structure identifies the probed interface by 221 address, that address can be a member of any address family. For 222 example: 224 o An ICMPv4 Extended Echo Request message can carry an ICMP 225 Extension Structure that identifies the probed interface by IPv4 226 address 228 o An ICMPv4 Extended Echo Request message can carry an ICMP 229 Extension Structure that identifies the probed interface by IPv6 230 address 232 o An ICMPv6 Extended Echo Request message can carry an ICMP 233 Extension Structure that identifies the probed interface by IPv4 234 address 236 o An ICMPv6 Extended Echo Request message can carry an ICMP 237 Extension Structure that identifies the probed interface by IPv6 238 address 240 Section 7 of [RFC4884] defines the ICMP Extension Structure. As per 241 RFC 4884, the Extension Structure contains exactly one Extension 242 Header followed by one or more objects. When applied to the ICMP 243 Extended Echo Request message, the ICMP Extension Structure contains 244 one or two instances of the Interface Identification Object 245 (Section 2.1). 247 In most cases, a single instance of the Interface Identification 248 Object can identify the probed interface. However, two instance are 249 required when neither uniquely identifies a interface (e.g., an IPv6 250 link-local address and an IEEE 802 address). 252 2.1. Interface Identification Object 254 The Interface Identification Object identifies the probed interface 255 by name, index, or address. Like any other ICMP Extension Object, it 256 contains an Object Header and Object Payload. The Object Header 257 contains the following fields: 259 o Class-Num: Interface Identification Object. Value is TBD by IANA 261 o C-type: Values are: (1) Identifies Interface By Name, (2) 262 Identifies Interface By Index, and (3) Identifies Interface By 263 Address 265 o Length: Length of the object, measured in octets, including the 266 object header and object payload. 268 If the Interface Identification Object identifies the probed 269 interface by name, the object payload contains the human-readable 270 interface name. The interface name SHOULD be the full MIB-II ifName 271 [RFC2863], if less than 255 octets, or the first 255 octets of the 272 ifName, if the ifName is longer. The interface name MAY be some 273 other human-meaningful name of the interface. The interface name 274 MUST be represented in the UTF-8 charset [RFC3629] using the Default 275 Language [RFC2277]. 277 If the Interface Identification Object identifies the probed 278 interface by index, the length is equal to 8 and the payload contains 279 the MIB-II ifIndex [RFC 2863]. 281 If the Interface Identification Object identifies the probed 282 interface by address, the payload is as depicted in Figure 2. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | AFI | Reserved | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Address .... 291 Figure 2: Interface Identification Object - C-type 3 Payload 293 Payload fields are defined as follows: 295 o Address Family Identifier (AFI): This 16-bit field identifies the 296 type of address represented by the Address field. All values 297 found in the IANA registry of Address Family Numbers (available 298 from ) are valid in this field. 299 Implementations MUST support values (1) IPv4, (2) IPv6, (6) IEEE 300 802, (16389) 48-bit MAC and (16390) 64-bit MAC. They MAY support 301 other values. 303 o Reserved: This 16-bit field MUST be set to zero and ignored upon 304 receipt. 306 o Address: This variable-length field represents an address 307 associated with the probed interface. 309 3. ICMP Extended Echo Reply 311 The ICMP Extended Echo Reply message is defined for both ICMPv4 and 312 ICMPv6. Like any ICMP message, the ICMP Extended Echo Reply message 313 is encapsulated in an IP header. The ICMPv4 version of the Extended 314 Echo Reply message is encapsulated in an IPv4 header, while the 315 ICMPv6 version is encapsulated in an IPv6 header. 317 Figure 3 depicts the ICMP Extended Echo Reply message. 319 0 1 2 3 320 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Code | Checksum | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Identifier | Sequence Number | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Proto Flags |S| RESERVED | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 3: ICMP Extened Echo Reply Message 331 IP Header fields: 333 o Source address: Copied from the Destination Address field of the 334 invoking Extended Echo Request message. 336 o Destination address: Copied from the Source Address field of the 337 invoking Extended Echo Request message. 339 ICMP fields: 341 o Type: Extended Echo Reply. The value for ICMPv4 is TBD by IANA. 342 The value for ICMPv6 is also TBD by IANA. 344 o Code: (0) No Error, (1) Malformed Query, (2) No Such Interface, 345 (3) Multiple Interfaces Satisfy Query 347 o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443. 349 o Identifier: Copied from the Identifier field of the invoking 350 Extended Echo Request packet. 352 o Sequence Number: Copied from the Sequence Number field of the 353 invoking Extended Echo Request packet. 355 o Proto Flags: Each bit in this field represents a protocol. The 356 bit is set if the S-bit is set and the corresponding protocol is 357 running on the probed interface. Bit mappings are as follows: Bit 358 0 (IPv4), Bit 1 (IPv6), Bit 2 (Ethernet), Bits 3-7 (Reserved) 360 o S Bit: This bit is set if the Code field is equal to No Error (0) 361 and the probed interface is active. Otherwise, this bit is clear. 363 o Reserved: This field MUST be set to zero and ignored upon receipt. 365 4. ICMP Extended Echo and Extended Echo Reply Processing 367 When a node receives an ICMP Extended Echo Request message and any of 368 the following conditions apply, the node MUST silently discard the 369 incoming message: 371 o The node does not recognize ICMP Extended Echo Request messages 373 o The node has not explicitly enabled ICMP Extended Echo 374 functionality 376 o The node has not explicitly enabled the incoming ICMP Extended 377 Echo Request type (i.e., by ifName, by IfIndex, by Address) 379 o The incoming ICMP Extend Echo Request carries a source address 380 that is not authorized for the incoming ICMP Extended Echo Request 381 type 383 o The Source Address of the incoming messages is not a unicast 384 address 386 Otherwise, when a node receives an ICMPv4 Extended Echo Request, it 387 MUST format an ICMP Extended Echo Reply as follows: 389 o Don't Fragment flag (DF) is 1 391 o More Fragments flag is 0 393 o Fragment Offset is 0 395 o TTL is 255 397 o Protocol is ICMP 399 When a node receives an ICMPv6 Extended Echo Request, it MUST format 400 an ICMPv6 Extended Echo Reply as follows: 402 o Hop Limit is 255 404 o Next Header is ICMPv6 406 In either case, the responding node MUST: 408 o Copy the source address from the Extended Echo Request message to 409 the destination address of the Extended Echo Reply 411 o Copy the destination address from the Extended Echo Request 412 message to the source address of the Extended Echo Reply 414 o Set the DiffServ codepoint to CS0 [RFC4594] 416 o Set the ICMP Type to Extended Echo Reply 418 o Copy the Identifier from the Extended Echo Request message to the 419 Extended Echo Reply 421 o Copy the sequence number from the Extended Echo Request message to 422 the Extended Echo Reply 424 o Set the Code field as described Section 4.1 426 o If the Code Field is equal to No Error (0) and the probed 427 interface is active, set the S-Bit. Otherwise, clear the S-Bit. 429 o If the S-bit is set, set Protocol Flags as appropriate. 430 Otherwise, clear all Protocol Flags. 432 o Set the checksum appropriately 434 o Forward the ICMP Extended Echo Reply to its destination 436 The status of the probed interface is determined exactly as if it had 437 been probed by a directly connected neighbor using traditional ping. 439 4.1. Code Field Processing 441 The following rules govern how the Code should be set: 443 o If the query is malformed, set the Code to Malformed Query (1) 445 o Otherwise, if the ICMP Extension Structure does not identify any 446 local interfaces, set the Code to No Such Interface (2) 448 o Otherwise, if the ICMP Extension Structure identifies more than 449 one local interfaces, set the Code to Multiple Interfaces Satisfy 450 Query (3) 452 o Otherwise, set the code to No Error (0) 454 5. The Xping Application 456 The Xping application accepts input parameters, sets a counter and 457 enters a loop to be exited when the counter is equal to zero. On 458 each iteration of the loop, Xping emits an ICMP Extended Echo 459 Request, decrements the counter, sets a timer, waits for the timer to 460 expire. If an expected ICMP Extended Echo Reply arrives while Xping 461 is waiting for the timer to expire, Xping relays information returned 462 by that message to its user. However, on each iteration of the loop, 463 Xping waits for the timer to expire, regardless of whether an 464 Extended Echo Reply message arrives. 466 Xping accepts the following parameters: 468 o Count 470 o Wait 472 o Source Interface Address 474 o Hop Count 476 o Destination Interface Address 478 o Probed Interface Identifier 480 Count is a positive integer whose default value is 3. Count 481 determines the number of times that Xping iterates through the above- 482 mentioned loop. 484 Wait is a positive integer whose minimum and default values are 1. 485 Wait determines the duration of the above-mentioned timer, measured 486 in seconds. 488 Source Interface Address specifies the source address of ICMP 489 Extended Echo Request. The Source Interface Address MUST be a 490 unicast address and MUST identify an interface that is local to the 491 probing node. 493 The destination Interface Address identifies the interface to which 494 the ICMP Extended Echo Request message is sent. It can be an IPv4 or 495 IPv6 address. If it is an IPv4 address, Xping emits an ICMPv4 496 message. If it is an IPv6 address, Xping emits an ICMPv6 message. 498 The probed interface is the interface whose status is being queried. 499 If the probed interface identifier is not specified, the Xping 500 application invokes the traditional Ping application and terminates. 501 If the probed interface identifier is specified, it can be any of the 502 following: 504 o an interface name 505 o an address from any address family (e.g., IPv4, IPv6, IEEE 802, 506 48-bit MAC, 64-bit MAC) 508 o an ifIndex 510 The probed interface identifier can have any scope. For example, the 511 probed interface identifier can be: 513 o an IPv6 address, whose scope is global 515 o an IPv6 address, whose scope is link-local 517 o an interface name, whose scope is node-local 519 o an ifIndex, whose scope is node-local 521 If the probed interface identifier is an address, it does not need to 522 be of the same address family as the destination interface address. 523 For example, Xping accepts an IPv4 destination interface address and 524 an IPv6 probed interface identifier. 526 6. Use-Cases 528 In the use cases below, Xping can be used to determine the 529 operational status of a forwarding interface. Other management 530 protocols (e.g., SNMP) might also be used to obtain this information. 531 However, we assume that those management protocols are not viable 532 options, either because they are too heavyweight or they are not 533 supported on the relevant nodes. 535 6.1. Unnumbered Interfaces 537 An IPv4 network contains many routers. On each router, a loopback 538 interface is numbered from global address space and all forwarding 539 interfaces are unnumbered. Network operations staff need a tool that 540 they can execute on any router in the network to determine the 541 operational status of any forwarding interface in the network. 543 6.2. Link-local Interfaces 545 An IPv6 network contains many routers. On each router, a loopback 546 interface is numbered from global address space and some or all 547 forwarding interfaces are numbered from link-local address space. 548 Network operations staff need a tool that they can execute on any 549 router in the network to determine the operational status of any 550 forwarding interface in the network. 552 6.3. Unadvertised Interfaces 554 A network contains many routers. On each router, the loopback 555 interface and all forwarding interfaces are numbered from global 556 address space. However, some forwarding interfaces do not 557 participate in any routing protocol nor are they advertised by any 558 routing protocol. Network operations staff need a tool that they can 559 execute on any router in the network to determine the operational 560 status of any forwarding interface in the network. 562 7. Updates to RFC 4884 564 Section 4.6 of RFC 4884 provides a list of extensible ICMP messages 565 (i.e., messages that can carry the ICMP Extension Structure). This 566 document adds the ICMP Extended Echo message and the ICMP Extended 567 Echo Reply message to that list. 569 8. IANA Considerations 571 This document requests the following actions from IANA: 573 o Add an entry to the "ICMP Type Number" registry, representing the 574 Extended Echo Request. This entry has one code (0). 576 o Add an entry to the "Internet Control Message Protocol version 6 577 (ICMPv6) Parameters" registry, representing the Extended Echo 578 Request. This entry has one code (0). 580 o Add an entry to the "ICMP Type Number" registry, representing the 581 Extended Echo Reply. This entry has the following codes: (0) No 582 Error, (1) Malformed Query, (2) No Such Interface, (3) Multiple 583 Interfaces Satisfy Query. Protocol Flag Bit mappings are as 584 follows: Bit 0 (IPv4), Bit 1 (IPv6), Bit 2 (Ethernet), Bits 3-15 585 (Reserved). 587 o Add an entry to the "Internet Control Message Protocol version 6 588 (ICMPv6) Parameters" registry, representing the Extended Echo 589 Reply. This entry has the following codes: (0) No Error, (1) 590 Malformed Query, (2) No Such Interface, (3) Multiple Interfaces 591 Satisfy Query. Protocol Flag Bit mappings are as follows: Bit 0 592 (IPv4), Bit 1 (IPv6), Bit 2 (Ethernet), Bits 3-15 (Reserved). 594 o Add an entry to the "ICMP Extension Object Classes and Class Sub- 595 types" registry, representing the Interface Identification Object. 596 It has C-types Reserved (0), Identifies Interface By Name (1), 597 Identifies Interface By Index (2), Identifies Interface By Address 598 (3) 600 Note to RFC Editor: this section may be removed on publication as an 601 RFC. 603 9. Security Considerations 605 The following are legitimate uses of Xping: 607 o to determine the operational status of an interface 609 o to determine which protocols (e.g., IPv4, IPv6) are active on an 610 interface 612 However, malicious parties can use Xping to obtain additional 613 information. For example, a malicious party can use Xping to 614 discover interface names. Having discovered an interface name, the 615 malicious party may be able to infer additional information. 616 Additional information may include: 618 o interface bandwidth 620 o the type of device that supports the interface (e.g., vendor 621 identity) 623 o the operating system version that the above-mentioned device 624 executes 626 Understanding this risk, network operators establish policies that 627 restrict access to ICMP Extended Echo functionality. In order to 628 enforce these polices, nodes that support ICMP Extended Echo 629 functionality MUST support the following configuration options: 631 o Enable/disable ICMP Extended Echo functionality. By default, ICMP 632 Extend Echo functionality is disabled. 634 o Define enabled query types (i.e., by ifName, by ifIndex, by 635 Address). By default, all query types are disabled. 637 o For each enabled query type, define the prefixes from which ICMP 638 Extended Echo Request messages are permitted 640 o For each interface, determine whether ICMP Echo Request messages 641 are accepted 643 When a node receives an ICMP Extended Echo Request message that it is 644 not configured to support, it MUST silently discard the message. See 645 Section 4 for details. 647 In order to protect local resources, implementations SHOULD rate- 648 limit incoming ICMP Extended Echo Request messages. 650 10. Acknowledgements 652 Thanks to Jeff Haas, Carlos Pignataro, Jonathan Looney and Joe Touch 653 for their thoughtful review of this document. 655 11. References 657 11.1. Normative References 659 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 660 RFC 792, DOI 10.17487/RFC0792, September 1981, 661 . 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, 665 DOI 10.17487/RFC2119, March 1997, 666 . 668 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 669 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 670 January 1998, . 672 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 673 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 674 . 676 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 677 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 678 2003, . 680 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 681 Control Message Protocol (ICMPv6) for the Internet 682 Protocol Version 6 (IPv6) Specification", RFC 4443, 683 DOI 10.17487/RFC4443, March 2006, 684 . 686 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 687 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 688 DOI 10.17487/RFC4884, April 2007, 689 . 691 11.2. Informative References 693 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 694 and E. Lear, "Address Allocation for Private Internets", 695 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 696 . 698 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ 699 IP Tools and Utilities", FYI 30, RFC 2151, 700 DOI 10.17487/RFC2151, June 1997, 701 . 703 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 704 Configuration of IPv4 Link-Local Addresses", RFC 3927, 705 DOI 10.17487/RFC3927, May 2005, 706 . 708 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 709 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 710 2006, . 712 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 713 Guidelines for DiffServ Service Classes", RFC 4594, 714 DOI 10.17487/RFC4594, August 2006, 715 . 717 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 718 Addressing inside an IPv6 Network", RFC 7404, 719 DOI 10.17487/RFC7404, November 2014, 720 . 722 Authors' Addresses 724 Ron Bonica 725 Juniper Networks 726 2251 Corporate Park Drive 727 Herndon, Virginia 20171 728 USA 730 Email: rbonica@juniper.net 731 Reji Thomas 732 Juniper Networks 733 Elnath-Exora Business Park Survey 734 Bangalore, Karnataka 560103 735 India 737 Email: rejithomas@juniper.net 739 Jen Linkova 740 Google 741 1600 Amphitheatre Parkway 742 Mountain View, California 94043 743 USA 745 Email: furry@google.com 747 Chris Lenart 748 Verizon 749 22001 Loudoun County Parkway 750 Ashburn, Virginia 20147 751 USA 753 Email: chris.lenart@verizon.com