https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16455
--- Comment #4 from Christopher Maynard <christopher.mayn...@igt.com> ---
(In reply to leut...@netsniffing.ch from comment #0)
> If you select an IPv6 header (with extensions) in the (collapsed) Packet
> Details, only the IPv6 Base header (40 Bytes) is marked in the Packet Bytes
> pane. The bytes for the Extension header are not marked, but are belonging
> to the IPv6 header. (8 Bytes in the enclosed example).
> Only if you specifically select the Fragment header, the 8 Bytes are marked
> correctly in the Packet Byte pane.
While it might seem like the extension headers should be counted as part of the
IPv6 header, that doesn't seem to be how RFC 8200 defines things, which I think
explains why Wireshark is implemented the way it is.
>From https://tools.ietf.org/html/rfc8200#page-6:
Payload Length 16-bit unsigned integer. Length of the IPv6
payload, i.e., the rest of the packet
following this IPv6 header, in octets. (Note
that any extension headers (see Section 4)
present are considered part of the payload,
i.e., included in the length count.)
That said, I do think it makes sense to highlight all the bytes of the IPv6
header including extensions when selecting the IPv6 layer. That would
hopefully also adjust the "Protocol Hierarchy Statistics" (PHS) to include the
IPv6 extensions bytes as part of IPv6. Looking at the attached capture file,
currently only 80 bytes are indicated in the IPv6 PHS, whereas 96 bytes should
be. Those 16 bytes are actually completely unaccounted for in the PHS.
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
