masanobu%iij.ad.jp@localhost writes: [moved to tech-net as masanobu@'s suggestion] [background; ntpd on boot fails to bind to autoconfigured v6 addresses, but ntpd started later works fine.] > Until a DAD completes, the address is marked as > "tentative(IN6_IFF_TENTATIVE)" and bind() with the address fails. This > is the reason why ntpd sometimes complains about an address. > > Some daemon programs check the routing socket and do bind() after getting > RTM_NEWADDR. For IPv4, it's no problem. For IPv6, if a daemon do the same > thing like IPv4, it may fail. It depends on the timing. > > And, perhaps all *BSD's routing socket's implement don't have the way to > inform the changing from tentative to preferred (== DAD completed and OK to > use). I am guessing there is no guidance in any spec... > To do this, there are 3 (or more?) solutions: > > A) Make a new routing message (RTM_ADDRINFO?) for a transistion from > tentative to preferred. > > If we have this message, bind()ing after getting the new message > solves the problem. > > B) Don't send RTM_NEWADDR when an address is added as tentative and send > it after transistion from tentative to preferred. I like this, because if you can't bind to an address, then it isn't really assigned. This is an artifact of DAD being in the kernl. In v4 dhcp, an address is offered, checked to some extent, and then when dhclient decides that it is going to let the host use the address it is put into the kernel. > C) Send RTM_NEWADDR for both timing. > > > none->tentative tentative->preferred > current RTM_NEWADDR - > A) RTM_NEWADDR RTM_ADDRINFO > B) - RTM_NEWADDR > C) RTM_NEWADDR RTM_NEWADDR > > > I think B) and C) is not good because the timing is not the time WHEN > A NEW ADDRESS IS ASSIGNED. But it is - there is a key difference 'tentatively assigned' and then 'really assigned'. Can tentative addresses be used as a source address? If so, why can't we bind? Does some spec say that? Or, can we not use them at all? In that case we should behave as if they don't exist except for administrative interfaces intended to debug this.
Attachment:
pgpaipvaPftmx.pgp
Description: PGP signature