Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Ted Lemon <[e-mail]>]

Indeed, this would also not actually solve the problem.   At present, the ISPs are doing something that is out of spec and causes problems.   If we “fix” this by accommodating what they do, does that help, or does it just encourage them to continue doing it?

What should be happening on the host with a prefix that’s deprecated is that TCP connections should be timing out.   This doesn’t take very long.   And if there is a new prefix being advertised on the link, that address should have a valid lifetime newer than the old prefix, meaning that the next TCP connection should come from that new prefix, not the old one.

I think Fernando’s plan to shorten some timers makes sense, but shortening the minimum really doesn’t—it just opens up an opportunity for an easy DoS, since I can now just send out death packets to the local network and break everything all at once.

If you Really Really want to be able to have the routers send out RAs that deprecate the default route, and, as Mark is saying here, to upgrade millions or perhaps billions of hosts, why not ask for something that’s a real improvement?

First of all, fix CPEs so that they definitely support clean deprecation of prefixes using PD.  Second, fix RA so that it’s non-repudiable by a device that doesn’t have the secret key.

SEND does this, sort of.  Nobody uses SEND because it tries to solve a too-big problem and does it using obsolete technology.   But the basic idea is good: include a public key in every RA that can be used to validate that the RA was signed with the corresponding private key. 

When another RA arrives, see if it was signed with the same key.   If so, it came from the same router, and can be trusted to update whatever information that router sent, including flash-deprecating a prefix.   If not, ignore it.

This avoids the problem of validating which RAs are good RAs: you just do what you’re doing now with RAs.  But if an RA goes out that supersedes a previous RA, you don’t let it supersede it unless it’s provably from the same source.  I’m currently doing something similar with DNSSD Service Registration Protocol, using ECDSA, and the implementation has a small enough footprint to run on IoT devices.  Something like this would make SEND/CGA a bit more useful, I think.

Note that this would not be required for hosts, and hence would not create unwanted privacy properties for host addresses.   Also, when used e.g. in a hotspot setting where it might be desirable to vary addresses, that’s okay, because a new key can be generated regularly as long as the prefix on the local link doesn’t need to be deprecated.