After thinking it through a bit more, I changed the default behavior to
the following:
The preferred lifetime is now as given by the ISP, however the DHCPv6
server will only hand out the address with the highest preferred
lifetime (= the ULA unless disabled).
Thus flash renumbering should still work (since only the ULA-address
cannot be changed immediately).
Is that okay with you or do you see any other issues?
Cheers,
Steven
On 26.03.2015 20:38, Arjen de Korte wrote:
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
