It would be extremely useful and I don't want to reinvent the wheel...
there must be a trace route utility out there already that allows you
to alter such options in the packet, no?
Thanks,
Scott
NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.
>Does anyone know of an application that exists that will allow me to
>set the protocol number in an IP trace route, such that I would be
>able to trace route using protocol 41, and determine where IPv6 over
>IPv4 is being blocked?
[compton ~]$ grep 41 /etc/protocols
41 IPv6
[compton ~]$ whatis traceroute6 tcptraceroute6 tracepath6
traceroute (8) - print the route packets take to network host
rltraceroute6 (8) - IPv6 traceroute tool
tracepath6 (8) - traces path to a network host discovering MTU
along this path
[compton ~]$
Depends on your unnamed distribution, but using that search engine you
are posting from should find them.
>It would be extremely useful and I don't want to reinvent the wheel...
>there must be a trace route utility out there already that allows you
>to alter such options in the packet, no?
Actually, there are quite a number of tools that will do this. What
did you use as search terms in your search?
Old guy
traceroute only uses proto 1 (icmp), proto 6 (tcp), and proto 17 (udp).
The OP wants to diagnose proto 41, which carries IPv6 over IPv4, so the
tool needs to test proto 41 on IPv4.
I'd be inclined to look at hping first. It's been a while since the
last time I needed to use it. It's a pretty versatile packet
constructor. It wasn't really designed for tracerouting, although it
may have been enhanced since I last used it. You could probably write a
script around it to do what you want. (Warning: You may find yourself
specifying an awful lot of options to get valid packets.)
Of course, any tracerouting will only verify what works. Some people
configure their network devices never to use ICMP, so a device which
accepts the trace packet when it times out may not emit a timeout
message. In other words, both devices that work and devices that are
broken can look broken. Although I'd argue that turning off *all* ICMP
to avoid *some* ICMP is still broken, it's not the kind of broken you're
looking for.
So I snagged the latest hping (hping3 from 2005). The version I had was
hping2-rc3 from 2004. Five years counts as a while, right?
There an option to do tracerouting.
hping3 -0 -t 1 -H 41 -T 192.88.99.1
... will probably be close to what you want.
>Moe Trin wrote:
>> Scott wrote:
>>> Does anyone know of an application that exists that will allow me
>>> to set the protocol number in an IP trace route, such that I would
>>> be able to trace route using protocol 41, and determine where IPv6
>>> over IPv4 is being blocked?
>> [compton ~]$ whatis traceroute6 tcptraceroute6 tracepath6
>> traceroute (8) - print the route packets take to network
>host
>> rltraceroute6 (8) - IPv6 traceroute tool
>> tracepath6 (8) - traces path to a network host discovering
>> MTU along this path
>> [compton ~]$
>> Actually, there are quite a number of tools that will do this. What
>> did you use as search terms in your search?
>traceroute only uses proto 1 (icmp), proto 6 (tcp), and proto 17 (udp).
Depends on your version. The SuSE version written by Olaf Kirch when
he was at Caldera lacks ICMP but does IPv6, while most lack TCP. Isn't
standardization wonderful? Actually, I'd use a tool that generates
real IPv6 datagrams, and pump that output over what-ever 6-to-4
conversion you have, based on the concept that the en-route problem
could be ipv6 related, rather than IPv6 over IPv4.
>I'd be inclined to look at hping first. It's been a while since the
>last time I needed to use it. It's a pretty versatile packet
>constructor. It wasn't really designed for tracerouting, although
>it may have been enhanced since I last used it.
-T --traceroute
Traceroute mode. Using this option hping2 will
increase ttl for each ICMP time to live 0 during
transit received. Try hping2 host --traceroute.
This option implies --bind and --ttl 1. You can
override the ttl of 1 using the --ttl option. Since
2.0.0 stable it prints RTT information.
That's the original version from 2001. The 2005 version (hping3)
also has this capability (as does nmap). However
-H --ipproto
Set the ip protocol in RAW IP mode.
that's only setting the protocol field, not generating the actual
protocol. (Yes, I see your other reply.)
>Of course, any tracerouting will only verify what works. Some people
>configure their network devices never to use ICMP, so a device which
>accepts the trace packet when it times out may not emit a timeout
>message.
That friendly 3 letter organization that developed SELinux recommends
blocking ICMP echo, mask request, and redirects (echoing a Cisco
document). Others (including myself) have been recommending allowing
0, 3, 4 and 11 INBOUND, 3, 4, and 8 OUTBOUND, while denying all else.
Some may consider type 4 (Source Quench) as undesirable (possible DOS).
YMMV
RFC1812 says generating an ICMP Type 11 Time Exceeded is a MUST, but
the same section (5.2.7.3) says that it MAY have a per-interface
option to disable origination of these messages on that interface, but
that option MUST default to allowing the messages to be originated.
Old guy
True, but the OP wants to find where protocol 41 is blocked, not IPv6.
Remember, protocol 41 is for IPv6-in-IPv4 encapsulation. Once the
tunnel packet reaches the IPv4 proxy/router, it's decapsulated. From
that point on, it's actual IPv6, not protocol 41 anymore. The IPv4
hops, except for the endpoints, don't care what's in the protocol 41 packet.
The IPv4 tunnel looks like a single hop to IPv6, so for tracerouting on
the other side of the tunnel, traceroute6 is the better tool. But
because the tunnel looks like a single hop to IPv6 in the first place,
traceroute6 provides no info on where the tunnel is being blocked.
That's where I think the OP wants some visibility.
>> Of course, any tracerouting will only verify what works. Some people
>> configure their network devices never to use ICMP, so a device which
>> accepts the trace packet when it times out may not emit a timeout
>> message.
>
> That friendly 3 letter organization that developed SELinux recommends
> blocking ICMP echo, mask request, and redirects (echoing a Cisco
> document). Others (including myself) have been recommending allowing
> 0, 3, 4 and 11 INBOUND, 3, 4, and 8 OUTBOUND, while denying all else.
> Some may consider type 4 (Source Quench) as undesirable (possible DOS).
> YMMV
I think most of the hype over echo is the failure to handle malformed
echo-requests properly from years ago. If someone's going to DoS your
bandwidth with pings, it doesn't matter if you drop them or not. My
biggest rant on ICMP blocking would be screwing with Path MTU Discovery,
though, but that's a different topic. Sermon, choir.
>Moe Trin wrote:
>> -H --ipproto
>> Set the ip protocol in RAW IP mode.
>>
>> that's only setting the protocol field, not generating the actual
>> protocol.
>True, but the OP wants to find where protocol 41 is blocked, not
>IPv6. Remember, protocol 41 is for IPv6-in-IPv4 encapsulation. Once
>the tunnel packet reaches the IPv4 proxy/router, it's decapsulated.
>From that point on, it's actual IPv6, not protocol 41 anymore. The
>IPv4 hops, except for the endpoints, don't care what's in the
>protocol 41 packet.
What's even more fun is that in the tunnel, the wrapper packet shares
none of the flags, or even source/destination IP, so much of the
tricks used in a traceroute type function aren't going to work. RFC3609
discusses this. There _was_ an experimental tool from RIPE back in 2003
that might be useful, but I don't think anyone developed it further.
>I think most of the hype over echo is the failure to handle malformed
>echo-requests properly from years ago.
Ah, the wonderful "ping of death" so beloved by skript kiddiez. To
bad most people aren't running unpatched win95 any more. ;-)
Old guy
Thanks Allen, hping is exactly what I was looking for. Kudos to you
for actually 'getting it'. :)