Re: Router advertisements for dynamic IPv6 prefix
On 15/10/20 09:44, Harald Dunkel wrote: On 10/14/20 10:18 AM, Stuart Henderson wrote: On 2020-10-11, Henrik Friedrichsen 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). I am affected by the same problem, even though my provider (Deutsche Telekom) resets the IPv6 prefix only once in a while. Wasn't there some RFC saying that the ISP has to (or should?) route both prefixes til the old prefix expires and that the forcible disconnect is allowed only for hardware failures or something similar? Resetting the prefix every 24h doesn't sound like that. Renumbering may happen for one reason or another (https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum). Me, I think robustness of the network shouldn't depend on prefixes being stable. More specifically, hosts should be able to do better. That's the goal of https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08 Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Router advertisements for dynamic IPv6 prefix
On 15/10/20 08:02, Christian Weisgerber wrote: On 2020-10-14, Fernando Gont wrote: Set the VL to 30', and the PL to 15'. You could even set the VL to 15', and the PL to 7.5', if necessary. How does this influence the lifetime of privacy addresses? It should affect it at all. Temporary (privacy) addresses enforce an upper limit on the Valid and Preferred Lifetimes. As such, as RAs keep being received, the PL and VL would continue being refreshed/extended, until their "cumulative" values hit the VL and PL for temporary addresses, at which point they would no longer be extended/refreshed, and temporary addresses would be regenerated. (With the current default values, the lifetimes for the prefixes are longer than the PL/VL for temporary addresses... so if you do an ifconfig, you'd see the PL/VL of temporary addresses decreasing over time, until they expire. However, if you employ the suggested values for the PL/VL of RAs, what you see is that VL/PL decrease from say, 30'/15', and upon receipt of an RA they are reset to 30'/15, and start decreasing again... until the commulative values reach the VL/PL for temporary addresses (as specified in RFC4941), at which point you'll finally see them decreasing from 30'/15' until they expire). Even with rad(8)'s defaults, I already need to specify an originating non-privacy address for all long-running ssh sessions, otherwise they die when the privacy address they're using is forcefully expired after a week or so. Yep. After all, "privacy addresses" (RFC4941) are temporary. Unfortunately, IPv6 lacks an appropriate API for apps to specify the semantics of the addresses they intend yo use. If such an API was available, one might expect that ssh would signal the OS that it shoudl use stable addresses as opposed to temporary adddresses when establishing new ssh sessions. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Router advertisements for dynamic IPv6 prefix
Hello, On 15/10/20 07:27, Henrik Friedrichsen wrote: Hey, On Wed, Oct 14, 2020 at 02:30:04PM -0300, Fernando Gont wrote: And you may also look at this other one, which has recommendations for CPEs, which in your case accounts for your DHCPv6-PD and RA daemons: https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-05 Looks like it's a problem that's not (easily) solved yet. Agreed. Thanks for the suggestions everyone. I'll reduce the lifetimes to the numbers suggested in the draft and move the reconnect to 5am as suggested by Stuart. Can this cause problems for connections that exceed these lifetimes? No. Because the RAs are expected to refresh the associated timers. (i.e., if you set the Preferred Lifetiem to 15 minteus and the Valid Lifetime to 30, the idea is that hosts might receive one unsolicited RA every, say, 5 minutes... and these RAs would refresh the associated timers and wouldn't let them expire). It seems that at least macOS will assign a new IPv6 address with every advertisement due to privacy extensions. Could you doublecheck? That'd be a bug. I'd hope that existing sockets will remain connected if the advertised prefix doesn't change, but I'm not sure. Indeed. As long as the Prefix doesn't become invalid, the sockets would remain unaffected. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Router advertisements for dynamic IPv6 prefix
On 10/14/20 10:18 AM, Stuart Henderson wrote: On 2020-10-11, Henrik Friedrichsen 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). I am affected by the same problem, even though my provider (Deutsche Telekom) resets the IPv6 prefix only once in a while. Wasn't there some RFC saying that the ISP has to (or should?) route both prefixes til the old prefix expires and that the forcible disconnect is allowed only for hardware failures or something similar? Resetting the prefix every 24h doesn't sound like that. Maybe there are better ISPs available at your site? Another option might be to NAT your internal net. Unlike NAT for IPv4 you could introduce a one-to-one mapping between internal and external IPv6 addresses and port numbers. Regards Harri
Re: Router advertisements for dynamic IPv6 prefix
On 2020-10-14, Fernando Gont wrote: > Set the VL to 30', and the PL to 15'. You could even set the VL to 15', > and the PL to 7.5', if necessary. How does this influence the lifetime of privacy addresses? Even with rad(8)'s defaults, I already need to specify an originating non-privacy address for all long-running ssh sessions, otherwise they die when the privacy address they're using is forcefully expired after a week or so. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Router advertisements for dynamic IPv6 prefix
Hey, On Wed, Oct 14, 2020 at 02:30:04PM -0300, Fernando Gont wrote: > And you may also look at this other one, which has recommendations for CPEs, > which in your case accounts for your DHCPv6-PD and RA daemons: > https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-05 Looks like it's a problem that's not (easily) solved yet. Thanks for the suggestions everyone. I'll reduce the lifetimes to the numbers suggested in the draft and move the reconnect to 5am as suggested by Stuart. Can this cause problems for connections that exceed these lifetimes? It seems that at least macOS will assign a new IPv6 address with every advertisement due to privacy extensions. I'd hope that existing sockets will remain connected if the advertised prefix doesn't change, but I'm not sure.
Re: Router advertisements for dynamic IPv6 prefix
On 11/10/20 12:52, Henrik Friedrichsen 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 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. Set the VL to 30', and the PL to 15'. You could even set the VL to 15', and the PL to 7.5', if necessary. You may want to have a look at this, too: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-04 And you may also look at this other one, which has recommendations for CPEs, which in your case accounts for your DHCPv6-PD and RA daemons: https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-05 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. There's yet another problem you may face: Consider the case where your ISP's CPE router is connected to a local switch on the LAN side, and the CPE router crashes and reboots. The local hosts will not see the "link down" event (since the switch has been "up"), but if your ISP does dynamic prefixes, your CPE is likely to get a new prefix without the CPE router even noticing. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Router advertisements for dynamic IPv6 prefix
Hi, On 14/10/20 05:18, Stuart Henderson wrote: On 2020-10-11, Henrik Friedrichsen 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). That's correct. But I'm trying to push work in this area: see https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08 Section 4.5 of the aforementioned document is what would solve the problem. -- ironically, that's the part of the document that received more push-back from the 6man wg of the IETF. (the mitigations that have so far been agreed-upon by the wg are those in: https://tools.ietf.org/html/draft-ietf-6man-slaac-renum-01) 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. I can implement this https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08#section-4.2 into OPenBSD if you wish. -- it has already been commited to the Linux kernel. 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. Not really. At the end of the day, the threat model is that you trust RAs. You can already do ND cache poisoning, disable routers (by setting the Router Lifetime to zero), insert more specific routes (via Redirects or RIOs), become a DNS man-in-the-middle (via RDNSS), etc., etc., etc. Honoring PIOs with a Valid Lifetime < 2h will not allow the attacker to do anything he/she can already achirve via other mechanisms. (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, Set the VL to no more than 1800 (or even a little less). Then set the preferred lifetime to half of that. That's how I (momentarily) deal with this problem while we solve the problem at the protocol level. - 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, Depending on where you are and the availability of POPs, you may get a horrible RTT (and geo-location). Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Router advertisements for dynamic IPv6 prefix
On 2020-10-11, Henrik Friedrichsen 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,
