Re: error from ntpd upon IPv6 address receipt/bind

[Motoyuki OHMORI <ohmori%chikushi-u.ac.jp@localhost>]

Hi, 

# I move it to tech-net as well.

> Unless that routing message is used by some system process for some
> very peculiar message, that would be my preference as the solution, a
> tentative address doesn't really exist, it is just in the process of being
> assigned.

I almost agree with you, however, here is just one thing.
We, users, may want to know if DAD finishes or not by checking ifconfig output.
However, if B) is taken, current ifconfig might not be able to get tentative
addresses by ioctl() or sysctl() in order to hide tentative addresses from
other applications that initially get addresses by those system calls.
Certainly ifconfig or such kind of special applications might be modified to use
KVM or some other method to get tentative addresses though.

Regards,
-- 
Motoyuki OHMORI <ohmori%chikushi-u.ac.jp@localhost>

On Tue, May 25, 2010 at 11:16:24PM +0700, Robert Elz wrote:
>     Date:        Tue, 25 May 2010 21:02:27 +0900
>     From:        Motoyuki OHMORI <ohmori%chikushi-u.ac.jp@localhost>
>     Message-ID:  <20100525120226.GF4956%fd.chikushi-u.ac.jp@localhost>
> 
>   | B) It would be okay if all daemon including routing daemons do not need
>   |    tentative addresses.
> 
> Unless that routing message is used by some system process for some
> very peculiar message, that would be my preference as the solution, a
> tentative address doesn't really exist, it is just in the process of being
> assigned.
> 
> Certainly no "normal" routing process is going to want to know about it,
> as in he (rare) case that DAD fails, anything that noticed the address and
> started using it while tentative is going to have to either just stop,
> or stop, then start again when a different address is assigned - either way
> is very poor behaviour for a routing daemon, they don't want to start
> announcing that an address exists, only to revoke that a second or two later.
> 
> Is anyone aware of anything that actually wants to know about tentative
> addresses (outside the kernel - they're needed in there to properly
> handle DAD in case two systems are both trying to assign the same address
> at the same time.)
> 
> kre
>