[zekica]

It is far away from transparent. Devices behind the router can't know that a change in Public IP happened and won't reconnect active connections.

One example is Apple's APNS and Android's GCM. In IPv4 multiwan network, after the change they won't receive notifications at all for up to 30 minutes. In IPv6, the router can invalidate the old prefix, and publish a new one immediately.

[njibhu]

I think we're talking about a different issue here. MultiWAN does break consumers which do not support reconnecting from a different source IP. But the issue is the same with IPV6, if the prefix changes, the client has to reconnect anyway.

Also, I'm personally not aware of any reliable way of invalidating IPV6 prefixes except waiting for the timeout. (And if it's republishing a RA, devices don't have to listen to it, and the packet might even be lost with an unreliable wifi for example). If I'm wrong here, I'd love to know about it.

[ikiris]

Short lifetime RAs for all of the address spaces are meant to cover this.

[throw0101a]

See also "Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events":

   In scenarios where network configuration information related to IPv6
   prefixes becomes invalid without any explicit and reliable signaling
   of that condition (such as when a Customer Edge router crashes and
   reboots without knowledge of the previously employed prefixes), hosts
   on the local network may continue using stale prefixes for an
   unacceptably long time (on the order of several days), thus resulting
   in connectivity problems.  This document describes this issue and
   discusses operational workarounds that may help to improve network
   robustness.  Additionally, it highlights areas where further work may
   be needed.

* https://datatracker.ietf.org/doc/html/rfc8978