[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...
This problem is still exist, so I'd like to fix it.
>> 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
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 (msaitoh%execsw.org@localhost
Main Index |
Thread Index |