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.
The recommendation made is usually based on the basis that DHCPv6 is
your only source of addresses which it isn't for us.
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.
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. 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. I would gladly get rid of
DHCPv6 after all for clients but there is no good way to collect
hostnames otherwise.
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.
Cheers,
Steven
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
