Thomas Graf wrote: > * Ville Nuorvala <[EMAIL PROTECTED]> 2006-08-09 11:36 >> Of the three original route lookup functions (ip6_route_input, >> ip6_route_output and rt6_lookup), rt6_lookup was the only one that was >> allowed to produce a NULL entry. Of these three rt6_lookup was also the >> only one not actually being used for routing. >> >> The function that absolutely requires ip6_null_entry is ip6_route_input. > > It would mean to change the logic of handling route errors like in the > IPv4 path and not handle them in .input/.output. Instead of a dst we'd > return a valid dst or a ERR_PTR() which would force the caller to take > appropriate actions such as updating statistics and sending ICMPs.
Ok, it might require quite big changes to the existing code, but if someone is willing to take a look at it I wouldn't be against it :-) >> There is also one more issue with ip6_null_entry: previously it has >> always been the result of an unsuccessful route lookup, now it can also >> be the result of a successful application of a FR_ACT_UNREACHABLE policy >> rule. From a networking point of view these two cases should IMO be >> considered equivalent and should therefore trigger the same response. >> This will however not be true if NULL (or an error code) is the result >> of an unsuccessful route lookup. > > Both would simply result in a -ENETUNREACHABLE. You know, I'm starting to think we could perhaps get rid of ip6_null_entry altogether. I at least don't really see any good reason to keep it after such changes. This would apply even more strongly to the new ip6_prohibit_entry and ip6_blk_hole_entry as they don't even serve as routing table dummy entries. Regards, Ville - 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
