ndp -a stops for a while because of lo0

[Lars Schotte]

Hi folks,

I noticed that on NetBSD 6.0, when you want ndp to show you the entries
table it stops first for a while because he looks also on lo0 so on the
loopback device which does not have any linklayer address on NetBSD.

On Linux I saw that Linux gets around this problem with having all
zeroes as the MACADDR of the loopback device. FreeBSD does not show any
loopback devices with ndp -a so neighbor discovery seems to be disabled
for loopback on FreeBSD by default also for the device itself.

When i call ndp -a on NetBSD i get the following (among others):
fe80::1%lo0 (incomplete) lo0 permanent R
cool, but on Linux I have only ::1 as the lo addrv6. So why is there
any fe80::1%lo0 "link scan" address at all?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Lars Schotte
I noticed that on NetBSD 6.0, when you want ndp to show you the entries
table it stops first for a while because he looks also on lo0 so on the
loopback device which does not have any linklayer address on NetBSD.

use '-n' to disable dns. on my machine, 'ndp -a' is quick.

Post by Lars Schotte
On Linux I saw that Linux gets around this problem with having all
zeroes as the MACADDR of the loopback device. FreeBSD does not show any
loopback devices with ndp -a so neighbor discovery seems to be disabled
for loopback on FreeBSD by default also for the device itself.

It looks like lo0 has no MAC address, which makes sense. It may or may
not be a bug that there is an NDP entry.

Post by Lars Schotte
fe80::1%lo0 (incomplete) lo0 permanent R
cool, but on Linux I have only ::1 as the lo addrv6. So why is there
any fe80::1%lo0 "link scan" address at all?

That's a 'link local' address. I think every interface is required to
have one, and there's no reason they have anything to do with MAC
addresses.

I've been running IPv6 for many years with NetBSD, and it generally
works. So you should perhaps post exactly what you are doing, what you
expect to see, and what you are seeing. I would suggest posting to
netbsd-users, unless your mail e.g. contains an analysis from the
standards and is pointing out a particular proble.

[Mouse]

Post by Greg Troxel

Post by Lars Schotte
I noticed that on NetBSD 6.0, when you want ndp to show you the
entries table it stops first for a while because he looks also on
lo0 so on the loopback device which does not have any linklayer
address on NetBSD.

use '-n' to disable dns. on my machine, 'ndp -a' is quick.

It is on mine too, even without -n. But mine are 4.0.1 and 5.1; I
don't know whether this is because of something about name resolution
on my network or because it's not 6.x, but it's another data point.
Snooping port-53 traffic seems to imply ndp is not even trying to
resolve the link-local addresses to names - I see PTR queries for the
globally routed addresses but none for the link-local addresses (on any
interface, lo0 or not).

Post by Greg Troxel

Post by Lars Schotte
On Linux I saw that Linux gets around this problem with having all
zeroes as the MACADDR of the loopback device. [...]

It looks like lo0 has no MAC address, which makes sense.

I agree. lo0 is not even vaguely Ethernettish, so there's no reason
for it to have a MAC, any more than I'd expect ppp0 to have a MAC.

Post by Greg Troxel

Post by Lars Schotte
fe80::1%lo0 (incomplete) lo0 permanent R

I see the same (modulo whitespace).

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lars Schotte]

On Mon, 22 Oct 2012 14:22:17 -0400

Post by Greg Troxel
use '-n' to disable dns. on my machine, 'ndp -a' is quick.

well, that's right, i did not expect that it may be DNS that makes this
all slower, with ndp -an it's fast to me as well.

Post by Greg Troxel
It looks like lo0 has no MAC address, which makes sense. It may or
may not be a bug that there is an NDP entry.

OK!

Post by Greg Troxel
That's a 'link local' address. I think every interface is required to
have one, and there's no reason they have anything to do with MAC
addresses.

Link Local would be ::1, or not???
But OK, I see the point that they need to have one with fe80::1 but if
this is required for loopback is the question. Maybe a sysctl control
could be made so that per default auto_linklocal would be disabled for
loopback device(s) (lo/lo0).

Post by Greg Troxel
I've been running IPv6 for many years with NetBSD, and it generally
works. So you should perhaps post exactly what you are doing, what
you expect to see, and what you are seeing. I would suggest posting
to netbsd-users, unless your mail e.g. contains an analysis from the
standards and is pointing out a particular proble.

Maybe you are talking now about my neighbor discovery problem, but
there i already found out that NetBSD maybe does have only the older
implementation of ND IPv6, the one before:
http://tools.ietf.org/html/rfc4861

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[i***@netbsd.org]

Post by Lars Schotte
On Mon, 22 Oct 2012 14:22:17 -0400

Post by Greg Troxel
use '-n' to disable dns. on my machine, 'ndp -a' is quick.

well, that's right, i did not expect that it may be DNS that makes this
all slower, with ndp -an it's fast to me as well.

Post by Greg Troxel
It looks like lo0 has no MAC address, which makes sense. It may or
may not be a bug that there is an NDP entry.

OK!

Post by Greg Troxel
That's a 'link local' address. I think every interface is required to
have one, and there's no reason they have anything to do with MAC
addresses.

Link Local would be ::1, or not???

No. Formally, that's not a link local address. Semantically, it's
host-local. Link-local addresses are visible outside the machine,
but can't leave a specific logical link.

Post by Lars Schotte
But OK, I see the point that they need to have one with fe80::1 but if
this is required for loopback is the question. Maybe a sysctl control
could be made so that per default auto_linklocal would be disabled for
loopback device(s) (lo/lo0).

You're trying to fix a problem that's not there at all. Whatever causes
your delay is caused by some name resolution on something else, I think.

My ndp -a (without -n) finishes with 10ms wallclock time, and resolves
all but the link-local addresses, be it from wm0, fwip0 or lo0.

Link-local addresses on all active links are required so that
diagnostic or infrastructural programs can operate on a link without
an a-priori-knowledge that it's supposed to be a loopback one.

-is