Steven Barth <cy...@openwrt.org> writes: >> >> The problem is that you try to be "smart" by abusing the ability to set >> the address preferred lifetime lower than T1. I don't dispute that it >> is allowed by the RFC, but it is definitely not recommended. > There is no formal requirement (not even a SHOULD) that says > otherwise.
Agreed. But as usual, balancing on the edge of what you are allowed to do will give you more trouble than playing it safe. The recommended values are clearly stated. It's very likely that some client implementation didn't anticipate servers not following the recommendation. Which of course is their fault. Still your problem, though. > The recommendation made is usually based on the basis that > DHCPv6 is your only source of addresses which it isn't for us. What makes you believe that? >> Based on this, it should not come as an surprise that a number of >> clients start behaving erratically if you set T1 much higher than the >> preferred lifetime. Don't do that. It causes problems. >> >> You can of course continue to argue that not honouring T1 is a bug, but >> that will not fix any of the failing clients. > Now we know that they actually don't. The clients behave well, that > seemed to be a misunderstanding. > The OP just tried with a version of our server which had a buggy T1 > calculation. Ah, OK. That sounds better. >> I have a real hard time understanding what makes a DHCPv6 IA_NA address >> any different from a RA based address wrt lifetimes. If you choose to >> provide both RA and DHCPv6 service to the lan clients using the same >> assigned prefix, then the lifetimes should be kept the same as well. >> Choosing between DHCPv6 and SLAAC is really up to the clients in this >> case. If you want to prefer one or the other from the server side, then >> I don't see any reason to provide both. > The big difference is that as a router I can send RAs whenever I want > and clients will react immediately. Sure. This is a very good argument for using only RAs in an environment where the address lifetimes cannot be trusted. > Most clients however do not > support the same when doing DHCP and only do dumb polling based on > T1/T2. So I have to be "smart" in some way to workaround. But how does it help? You are still not able to assign a new address to any DHCPv6 (only) client until T1 expires. And the SLAAC+DHCPv6 clients get a new and usable address immediately whether or not the old DHCPv6 address is deprecated. Yes, I can see that it helps clients using both DHCPv6 and SLAAC with their source address selection, simply by always avoiding DHCPv6 assigned addresses. But this policy should be up to the client, not the router. If they don't want to use the DHCPv6 address then they shouldn't ask for it. If they do want to use it, then you shouldn't prevent them from doing so. > I would > gladly get rid of DHCPv6 after all for clients but there is no good > way to collect hostnames otherwise. Huh? How can you collect a hostname from DHCPv6? You get a DUID and that's all, isn't it? Ah, I see that you use DHCPV6_OPT_FQDN aka OPTION_CLIENT_FQDN. OK, so you want all the good parts from both DHCPv6 and SLAAC without sacrificing anything. Understandable :-) I'm still not convinced that it is a good idea to assign immedietaly deprecated addresses. The 1 second change of preferred source address every T1 seconds is likely to break stuff far more times than an occasional wan link failover. Applications tend to associate sessions with IP addresses, grouping tcp connections from the same address into a session. Load balancers try hard to redirect you to the same server, but don't necessarily understand that you may use several different source addresses. Regularily switching the preferred source address like that is bad. >> And wrt the fear of sudden renumbering: The upstrem source, where you get >> these addresses assigned, will include lifetimes. Why don't you reuse >> those (after some basic sanitation)? If the problem is that the upstream >> lies to you, then I suggest fixing that instead. > We do propagate them as-is through RAs. However imagine manual or > automatic failover to a different ISP / connection or simply an ISP > doing 6rd where your IPv6 prefix is mapped from your IPv4-address and > th connection flaps and you get a different v4-address or a > VPN-connection being brought up or down. In all these scenarios there > needs to be a way to tell clients to stop using an address for global > traffic near instantaneously otherwise they might lose connectivity. Those use cases are broken by design. Don't get me started on 6rd :-) But they should of course be supported as smoothly as possible despite the inherent flaws. One option would be prefix translation, possibly with ULA addresses on the lan. Has this been considered? It would avoid the need to renumber the lan at all. Please also note that the use cases break connectivity whether you have an OpenWRT router in the path or not. ISPs will hopefully realize that and avoid such solutions. The ISP failover is of course still something that might happen. But that won't be a common coonfiguration, will it? Could the deprecated DHCPv6 assigned addresses depend on such an uplink config? Chances are high that you never will experience renumbering if you have a single wan uplink from an ISP using DHCPv6-PD. Bjørn _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
