Win7 ping first ICMPv6 packet has the Router Alert option

[Tassos Chatzithomaoglou]

I get two types of HbH messages with Router Alert: MLD reports (143) destined to ff02:16 and echo requests (128) destined to every target i start a ping.
Booting in safe mode seems to remove this strange behavior, so i'm searching what might have messed with the ping command, making it send a different initial packet.
File is intact, communications using other protocols don't exhibit the same behavior, so even if a driver changed this, i can't understand the reason behind such a change.

--
Tassos


Marco Sommani wrote on 11/03/2013 09:29:
> Not all ICMPv6 packets are pings (type 128 or 129). If your ICPv6 packet is an MLD Report (type 131 or 143), then it must be preceded by a HbH header.
>
> Marco
>
> On 10/mar/2013, at 13:14, Tassos Chatzithomaoglou wrote:
>
>> I'm trying to find out why the last few weeks one of my Win7 machines, when doing an IPv6 ping, sends the first ICMPv6 packetwith a HbH header (IPv6 Router Alert, MLD), which leads to this packet being dropped somewhere in the path.
>>
>>
>> C:\Users\Tassos>ping -6 www.google.com
>>
>> Pinging www.google.com [2a00:1450:4017:801::1012] with 32 bytes of data:
>> Request timed out.
>> Reply from 2a00:1450:4017:801::1012: time=62ms
>> Reply from 2a00:1450:4017:801::1012: time=61ms
>> Reply from 2a00:1450:4017:801::1012: time=49ms
>>
>> Next header: IPv6 hop-by-hop option (0)
>> Hop-by-Hop Option
>> Next header: ICMPv6 (58)
>> Length: 0 (8 bytes)
>> IPv6 Option (Router Alert)
>> Type: Router Alert (5)
>> Length: 2
>> Router Alert: MLD (0)
>> IPv6 Option (PadN)
>> Type: PadN (1)
>> Length: 0
>> PadN: <MISSING>
>> Internet Control Message Protocol v6
>> Type: Echo (ping) request (128)
>>
>>
>> Other Win7, Win8, WinXP machines do not show that behavior.
>>
>> C:\Users\Tassos>ping -6 www.google.com
>>
>> Pinging www.google.com [2a00:1450:4017:801::1012] with 32 bytes of data:
>> Reply from 2a00:1450:4017:801::1012: time=51ms
>> Reply from 2a00:1450:4017:801::1012: time=49ms
>> Reply from 2a00:1450:4017:801::1012: time=53ms
>> Reply from 2a00:1450:4017:801::1012: time=47ms
>>
>>
>> Any idea?
>> I'm guessing an update or a new program/driver installation might have caused it, but i haven't found anything related.
>>
>>
>> -- 
>> Tassos
>>
>
>