Re: 6renum alive again? [A common problem with SLAAC in "renumbering" scenarios]

[Fernando Gont <[e-mail]>]

On 20/2/19 01:02, Brian E Carpenter wrote:
> Maybe everybody could read up on previous rounds of discussion:
> 
> https://tools.ietf.org/html/rfc4192
> https://tools.ietf.org/html/rfc5887
> https://tools.ietf.org/html/rfc6866
> https://tools.ietf.org/html/rfc6879
> https://tools.ietf.org/html/rfc7010
> (In that last one, the section "Gaps Considered Unsolvable"
> might be of interest.)

Thanks a lot for the pointers. I quickly checked RFC7010 (the section
title made me curious), specifically:


10.1.  Address Configuration

   o  RA Prefix Lifetime Limitation

      Section 5.5.3 of [RFC4862] states "If the received Valid Lifetime
      is greater than 2 hours or greater than RemainingLifetime, set the
      valid lifetime of the corresponding address to the advertised
      Valid Lifetime."  So when renumbering, if the previous
      RemainingLifetime is longer than two hours, it is impossible to
      reduce a prefix's lifetime to less than two hours.  This
      limitation is to prevent denial-of-service attacks.

This seems a flaw in RFC4862 to me. Me, I think ND security boils down
to: modulo some basic sanity checks, you trust the RAs, or you don't.
There's not much of a point in sanitizing the Prefix Lifetimes and then
honoring Router Lifetimes of 0, or even blindly trusting RAs that would
make you configuring addresses from invalid prefixes, RAs that might
override your preferred router with one with higher preference, etc.

That aside, in the context of RFC8028, it would seem to me that any
prefix lifetimes larger than the Router Lifetime don't make much sense.




> Yes, the topic was site renumbering, not host renumbering. But
> the assumption has always been that renumbering should be a routine
> event in IPv6. (Those of us who had to manage IPv4 site renumberings,
> especially before the advent of DHCP, have always been sensitive on
> this topic.) Thus, hosts need to be ready for renumbering at any time,
> without notice.
> 
> Better I think to focus on Fernando's specific issue.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492