tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

IPv6 tentative address and RTM_NEWADDR (again) (was: Re: error from ntpd upon IPv6 address receipt/bind)


 This discussion have been stopped for 2 years... 
(my summary)

This problem is still exist, so I'd like to fix it.

Greg said:
>>  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     -
>> B)      -               RTM_NEWADDR
>>  I think B) and C) is not good because the timing is not the time WHEN
> 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. The address can be used after the DAD was solved.

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

 Two years ago, I said that Plan B and C were not good, but I think the plan B
is the best solution. Almost all people don't expect RTM_NEWADDR when a 
address is set but expect RTM_NEWADDR when the address is usable.

 Do you agree with this solution?

                SAITOH Masanobu (

Home | Main Index | Thread Index | Old Index