idnits 2.17.1 draft-bonica-intarea-eping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 23, 2016) is 2857 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 (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA R. Bonica 3 Internet-Draft R. Thomas 4 Intended status: Standards Track Juniper Networks 5 Expires: December 25, 2016 June 23, 2016 7 Extended Ping (eping) 8 draft-bonica-intarea-eping-00 10 Abstract 12 This document describes a new diagnostic tool called Extended Ping 13 (eping). Network operators execute eping to determine whether a 14 remote interface is active. In this respect, eping is similar to 15 ping. Eping differs from ping in that it does not require network 16 reachability between itself and remote interface whose status is 17 being queried. 19 Eping relies on two new ICMP messages, called Extended Echo and 20 Extended Echo Reply. Both ICMP messages are defined herein. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 December 25, 2016. 45 Copyright Notice 47 Copyright (c) 2016 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 (http://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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 63 2. ICMP Extended Echo . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Interface Identification Object . . . . . . . . . . . . . 5 65 3. ICMP Extended Echo Reply . . . . . . . . . . . . . . . . . . 6 66 4. ICMP Extended Echo and Extended Echo Reply Processing . . . . 7 67 5. The Eping Application . . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7.1. Probing by ifName and ifDescr . . . . . . . . . . . . . . 10 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 9.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Problem Statement 80 Network operators use ping [RFC2151] to determine whether a remote 81 interface is alive. Ping sends an ICMP [RFC0792] [RFC4443] Echo 82 message to the interface being probed and waits for an ICMP Echo 83 Reply. If ping receives the expected ICMP Echo Reply, it reports 84 that interface is alive. 86 In order for the Echo message to reach the probed interface, the 87 probed interface must be addressed appropriately. IP addresses are 88 scoped as follows: 90 o Global [RFC4291] 92 o Private [RFC1918] [RFC4193] 93 o Link-local [RFC3927] [RFC4291] 95 Global addresses are the most widely scoped. A globally addressed 96 interface can be reached from any node on the Internet. By contrast, 97 link-local addresses are the least widely scoped. An interface whose 98 only address is link-local can be reached from on-link interfaces 99 only. 101 Network operators seek to decrease their dependence on widely-scoped 102 interface addressing. For example: 104 o The operator of an IPv4 network currently assigns global addresses 105 to all interfaces. In order to conserve scarce IPv4 address 106 space, this operator seeks to renumber selected interfaces with 107 private addresses. 109 o The operator of an IPv4 network currently assigns private 110 addresses to all interfaces. In order to achieve operational 111 efficiencies, this operator seeks to leave selected interfaces 112 unnumbered. 114 o The operator of an IPv6 network currently assigns global addresses 115 to all interfaces. In order to achieve operational efficiencies, 116 this operator seeks to allow selected interfaces to be 117 automatically configured with link-local addresses. 119 When a network operator renumbers an interface, replacing a more 120 widely-scoped address with a less widely-scope address, the operator 121 also reduces the number of nodes from which ping can probe the 122 interface. Furthermore, when a network operator removes all 123 addresses from an interface, leaving it unnumbered, the operator 124 makes that interface totally inaccessible to ping. Therefore, many 125 network operators who rely on ping remain dependant upon widely- 126 scoped interface addressing. 128 This document describes a new diagnostic tool called Extended Ping 129 (eping). Network operators use eping to determine whether a remote 130 interface is active. In this respect, eping is similar to ping. 131 Eping differs from ping in that it does not require reachability 132 between the probing node and the probed interface. Or, said another 133 way, eping does not require reachability between the node upon which 134 it executes and the interface whose status is being queried. 136 Eping relies on two new ICMP messages, called Extended Echo and 137 Extended Echo Reply. The Extended Echo message makes a semantic 138 distinction between the destination interface and the probed 139 interface. The destination interface is the interface to which the 140 Extended Echo message is delivered. It must be reachable from the 141 probing node. The probed interface is the interface whose status is 142 being queried. It does not need to be reachable from the probing 143 node. However, the destination and probed interfaces must be local 144 to one another (i.e., the same node must support both interfaces). 146 Because the Extended Echo message makes a distinction between the 147 destination and probed interfaces, eping can probe every interface on 148 a node if it can reach any node on the node. In many cases, this 149 allows network operators to decrease their dependence on widely- 150 scoped interface addressing. 152 This document is divided into sections, with Section 2 describing the 153 Extended Echo message and Section 3 describing the Extended Echo 154 Reply message. Section 4 describes how the probed node processes the 155 Extended Echo message and Section 5 describes the eping application. 157 2. ICMP Extended Echo 159 The ICMP Extended Echo message is applicable to both ICMPv4 and 160 ICMPv6. Like any ICMP message, the ICMP Extended Echo message is 161 encapsulated in an IP header. The ICMPv4 version of the Extended 162 Echo message is encapsulated in an IPv4 header, while the ICMPv6 163 version is encapsulated in an IPv6 header. 165 Figure 1 depicts the ICMP Extended Echo message. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type | Code | Checksum | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Identifier | Sequence Number | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | ICMP Extensions ........ 176 Figure 1: ICMP Extened Echo Message 178 IP Source Address: Identifies an interface on the probing node. 180 IP Destination Address: Identifies the destination interface (i.e., 181 the interface to which this message will be delivered). 183 Type: Extended Echo (TBD. Value to be assigned by IANA.) 185 Code: 0 186 Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443. 188 Identifier: An identifier to aid in matching Extended Echo Replies to 189 this Extended Echo Request. May be zero. 191 Sequence Number: A sequence number to aid in matching Extended Echo 192 Replies to this Extended Echo Request. May be zero. 194 If the destination interface is different from the probed interface, 195 the Extended Echo message MUST include ICMP Extensions. ICMP 196 Extensions MUST include the ICMP Extension Structure Header [RFC4884] 197 and the Interface Identification Object (Section 2.1). 199 If the Extended Echo message does not include the Interface 200 Identification Object, the destination and probed interfaces are 201 understood to be the same. 203 2.1. Interface Identification Object 205 The Interface Identification Object identifies the probed interface. 206 It includes an ICMP Object Header (RFC 4884) and at least one sub- 207 TLV. 209 The ICMP Object Header contains Class-Num and C-Type fields. The 210 Class-Num field MUST be set to Interface Identification Class (value 211 to be assigned by IANA). The C-Type indicates how the probed 212 interface is identified. The C-Type value MUST be one of the 213 following: 215 o By Address (value to be assigned by IANA) 217 o By ifName (value to be assigned by IANA) 219 o By ifIndex (value to be assigned by IANA) 221 See [RFC2863] for a definition of the IfName and IfIndex. 223 If C-type equals "By Address", the Identification Object payload MUST 224 be an Interface IP Address Sub-Object. If C-type equals "By ifName", 225 the Identification Object payload MUST be an Interface IP Name Sub- 226 Object. Both of these are defined in [RFC5837]. If C-type equals 227 "By ifIndex, the Identification Object payload MUST be a 32-bit 228 ifIndex. 230 If the probed interface is identified by address, its address family 231 does not need to be the same as that of the destination address. For 232 example, the probed interface can be identified by its Ethernet 233 address while the destination address is identified by an IPv4 234 address. 236 By default, implementations SHOULD NOT support probing by ifName. 237 See Section 7 for details. 239 3. ICMP Extended Echo Reply 241 The ICMP Extended Echo Reply message is applicable to both ICMPv4 and 242 ICMPv6. Like any ICMP message, the ICMP Extended Echo Reply message 243 is encapsulated in an IP header. The ICMPv4 version of the Extended 244 Echo Reply message is encapsulated in an IPv4 header, while the 245 ICMPv6 version is encapsulated in an IPv6 header. 247 Figure 2 depicts the ICMP Extended Echo Reply message. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type | Code | Checksum | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Identifier | Sequence Number | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | ICMP Extensions ........ 258 Figure 2: ICMP Extened Echo Reply Message 260 IP source address: Identifies the interface to which the 261 corresponding ICMP Extended Echo message was sent 263 IP destination address: Identifies the interface from which the 264 corresponding ICMP Extended Echo message was sent 266 Type: Extended Echo Reply (TBD. Value to be assigned by IANA.) 268 Code: Indicates operational status of probed interface. Defined 269 values are: 271 o Inactive (value to be assigned by IANA) 273 o Active (value to be assigned by IANA) 275 o Interface_does_not_exist (value to be assigned by IANA) 277 o Query_not_supported (value to be assigned by IANA) 279 Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443. 281 Identifier: An identifier to aid in matching Extended Echo Replies to 282 this Extended Echo Request. May be zero. 284 Sequence Number: A sequence number to aid in matching Extended Echo 285 Replies to this Extended Echo Request. May be zero. 287 ICMP Extensions: ICMP Extensions are optional. Currently, no 288 extensions are specified for the ICMP Extended Echo Reply message. 289 However, ICMP Extensions may be defined in the future to carry 290 additional OAM information. 292 4. ICMP Extended Echo and Extended Echo Reply Processing 294 When a node receives an ICMPv4 Extended Echo, it MUST format an ICMP 295 Extended Echo Reply as follows: 297 o Don't Fragment flag (DF) is 1 299 o More Fragments flag is 0 301 o Fragment Offset is 0 303 o TTL is 255 305 o Protocol is ICMP 307 When a node receives an ICMPv6 Extended Echo, it MUST format an 308 ICMPv6 Extended Echo Reply as follows: 310 o Hop Limit is 255 312 o Next Header is ICMPv6 314 o Flow Label is 0 316 In either case, the responding node MUST: 318 o Copy the source address from the Extended Echo message to the 319 destination address of the Extended Echo Reply 321 o Copy the destination address from the Extended Echo message to the 322 source address of the Extended Echo Reply 324 o Set the DiffServ codepoint to CS0 [RFC4594] 326 o Set the ICMP Type to Extended Echo Reply 327 o Copy the Identifier from the Extended Echo message to the Extended 328 Echo Reply 330 o Copy the sequence number from the Extended Echo message to the 331 Extended Echo Reply 333 o Set the code appropriately 335 o Append ICMP Extensions as required 337 o Set the checksum appropriately 339 The following rules govern how the Code should be set: 341 o If the query type is not supported, set the Code to 342 Query_not_supported 344 o Otherwise, if the interface does not exist, set the Code to 345 Interface_does_not_exist 347 o Otherwise, if the destination interface is in one security domain 348 and the probed interface is in another security domain, set the 349 Code to Interface_does_not_exist. Virtual Private Networks are 350 examples of security domains. 352 o Otherwise, if the probed inactive, set the Code to Inactive 354 o Otherwise, set the code to Active 356 5. The Eping Application 358 The eping application accepts input parameters, sets a counter and 359 enters a loop to be exited when the counter is equal to zero. On 360 each iteration of the loop, eping emits an ICMP Extended Echo, 361 decrements the counter, sets a timer, waits for the timer to expire. 362 If an expected ICMP Extended Echo Reply arrives while eping is 363 waiting for the timer to expire, eping relays information returned by 364 that message to its user. However, on each iteration of the loop, 365 eping waits for the timer to expire, regardless of whether an 366 Extended Echo Reply message arrives. 368 Eping accepts the following parameters: 370 o Count 372 o Wait 374 o Source Interface Address 375 o Hop Count 377 o Destination Interface Address 379 o Probed Interface Identifier 381 Count is a positive integer whose default value is 3. Count 382 determines the number of times that eping iterates through the above- 383 mentioned loop. 385 Wait is a positive integer whose minimum and default values are 1. 386 Wait determines the duration of the above mentioned timer, measured 387 in seconds. 389 Source Interface Address specifies the source address of ICMP 390 Extended Echo. 392 The destination Interface Address identifies the interface to which 393 the ICMP Extended Echo message is sent. It can be an IPv4 address or 394 an IPv6 address. If it is an IPv4 address, eping emits an ICMPv4 395 message. If it is an IPv6 address, eping emits an ICMPv6 message. 397 The probed interface is the interface whose status is being queried. 398 If the probed interface identifier is not specified, the destination 399 and probed interfaces are understood to be identical. If the probed 400 interface identifier is specified, it can be: 402 o an interface name 404 o an interface description 406 o an address from any address family (e.g., IPv4, IPv6, MAC) 408 o an ifIndex 410 The probed interface identifier can have any scope. For example, the 411 probed interface identifier can be: 413 o an IPv6 address, whose scope is global 415 o an IPv6 address, whose scope is link-local 417 o an interface name, whose scope is node-local 419 o an interface description, whose scope is node-local 421 o an ifIndex, whose scope is node-local 422 If the probed interface identifier is an address, it does not need to 423 be of the same address family as the destination interface address. 424 For example, eping accepts an IPv4 destination interface address and 425 an IPv6 probed interface identifier. 427 6. IANA Considerations 429 This document requests the following actions from IANA: 431 o Add an entry to the "ICMP Type Number" registry, representing the 432 Extended Echo. This entry has one code (0). 434 o Add an entry to the "ICMP Type Number" registry, representing the 435 Extended Echo Reply. This entry has the following codes: 436 Inactive, Active, Interface_does_not_exist, and 437 Query_not_supported. 439 o Add an entry to the "ICMPv6 Type Number" registry, representing 440 the Extended Echo. This entry has the following codes: Inactive, 441 Active, Interface_does_not_exist, and Query_not_supported. 443 o Add an entry to the "ICMPv6 Type Number" registry, representing 444 the Extended Echo Reply. This entry has one code (0). 446 o Add an entry to the "ICMP Extension Object Classes and sub- 447 classes" registry, representing the Interface Identification 448 Class. This Class includes the sub-classes "By Address", "By 449 Name" , and "By ifIndex". 451 o 453 Note to RFC Editor: this section may be removed on publication as an 454 RFC. 456 7. Security Considerations 458 7.1. Probing by ifName and ifDescr 460 Many implementations encode the following information in an ifName: 462 o Interface type (e.g.., Gigabit Ethernet, SONET, T1) 464 o Location on chassis (i.e., slot identifier) 466 o Location on line card (i.e., port identifier) 468 o Location on port (i.e., logical port identifier) 469 While an operator may have a requirement to probe ports using eping, 470 that operator may not want to expose the above mentioned information. 471 Therefore, by default, implementations SHOULD NOT support probing by 472 ifName. However, probing by ifName can be enabled through 473 configuration. 475 8. Acknowledgements 477 TBD 479 9. References 481 9.1. Normative References 483 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 484 RFC 792, DOI 10.17487/RFC0792, September 1981, 485 . 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, 489 DOI 10.17487/RFC2119, March 1997, 490 . 492 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 493 Control Message Protocol (ICMPv6) for the Internet 494 Protocol Version 6 (IPv6) Specification", RFC 4443, 495 DOI 10.17487/RFC4443, March 2006, 496 . 498 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 499 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 500 DOI 10.17487/RFC4884, April 2007, 501 . 503 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 504 N., and JR. Rivers, "Extending ICMP for Interface and 505 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 506 April 2010, . 508 9.2. Informative References 510 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 511 and E. Lear, "Address Allocation for Private Internets", 512 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 513 . 515 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ 516 IP Tools and Utilities", FYI 30, RFC 2151, 517 DOI 10.17487/RFC2151, June 1997, 518 . 520 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 521 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 522 . 524 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 525 Configuration of IPv4 Link-Local Addresses", RFC 3927, 526 DOI 10.17487/RFC3927, May 2005, 527 . 529 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 530 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 531 . 533 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 534 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 535 2006, . 537 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 538 Guidelines for DiffServ Service Classes", RFC 4594, 539 DOI 10.17487/RFC4594, August 2006, 540 . 542 Appendix A. An Appendix 544 Authors' Addresses 546 Ron Bonica 547 Juniper Networks 548 2251 Corporate Park Drive 549 Herndon, Virginia 20171 550 USA 552 Email: rbonica@juniper.net 554 Reji Thomas 555 Juniper Networks 556 Elnath-Exora Business Park Survey 557 Bangalore, Kanata 560103 558 India 560 Email: rejithomas@juniper.net