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

[Neil Horman <nhorman@tuxdriver.com>]

On Thu, Feb 08, 2007 at 06:52:06AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <20070207205503.GB20804@hmsreliant.homelinux.net> (at Wed, 7 Feb 2007 15:55:03 -0500), Neil Horman <nhorman@tuxdriver.com> says:
> 
> > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> > index 7b7bd44..8a1ea96 100644
> > --- a/net/ipv6/ip6_output.c
> > +++ b/net/ipv6/ip6_output.c
> > @@ -859,6 +859,34 @@ static int ip6_dst_lookup_tail(struct sock *sk,
> >  		err = ipv6_get_saddr(*dst, &fl->fl6_dst, &fl->fl6_src);
> >  		if (err)
> >  			goto out_err_release;
> > +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> > +		/*
> > +		 * Here if the dst entry we've looked up 
> > +		 * has a neighbour entry that is in the INCOMPLETE
> > +		 * state and the src address from the flow is 
> > +		 * marked as OPTIMISTIC, we release the found 
> > +		 * dst entry and replace it instead with the 
> > +		 * dst entry of the nexthop router
> > +		 */
> > +		if (!((*dst)->neighbour->nud_state & NUD_VALID)) {
> > +			struct inet6_ifaddr *ifp;
> > +			struct flowi fl_gw;
> > +			ifp = ipv6_get_ifaddr(&fl->fl6_src, (*dst)->dev, 1);
> > +
> > +			if (ifp && ifp->flags & IFA_F_OPTIMISTIC) {
> > +				/*
> > +				 * We need to get the dst entry for the 
> > +				 * default router instead
> > +				 */
> > +				dst_release(*dst);
> > +				memcpy(&fl_gw, fl, sizeof(struct flowi));
> > +				memset(&fl_gw.fl6_dst, 0, sizeof(struct in6_addr));
> > +				*dst = ip6_route_output(sk, &fl_gw);
> > +				if ((err = (*dst)->error))
> > +					goto out_err_release;				
> > +			}
> > +		}
> > +#endif
> >  	}
> >  
> >  	return 0;
> 
> Sorry, this is still not correct if the source address is already
> specified.  I think they should be placed just betwee laste "}" and
> "return 0;", no?
> 
I think moving it would be no more correct or incorrect, but it would be less
efficient.  ipv6_addr_any will only return true if the source address is the
anycast address (::).  That address will never be optimistic.  So we could
certainly move  the optimistic code to where you indicate, but then we'd be
checking the code for optimistic address without any need?  Or is there
something I'm missing?

> 
> I still have a question.  Now, who will install the kernel route for
> the incoming packet?  Can we get packet for our unicast address during
> optimistic DAD period?
> 
Not sure what you're getting at here.  RFC 4429 makes no distinction between
optimistic and non-optimistic packets for recevied frames, so routes for
received packets will be added by the same code that does it currently (which I
admittedly haven't looked into to closely).  Packets received for our unicast
address (even if it is optimistic) are handled just as any other packet is (same
as it is for TENTATIVE addresses, as I understand it). 

Regards
Neil

> --yoshfuji
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html