RTA_SRC is just a hint for the address selection algo used by the kernel. It doesn't make the route any more special.
From the example you posted, it sure looks to me like a default route?

Can you post a real world example, maybe with your routes and dhcpcd's default route and highlight which one is from dhcpcd please?

RTA_SRC is just a hint for the address selection algo used by the kernel. It doesn't make the route any more special. From the example you posted, it sure looks to me like a default route?

I believe the "hint" is RTA_PREFSRC. RTA_SRC is part of the route itself, and is generally ::0/0 (or "default" in ip route lingo)

Can you post a real world example, maybe with your routes and dhcpcd's default route and highlight which one is from dhcpcd please?

# Adds a traditional default route, RTA_SRC is ::0/0
$ ip -6 route add default via <LLADDR> dev <DEV>
# Adds a source-based default route, RTA_SRC is <SUBNET>
$ ip -6 route add default from <SUBNET> via <LLADDR> dev <DEV>
# Adds traditional default route with "hint" (RTA_SRC is ::0/0, RTA_PREFSRC is <GADDR>)
$ ip -6 route add default via <LLADDR> dev <DEV> src <GADDR>

# To show routes under dhcpcd on vlan1 in a test network (w/ src route added):
$ ip -6 route show default # <- will show both default routes
default from fd55:5555:5555:c020::/60 via fe80::5375:19b4:8204:362a dev vlan1 metric 99 pref medium
default via fe80::5375:19b4:8204:362a dev vlan1 proto ra metric 1000 pref medium
$ ip -6 route show default from default # <- will show only the non-source default route
default via fe80::5375:19b4:8204:362a dev vlan1 proto ra metric 1000 pref medium

Source-based routing is basically the same as adding an ip rule from <SUBNET>... but makes it possible to scope the default routes in the "main" table (since dhcpcd doesn't currently support using routing tables -- for policy routing).

Let me know if that doesn't answer your question...
S.

PS As an aside, I just tested with ip route add default via <LLADDR> dev <DEV> src <GADDR> metric <NOT-DEAULT-ROUTE-METRIC> -- and then deleted it -- and dhcpcd also removed it's internal default route... so ideally it's internal table should include the route metric in it's "primary key" (as the linux kernel does), so that routes that it doesn't manage don't cause problems... but that's another kind of bug :)

Thanks for the summary. Can we put part of the in a comment in the code please just to clarify it? The one liner is not verbose enough as to why we are ignoring it.

@rsmarples Just curious, I fixed the two issues from your review a couple weeks ago, was there something else you wanted me to change?

Sorry, I've been distracted of late.