[pim@ipng.nl: NetBSD kame - strange behavior]

[Pim van Pelt]

Hi 6bone folk,

It has come to my attention that NetBSD (at least 1.5-1.5.2) have some
peculiarity in the KAME stack for IPv6 regarding linklocal on the loopback
interface. Let us take a NetBSD box:

$ uname -a
NetBSD biscuit 1.5 NetBSD 1.5 (PEERING) #1

and an OpenBSD box:
$ uname -a
OpenBSD ghoul 3.0 GHOUL#2 i386

Regarding the NetBSD one, look at its lo0 device:
[NetBSD 1.5] $ ifconfig lo0
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33228
        inet 127.0.0.1 netmask 0xff000000
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet6 ::1 prefixlen 128

and conclude that fe80::1 is the linklocal address for lo0. Pinging this address 
works, obviously:
[NetBSD 1.5] $ ping6 -c 3 fe80::1%lo0
PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::1%lo0
16 bytes from fe80::1%lo0, icmp_seq=0 hlim=64 time=0.654 ms
16 bytes from fe80::1%lo0, icmp_seq=1 hlim=64 time=1.581 ms
16 bytes from fe80::1%lo0, icmp_seq=2 hlim=64 time=0.679 ms

--- fe80::1%lo0 ping6 statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.654/0.971/1.581/0.431 ms

However, NetBSD (as opposed to FreeBSD and OpenBSD) listens
to any fe80::/10 address on lo0. Look:
[NetBSD 1.5] $ ping6 -c 3 fe80::dead:babe:c0ff:ee%lo0
PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::dead:babe:c0ff:ee%lo0
16 bytes from fe80::dead:babe:c0ff:ee%lo0, icmp_seq=0 hlim=64 time=0.732 ms
16 bytes from fe80::dead:babe:c0ff:ee%lo0, icmp_seq=1 hlim=64 time=1.524 ms
16 bytes from fe80::dead:babe:c0ff:ee%lo0, icmp_seq=2 hlim=64 time=0.781 ms

--- fe80::dead:babe:c0ff:ee%lo0 ping6 statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.732/1.012/1.524/0.362 ms

My coffee bringing dead babe is alive! This results in a somewhat logical
observation that:
[NetBSD 1.5] $ ping6 ff02::1%gif53
PING6(56=40+8+8 bytes) fe80::210:4bff:fe09:1b16%gif53 --> ff02::1%gif53
16 bytes from fe80::210:4bff:fe09:1b16%lo0, icmp_seq=0 hlim=64 time=1.36 ms
16 bytes from fe80::206:5bff:fe11:1c38%gif53, icmp_seq=0 hlim=64 time=23.051 ms(DUP!)

See that the first reply (the localhost) comes from lo0!

For reference (you may check this) OpenBSD and FreeBSD, both, reply from 
the GIF interface and not lo0:
[OpenBSD 3.0] $ ping6 ff02::1%gif1
PING6(56=40+8+8 bytes) fe80::260:8ff:fe46:4b3f%gif1 --> ff02::1%gif1
16 bytes from fe80::260:8ff:fe46:4b3f%gif1, icmp_seq=0 hlim=64 time=0.948 ms
16 bytes from fe80::250:4ff:fe4e:222d%gif1, icmp_seq=0 hlim=64 time=33.468 ms(DUP!)

so that pinging an unconfigured address at lo0 does not work on on f/oBSD:
[OpenBSD 3.0] $ ping6 -c 3 fe80::dead:babe:c0ff:ee%lo0
PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::dead:babe:c0ff:ee%lo0
--- fe80::dead:babe:c0ff:ee%lo0 ping6 statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

In short (glad you made it this far :), why does NetBSD do this ?

groet,
Pim

-- 
---------- - -    - - -+- - -    - - ----------
Pim van Pelt                 Email: pim@ipng.nl
http://www.ipng.nl/             IPv6 Deployment
-----------------------------------------------