Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Richard Patterson <[e-mail]>]

On Sat, 23 Feb 2019 at 05:22, Fernando Gont <[e-mail]> wrote:

> * As per RFC4862, it turns out that you cannot remove a stale prefix vy
> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards,
> not even the CPEs can (even if they wanted to) do something to fix the
> problem.


The Valid Lifetime cannot be zeroed or shortened below 2 hours, but
the Preferred Lifetime can.  So we can't invalidate the prefix, but we
can deprecate it so it's not used for new outbound sessions.   This is
what we've implemented in our CPEs, after an unavoidable change in
prefix, and it seems to have mitigated (or reduced the impact of) the
issue.

RFC4862 §5.5.3

e)  If the advertised prefix is equal to the prefix of an address
      configured by stateless autoconfiguration in the list, the
      preferred lifetime of the address is reset to the Preferred
      Lifetime in the received advertisement.

....

      Note that the preferred lifetime of the corresponding address is
      always reset to the Preferred Lifetime in the received Prefix
      Information option, regardless of whether the valid lifetime is
      also reset or ignored.  The difference comes from the fact that
      the possible attack for the preferred lifetime is relatively
      minor.  Additionally, it is even undesirable to ignore the
      preferred lifetime when a valid administrator wants to deprecate a
      particular address by sending a short preferred lifetime (and the
      valid lifetime is ignored by accident).