Citeren Steven Barth <cy...@openwrt.org>:
This breaks clients that need fixed IPs (in my case, mostly webmail
clients).
I wonder why they are so sensitive to source-address changes since
their old address is still valid and not deprecated so there is no
need to switch.
Webmail clients usually don't keep a connection open to the server,
hence every connection is a new one. The webmail server only sees the
source IP, so even if the DHCPv6 address is still valid for the
client, a re-login is needed because the source IP changes.
I would gladly send the DHCPv6 address with 0 preferred lifetime but
Apple's DHCPv6 client has issues and discard addresses therefore the
1.
I could create a patch for this, but for now I consider this a
regression, rather than a feature that needs to be configurable. I
fail to understand the reasons why this change, which deliberately
breaks the outgoing addresses (even if only momentarily) was
introduced.
The reason for this change is that no host seems to support DHCPv6
reconfiguration so we cannot update clients whenever we see fit
(e.g. ISP goes down / is switched / designates a different PD).
Which means that in absence of that in worst case client
connectivity is lost for T1 seconds.
I don't see how this fixes things then. When ra_management is '2'
you'd still run into the exact same problem (just without the fallback
to SLAAC). In contrast, if the ip6prefix is configured statically (as
in my case), there is no chance this will ever happen, since changes
will never happen unexpectedly.
I think this would be much better fixed by making the client renew its
lease more frequently (by lowering the valid and preferred lifetimes).
The present fix will also not work for anthing else than a /64.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel