IPv6: ifconfig & rad messages fight disabling routes

Short form:
  I'm using rad to update local machines with the IPv6 address prefix
currently assigned by Verizon. It runs on my firewall/external router.
The router advertisement destructively changes the route and interface
of an address on that machine.

dhcpcd gets <prefix>/56 from Verizon fiber service.
manually ifconfig interface1 inet6 <prefix>::9/56
netstat -rn -f inet6 shows
      <prefix/56>:: and <prefix>::9 routed via interface1
everything works.
rad message sent out from interface1:
      <prefix>/56 valid 1000 preferred 10000
netstat now shows
      <prefix/56> routed via lo0
      <prefix>::9 is still on interface1
That address is now (mostly) unusable
Other addresses assigned to that interface work.

Is this expected?
Possible workarounds:
  blocking loopback of router advertisements (preferred)
  dhcp6 server for guest machines & fixed assignments
      for servers/test machine (inconvenient or worse)
      Monitor prefix for changes - hope that's not often

I have to assume the mechanism which processes RAs follows the
RFC and uses the link level address of the sender.
I hypothesize it sees lo0 as the sender
and Bad Things happen.

ding:236$ doas ifconfig cnmac0 inet6 2600:4040:xxxx:xxxx:7 prefixlen 56
ding:237$ netstat -rn -f inet6

2600:4040:xxxx:xxxx::/56 2600:4040:xxxx:xxx::7          UCn       
0        0     -     4 cnmac0
2600:4040:xxxx:xxxx::7 f0:9f:c2:cf:9e:e7              UHLl      
0        0     -     1 cnmac0
------- rad message

22:06:10.869060 fe80::f29f:c2ff:fecf:9ee7 > ff02::1: icmp6: router
advertisement
  (chlim=64, pref=medium, router_ltime=1800, reachable_time=0,
retrans_time=0)
  (prefix info: LA valid_ltime=7200, preferred_ltime=7200,
prefix=2600:4040:xxxx:xxx::/56)
  (prefix info: LA valid_ltime=2592000, preferred_ltime=604800,
prefix=fde3:3eec:4f3c:29dc::/64)
  (rdnss: lifetime=2000s, addr=fde3:3eec:4f3c:29dc::7)(dnssl:
opt_len=3) [icmp6 cksum ok] (len 128, hlim 255)

2600:4040:xxxx:xxx::/56            ::1 UGR        0      718 32768    56
lo0
2600:4040:xxxx:xxx::7              f0:9f:c2:cf:9e:e7 UHLl       0      
16     -     1 cnmac0


There's a off-by-4 in RAD display in tcpdump. Will post that later.
I added the extra detail in that as well - will post if anyone things
it's useful.
 geoff steckel