Internet DRAFT - draft-watkins-icmptype11code0

draft-watkins-icmptype11code0



Internet-Draft                                              Alan Watkins
Network Working Group                                          IBM Corp.
Intended Status: Experimental                             March 29, 2007
Expires: September 30th, 2007

                      ICMP Type 11 Code 0 Enhancement
                   <draft-watkins-icmptype11code0-02.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 30th, 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

   Note that [RFC1812] allows this  datagram to contain as much of the
   original datagram as possible without the length of the ICMP datagram
   exceeding 576 bytes.

   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].















Watkins                    Standards Track                      [Page 2]

Draft             ICMP Type 11 Code 0 Enhancement          March    2007


   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
                           (Future C-Types would use protocol version)
                  Length = 4 for IPv4, 16 for IPv6

              0             1             2            3
      +-------------------------------------------------------+
      |                                                       |
      |             // IP Address for next hop //             |
      |                                                       |
      +-------------+-------------+-------------+-------------+

                     Figure 2: Next Hop Object


   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


Watkins                    Standards Track                      [Page 3]

Draft             ICMP Type 11 Code 0 Enhancement          March    2007


   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.


Security Considerations

   Although next hop information is not necessarily a security risk if
   ICMP traffic is being permitted, it should be pointed out that this
   ICMP extension could allow private address information to be exposed.


Normative References

   [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
            September 1981.

   [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
             RFC 1812, June 1995.

   [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

Watkins                    Standards Track                      [Page 4]

Draft             ICMP Type 11 Code 0 Enhancement          March    2007


   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

   This Internet-Draft will expire on September 30th, 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.

   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]