IPv6 RA SLAAC prefix lifetime

Question

From what I understand, there is no way to change the prefix lifetime once hosts install the prefix. If I shorten the valid/preferred timer for a prefix, it has no effect on hosts already using the prefix with SLAAC until the host tries to renew the address? Unlike RA lifetime (for purpose of default gateway), RA lifetime gets extended upon receiving a RA message. Can someone point me to the RFC section for prefix/default-gateway renewal process?

What I want to achieve is to delete a SLAAC prefix through the network before the valid lifetime expires, is there any way to do it? Either router side or access/host side. I tested on IOS 12.4 even shut/no shut an interface won't remove the prefix learned from SLAAC. I can configure another prefix but I don't want hosts to continue using the old one.

I think I saw somewhere RA with a prefix lifetime=0 can mark a prefix for deletion, is this an RFC or just some vendor specific thing? If there is such a thing, how can I force this message to be regenerated in case some hosts missed the first one?

What is the guideline for configuring RA/prefix lifetime? How short can it be? HA design considerations?

Thanks

Answer 1

For prefix assignment using SLAAC (RFC 4862), the lifetimes are fully governed by the description in section 5.5.3. Router Advertisement Processing. To simplify:

1. If the prefix is not yet used, you can use it with the preferred and valid lifetimes that are signaled, no restrictions.
2. If the prefix is already used, update the preferred lifetime with the signaled value, no restrictions. For the valid lifetime the signaled valid lifetime (signaled) must be compared to the current remaining valid lifetime (remaining).
3. If remaining<signaled: just update it, no restrictions.
4. If signaled<remaining: Beware, this could be a DOS attack, only update this if signaled > 2h (or the source is authenticated). 2h should be enough time to allow a valid RA with correct timers to appear.

So in short, when it comes to deprecation you can make sure that a SLAAC address is no longer used for new connections (set preferred lifetime to 0) but you cannot kill ongoing sessions as long as the valid lifetime is running. Of course various implementations might provide administrative interfaces to forcefully remove an address, but that's outside of RFC scope.

As far as the RFC goes, you can put the preferred lifetime to anything, though 0 does not make sense. The valid lifetime cannot be 0 except when deprecating. Preferred must always be bigger than valid. So what time you put it is your own choice and depends on your use case.

What RFC 4862 states about prefix lifetimes has nothing to do with SLAAC, this is pure about how long on-link prefixes are valid to perform neighbor discovery.

Answer 2

RFC4861 section 6.3.4. Processing Received Router Advertisements: - If the prefix is already present in the host's Prefix List as the result of a previously received advertisement, reset its invalidation timer to the Valid Lifetime value in the Prefix Information option. If the new Lifetime value is zero, time-out the prefix immediately (see Section 6.3.5).

However, prefix is not forgotten immediately by host, at least if the implementation is robust and follows RFC4862. There are additional rules for prefix lifetime handling: See RFC4862 section 5.5.3. Router Advertisement Processing, point e) more specific. There is 2 hours "safety" period before prefix discard.

When selecting the lifetimes, keep Preferred lifetime <= Valid lifetime!