[OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
Arjen de Korte
arjen+openwrt at de-korte.org
Thu Mar 26 14:36:49 EDT 2015
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
> 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
>>> 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
>> 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
More information about the openwrt-devel