On Fri, 2009-08-07 at 17:45 +0200, Erik Nordmark wrote: > Sebastien Roy wrote: > > >> ip_ndp.c: You've removed the special handling if IP_ADDR_LEN around line > >> 3682. With this change how does a point-to-multipoint device driver tell > >> the nexthop that the packet should be sent to? Perhaps 6to4 tunnels > >> don't need this because the nexthop is always extracted from the IPv6 > >> destination address. But I don't see how other point-to-multipoint > >> devices (IP over X.25, Fibrechannel, etc) can work with this removed. > > > > DISCUSS: 6to4 tunnels would also benefit from this point-to-multipoint > > mechanism, but it currently can't because the GLDv3 framework can't > > currently cope with processing a DL_UNITDATA_REQ that has a destination > > address of a different length than the length of the link's registered > > link-layer address. This could be made to work in the future for 6to4. > > What is the length for 6to4? Something different than 4 + sap?
It's exactly 4 + sap. The issue is that the IP interface above the 6to4 link is an IPv6 interface, and those IP addresses (those that would be included in this point-to-multipoint hack) are 16 bytes, and not 4 as GLDv3 expects in messages for such links. > > For other types of links, I can bring that code back, but it won't work > > as-is. The reason is that this will inhibit tunnel links from > > negotiating proper fast-path headers. What I can do is bring the code > > back, but only for link types that are not DL_IPV4, DL_IPV6, and > > DL_6TO4. Does that make sense to you? > > I think that makes sense. Okay, I will do that. ACCEPT > I also haven't looked if you have the same check for IPv6 > (IPV6_ADDR_LEN). We used to have such code, but perhaps somebody else > removed that. I believe Surya removed it a while ago. I'll have to add it back in for this to make sense, obviously. Thanks, -Seb
