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: <20070131.011629.84005028.yoshfuji@linux-ipv6.org>
Date:	Wed, 31 Jan 2007 01:16: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 <20070130130208.GA3723@...reliant.homelinux.net> (at Tue, 30 Jan 2007 08:02:08 -0500), Neil Horman <nhorman@...driver.com> says:

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

No, router may update its link-layer address by NA with Override flag set.
In that case, we must use new link-layer for subsequent packets from
our opportunistic address duing DAD.

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

I mean, if the status of the selected default router has changed or 
has been deleted, we should try other router, at least.

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

We MUST take this into account.

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