[OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Steven Barth]

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 <cyrus at 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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel