Dear Maintainer,

I am encountering an issue when adding an IPv6 route within a VRF
context on Debian using ifupdown2. The problem occurs when I attempt to
add an unreachable default route with a specific source address. I
receive an "Invalid source address" error. However, this issue does not
occur with IPv4 routes under similar conditions.

/etc/network/interfaces Configuration:
auto routing
iface routing
      address 127.0.0.1/8
      address ::1/128
      vrf-table 1011

auto dummy0
iface dummy0
      link-type dummy
      pre-up /usr/sbin/ip link add dummy0 type dummy
      post-down /usr/sbin/ip link del dummy0 type dummy
      address 169.254.0.10/32
      address fd6c:3502:f677::10/128
      vrf routing

Steps to Reproduce:
1. Add the IPv6 route in the VRF context: ip -6 route add unreachable
default src fd6c:3502:f677::10 vrf routing
     Result: Error: Invalid source address.

2. Add the IPv4 route in the VRF context: ip route add unreachable
default src 169.254.0.10 vrf routing
     Result: No error, and the routing table is updated correctly:

     # ip route show vrf routing
     unreachable default src 169.254.0.10
     127.0.0.0/8 dev routing proto kernel scope link src 127.0.0.1

3. Adding another dummy interface not in the VRF context:
     auto dummy1
     iface dummy1
         link-type dummy
         pre-up /usr/sbin/ip link add dummy1 type dummy
         post-down /usr/sbin/ip link del dummy1 type dummy
         address fd6c:3502:f677::10/128

4. Retry adding the IPv6 route in the VRF context: ip -6 route add
unreachable default src fd6c:3502:f677::10 vrf routing
     Result: No error, and the routing table is updated correctly:

     # ip -6 route show vrf routing
     ::1 dev routing proto kernel metric 256 pref medium
     fd6c:3502:f677::10 dev dummy0 proto kernel metric 256 pref medium
     fe80::/64 dev dummy0 proto kernel metric 256 pref medium
     multicast ff00::/8 dev dummy0 proto kernel metric 256 pref medium
     unreachable default dev lo src fd6c:3502:f677::10 metric 1024 pref
medium

The issue seems to be related to the source address check being
performed in the default VRF context instead of the specified VRF
context when adding an IPv6 route. This behavior is inconsistent with
the IPv4 routing behavior in a VRF context.

Please let me know if further information is required or if there are
any patches or tests I can perform to assist in resolving this issue.

Best regards,
Tharyrok

Control: tags -1 upstream
to
not

Please report this upstream, there are no patches in Debian so the
behaviour is just what upstream provides.