netdev - Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection

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: <20070130130208.GA3723@hmsreliant.homelinux.net>
Date:	Tue, 30 Jan 2007 08:02:08 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	YOSHIFUJI Hideaki / 吉藤英明 
	<yoshfuji@...ux-ipv6.org>
Cc:	vladislav.yasevich@...com, sri@...ibm.com, davem@...emloft.net,
	kuznet@....inr.ac.ru, pekkas@...core.fi, jmorris@...ei.org,
	kaber@...eworks.de, netdev@...r.kernel.org
Subject: Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection

On Tue, Jan 30, 2007 at 07:25:36AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <20070129213013.GA26841@...reliant.homelinux.net> (at Mon, 29 Jan 2007 16:30:13 -0500), Neil Horman <nhorman@...driver.com> says:
> 
> > Quick reality check here.  In thinking about how best to go about this
> > redirection of frames to the default router, based on Dave M.s input, I think
> > that the best solution would be in ndisc_send_ns.  What I was thinking was that
> > in ndisc_send_ns, we already detect if a source address is optimistic and squash
> > the transmission of the frame there.  What if in addition to that supression, we
> :
> 
> Well...I think it is okay if sending NS is deferred (or omit) in
> ndisc_send_ns() (or in ndisc_solicit(), probably) if the source is
Agreed, the code already does this, per the RFC.

> optimistic address, but... I'm not sure so far if it is appropriate
> from design POV. The ndisc_send_ns() nor ndisc_solicit() is not about
> our current neigh state machine, at all.
> 
Thats true, but I'm not sure how we can avoid that.

> I do not think we should copy neighbor information from (one of)
> default routers, but use temporary neigh entry (or neigh in new state)
> for such datagrams in stead.  We should aware that:
> 
Not sure how that is different from what I'm proposing.  a neighbor entry that
maps a given host on the current subnet to the MAC of the default router, that
then gets flushed when DAD completes is temporary, as far as I can see.

>  1) default router's link-layer address may change.
True, but if this changes, all our network connectivity is lost, until the
normal neighbor solicitation process completes anyway.

>  2) we may have more than one default routers.
True, but I would think we could select any of them and this would work.
Granted, we wouldn't use all the default routers in the table as we would with
routed frames, but I'm not sure how we avoid that.

>  3) the default router's link-layer may be invalidated.
> 
yes, but this would be bad for the same reason as (1)

> Anyway, I'm start thinking about CONFIG_IPV6_OPTIMISTIC_DAD to 
> make sure the new code path will not break anything else...
> 
Agreed, I'll add in the config option with my next patch.

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