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)



 Hi.

 This discussion have been stopped for 2 years...

        http://mail-index.netbsd.org/current-users/2010/05/12/msg013334.html
        http://mail-index.netbsd.org/current-users/2010/05/25/msg013529.html 
(my summary)
        http://mail-index.netbsd.org/tech-net/2010/05/25/msg002094.html

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     -
>> 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. 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 
tentative
address is set but expect RTM_NEWADDR when the address is usable.

 Do you agree with this solution?

-- 
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)


Home | Main Index | Thread Index | Old Index