[OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
cyrus at openwrt.org
Mon Mar 30 04:57:36 EDT 2015
After thinking it through a bit more, I changed the default behavior to
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?
On 26.03.2015 20:38, Arjen de Korte wrote:
> Citeren Steven Barth <cyrus at openwrt.org>:
>>> This breaks clients that need fixed IPs (in my case, mostly webmail
>> 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
>> 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 at lists.openwrt.org
More information about the openwrt-devel