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