>Number:         15360
>Category:       kern
>Synopsis:       NetBSD emits erroneous IPv6 neighbor solicitation packet.
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 25 03:33:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Frode V. Fjeld
>Release:        NetBSD 1.5.2
>Organization:
	Univ. of Tromsoe, Norway
>Environment:
System: NetBSD dslab8 1.5.2 NetBSD 1.5.2 (FVF-KONTOR) #7: Wed Oct 3 19:04:15 CEST 2001 frodef@dslab8:/usr/src/sys/arch/i386/compile/FVF-KONTOR i386
Architecture: i386
Machine: i386
>Description:
	I'm observing with tcpdump the following packet emitted from this
NetBSD machine:

11:49:35.575991 0:1:3:40:d0:94 0:40:5:18:66:d8 ip6 172: fe80::201:3ff:fe40:d094 > fe80::240:5ff:fe18:66d8: icmp6: neighbor sol: who has fe80::240:5ff:fe18:66
d8
0x0000   6000 0000 0076 3aff fe80 0000 0000 0000        `....v:.........
0x0010   0201 03ff fe40 d094 fe80 0000 0000 0000        .....@..........
0x0020   0240 05ff fe18 66d8 8700 0220 0000 0000        .@....f.........
0x0030   fe80 0000 0000 0000 0240 05ff fe18 66d8        .........@....f.
0x0040   0101 0001 0340 d094 0001 0340 d094 0000        .....@.....@....
0x0050   0000

This solicitation packet looks precisely like the regular solicitation
packets, except it is 172 bytes long rather than the normal 86 (i.e. IP
payload is 118 bytes rather than 32). Not all the extra data is included in
the dump above, but what can be seen is one neighbor discovery option type #0,
which is an invalid value (by RFC 2461, sec. 4.6), and then an option of
type #0 and length 0, which both are invalid. I suppose this is really
just random trash data, and that the actual error is that the packet length
is set to 172/118 rather than the correct 86/32. This suggests a bug in
either the ICMPv6 or IPv6 code.

>How-To-Repeat:
	It is difficult to consistently trigger this packet, but it seems
to happen mostly when I ping some machine (from the NetBSD box) and then
while pinging I halt the target machine for a few seconds before restarting it.
>Fix:
	Correct IPv6 stacks should discard this erroneous packet, so no
particular fix is strictly necessary. But this could be the symptom of a
potentially serious bug in the NetBSD IPv6 stack, so it probably should be
corrected, if anyone is able to reproduce this at all.. :)
>Release-Note:
>Audit-Trail:
>Unformatted: