From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: "Sridhar Samudrala" <sri@us.ibm.com>,
"YOSHIFUJI Hideaki / 吉藤英明" <yoshfuji@linux-ipv6.org>,
davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi,
jmorris@namei.org, kaber@coreworks.de, netdev@vger.kernel.org
Subject: Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Date: Thu, 25 Jan 2007 12:16:59 -0500 [thread overview]
Message-ID: <45B8E60B.7080809@hp.com> (raw)
In-Reply-To: <20070125133340.GA8891@hmsreliant.homelinux.net>
Neil Horman wrote:
> On Wed, Jan 24, 2007 at 05:54:47PM -0800, Sridhar Samudrala wrote:
>> Sec 2.1 of RFC 4429 says
>>
>> Unless noted otherwise, components of the IPv6 protocol stack should
>> treat addresses in the Optimistic state equivalently to those in the
>> Deprecated state, indicating that the address is available for use
>> but should not be used if another suitable address is available. For
>> example, Default Address Selection [RFC3484] uses the address state
>> to decide which source address to use for an outgoing packet.
>> Implementations should treat an address in state Optimistic as if it
>> were in state Deprecated. If address states are recorded as
>> individual flags, this can easily be achieved by also setting
>> 'Deprecated' when 'Optimistic' is set.
>>
>> So i think DEPRECATED flag also should be set when we mark an address
>> as OPTIMISTIC so that we don't use it as source address for new
>> connections if another address is available until DAD is completed.
>>
>> Thanks
>> Sridhar
>>
>
> Oh, good catch. Thank you Sri. However, I'm worried about the next paragraph:
>
> It is important to note that the address lifetime rules of [RFC2462]
> still apply, and so an address may be Deprecated as well as
> Optimistic. When DAD completes without incident, the address becomes
> either a Preferred or a Deprecated address, as per RFC 2462
>
> Given that, it seems to me that addresses which are flagged as Deprecated may
> enter and exit that state independently of the DAD process, which I think gives
> rise to the possibility of a race. I.e. if an address becomes deprecated right
> before DAD completes, and then addrconf_dad_complete clears the IFA_F_DEPRECATED
> flag, that seems wrong. Instead I think it would be better if we tested for the
> OPTIMISTIC flag in ipv6_dev_get_saddr in parallel with the DEPRECATED flag. I
> may be wrong about this, but I'm going to err on the side of safety. If you can
> ensure that this race is not possible. Please let me know, and I'll happily
> just set the flag. I'll repost a new patch soon.
I tend to agree with Neil here. Marking optimistic addresses as deprecated doesn't
buy as much since the address can transition in and out of deprecated state regardless
of DAD.
However, there is a problem with the current implementation in that OPTIMISTIC address
will never be chosen as source because it's always TENTATIVE and OPTIMISTIC at the
same time. What needs to happen is for ipv6_dev_get_saddr() to not ignore OPTIMISTIC
addresses and treat them same as DEPRECATED.
-vlad
next prev parent reply other threads:[~2007-01-25 17:17 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-19 21:23 [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection Neil Horman
2007-01-19 23:05 ` YOSHIFUJI Hideaki / 吉藤英明
2007-01-20 1:41 ` Neil Horman
2007-01-22 18:15 ` Neil Horman
2007-01-22 18:39 ` Mika Penttilä
2007-01-22 19:45 ` Neil Horman
2007-01-22 20:25 ` Vlad Yasevich
2007-01-23 18:36 ` Neil Horman
2007-01-23 19:27 ` Vlad Yasevich
2007-01-23 0:18 ` YOSHIFUJI Hideaki / 吉藤英明
2007-01-23 20:51 ` Neil Horman
2007-01-25 1:54 ` Sridhar Samudrala
2007-01-25 13:33 ` Neil Horman
2007-01-25 17:16 ` Vlad Yasevich [this message]
2007-01-25 19:45 ` Neil Horman
2007-01-25 20:18 ` Vlad Yasevich
2007-01-25 21:26 ` Neil Horman
2007-01-25 22:13 ` Vlad Yasevich
2007-01-26 14:27 ` Neil Horman
2007-01-26 15:44 ` YOSHIFUJI Hideaki / 吉藤英明
2007-01-26 19:03 ` Neil Horman
2007-01-25 22:34 ` Vlad Yasevich
2007-01-26 0:13 ` YOSHIFUJI Hideaki / 吉藤英明
2007-01-26 14:20 ` Vlad Yasevich
2007-01-26 19:18 ` Neil Horman
2007-01-26 20:28 ` Vlad Yasevich
2007-01-26 21:35 ` Neil Horman
2007-01-26 21:42 ` Vlad Yasevich
2007-01-29 16:34 ` Neil Horman
2007-01-29 21:30 ` Neil Horman
2007-01-29 22:25 ` YOSHIFUJI Hideaki / 吉藤英明
2007-01-30 13:02 ` Neil Horman
2007-01-30 16:16 ` YOSHIFUJI Hideaki / 吉藤英明
2007-01-31 20:54 ` Neil Horman
2007-02-02 19:06 ` Neil Horman
2007-02-02 19:46 ` David Miller
2007-02-02 20:13 ` Neil Horman
2007-02-02 22:22 ` Vlad Yasevich
2007-02-03 15:06 ` Neil Horman
2007-02-02 21:28 ` Brian Haley
2007-02-02 22:05 ` Vlad Yasevich
2007-02-02 23:57 ` Brian Haley
2007-02-03 15:05 ` Neil Horman
2007-02-05 17:33 ` Brian Haley
2007-02-05 18:37 ` Neil Horman
2007-02-02 21:50 ` Vlad Yasevich
2007-02-03 15:03 ` Neil Horman
[not found] ` <20070205205651.GB484@hmsreliant.homelinux.net>
2007-02-06 1:24 ` YOSHIFUJI Hideaki / 吉藤英明
2007-02-06 1:32 ` David Miller
2007-02-06 1:44 ` YOSHIFUJI Hideaki / 吉藤英明
2007-02-06 1:43 ` David Miller
2007-02-06 12:51 ` Neil Horman
2007-02-06 20:09 ` Neil Horman
2007-02-06 21:13 ` Vlad Yasevich
2007-02-07 20:55 ` Neil Horman
2007-02-07 21:19 ` Vlad Yasevich
2007-02-07 21:52 ` YOSHIFUJI Hideaki / 吉藤英明
2007-02-08 13:07 ` Neil Horman
2007-02-12 23:27 ` YOSHIFUJI Hideaki / 吉藤英明
2007-02-13 18:22 ` Neil Horman
2007-02-07 22:26 ` YOSHIFUJI Hideaki / 吉藤英明
2007-02-08 16:41 ` Neil Horman
2007-02-08 17:10 ` YOSHIFUJI Hideaki / 吉藤英明
2007-02-08 19:32 ` Neil Horman
2007-02-12 21:20 ` Neil Horman
2007-02-13 20:45 ` Neil Horman
2007-02-13 21:46 ` YOSHIFUJI Hideaki / 吉藤英明
2007-02-13 21:53 ` David Miller
[not found] ` <20070221.040259.60395625.yoshfuji@linux-ipv6.org>
[not found] ` <20070221.000222.71087924.davem@davemloft.net>
2007-02-21 8:15 ` YOSHIFUJI Hideaki / 吉藤英明
2007-02-21 9:30 ` David Miller
2007-02-21 13:37 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45B8E60B.7080809@hp.com \
--to=vladislav.yasevich@hp.com \
--cc=davem@davemloft.net \
--cc=jmorris@namei.org \
--cc=kaber@coreworks.de \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=pekkas@netcore.fi \
--cc=sri@us.ibm.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).