Re: error from ntpd upon IPv6 address receipt/bind

[masanobu%iij.ad.jp@localhost]

 Hi, Greg.

From: Greg Troxel <gdt%ir.bbn.com@localhost>
Subject: Re: error from ntpd upon IPv6 address receipt/bind
Date: Tue, 25 May 2010 08:54:59 -0400

> 
> 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?

No, it can't be used.

And, to do the behavior:

  bind() fails if the address is tentative.

or

  D) bind() returns successfully and drop in ip6_output() ->  in6_selectsrc().

===============
diff -u -r1.49 in6_src.c
--- in6_src.c   25 May 2009 22:49:23 -0000      1.49
+++ in6_src.c   26 May 2010 00:57:29 -0000
@@ -546,7 +546,9 @@
                break;
        }
 
-       if ((ia = ia_best) == NULL) {
+       ia = ia_best;
+       
+       if ((ia == NULL) || ((ia->ia6_flags & IN6_IFF_NOTREADY) != 0)) {
                *errorp = EADDRNOTAVAIL;
                return (NULL);
        }
===============

How about this?

>  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.

----------------------------------------------------------
                SAITOH Masanobu (masanobu%iij.ad.jp@localhost
                                  msaitoh%netbsd.org@localhost)