On 26/03/2015 18:36, Arjen de Korte wrote: > Citeren Steven Barth <cy...@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@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
I know this isn't ideal and I've come in late to this discussion, have you considered using the DHCPv6 functionality in dnsmasq? I have strenuously avoided radvd & odhcpv6 in preference for keeping everything in one place. I shall now return to my cupboard :-)
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
