Alexis La Goutte
changed
bug 10006
Comment # 1
on bug 10006
from Alexis La Goutte
(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.