ICMPv6 dissector: PREF64 option parsing only works for prefix length 96
Summary
Dissection of ICMPv6 PREF64 options fails if the PLC (prefix length code) of the option is any other value than 96 bits.
Steps to reproduce
The attached capture file has two Router Advertisements with the PREF64 option. The first packet has a PLC of 64 bits and shows the bug. The second packet has a PLC of 96 bits and is dissected properly. Open the file, look at the first packet, in particular the PREF64 option.
What is the current bug behavior?
The dissector only recognizes the number of bits given in the PLC as part of the option. Using shorter PLCs than the maximum of 96 bits results in unused bits at the end of the option that are not recognized as part of the option. This marks the packet as malformed when in fact it is not.
What is the expected correct behavior?
RFC 8781 states that the prefix in the option always has 96 bits, regardless of the number of bits marked as significant in the PLC. Copying only the significant bits to the dissected prefix field is correct. The offset should however always be advanced by 96 bits, rather than only by the number of significant bits given in the PLC to consume all bits of the option before parsing the next option.
Sample capture file
Relevant logs and/or screenshots
Build information
3.6.2 (Git commit 626020d9b3c3)
Compiled (64-bit) using GCC 11.2.1 20220127 (Red Hat 11.2.1-9), with Qt 5.15.2,
with libpcap, with POSIX capabilities (Linux), with libnl 3, with GLib 2.70.4,
with zlib 1.2.11, with Lua 5.1.5, with GnuTLS 3.7.2 and PKCS #11 support, with
Gcrypt 1.9.4-unknown, with MIT Kerberos, with MaxMind DB resolver, with nghttp2
1.45.1, without brotli, without LZ4, with Zstandard, without Snappy, without
libxml2, with libsmi 0.4.8, with QtMultimedia, without automatic updates, with
SpeexDSP (using bundled resampler), without Minizip.
Running on Linux 5.14.18-300.fc35.x86_64, with QEMU Virtual CPU version 2.5+,
with 64299 MB of physical memory, with GLib 2.70.5, with zlib 1.2.11, with Qt
5.15.2, with libpcap 1.10.1 (with TPACKET_V3), with c-ares 1.17.2, with GnuTLS
3.7.2, with Gcrypt 1.9.4-unknown, with nghttp2 1.45.1, with Zstandard 1.5.2,
with libsmi 0.4.8, with light display mode, without HiDPI, with
LC_TYPE=en_US.UTF-8, binary plugins supported (15 loaded).Current master shows the same behavior, I'm currently working on a patch to fix this.