Internet R. Bonica
Internet-Draft D. Gan
Expires: July 30, 2006 Juniper Networks
P. Nikander
Ericsson Research Nomadic Lab
D. Tappan
C. Pignataro
Cisco Systems, Inc.
January 26, 2006
Extending the Internet Control Message Protocol (ICMP)
draft-bonica-internet-icmp-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines a syntax that can be used to extend ICMPv4.
The syntax is characterized by an extension structure that is
appended to selected ICMP messages. The extension structure contains
Bonica, et al. Expires July 30, 2006 [Page 1]
Internet-Draft Extending ICMP January 2006
an header followed by one or more objects. Each object contains a
header and a payload. All object headers share a common format.
Table of Contents
1. Conventions Used In This Document . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The ICMP Extension Structure . . . . . . . . . . . . . . . . . 4
4. ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 5
5. ICMP Extensibility . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Destination Unreachable . . . . . . . . . . . . . . . . . 8
5.2. Source Quench . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Time Exceeded . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Parameter Problem . . . . . . . . . . . . . . . . . . . . 10
5.5. ICMP Messages That Cannot Be Extended . . . . . . . . . . 10
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10
6.1. Classic Application Receives ICMP Message With
Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Partially Compliant Application Receives ICMP Message
With No Extensions . . . . . . . . . . . . . . . . . . . . 12
6.3. Partially Compliant Application Receives ICMP Message
With Fully Compliant Extensions . . . . . . . . . . . . . 13
6.4. Fully Compliant Application Receives ICMP Message With
No Extensions . . . . . . . . . . . . . . . . . . . . . . 13
6.5. Fully Compliant Application Receives ICMP Message With
Partially Compliant Extensions . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Bonica, et al. Expires July 30, 2006 [Page 2]
Internet-Draft Extending ICMP January 2006
1. Conventions Used In This Document
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 RFC2119 [1].
2. Introduction
This document defines a syntax that can be used to extend ICMPv4 [2].
In this document, the term ICMP refers exclusively to ICMPv4. Unless
explicitly noted, ICMPv6 is NOT discussed in this memo.
The syntax defined in this document MUST NOT be used to extend
ICMPv6. This syntax was designed to be backwards compatible with
currently deployed, MPLS-aware ICMPv4 implementations. Consequently,
the syntax is not as clean as would be desirable. For ICMPv6, where
there are no similarly deployed implementations, a better format
should be created. However, other than this note, ICMPv6 is beyond
the scope of this memo.
The syntax defined herein is characterized by an extension structure
that is appended to selected ICMP messages. The extension structure
contains an extension header followed by one or more objects. Each
object contains an object header and a payload. All object headers
share a common format.
This document addresses a fundamental problem in ICMP extensibility.
Many ICMP messages, as currently defined, end with a variable-length
field that lacks a length attribute. Application software infers the
length of this final field from the total length of the ICMP message.
If an extension structure were appended to these messages, without
adding a length attribute for the variable-length field, application
software would not be able to parse the ICMP message. Specifically,
application software would not be able to determine where the
variable-length field ends and where the extension structure begins.
The current memo also addresses backwards compatibility with existing
ICMP implementations that either do not implement the extensions
defined herein or implement them without adding the required length
attributes. In particular, this draft addresses backwards
compatibility with certain, widely deployed, MPLS-aware ICMP
implementations that send the extensions defined herein without
adding the required length attribute.
However, the current memo does not define any ICMP extension objects.
It defines only the extension header and a common header that all
objects share.
Bonica, et al. Expires July 30, 2006 [Page 3]
Internet-Draft Extending ICMP January 2006
3. The ICMP Extension Structure
This memo proposes an optional ICMP Extension Structure that can be
appended to any ICMP message, except for those that are disqualified
in Section 5.5 of this document.
The Extension Structure contains exactly one Extension Header
followed by one or more objects. Having received an ICMP message
with extensions, application software MAY process selected objects
while ignoring others. The presence of an unrecognized object does
not imply that an ICMP message is malformed.
As stated in RFC 792, the total length of the ICMP message, including
extensions, MUST NOT exceed 576 octets. Figure 1 depicts the ICMP
Extension Header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| (Reserved) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ICMP Extension Header
The fields of the ICMP Extension Header are as follows:
Version: 4 bits
ICMP extension version number. This is version 2.
Reserved: 12 bits
Must be set to 0.
Checksum: 16 bits
The one's complement of the one's complement sum of the data
structure, with the checksum field replaced by zero for the
purpose of computing the checksum. An all-zero value means that
no checksum was transmitted.
If the checksum field contains a value other than described above,
the ICMP message does not include the extensions described in this
memo. However, due to backwards compatibility, this does not
imply that the ICMP message is malformed. See for Section 6
details.
Bonica, et al. Expires July 30, 2006 [Page 4]
Internet-Draft Extending ICMP January 2006
4. ICMP Extension Objects
Each extension object contains one or more 32-bit words, representing
an object header and payload. All object headers share a common
format. Figure 2 depicts the Object Header and payload.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| // (Object payload) // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Object Header and Payload
An object header has the following fields:
Length: 16 bits
Length of the object, measured in octets, including the object
header and object payload.
Class-Num: 8 bits
Identifies object class.
C-Type: 8 bits
Identifies object sub-type.
5. ICMP Extensibility
RFC 792 defines the following ICMP message types:
- Destination Unreachable
- Time Exceeded
- Parameter Problem
Bonica, et al. Expires July 30, 2006 [Page 5]
Internet-Draft Extending ICMP January 2006
- Source Quench
- Redirect
- Echo Request/Reply
- Timestamp/Timestamp Reply
- Information Request/Information Reply
RFC 1191 [3] adds a "Next-Hop MTU" field to the Destination
Unreachable message. Subsequent RFCs define the following messages:
- Address Mask Request/Reply [5]
- Router Solicitation/Advertisement [6]
- Traceroute [7]
- Domain Name Request/Reply [8]
- Security Failure [9]
- Experimental Mobility [10]
Many ICMP messages are extensible as currently defined. Protocol
designers can extend ICMP messages by simply appending fields or data
structures to them.
The following ICMP messages are not extensible as currently defined:
- Destination Unreachable
- Source Quench
- Time Exceeded
- Parameter Problem
- Redirect
- Echo Request
- Echo Reply
Bonica, et al. Expires July 30, 2006 [Page 6]
Internet-Draft Extending ICMP January 2006
- Domain Name Reply
These ICMP messages contain a field which represents a portion of the
original datagram to which the ICMP messages is a response. As
originally defined, this field includes the IP header plus the next
eight octets of the original datagram. RFC 1812 [4] extends this
field to contain as many octets as possible, without exceeding a
limit of 576 octets for the entire ICMP message.
Unfortunately, the above mentioned field lacks a length attribute.
Application software infers the length of this field from the total
length of the ICMP message. If an extension structure were appended
to the ICMP message, without adding a length attribute for the
variable-length field, application software would not be able to
parse the ICMP message. Specifically, application software would not
be able to determine where the variable-length field ends and where
the extension structure begins.
In order to solve this problem, this memo introduces an 8-bit length
attribute to the following ICMP messages.
- Destination Unreachable
- Source Quench
- Time Exceeded
- Parameter Problem
The length attribute MUST be specified when the ICMP Extension
Structure is appended to the above mentioned ICMP messages. It
SHOULD be specified when the ICMP Extension Structure is not appended
to the above mentioned ICMP messages.
The length attribute represents the size of the associated variable-
length field, measured in 32-bit words. When the length attribute is
specified, the associated variable-length field MUST be zero padded
to the nearest 32-bit boundary. Space for the length attribute is
claimed from reserved octets, whose value was previously required to
be zero.
In order the achieve backwards compatibility, when the ICMP Extension
Structure is appended to the Time Exceeded or Destination Unreachable
messages, the variable-length field MUST contain at least 128 octets.
If the orignal datagram that the variable-length field represents did
not contain 128 octets, the variable-length field MUST be zero padded
to 128 octets. (See Section 6 for rationale.)
Bonica, et al. Expires July 30, 2006 [Page 7]
Internet-Draft Extending ICMP January 2006
The following sub-sections depict length attribute as it has been
introduced to selected ICMP messages.
5.1. Destination Unreachable
Figure 3 depicts the Destination Unreachable 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | Next-Hop MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Destination Unreachable
The syntax and semantics of all fields are unchanged from RFC 792 and
RFC 1191. However, a length attribute is added to the second word.
The length attribute represents length of the padded "original
datagram" field, measured in 32-bit words.
When the ICMP Extension Structure is appended to this message, the
"original datagram" field MUST contain at least 128 octets (32
words).
5.2. Source Quench
Figure 4 depicts the Source Quench Message.
Bonica, et al. Expires July 30, 2006 [Page 8]
Internet-Draft Extending ICMP January 2006
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Source Quench
The syntax and semantics of all fields are unchanged from RFC 792,
except for a length attribute which is added to the second word. The
length attribute represents length of the padded "original datagram"
field, measured in 32-bit words.
5.3. Time Exceeded
Figure 5 depicts the Time Exceeded 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Time Exceeded
The syntax and semantics of all fields are unchanged from RFC 792,
except for a length attribute which is added to the second word. The
length attribute represents length of the padded "original datagram"
field, measured in 32-bit words.
When the ICMP Extension Structure is appended to this message, the
"original datagram" field MUST contain at least 128 octets (32
Bonica, et al. Expires July 30, 2006 [Page 9]
Internet-Draft Extending ICMP January 2006
words).
5.4. Parameter Problem
Figure 6 depicts the Parameter Problem 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Parameter Problem
The syntax and semantics of all fields are unchanged from RFC 792,
except for a length attribute which is added to the second word. The
length attribute represents length of the padded "original datagram"
field, measured in 32-bit words.
5.5. ICMP Messages That Cannot Be Extended
Due to a lack of reserved octets from which to allocate space, a
length attribute could not be added to the following ICMP messages:
- Redirect
- Echo Request
- Echo Reply
- Domain Name Reply
Therefore, the ICMP Extension Structure described in this memo cannot
be used in conjunction with the above mentioned ICMP messages.
6. Backwards Compatibility
ICMP messages can be categorized as follows:
Bonica, et al. Expires July 30, 2006 [Page 10]
Internet-Draft Extending ICMP January 2006
- Messages that do not include any ICMP extensions
- Messages that include partially compliant ICMP extensions
- Messages that includes fully compliant ICMP extensions
Any ICMP implementation can send a message that does not include
extensions. ICMP implementations produced prior to 1999 never send
ICMP extensions.
Some ICMP implementations, produced between 1999 and the present, may
send a partially compliant version of ICMP extensions described in
this memo. Specifically, these implementations may append the ICMP
Extension Structure to the Time Exceeded and Destination Unreachable
messages. When they do this, they send exactly 128 octets
representing the original datagram, zero padding if required.
However, they do not specify a length attribute to be associated with
the "original datagram" field.
It is assumed that ICMP implementations produced in the future will
send ICMP extensions that are fully compliant with this
specification.
Likewise, applications that consume ICMP messages can be categorized
as follows:
- Classic applications
- Partially compliant applications
- Fully compliant applications
Classic applications do not parse extensions defined in this memo.
Partially compliant implementations parse the extensions defined in
this memo, but only in conjuntion with the Time Expired and
Destination Unreachable messages. They require the "original
datagram" field to contain exactly 128 octets and are insensitive to
the length attribute that is associated with that field. Partially
compliant applications were produced between 1999 and the present.
Fully compliant applications comply fully with the specifications of
this document.
In order to demonstrate backwards compatibility, Table 1 describes
how members of each application catagory would parse each category of
ICMP message.
Bonica, et al. Expires July 30, 2006 [Page 11]
Internet-Draft Extending ICMP January 2006
+----------------+----------------+----------------+----------------+
| | No Extentions | Partially | Fully |
| | | Compliant | Compliant |
| | | Extentions | Extentions |
+----------------+----------------+----------------+----------------+
| Classic | - | Section 6.1 | Section 6.1 |
| Application | | | |
| | | | |
| Partially | Section 6.2 | - | Section 6.3 |
| Compliant | | | |
| Application | | | |
| | | | |
| Fully | Section 6.4 | Section 6.5 | - |
| Compliant | | | |
| Application | | | |
+----------------+----------------+----------------+----------------+
Table 1
In the table above, cells that are left blank represent the nominal
case and require no explanation. In the following sections, we
assume that the ICMP message type is "Time Exceeded".
6.1. Classic Application Receives ICMP Message With Extensions
When a classic application receives an ICMP message that includes
extensions, it will incorrectly interpret those extensions as being
part of the "original datagram" field. Fortunately, the extensions
are guaranteed to begin at least 128 octets beyond the begining of
the "original datagram" field. So, only those ICMP applications that
process the 129th octet of the "original datagram" field will be
adversely effected. To date, no such applications have been
identified.
6.2. Partially Compliant Application Receives ICMP Message With No
Extensions
When a partially compliant application receives a message that
contains no extensions, the application examines the total length of
the ICMP message. If the total ICMP message length is less than the
length of its IP header plus 144 octets, the application correctly
determines that the message does not contain any extensions.
The 144 octet sum is derived from 8 octets for the first two words of
the ICMP Time Exceeded message, 128 octets for the "original
datagram" field, 4 octets for the ICMP Extension Header and 4 octets
for a single ICMP Object header. All of these octets would be
required if extensions were present.
Bonica, et al. Expires July 30, 2006 [Page 12]
Internet-Draft Extending ICMP January 2006
If the ICMP payload contains 144 octets or more, the application must
examine the 137th octet to determine whether it represents a valid
ICMP Extension Header. In order to represent a valid Extension
Header, it must contain a valid version number and checksum. If it
does not contain a valid version number and checksum, the application
correctly determines that the message does not contain any
extensions.
Partially compliant applications assume that the ICMP Extension
Structure begins on the 137th octet of the Time Exceeded message,
after a 128 octet field representing the padded "original datagram"
message.
6.3. Partially Compliant Application Receives ICMP Message With Fully
Compliant Extensions
When a partially compliant application receives a message that
contains fully compliant ICMP extensions, it will parse those
extensions correctly only if the "original datagram" field contains
exactly 128 octets. This is because partially compliant applications
are insensitive to the length attribute that is associated with the
"original datagram" field. (They assume its value to be 128.)
Therefore, when fully compliant ICMP implementations append
extensions to the ICMP Destination Unreachable and Time Expired
Messages, they SHOULD restrict the "original datagram" field to its
minimum length, 128 octets.
6.4. Fully Compliant Application Receives ICMP Message With No
Extensions
When a fully compliant application receives a message that contains
no extensions, it first examines the length attribute that is
associated with the "original datagram" field. If that length
attribute is not specified, the application examines the total length
of the ICMP message. If the total ICMP message length is less than
the length of the IP header plus 144 octets, the application can
correctly determine that the message does not contain any extensions.
The 144 octet sum is derived from 8 octets for the first two words of
the ICMP Time Exceeded message, 128 octets for the "original
datagram" field, 4 octets for the ICMP Extension Header and 4 octets
for a single ICMP Object header. All of these octets would be
required if extensions were present.
If the ICMP payload contains 144 octets or more, the application must
examine the 137th octet to determine whether it represents a valid
ICMP Extension Header. In order to represent a valid Extension
Bonica, et al. Expires July 30, 2006 [Page 13]
Internet-Draft Extending ICMP January 2006
Header, it must contain a valid version number and checksum. If it
does not contain a valid version number and checksum, the application
correctly determines that the message does not contain any
extensions.
6.5. Fully Compliant Application Receives ICMP Message With Partially
Compliant Extensions
When a fully compliant application receives a message that contains
partially compliant extensions, it first examines the length
attribute that is associated with the "original datagram" field.
Because length attribute is not specified, it examines the total
length of the ICMP message.
Because the ICMP payload contains 144 octets or more, the application
must examine the 137th octet to determine whether it represents a
valid ICMP Extension Header. In order to represent a valid Extension
Header, it must contain a valid version number and checksum. If it
does not contain a valid version number and checksum, the application
correctly determines that the message does not contain any
extensions.
7. Security Considerations
Upon receipt of an ICMP message, application software must check it
for syntactic correctness. Improperly specified length attributes
and other syntax problems may result in buffer overruns.
This memo does not define the conditions under which a router sends
an ICMP message. Therefore, it does not expose routers to any new
denial of service attacks.
8. IANA Considerations
The ICMP Extension Object header contains two 8-bit fields: The
Class-Num identifies the object class, and the C-Type identifies the
class sub-type. Sub-type values are defined relative to a specific
object class value, and are defined per-class.
IANA should establish a registry of ICMP extention objects classes
and class sub-types. There are no values assigned within this
document to maintain. Object classes 0xF7 - 0xFF are reserved for
private use. Object class values are assignable on a first-come-
first-serve. The policy for assigning sub-type values should be
defined in the document defining new class values.
Bonica, et al. Expires July 30, 2006 [Page 14]
Internet-Draft Extending ICMP January 2006
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[3] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[4] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
9.2. Informative References
[5] Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC 950, August 1985.
[6] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[7] Malkin, G., "Traceroute Using an IP Option", RFC 1393,
January 1993.
[8] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.
[9] Karn, P. and W. Simpson, "ICMP Security Failures Messages",
RFC 2521, March 1999.
[10] Kempf, J., "Instructions for Seamoby and Experimental Mobility
Protocol IANA Allocations", RFC 4065, July 2005.
Bonica, et al. Expires July 30, 2006 [Page 15]
Internet-Draft Extending ICMP January 2006
Authors' Addresses
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
US
Email: rbonica@juniper.net
Der-Hwa Gan
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: dhg@juniper.net
Pekka Nikander
Ericsson Research Nomadic Lab
JORVAS FIN-02420
Finland
Email: pekka.nikander@nomadiclab.com
Daniel C. Tappan
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
US
Email: tappan@cisco.com
Carlos Pignataro
Cisco Systems, Inc.
7025 Kit Creek Road
Research Triangle Park, N.C. 27709
US
Email: cpignata@cisco.com
Bonica, et al. Expires July 30, 2006 [Page 16]
Internet-Draft Extending ICMP January 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bonica, et al. Expires July 30, 2006 [Page 17]
