Hi,
On 14/10/20 05:18, Stuart Henderson wrote:
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).
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
