traceroute6 error indicators out of sync with traceroute

[Ignatios Souvatzis <is%netbsd.org@localhost>]

Hi,

I found the time to actually read traceroute6.c and detected why it always
confused me.

It uses !P - which is "protocol unreachable" in traceroute - for 
administratiely prohibited, which traceroute marks as !X.

I've compared to Solaris; their integrated traceroute produces !X in
this case.

1. So I propose to:

--- src/usr.sbin/traceroute6/traceroute6.c      7 Oct 2006 10:24:48 -0000       
1.37
+++ src/usr.sbin/traceroute6/traceroute6.c      13 Feb 2009 10:21:49 -0000
@@ -883,7 +883,7 @@
                                                break;
                                        case ICMP6_DST_UNREACH_ADMIN:
                                                ++unreachable;
-                                               printf(" !P");
+                                               printf(" !X");
                                                break;
                                        case ICMP6_DST_UNREACH_NOTNEIGHBOR:
                                                ++unreachable;

2. You might wonder what's with the other differences:

        traceroute              traceroute6

N!      network unreach.        no route
H!      host unreachable        -/-
A!      -/-                     address unreachable
S!      source route unreach.   not neighbour


2. One can argue that ICMP6_UNREACH_ADDRESS should be translated
to !H, although its not completely equivalent - !A it's explicitly
associated with a neighbour discovery failure (similar to an ARP
failure) and similar link-level translation problems.  I tend to
do that, too; that's another one-line diff 6 lines below the other.

3. traceroute6 !S happens during source routing, and isn't mentioned
in RFC2463 any longer (it was in 1885), so it's actually more or
less equivalent to the traceroute !S.

4. For all those who advocate integration of the two utilities:
view this as a first step.  I don't know for sure how ugly the code
would become given the different socket APIs, that is, less hacks
needed than for IPv4, so I won't handle that problem right know.

I tend to do the proposed change fast. It may even be appropriate
for pullup to the -5 branch; it shouldn't affect any other part of the
system.

Regards,
        -is
-- 
seal your e-mail: http://www.gnupg.org/