On 2020-10-11, Henrik Friedrichsen <hen...@diff.cc> wrote: > Hey, > > my ISP provides connectivity via PPPoE. An IPv6 prefix is handed out via > DHCPv6 PD, which my OpenBSD gateway passes on to clients with the help > of router advertisements using rad. > > This works fine until the ISP disconnects me after 24h (force disconnect > on ISP side). The gateway receives a new prefix via prefix delegation > and rad advertises it in the local network. So far so good. However, as
The IPv6 protocol does not have the necessary features to reliably cope with this setup. (Neither does IPv4 for that matter). > the old stale prefix is still valid according to the advertised > lifetime, clients keep their stale IPv6 addresses. I have already > decreased the lifetimes in rad to <24h, which mitigates the problem > somewhat, but it's not perfect. For instance, some clients may receive > the advertisement 1h before the disconnect but since the lifetimes are > static, the client will assume a validity of ~23h (as set), although the > prefix will expire in 1h. > > After some research I found out that other router advertisement daemons, > e.g. radvd, have settings to alleviate this: > > - DeprecatePrefix will advertise a 0 plt and 2h vlt for the stale prefix > - DecrementLifetimes decrements the lifetimes by the number of seconds > since the last advertisement These don't really work well either. DeprecatePrefix is only sent once so a device that is asleep will miss it; also it is still advertising the prefix as *valid* just not preferred. DecrementLifetimes might work to some extent (but will need to be synchronized with the vltime from the ISP) but hosts are required to ignore this if less than 7200 seconds (2h) unless the new vltime is *higher* than the current one. If there *was* some magic RA to say "immediately stop using the prefix you're currently using", that would be quite a DoS risk. (Remember they are not authenticated, and sent unsolicited so must be listened for all the time. Compare with v4; also not auth'd but at least they're only sent in response to a client query, so an attacker wouldn't be able to kill connectivity for everyone in one go). If you can't get a stable v6 prefix from your ISP and no better ISP is available I would suggest either of: - take the same approach you would have to use in IPv4 if your ISP gave you a routed range that changed every reconnect: use a private prefix (rfc1918 for v4, ULA for v6) and NAT to the current range, - set 7200 vltime, and force an ISP reconnect when nobody is using the network, - ignore the ISP's pseudo-IPv6 setup and get your v6 connectivity via tunnel to HE, as long as you don't need to reach hosts single-homed behind Cogent, - disable v6 towards clients,
