netdev - Re: [IPV6] ADDRCONF: Defer dad for global address until dad for linklocal is completed.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4832C9AC.3030502@miraclelinux.com>
Date:	Tue, 20 May 2008 21:53:00 +0900
From:	Toyo Abe <tabe@...aclelinux.com>
To:	YOSHIFUJI Hideaki / 吉藤英明 
	<yoshfuji@...ux-ipv6.org>
CC:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [IPV6] ADDRCONF: Defer dad for global address until dad for linklocal
 is completed.

sorry again. there was typo.

Toyo Abe wrote:
> Sorry for lack of explanation.
>
> > But then, many other test scenarios in TAHI test suite went to FAIL. 
> It was because
> > the tester node send RA with prefix option to the host right after 
> it receives DAD NS
> > from the host, which is obviously in autoconfiguration process for 
> linklocal address.
>
> And the tester node never accepts RS(es) from the host after sending 
> the RA. The tester
> node determine FAIL unless it doesn't receive DAD NS for corresponding 
> global address
> from the host.
... unless it receives DAD NS for corresponding global address from the host

>
>
> -toyo
>
> Toyo Abe wrote:
>> Yoshifuji-san,
>>
>> Thanks for your response.
>>
>> > Why don't we just ignore RA until DAD for link-local
>> > address has been successfully completed?
>> I was also thinking so. And I tried it at first.
>> But then, many other test scenarios in TAHI test suite went to FAIL. 
>> It was because
>> the tester node send RA with prefix option to the host right after it 
>> receives DAD NS
>> from the host, which is obviously in autoconfiguration process for 
>> linklocal address.
>>
>> Besides, RFC4862 section 4(protocol overview) says;
>> ---
>> To speed the autoconfiguration process, a host may generate its link-
>> local address (and verify its uniqueness) in parallel with waiting
>> for a Router Advertisement. Because a router may delay responding to
>> a Router Solicitation for a few seconds, the total time needed to
>> complete autoconfiguration can be significantly longer if the two
>> steps are done serially.
>> ---
>>
>> The  text indicates that a host *may* accept RA including prefix 
>> option even before
>> completion of DAD for linklocal address.
>> Since current addrconf code actually accepts RA including prefix 
>> option while DAD for
>> linklocal address is processing, changes of the behaviour looks like 
>> a degradation for me.
>> Hence, I chose to accept RA at that moment and defer sending DAD NS 
>> for global addresses.
>>
>> Thanks,
>> -toyo
>>
>> YOSHIFUJI Hideaki / 吉藤英明 wrote:
>>> In article <48324792.5070309@...aclelinux.com> (at Tue, 20 May 2008 
>>> 12:37:54 +0900), Toyo Abe <tabe@...aclelinux.com> says:
>>>
>>>> This patch fixes the problem by deferring DAD initiation for global 
>>>> address until
>>>> DAD for linklocal address is completed. Now the failed test 
>>>> scenarios noted above
>>>> are all passed.
>>>
>>> Why don't we just ignore RA until DAD for link-local
>>> address has been successfully completed?
>>>
>>> --yoshfuji
>>>
>>>
>>
>>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html