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

[Mark Smith <[e-mail]>]

On Mon., 25 Feb. 2019, 21:33 Richard Patterson, <[e-mail]>
wrote:

> 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.
>

It seems the Ubiquity Networks community have discovered the
DeprecatePrefix option of 'radvd' and are suggesting its use to mitigate
this issue.

https://community.ubnt.com/t5/EdgeRouter/Solution-for-client-losing-IPv6-connectivity-after-PPPoE-re/td-p/2019416



> 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).
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>