Comment # 4 on bug 1201263 from Marius Tomaschewski

Works fine for me:

# cat ifcfg-lab50
STARTMODE='auto'
BOOTPROTO='static'
IPADDRv4='172.22.50.107/24'
IPADDRv6='2001:db8:514f:5000::107/64'
ZONE=trusted

# cat ifroute-lab50 
default 172.22.50.1
2620:10e:6024:f004::/64 fe80::1 - lab50 src 2001:db8:514f:5000::107

# wicked show-config lab50
[...]
  <ipv6:static>
    <address>
      <local>2001:db8:514f:5000::107/64</local>
    </address>
    <route>
      <destination>2620:10e:6024:f004::/64</destination>
      <nexthop>
        <gateway>fe80::2ec8:1bff:febc:400</gateway>
      </nexthop>
      <pref-source>2001:db8:514f:5000::107</pref-source>
    </route>
  </ipv6:static>
[...]

# ifup lab50 
lab50           up

# ip a s dev lab50
2: lab50: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
group default qlen 10
00
    link/ether 66:52:54:50:01:07 brd ff:ff:ff:ff:ff:ff
    altname enp1s0
    inet 172.22.50.107/24 brd 172.22.50.255 scope global lab50
       valid_lft forever preferred_lft forever
    inet6 2001:db8:514f:5000::107/64 scope global
       valid_lft forever preferred_lft forever
    inet6 2001:db8:514f:5000:894a:9c44:347:1a6c/64 scope global temporary
dynamic
       valid_lft 4387sec preferred_lft 3487sec
    inet6 2001:db8:514f:5000:6452:54ff:fe50:107/64 scope global dynamic
mngtmpaddr
       valid_lft 4387sec preferred_lft 3487sec
    inet6 fe80::6452:54ff:fe50:107/64 scope link
       valid_lft forever preferred_lft forever

# ip -6 r s dev lab50
2001:db8:514f:5000::/64 proto kernel metric 256 pref medium
2620:10e:6024:f004::/64 via fe80::1 src 2001:db8:514f:5000::107 metric 1024
pref medium
fe80::/64 proto kernel metric 256 pref medium
default via fe80::2ec8:1bff:febc:400 proto ra metric 1024 expires 1718sec pref
medium

The problem is most probably: You're using an EUI64 **autoconf** (dynamic
mngtmpaddr) IP address (2620:10e:6026:d0a6:92b1:1cff:fe69:b05b) as source
which is created by the host at router RA receive time (not processed when
e.g. forwarding=1 and accept_ra<=1 or autoconf=0 or ... are set) managed 
(e.g. deleted to enforce duplicate address detection) by the kernel and
most probably not applied (yet) while the _static_ addresses + routes are
applied by wicked. (As already noticed in comment 2).

When the address is not applied to the interface, the creation of the
static route fails (rejected by the kernel).

Wicked does not make any attempts to syncronize dynamic and static address
and route configuration mechanisms and will not make any attempts to do this.
The static, autoconf and dhcp mechanisms are fully independent to each other.

==> Use a static source address instead.
(Set IPADDR6=2620:10e:6026:d0a6:92b1:1cff:fe69:b05b/64 as static IP...)

(In reply to Jason Mader from comment #3)
> This is the best I can come up with, but there's got to be a better way,

You can use a static service and POST_UP_SCRIPT="systemd:eth0-routes.service"
or POST_UP_SCRIPT="systemd:myroutes@.service" where wicked will fill out the
eth0 in the template -> myroutes@eth0.service, so the route is applied at the
end of all (explicit + implicit) "ifup" runs.

But no, the time when the RA arrives is "undefined". Depending on the router,
the router may also ignore RS (RA requests) for a while to protect itself
from clients asking too often... (MinDelayBetweenRAs of 3 sec) and the like.

So this will always remain an unreliable setup and not a bug, thus I've to
resolve it as invalid.