Pekka, For a slightly different approach at the problem, take a look at draft-atlas-icmp-unnumbered-02.txt. It has the ability to report on what would have been the outgoing interface, as well as the incoming interface. The information can include an ifIndex, an IP address, and a brief string description.
I'd be very interested in your feedback. Thanks, Alia On 3/18/07, Pekka Savola <[EMAIL PROTECTED]> wrote:
On Thu, 8 Mar 2007, [EMAIL PROTECTED] wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : ICMP Type 11 Code 0 Enhancement > Author(s) : A. Watkins > Filename : draft-watkins-icmptype11code0-01.txt > Pages : 5 > Date : 2007-3-8 > > 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. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-watkins-icmptype11code0-01.txt I read this and thought this might be interesting; I certainly don't think it'd hurt. Unfortunately, as written this wouldn't provide very useful results with IPv6 (link local addresses only..) when an IGP is being used or in some cases with host<->router link. Next-hops pointing at a point-to-point link instead of an address are also unspecified (maybe draft-atlas-icmp-unnumbered-02 would help there).. A couple of comments: ==> the draft is missing IANA considerations section (and you require a value from IANA). Further, draft-bonica states 'The policy for assigning sub-type values should be defined in the document defining new class values.' -- I don't see that policy defined though. ==> the draft is missing a security considerations section. It should discuss the fact that the next-hop information being reported here is not currently publicly available and this would make it so. Doing so could expose e.g., private addressing plans. (Personally, I don't think that's a big issue as if this kind of secrecy is needed, traceroute is typically blocked. But it needs to be discussed briefly.) The format of an ICMP Type 11 Code 0 message is [RFC792]: ==> note that RFC1812 updates this format, specifically, by suggesting the router send more than just the header + 64 bits if the datagram was longer than that. 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 // | | | +-------------+-------------+-------------+-------------+ ==> what will be returned (if anything) if the next-hop is a point-to-point interface (which may or may not have IP addresses)? (in contrast, I believe that when TTL expiry is sent on such an interface, currently the ICMP error message is originated with a loopback address.) ==> in most cases with IPv6 when a routing protocol is used, this will result in returning IPv6 link local addresses. Is that a problem? Is there something to be done about it? Two operational examples from our backbone (yes, the links do have IPv6 global addresses as well): ... 2001:708:510::/48 *[IS-IS/165] 3w5d 11:38:53, metric 14 > to fe80::280:42ff:fe19:7623 via so-2/0/0.0 ... 2001:708:10:9::/64 *[IS-IS/165] 3w5d 11:41:08, metric 22 > to fe80::290:69ff:fe76:4e17 via ge-0/0/0.0 To extend this idea to IPv6 would most likely require an additional ICMP message type. ==> maybe this was not updated when the draft-bonica-internet-icmp was modified to support IPv6 as well. If this was to be specified, IPv6 must be supported from day one (even if it reported just link-local addresses). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
