Internet-Draft Alan Watkins
Network Working Group IBM Corp.
Intended Status: Experimental March 7, 2007
Expires: September 8th, 2007
ICMP Type 11 Code 0 Enhancement
<draft-watkins-icmptype11code0-01.txt>
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 September 8th, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
When performing a traceroute, it would be useful to know where
packets are trying to go when they cannot be routed. ICMP Type 11
Code 0 packets could be used to provide this information, and the
traceroute facility could report this information.
1. ICMP Type 11 Code 0 Enhancement
When performing a traceroute, it would be useful to know where
packets are trying to go when they cannot be routed. ICMP Type 11
Code 0 packets could be used to provide this information, and the
traceroute facility could report this information.
Watkins Standards Track [Page 1]
Draft ICMP Type 11 Code 0 Enhancement March 2007
Basically, next hop information could be appended to ICMP type 11,
code 0 messages and this would allow for further remote analysis of
network problems. ICMP error messages carry a variety of
information; the concept behind the traceroute program is to send
messages with increasing TTL values so that each router along the
path will return a Type 11 Code 0 message and the traceroute program
can use this to incrementally print out the path from the source IP
address to the destination IP address. When something goes wrong,
traceroute reports the last router it could successfully reach. The
idea presented here would give one more piece of information, namely
where a packet was trying to go when it failed.
The format of an ICMP Type 11 Code 0 message is [RFC792]:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + 64 bits of Original Data Datagram |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ICMP Type 11 Code 0 Message
The IP address that would have been the next hop if the TTL had not
expired could be appended as an ICMP Extension. Figure 2 shows a
Next Hop Object. It must be preceeded by an ICMP Extension
Structure Header and an ICMP Object Header. Both are defined in
[I-D.bonica-internet-icmp].
All that is in the object payload is the next hop information.
Class-Num = 2, Next Hop Class (to be assigned by IANA)
C-Type = 4 or 6, indicating IPv4 or IPv6
Length = 4 for IPv4, 16 for IPv6
0 1 2 3
+-------------------------------------------------------+
| |
| // IP Address for next hop // |
| |
+-------------+-------------+-------------+-------------+
Figure 2: Next Hop Object
Watkins Standards Track [Page 2]
Draft ICMP Type 11 Code 0 Enhancement March 2007
The originator can use this information in a variety of
ways. One interesting way would be for the traceroute facility to
print this next hop information out:
#traceroute www.foo.com
Tracing route to www.foo.com [192.168.0.150]
over a maximum of 30 hops:
Next Hop
1 2 ms 2 ms 2 ms 10.1.1.1 10.1.2.1
2 10 ms 10 ms 23 ms 10.1.2.1 10.1.3.1
3 9 ms 11 ms 9 ms 10.1.3.1 192.168.0.1
4 12 ms 9 ms 9 ms 192.168.0.1 1.1.1.1
5 * * * Request timed out
Even with just this additional information, we now know that there is
a problem between 192.168.0.1->1.1.1.1. Maybe 1.1.1.1 is not the
right hop (bad routing entry on 192.168.0.1) or maybe the link
between these routers is down. Before, we didn't know anything about
1.1.1.1 being in the picture. A user with this problem may have no
knowledge of 1.1.1.1, but maybe it is their router...so perhaps this
would point to a configuration problem on a router they control.
This information wouldn't have been available otherwise.
If the other side (in this case www.foo.com) does a traceroute and
receives something similar to:
1 24 ms 28 ms 27 ms 192.168.0.150 1.1.1.1
2 27 ms 24 ms 55 ms 1.1.1.1 192.168.0.1
3 * * * Request timed out
We can now pretty much be sure that the problem is with the
192.168.0.1 - 1.1.1.1 link.
If one of the routers along the path doesn't support this, the only
negative thing would be that the information wouldn't be available
for that particular router. This allows for backwards compatibility
with existing routers. To extend this idea to IPv6 would most likely
require an additional ICMP message type.
Normative References
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981.
Watkins Standards Track [Page 3]
Draft ICMP Type 11 Code 0 Enhancement March 2007
[I-D.bonica-internet-icmp]
Bonica, R., "Extended ICMP to Support Multi-part
Messages", draft-bonica-internet-icmp-16 (work in
progress), January 2007.
Author's Address
Alan Watkins
IBM Corp.
Email: watkinal@us.ibm.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE
IETF TRUST 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.
This Internet-Draft will expire on September 8th, 2007.
Intellectual Property
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 ISOC's procedures with respect to
rights in ISOC 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.
Watkins Standards Track [Page 4]
Draft ICMP Type 11 Code 0 Enhancement March 2007
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.
Watkins Standards Track [Page 5]