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]

Date:	Fri, 26 Jan 2007 14:03:37 -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 Sat, Jan 27, 2007 at 12:44:29AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <20070126142730.GA15916@...reliant.homelinux.net> (at Fri, 26 Jan 2007 09:27:30 -0500), Neil Horman <nhorman@...driver.com> says:
> 
> > I'm looking for it at the moment, but I too had assumed that redirecting the
> > outgoing packet to the default router would happen automatically within the
> > routing code as a result of not having a completed neighbor entry available.
> > Since I've modified ndisc_send_ns such that we will never send Neighbor
> > solicitations from an optimistic address, as per section 3.2, we'll never get a
> > completed neightbor entry while the address is optimistic.  If thats not the
> > case, I'd welcome some suggestions on how to implement this (given that I'm not
> > overly familiar with the code right now).  From what I see, I think the routing
> > code will select the default route when rti6_nexthop is null during route
> > selection, which it will be if the neighbor entry doesn't get resolved.  Not
> > 100% sure though.  Let me know what you think.
> 
> (Now I remember that I hit similar issue before when I once
> tried to implement this....)
> 
> Well... no, you cannot assume that routing code solves this issue.
> This is not so trivial, and I am not aware clean solution yet...
> 
> On reason of this issue is because the source address may not be
> probided by user, and the source address selection will be done
> after looking up routing table.
> 
> One possibiliy is to solve by rt->rt6i_nexthop->output(),
> but I guess we will hit some race condition.
> 
> Hmm...
> 
Is this perhaps something we can do in ip6_output2?  We can test the interface
flags there and if the interface is optimistic, we can lookup the default route
(perhaps via rt6_lookup, using the unspecified address for the daddr), and then
replace skb->dst with the dst_entry retrieved from the lookup, which should give
us the proper mac header construction starting in ip6_output_finish.

What do you think?
Neil

-
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