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: <20070127.004429.96717403.yoshfuji@linux-ipv6.org>
Date:	Sat, 27 Jan 2007 00:44:29 +0900 (JST)
From:	YOSHIFUJI Hideaki / 吉藤英明 
	<yoshfuji@...ux-ipv6.org>
To:	nhorman@...driver.com
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, yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address
 Detection

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

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