On Tue, Jan 30, 2007 at 07:25:36AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Mon, 29 Jan 2007 16:30:13 -0500), Neil 
> Horman <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to