Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 10006] IPv6 Mobility Header Link Layer Address is parsed i

Date: Fri, 18 Apr 2014 20:30:58 +0000

changed bug 10006

What Removed Added
CC   [email protected]

Comment # 1 on bug 10006 from
(In reply to comment #0)
> Created attachment 12711 [details]
> A packet with IPv6 layer that contains a Link Layer address mobility option
> 
> Build Information:
> Version 1.6.6 (SVNRev 41803 from /trunk-1.6)
> 
> Copyright 1998-2012 Gerald Combs <[email protected]> and contributors.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> Compiled (64-bit) with GTK+ 2.22.1, with GLib 2.26.1, with WinPcap (version
> unknown), with libz 1.2.5, without POSIX capabilities, without libpcre,
> without
> SMI, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.12.18,
> with
> Gcrypt 1.4.6, without Kerberos, with GeoIP, with PortAudio V19-devel (built
> Mar
> 27 2012), with AirPcap.
> 
> Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
> 4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
> 1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
> 
> Built using Microsoft Visual C++ 9.0 build 21022
> 
> Wireshark is Open Source Software released under the GNU General Public
> License.
> 
> Check the man page and http://www.wireshark.org for more information.
> --
> Discovered while working on Pcap.Net (http://pcapdot.net).
> 
> Looking at RFC 5568 (http://tools.ietf.org/html/rfc5568#section-6.4.3), it
> says that the Link-Layer Address (LLA) Option, should have an address right
> after the option code.
In your pcap it is the type 7 (and no 19)
You need to see http://tools.ietf.org/html/rfc5568#section-6.4.4



> In Wireshark, in the attached example, you can see that it says:
> Link-layer address: 86:f2:70:7b:be:0e:99:cc:86:be:8d:be:e3:06
> While the byte after the option code is 0x88 and not 0x86.
> I believe the correct Link-layer address should be:
> 88:86:f2:70:7b:be:0e:99:cc:86:be:8d:be:e3.
> 
There is a comment in Wireshark code source :

        /*
         * I'm not sure what "The format of the option when the LLA is 6
         * bytes is shown in Figure 15.  When the LLA size is different,
         * the option MUST be aligned appropriately.  See Section 6.2 in
         * [3]." in RFC 4068 says should be done with an LLA size other
         * than 6 bytes; section 6.2 in RFC 3775 (reference 3 in RFC 4068)
         * says "Mobility options may have alignment requirements.  Following
         * the convention in IPv6, these options are aligned in a packet so
         * that multi-octet values within the Option Data field of each
         * option fall on natural boundaries (i.e., fields of width n octets
         * are placed at an integer multiple of n octets from the start of
         * the header, for n = 1, 2, 4, or 8) [11]."
         *
         * Reference 11 in RFC 3775 is RFC 2460, the IPv6 spec; nothing
         * in there seems to talk about inserting padding *inside* the
         * data value of an option, so I'm not sure what the extra pad0
         * is doing there, unless the idea is to arrange that the LLA is
         * at least aligned on a 2-byte boundary, in which case presumably
         * it's always present.  We'll assume that.
         */


You are receiving this mail because:
  • You are watching all bug changes.