>Number:         17523
>Category:       kern
>Synopsis:       sparc64 system fails to configure IPv6 on hme0
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 08 11:11:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Havard Eidnes
>Release:        NetBSD 1.6D
>Organization:
	
>Environment:
System: NetBSD mizar.urc.uninett.no 1.6D NetBSD 1.6D (MIZAR) #21: Mon Jul  8 15:02:28 CEST 2002     he@mizar.urc.uninett.no:/usr/src/sys/arch/sparc64/compile/MIZAR sparc64
Architecture: sparc64
Machine: sparcc64
>Description:
	I just updated my singly-connected Ultra2, and found that
	after the update, IPv6 auto-configuration no longer works.
	In particular, the kernel's duplicate address detection logic
	seems to think I have another machine on the same network with
	the same MAC address, something I find hard to beleive.

	The result after boot is:

mizar# ifconfig hme0
hme0: flags=8a63<UP,BROADCAST,NOTRAILERS,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        address: 08:00:20:85:64:e9
        media: Ethernet autoselect (10baseT)
        status: active
        inet 158.38.152.42 netmask 0xffffff00 broadcast 158.38.152.255
        inet6 fe80::a00:20ff:fe85:64e9%hme0 prefixlen 64 duplicated scopeid 0x1
        inet6 2001:700:1:2:a00:20ff:fe85:64e9 prefixlen 64 duplicated

and kernel messages saying:

hme0: DAD detected duplicate IPv6 address fe80:0001::0a00:20ff:fe85:64e9: NS in/out=1/1, NA in=0
hme0: DAD complete for fe80:0001::0a00:20ff:fe85:64e9 - duplicate found
hme0: manual intervention required
Sending router solicitation...
hme0: DAD detected duplicate IPv6 address 2001:0700:0001:0002:0a00:20ff:fe85:64e9: NS in/out=1/1, NA in=0
hme0: DAD complete for 2001:0700:0001:0002:0a00:20ff:fe85:64e9 - duplicate found
hme0: manual intervention required

	After manually doing

mizar# ifconfig hme0 inet6 fe80::a00:20ff:fe85:64e9%hme0 delete
mizar# ifconfig hme0 inet6 2001:700:1:2:a00:20ff:fe85:64e9 delete

	and running a tcpdump while doing

mizar# ifconfig hme0 inet6 fe80::a00:20ff:fe85:64e9%hme0

	results again in a duplicate address detection.
	The tcpdump results were:

mizar# tcpdump -e -p -s 1500 ip6
tcpdump: listening on hme0
19:59:02.838911 0:0:c:5b:77:d4 33:33:0:0:0:1 ip6 110: fe80::200:cff:fe5b:77d4 > ff02::1: icmp6: router advertisement [class 0x70]
19:59:08.142825 0:0:c:5b:77:d4 33:33:0:0:0:1 ip6 110: fe80::200:cff:fe5b:77d4 > ff02::1: icmp6: router advertisement [class 0x70]
19:59:13.222927 0:0:c:5b:77:d4 33:33:0:0:0:1 ip6 110: fe80::200:cff:fe5b:77d4 > ff02::1: icmp6: router advertisement [class 0x70]
19:59:18.663050 0:0:c:5b:77:d4 33:33:0:0:0:1 ip6 110: fe80::200:cff:fe5b:77d4 > ff02::1: icmp6: router advertisement [class 0x70]
19:59:24.215239 0:0:c:5b:77:d4 33:33:0:0:0:1 ip6 110: fe80::200:cff:fe5b:77d4 > ff02::1: icmp6: router advertisement [class 0x70]
19:59:28.161487 8:0:20:85:64:e9 33:33:ff:85:64:e9 ip6 86: :: > ff02::1:ff85:64e9: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff85:64e9 [hlim 1]
19:59:28.161569 8:0:20:85:64:e9 33:33:53:95:d9:ec ip6 86: :: > ff02::2:5395:d9ec: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::2:5395:d9ec [hlim 1]
19:59:28.161599 8:0:20:85:64:e9 33:33:ff:85:64:e9 ip6 86: :: > ff02::1:ff85:64e9: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff85:64e9 [hlim 1]
19:59:28.161642 8:0:20:85:64:e9 33:33:ff:85:64:e9 ip6 78: :: > ff02::1:ff85:64e9: icmp6: neighbor sol: who has fe80::a00:20ff:fe85:64e9
19:59:28.161688 8:0:20:85:64:e9 33:33:53:95:d9:ec ip6 86: :: > ff02::2:5395:d9ec: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::2:5395:d9ec [hlim 1]
19:59:28.161772 8:0:20:85:64:e9 33:33:ff:85:64:e9 ip6 78: :: > ff02::1:ff85:64e9: icmp6: neighbor sol: who has fe80::a00:20ff:fe85:64e9
19:59:29.535350 0:0:c:5b:77:d4 33:33:0:0:0:1 ip6 110: fe80::200:cff:fe5b:77d4 > ff02::1: icmp6: router advertisement [class 0x70]
19:59:29.535509 8:0:20:85:64:e9 33:33:ff:85:64:e9 ip6 78: :: > ff02::1:ff85:64e9: icmp6: neighbor sol: who has mizar.urc.uninett.no
19:59:29.535612 8:0:20:85:64:e9 33:33:ff:85:64:e9 ip6 78: :: > ff02::1:ff85:64e9: icmp6: neighbor sol: who has mizar.urc.uninett.no
19:59:34.671482 0:0:c:5b:77:d4 33:33:0:0:0:1 ip6 110: fe80::200:cff:fe5b:77d4 > ff02::1: icmp6: router advertisement [class 0x70]
19:59:39.767637 0:0:c:5b:77:d4 33:33:0:0:0:1 ip6 110: fe80::200:cff:fe5b:77d4 > ff02::1: icmp6: router advertisement [class 0x70]
19:59:45.111758 0:0:c:5b:77:d4 33:33:0:0:0:1 ip6 110: fe80::200:cff:fe5b:77d4 > ff02::1: icmp6: router advertisement [class 0x70]
19:59:50.207907 0:0:c:5b:77:d4 33:33:0:0:0:1 ip6 110: fe80::200:cff:fe5b:77d4 > ff02::1: icmp6: router advertisement [class 0x70]
^C
362 packets received by filter
0 packets dropped by kernel
mizar#

	I'll admit that I can't quite make heads or tails of this, but
	it doesn't look like the machine is actually getting any
	responses back to the probes.

>How-To-Repeat:
	Update sparc64 machine to kernel of today -- watch it lose.

>Fix:
	Sorry, don't know.
>Release-Note:
>Audit-Trail:
>Unformatted: