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

[Arjen de Korte]

Citeren Steven Barth <cyrus at openwrt.org>:

>> In that case, I have a lot of bug reports to file, because none of  
>> the DHCPv6 clients I tried were happy with preferred lifetimes of 1  
>> second on their leases (which includes Windows 7, 8.1 and openSUSE  
>> 13.2).
> Sorry, I cannot confirm this. I just tried it with both Windows 8.1  
> and Debian testing (w/ network-manager) both didn't react strangely  
> or tried to renew the lease every second. Connectivity was okay.

The constant refreshes were only with the first patch that introduced  
this behavior (sorry for the confusion), with the current odhcpd  
clients will indeed not attempt to renew continuously. But they won't  
be able to use the address provided by DHCPv6 for outgoing connections  
either. They will use the address from SLAAC most of the time, but at  
the time the lease is renewed, switch to the DHCPv6 address and back  
again to SLAAC 1 second later. Although the window of opportunity for  
this to happen may seem to be small, it is enough for webmail clients  
that happen to check for the source IP to require logging in again  
when this happens (twice in a row actually, as the source IP changes  
twice).

>>> Besides you also get addresses with higher values for preferred  
>>> lifetime using RAs so you always have usable IPv6 addresses, so if  
>>> your network-manager / OS behaves sanely you shouldn't have any  
>>> issues.
>>
>> They don't have an issue with IPv6 connectivity, its the source  
>> address that is used *I* have a problem with.
> Unless you disable RAs there is no way to tell the client which  
> source address to pick anyway. If some OS use the DHCPv6 addresses  
> by default then thats by chance.

True. But most OSes will pick either one and will stick to that.  
Windows seems to favor DHCPv6, while Linux by defaults selects SLAAC  
then. Both are OK with me. The problem I have with the current  
implementation in odhcpd, is that systems favoring DHCPv6 will switch  
between the two.

>>> A work-around for this is setting:
>>> option ra_management 0
>>> in the lan-section of /etc/config/dhcp which will cause most  
>>> clients to not use DHCPv6 and rely on RAs only.
>>
>> This is not an option, as the whole purpose of using DHCPv6 for  
>> address configuration is to give clients a fixed IPv6 address. This  
>> has worked correctly since Barrier Breaker was released, I see no  
>> reason why it no longer should.
> That still works. The client will just not use the address for  
> outgoing traffic.

This breaks clients that need fixed IPs (in my case, mostly webmail clients).

> I'm fine with making this configurable (current behavior as default)  
> though and would welcome a patch for this. I could put it on my todo  
> but don't really know when I have the time to deal with this.

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