Subject: [Int-area] Re: I-D ACTION:draft-watkins-icmptype11code0-01.txt

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Mar 2007 19:32:34 +0200 (EET)

On Thu, 8 Mar 2007, [email-masked] 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-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "Alia Atlas" <[email-masked]>
Date: Sun, 18 Mar 2007 13:28:50 -0700

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

---

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Mar 2007 23:38:55 +0200 (EET)

On Sun, 18 Mar 2007, Alia Atlas wrote:
> 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.
>

The draft is unclear wrt 'description'.  It says that it SHOULD report 
'ifName' but other info can be reported as well. This is very 
confusing as 'description' has established meaning in the ops 
community and that meaning is NOT ifName.  The object should be named 
'Interface name' (ifName) because that's distinct from description 
(ifAlias).

I'd very strongly object to reporting 'description' (ifAlias).  In 
deployments I've seen this often includes confidential information 
(e.g., customer numbers, link identification numbers, etc.).  I 
suggest rephrasing this so that the name of the object is 'Interface 
name' (ifName).  If description (ifAlias) would be retained, the spec 
should require that by default it MUST NOT be reported.

In general, I find the specification having features that I don't see 
necessary. Reporting ifIndex is not necessary (and the index is not 
very useful as is to a human) if ifName is reported.  Addresses are 
already known from the source address though somewhat less reliably so 
those need not be reported for outgoing interface use, and could also 
result in reporting IPv6 link-local addresses (or IPv4 private 
addresses) which wouldn't necessarily be useful or desired.

There also seems to be some specification about incoming/outgoing 
interface (which is probably why addresses are supported).  This is 
distinct from what draft-watkins-icmptype11code0 is about because that 
draft reports next-hops which this doesn't do.

Personally, I'd prefer seeing either one big document or two 
documents, one describing 'ifName' reporting and one describing IP 
address reporting (nexthop, possibly input/output interface). 
Currently input/output address reporting seems to be out of scope of 
this draft though: the title, draft name, abstract, etc. don't reflect 
these address extensions (meant to identify the incoming interface) so 
some rewording at the very least is needed there.

As a more editorial issue, the first two paragraphs could maybe use 
slight modification to better account for IPv6 (e.g., ref to ICMPv6 
spec).  As a detail, source address selection for ICMPv6 is specified 
slightly differently, but it's spec-compliant to do it the same way as 
for IPv4.  It's not guaranteed though.