[OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
bjorn at mork.no
Fri Mar 27 07:33:23 EDT 2015
Steven Barth <cyrus at openwrt.org> writes:
> If the DHCPv6 server sends values for T1 and / or T2 which are valid
> the client must honor them and not try to be "smart" about lifetimes
> of addresses.
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.
Quoting from RFC3315:
22.4. Identity Association for Non-temporary Addresses Option
The server selects the T1 and T2 times to allow the client to extend
the lifetimes of any addresses in the IA_NA before the lifetimes
expire, even if the server is unavailable for some short period of
time. Recommended values for T1 and T2 are .5 and .8 times the
shortest preferred lifetime of the addresses in the IA that the
server is willing to extend, respectively.
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.
> in the lan-section of /etc/config/dhcp which will cause most clients
> to not use DHCPv6 and rely on RAs only.
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.
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.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel