Wireshark-users: Re: [Wireshark-users] ipv6 packet with routing header type 0, last segment
From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Thu, 23 Sep 2010 09:02:44 +0200
On 09/22/2010 09:22 PM, Mike Cross wrote:
One sentence summary: Why does wireshark generate the icmpv6 checksum
based on the routing header type 0 addresses if there are 0 segments
remaining, since the destination address of the ipv6 header field should
be used instead?

I know that type 0 routing headers are depcrecated.  I am just debugging
packets someone else generates.

RFC 2460 says down in 8.1

"If the IPv6 packet contains a Routing header, the Destination
Address used in the pseudo-header is that of the final
destination. At the originating node, that address will be in
the last element of the Routing header; at the recipient(s),
that address will be in the Destination Address field of the
IPv6 header."

Here's my sample capture

http://digitalsushi.com/rh0.seg0_vs_seg1.pcap

In the first packet, I have an ICMPv6 packet with a routing header type
0 that has a segment left.  Wireshark calculates the checksum based on
the destination address in the routing header.  Wireshark even overrides
the destination IP column value with the rh0 address. All of this is as
I expect it to be.

In the second packet, though, there are 0 segments remaining.  Wireshark
again uses the last address in the routing header as the destination,
but this I do not expect.  The packet has already visited this segment,
and I expect the ICMPv6 checksum to be generated on the destination in
the IPv6 header, not the routing header.

Per the above specification quote, "at the recipient(s), that address
will be in the Destination Address field of the IPv6 header."  Since
this packet has 0 segments remaining, surely it must be a receipient and
should use the destination address of the IPv6 header.  But wireshark
seems to still be using the last address in the routing header, a
segment which has already been visited.

--mike


Hi Mike,

Normally we would ask you to file a bug report at http://bugs.wireshark.org.
I've already done so (see bug 5252) and committed a fix, which will be ported to Wireshark 1.4.1.

Thanks,
Jaap