On Wed, Jan 31, 2007 at 01:16:29AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: > In article <[EMAIL PROTECTED]> (at Tue, 30 Jan 2007 08:02:08 -0500), Neil > Horman <[EMAIL PROTECTED]> 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. >
Ok, understood. In summary, we can't simply fill out the neighbor entry for a given host with the address of a default router because 1) Any changes to the router link layer address wont be reflected in that when it (the change) happens, redering the local address unable to communicate until the neighbour entries age out. 2) There may be more than one default router as selected by the routing policy, and we should be able to try those routes if the selected router becomes unavailable It sounds like what we need to do is shim into the route lookup code, and detect there if we need to redirect every packet as they are sent. I think I may have an idea for this. What if we implement the lookup in ip6_dst_lookup_tail. In there we can check if the associated neigh entry for the resolved dst_entry is in a INCOMPLETE or FAILED state, and if the ifaddr associated withe the source address passed in via the flowi struct is in an OPTIMISTIC state. If both conditions are true, we release the dst_entry that we origionally looked up, and instead conduct a second lookup with a newly constructed flowi struct with the dst addr replaced with an all zeros address (which I think should return a gateway, selected as per routing policy). Then we can return that dst entry instead. Since ip6_push_pending frames seems to bulid the ipv6 header using the addresses in the flowi struct passed into ip6_*_dst_lookup from *_sendmsg routines, and the link layer header is built based on the info gathered from the resolved dst_entry (If I'm reading the code right), I think this give us what we want, in that we redirect to a gatweway when we send from an optimistic address, and we select the gateway based on the logic in the route lookup code (ip6_route_output() specifically). I'm trying to implement this right now, and will post a new patch as soon as I have it done. In the meantime, any thoughts would be most appreciated. Regards Neil > --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 - 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
