• David Ahern's avatar
    net/ipv6: Change address check to always take a device argument · 232378e8
    David Ahern authored
    ipv6_chk_addr_and_flags determines if an address is a local address and
    optionally if it is an address on a specific device. For example, it is
    called by ip6_route_info_create to determine if a given gateway address
    is a local address. The address check currently does not consider L3
    domains and as a result does not allow a route to be added in one VRF
    if the nexthop points to an address in a second VRF. e.g.,
    
        $ ip route add 2001:db8:1::/64 vrf r2 via 2001:db8:102::23
        Error: Invalid gateway address.
    
    where 2001:db8:102::23 is an address on an interface in vrf r1.
    
    ipv6_chk_addr_and_flags needs to allow callers to always pass in a device
    with a separate argument to not limit the address to the specific device.
    The device is used used to determine the L3 domain of interest.
    
    To that end add an argument to skip the device check and update callers
    to always pass a device where possible and use the new argument to mean
    any address in the domain.
    
    Update a handful of users of ipv6_chk_addr with a NULL dev argument. This
    patch handles the change to these callers without adding the domain check.
    
    ip6_validate_gw needs to handle 2 cases - one where the device is given
    as part of the nexthop spec and the other where the device is resolved.
    There is at least 1 VRF case where deferring the check to only after
    the route lookup has resolved the device fails with an unintuitive error
    "RTNETLINK answers: No route to host" as opposed to the preferred
    "Error: Gateway can not be a local address." The 'no route to host'
    error is because of the fallback to a full lookup. The check is done
    twice to avoid this error.
    Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
    Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    232378e8
datagram.c 24.7 KB