Extended Ping (Xping)
draft-bonica-intarea-eping-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Ron Bonica , Reji Thomas | ||
| Last updated | 2016-10-06 | ||
| Replaced by | draft-ietf-intarea-probe, RFC 8335 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bonica-intarea-eping-02
INTAREA R. Bonica
Internet-Draft R. Thomas
Intended status: Standards Track Juniper Networks
Expires: April 9, 2017 October 6, 2016
Extended Ping (Xping)
draft-bonica-intarea-eping-02
Abstract
This document describes a new diagnostic tool called Extended Ping
(Xping). Network operators execute Xping to determine the status of
a remote interface. In this respect, Xping is similar to Ping.
Xping differs from Ping in that it does not require network
reachability between itself and remote interface whose status is
being queried.
Xping relies on two new ICMP messages, called Extended Echo and
Extended Echo Reply. Both ICMP messages are defined herein.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 9, 2017.
Bonica & Thomas Expires April 9, 2017 [Page 1]
Internet-Draft Extended Ping (eping) October 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
2. ICMP Extended Echo . . . . . . . . . . . . . . . . . . . . . 4
2.1. Interface Identification Object . . . . . . . . . . . . . 6
3. ICMP Extended Echo Reply . . . . . . . . . . . . . . . . . . 7
4. ICMP Extended Echo and Extended Echo Reply Processing . . . . 8
4.1. Code Field Processing . . . . . . . . . . . . . . . . . . 9
5. The Eping Application . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Problem Statement
Network operators use Ping [RFC2151] to determine whether a remote
interface is alive. Ping sends an ICMP [RFC0792] [RFC4443] Echo
message to the interface being probed and waits for an ICMP Echo
Reply. If Ping receives the expected ICMP Echo Reply, it reports
that the probed interface is alive.
In order for the ICMP Echo message to reach the probed interface, the
probed interface must be addressed appropriately. IP addresses are
scoped as follows:
o Global [RFC4291]
o Private [RFC1918] [RFC4193]
Bonica & Thomas Expires April 9, 2017 [Page 2]
Internet-Draft Extended Ping (eping) October 2016
o Link-local [RFC3927] [RFC4291]
Global addresses are the most widely scoped. A globally addressed
interface can be reached from any node on the Internet. By contrast,
link-local addresses are the least widely scoped. An interface whose
only address is link-local can be reached from on-link interfaces
only.
Network operators seek to decrease their dependence on widely-scoped
interface addressing. For example:
o The operator of an IPv4 network currently assigns global addresses
to all interfaces. In order to conserve scarce IPv4 address
space, this operator seeks to renumber selected interfaces with
private addresses.
o The operator of an IPv4 network currently assigns private
addresses to all interfaces. In order to achieve operational
efficiencies, this operator seeks to leave selected interfaces
unnumbered.
o The operator of an IPv6 network currently assigns global addresses
to all interfaces. In order to achieve operational efficiencies,
this operator seeks to number selected interfaces with link-local
addresses only.
When a network operator renumbers an interface, replacing a more
widely scoped address with one that is less widely scoped, the
operator also reduces the number of nodes from which Ping can probe
the interface. Therefore, many network operators who rely on Ping
remain dependant upon widely scoped interface addressing.
This document describes a new diagnostic tool called Extended Ping
(Xping). Network operators use Xping to determine the status of a
remote interface. In this respect, Xping is similar to Ping. Xping
differs from Ping in that it does not require reachability between
the probing node and the probed interface. Or, said another way,
Xping does not require reachability between the node upon which it
executes and the interface whose status is being queried.
Xping relies on two new ICMP messages, called Extended Echo and
Extended Echo Reply. The Extended Echo message makes a semantic
distinction between the destination interface and the probed
interface. The destination interface is the interface to which the
Extended Echo message is delivered. It must be reachable from the
probing node. The probed interface is the interface whose status is
being queried. It does not need to be reachable from the probing
Bonica & Thomas Expires April 9, 2017 [Page 3]
Internet-Draft Extended Ping (eping) October 2016
node. However, the destination and probed interfaces must be local
to one another (i.e., the same node must support both interfaces).
Because the Extended Echo message makes a distinction between the
destination and probed interfaces, Xping can probe every interface on
a node if it can reach any interface on the node. In many cases,
this allows network operators to decrease their dependence on widely
scoped interface addressing.
Network operators can use Xping to determine the operational status
of the probed interface. They can also use Xping to determine which
protocols (e.g., IPv4, IPv6) are active on the interface. However,
they cannot use Xping to obtain other information regarding the
interface (e.g., bandwidth, MTU). In order to obtain such
information, they should use other network management protocols
(e.g., SNMP, Netconf).
This document is divided into sections, with Section 2 describing the
Extended Echo message and Section 3 describing the Extended Echo
Reply message. Section 4 describes how the probed node processes the
Extended Echo message and Section 5 describes the Xping application.
2. ICMP Extended Echo
The ICMP Extended Echo message is applicable to both ICMPv4 and
ICMPv6. Like any ICMP message, the ICMP Extended Echo message is
encapsulated in an IP header. The ICMPv4 version of the Extended
Echo message is encapsulated in an IPv4 header, while the ICMPv6
version is encapsulated in an IPv6 header.
Figure 1 depicts the ICMP Extended Echo message.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Extension Structure
Figure 1: ICMP Extended Echo Message
IP Header fields:
Bonica & Thomas Expires April 9, 2017 [Page 4]
Internet-Draft Extended Ping (eping) October 2016
o Source Address: Identifies an interface on the probing node.
o Destination Address: Identifies the destination interface (i.e.,
the interface to which this message will be delivered).
ICMP fields:
o Type: Extended Echo. The value for ICMPv4 is TBD by IANA. The
value for ICMPv6 is also TBD by IANA.
o Code: 0
o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443.
o Identifier: An identifier to aid in matching Extended Echo Replies
to this Extended Echo Request. May be zero.
o Sequence Number: A sequence number to aid in matching Extended
Echo Replies to this Extended Echo Request. May be zero.
o ICMP Extension Structure: Identifies the probed interface, by
name, index or address.
If the ICMP Extension Structure identifies the probed interface by
address, that address can be a member of any address family. For
example:
o An ICMPv4 Extended Echo message can carry an ICMP Extension
Structure that identifies the probed interface by IPv4 address
o An ICMPv4 Extended Echo message can carry an ICMP Extension
Structure that identifies the probed interface by IPv6 address
o An ICMPv6 Extended Echo message can carry an ICMP Extension
Structure that identifies the probed interface by IPv4 address
o An ICMPv6 Extended Echo message can carry an ICMP Extension
Structure that identifies the probed interface by IPv6 address
Section 7 of [RFC4884] defines the ICMP Extension Structure. As per
RFC 4884, the Extension Structure contains exactly one Extension
Header followed by one or more objects. When applied to the ICMP
Extended Echo message, the ICMP Extension Structure contains one or
two instances of the Interface Identification Object (Section 2.1).
In most cases, a single instance of the Interface Identification
Object can identify the probed interface. However, two instance are
Bonica & Thomas Expires April 9, 2017 [Page 5]
Internet-Draft Extended Ping (eping) October 2016
required when neither uniquely identifies a interface (e.g., an IPv6
link-local address and an IEEE 802 address.
2.1. Interface Identification Object
The Interface Identification Object identifies the probed interface
by name, index, or address. Like any other ICMP Extension Object, it
contains an Object Header and Object Payload. The Object Header
contains the following fields:
o Class-Num: Interface Identification Object. Value is TBD by IANA
o C-type: Values are: (1) Identifies Interface By Name, (2)
Identifies Interface By Index, and (3) Identifies Interface By
Address
o Length: Length of the object, measured in octets, including the
object header and object payload.
If the Interface Identification Object identifies the probed
interface by name, the object payload contains the human-readable
interface name. The interface name SHOULD be the full MIB-II ifName
[RFC2863], if less than 255 octets, or the first 255 octets of the
ifName, if the ifName is longer. The interface name MAY be some
other human-meaningful name of the interface. The interface name
MUST be represented in the UTF-8 charset [RFC3629] using the Default
Language [RFC2277].
If the Interface Identification Object identifies the probed
interface by index, the length is equal to 8 and the payload contains
the MIB-II ifIndex [RFC 2863].
If the Interface Identification Object identifies the probed
interface by address, the payload is as depicted in Figure 2.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address ....
Figure 2: Interface Identification Object - C-type 3 Payload
Payload fields are defined as follows:
Bonica & Thomas Expires April 9, 2017 [Page 6]
Internet-Draft Extended Ping (eping) October 2016
o Address Family Identifier (AFI): This 16-bit field identifies the
type of address represented by the Address field. All values
found in the IANA registry of Address Family Numbers (available
from <http://www.iana.org>) are valid in this field.
Implementations MUST support values (1) IPv4, (2) IPv6 and (6)
IEEE 802. They MAY support other values.
o Reserved: This 16-bit field MUST be set to zero and ignored upon
receipt.
o Address: This variable-length field represents an address
associated with the probed interface.
3. ICMP Extended Echo Reply
The ICMP Extended Echo Reply message is applicable to both ICMPv4 and
ICMPv6. Like any ICMP message, the ICMP Extended Echo Reply message
is encapsulated in an IP header. The ICMPv4 version of the Extended
Echo Reply message is encapsulated in an IPv4 header, while the
ICMPv6 version is encapsulated in an IPv6 header.
Figure 3 depicts the ICMP Extended Echo Reply message.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Protocol Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ICMP Extened Echo Reply Message
IP Header fields:
o Source address: Identifies the interface to which the
corresponding ICMP Extended Echo message was sent
o Destination address: Identifies the interface from which the
corresponding ICMP Extended Echo message was sent
ICMP fields:
Bonica & Thomas Expires April 9, 2017 [Page 7]
Internet-Draft Extended Ping (eping) October 2016
o Type: Extended Echo Reply. The value for ICMPv4 is TBD by IANA.
The value for ICMPv6 is also TBD by IANA.
o Code: (0) No Error, (1) Xping Not Enabled, (2) Malformed Query,
(3) Query Type Not Enabled, (4) No Such Interface, (5) Multiple
Interfaces Satisfy Query
o Checksum: For ICMPv4, see RFC 792. For ICMPv6, see RFC 4443.
o Identifier: An identifier to aid in matching Extended Echo Replies
to this Extended Echo Request. May be zero.
o Sequence Number: A sequence number to aid in matching Extended
Echo Replies to this Extended Echo Request. May be zero.
o S Bit: This bit is set if the Code field is equal to No Error (0)
and the probed interface is active. Otherwise, this bit is clear.
o Reserved: This 15-bit field MUST be set to zero and ignored upon
receipt.
o Protocol Flags: Each bit in this field represents a protocol. The
bit is set if the S-bit is set and the corresponding protocol is
running on the probed interface. Bit mappings are as follows: Bit
0 (IPv4), Bit 1 (IPv6), Bit 2 (Ethernet), Bits 3-15 (Reserved)
4. ICMP Extended Echo and Extended Echo Reply Processing
When a node receives an ICMPv4 Extended Echo, it MUST format an ICMP
Extended Echo Reply as follows:
o Don't Fragment flag (DF) is 1
o More Fragments flag is 0
o Fragment Offset is 0
o TTL is 255
o Protocol is ICMP
When a node receives an ICMPv6 Extended Echo, it MUST format an
ICMPv6 Extended Echo Reply as follows:
o Hop Limit is 255
o Next Header is ICMPv6
Bonica & Thomas Expires April 9, 2017 [Page 8]
Internet-Draft Extended Ping (eping) October 2016
In either case, the responding node MUST:
o Copy the source address from the Extended Echo message to the
destination address of the Extended Echo Reply
o Copy the destination address from the Extended Echo message to the
source address of the Extended Echo Reply
o Set the DiffServ codepoint to CS0 [RFC4594]
o Set the ICMP Type to Extended Echo Reply
o Copy the Identifier from the Extended Echo message to the Extended
Echo Reply
o Copy the sequence number from the Extended Echo message to the
Extended Echo Reply
o Set the Code field as described Section 4.1
o If the Code Field is equal to No Error (0) and the probed
interface is active, set the S-Bit. Otherwise, clear the S-Bit.
o If the S-bit is set, set Protocol Flags as appropriate.
Otherwise, clear all Protocol Flags.
o Set the checksum appropriately
o Forward the ICMP Extended Echo Reply to its destination
4.1. Code Field Processing
The following rules govern how the Code should be set:
o If Xping is not enabled, set the Code to Xping Not Enabled (1)
o Otherwise, if the query is malformed, set the Code to Malformed
Query (2)
o Otherwise, if the query type is not supported, set the Code to
Query Type Not Enabled (3)
o Otherwise, if the ICMP Extension Structure does not identify any
local interfaces, set the Code to No Such Interface (4)
o Otherwise, if the ICMP Extension Structure identifies more than
one local interfaces, set the Code to Multiple Interfaces Satisfy
Query (5)
Bonica & Thomas Expires April 9, 2017 [Page 9]
Internet-Draft Extended Ping (eping) October 2016
o Otherwise, set the code to No Error (0)
5. The Eping Application
The Xping application accepts input parameters, sets a counter and
enters a loop to be exited when the counter is equal to zero. On
each iteration of the loop, Xping emits an ICMP Extended Echo,
decrements the counter, sets a timer, waits for the timer to expire.
If an expected ICMP Extended Echo Reply arrives while Xping is
waiting for the timer to expire, Xping relays information returned by
that message to its user. However, on each iteration of the loop,
Xping waits for the timer to expire, regardless of whether an
Extended Echo Reply message arrives.
Xping accepts the following parameters:
o Count
o Wait
o Source Interface Address
o Hop Count
o Destination Interface Address
o Probed Interface Identifier
Count is a positive integer whose default value is 3. Count
determines the number of times that Xping iterates through the above-
mentioned loop.
Wait is a positive integer whose minimum and default values are 1.
Wait determines the duration of the above-mentioned timer, measured
in seconds.
Source Interface Address specifies the source address of ICMP
Extended Echo. The source address MUST identify an interface that is
local to the probing node.
The destination Interface Address identifies the interface to which
the ICMP Extended Echo message is sent. It can be an IPv4 address or
an IPv6 address. If it is an IPv4 address, Xping emits an ICMPv4
message. If it is an IPv6 address, Xping emits an ICMPv6 message.
The probed interface is the interface whose status is being queried.
If the probed interface identifier is not specified, the Xping
application invokes the traditional Ping application and terminates.
Bonica & Thomas Expires April 9, 2017 [Page 10]
Internet-Draft Extended Ping (eping) October 2016
If the probed interface identifier is specified, it can be any of the
following:
o an interface name
o an address from any address family (e.g., IPv4, IPv6, MAC)
o an ifIndex
The probed interface identifier can have any scope. For example, the
probed interface identifier can be:
o an IPv6 address, whose scope is global
o an IPv6 address, whose scope is link-local
o an interface name, whose scope is node-local
o an ifIndex, whose scope is node-local
If the probed interface identifier is an address, it does not need to
be of the same address family as the destination interface address.
For example, Xping accepts an IPv4 destination interface address and
an IPv6 probed interface identifier.
6. IANA Considerations
This document requests the following actions from IANA:
o Add an entry to the "ICMP Type Number" registry, representing the
Extended Echo. This entry has one code (0).
o Add an entry to the "Internet Control Message Protocol version 6
(ICMPv6) Parameters" registry, representing the Extended Echo.
This entry has one code (0).
o Add an entry to the "ICMP Type Number" registry, representing the
Extended Echo Reply. This entry has the following codes: (0) No
Error, (1) Xping Not Enabled, (2) Malformed Query, (3) Query Type
Not Enabled, (4) No Such Interface, (5) Multiple Interfaces
Satisfy Query. Protocol Flag Bit mappings are as follows: Bit 0
(IPv4), Bit 1 (IPv6), Bit 2 (Ethernet), Bits 3-15 (Reserved).
o Add an entry to the "Internet Control Message Protocol version 6
(ICMPv6) Parameters" registry, representing the Extended Echo
Reply. This entry has the following codes: (0) No Error, (1)
Xping Not Enabled, (2) Malformed Query, (3) Query Type Not
Enabled, (4) No Such Interface, (5) Multiple Interfaces Satisfy
Bonica & Thomas Expires April 9, 2017 [Page 11]
Internet-Draft Extended Ping (eping) October 2016
Query. Protocol Flag Bit mappings are as follows: Bit 0 (IPv4),
Bit 1 (IPv6), Bit 2 (Ethernet), Bits 3-15 (Reserved).
o Add an entry to the "ICMP Extension Object Classes and Class Sub-
types" registry, representing the Interface Identification Object.
It has C-types Reserved (0), Identifies Interface By Name (1),
Identifies Interface By Index (2), Identifies Interface By Address
(3)
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
Implementations MUST include a configuration option that enables
processing of the ICMP Extended Echo. By default, this configuration
option MUST be disabled. When an implementation receives an ICMP
Extended Echo and this configuration option is disabled, the
implementation returns an ICMP Extended Reply with Code equal to
Xping Not Enabled (1).
Implementations MUST also include a configuration options that enable
the probed interface identification by name, index and address. By
default, these configuration options MUST be enabled. When an
implementation receives an ICMP Extended Echo and the appropriate
configuration option is disabled, the implementation returns an ICMP
Extended Reply with Code equal to Query Type Not Enabled (3).
8. Acknowledgements
Thanks to Jeff Haas, Carlos Pignataro and Joe Touch for their
thoughtful review of this document.
9. References
9.1. Normative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<http://www.rfc-editor.org/info/rfc792>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Bonica & Thomas Expires April 9, 2017 [Page 12]
Internet-Draft Extended Ping (eping) October 2016
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
January 1998, <http://www.rfc-editor.org/info/rfc2277>.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<http://www.rfc-editor.org/info/rfc2863>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007,
<http://www.rfc-editor.org/info/rfc4884>.
9.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/
IP Tools and Utilities", FYI 30, RFC 2151,
DOI 10.17487/RFC2151, June 1997,
<http://www.rfc-editor.org/info/rfc2151>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005,
<http://www.rfc-editor.org/info/rfc3927>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
Bonica & Thomas Expires April 9, 2017 [Page 13]
Internet-Draft Extended Ping (eping) October 2016
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>.
Appendix A. An Appendix
Authors' Addresses
Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, Virginia 20171
USA
Email: rbonica@juniper.net
Reji Thomas
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore, Kanata 560103
India
Email: rejithomas@juniper.net
Bonica & Thomas Expires April 9, 2017 [Page 14]