Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: error from ntpd upon IPv6 address receipt/bind
Hi, Saitoh-san,
Here is my humble opinion:
A) I am afraid that all daemons should be able to support RTM_ADDRINFO and it
might be difficult to deploy and to support backward compatibility.
B) It would be okay if all daemon including routing daemons do not need
tentative addresses.
C) It would be okay becuase I think that daemons can detect tentative flags by
ifam_flags in ifa_msghdr. Isn't it true?
Regards,
--
Motoyuki OHMORI <ohmori%chikushi-u.ac.jp@localhost>
On Tue, May 25, 2010 at 07:24:52PM +0900, masanobu%iij.ad.jp@localhost wrote:
>
> Hi.
>
> 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).
>
> 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.
>
> 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.
>
> If we choice A) some programs that strictly check incoming routing messages
> may crash e.g.:
>
> switch(rtm->rtm_type) {
> case RTM_NEWADDR:
> case RTM_DELADDR:
> case RTM_ADD:
> .
> .
> .
> break;
> deafult:
> perror("damn");
> exit(1);
> }
>
> How should we solve it?
>
> ----------------------------------------------------------
> SAITOH Masanobu (masanobu%iij.ad.jp@localhost
> msaitoh%netbsd.org@localhost)
Home |
Main Index |
Thread Index |
Old Index