Re: [v6ops] Stability and Resilience (was Re: A common...)

[Tim Chown <[e-mail]>]

Hi,

On 22 Feb 2019, at 17:04, Owen DeLong <[e-mail]<mailto:[e-mail]>> wrote:

Networks should, as much as possible, be resilient to prefix changes. Some things networks can do to improve resilience:

  1.


Write a learned prefix to non-volatile memory and issue a DHCPv6 Renew for that prefix on reboot.

  2.


Use dynamic DNS and shorter TTLs.

  3.


Implement something like NETCONF to distribute prefix information to policy devices like firewalls or SD-WAN controllers. I think a separate document describing this application of NETCONF would make sense.

If the prefix is written to nv men, wouldn’t it also be possible for implementers to send rapid deprecation RAs for any prefix not renewed?

In other words, after reboot, try to reacquire same prefix. If that doesn’t work, when you advertise the new prefix, you could also include the old prefix with a very short preferred and valid lifetime (e.g. 1 second) in the first RA, which should be sent to the all nodes on link multicast?

It doesn’t eliminate the problem, but 1 second additional duration would be barley noticeable amid the minute or so it takes most home gateways to reboot.

That's similar in spirit to RAmond, which we used to use when seeing rogue RAs on our campus network.  It would auto-deprecate any prefixes that shouldn't be there. (http://ramond.sourceforge.net/)

The snag is that I suspect most OSes would ignore a valid timer of 1 second, given the 7200 second (2 hour) minimum defined in RFC 4862 (unless the RA is authenticated, somehow).  The preferred timer can be zero.  When RAmond was written, if we used a valid timer less than 7200 seconds it seemed that the deprecating RAs were ignored.  That was 10+ years ago though.  Perhaps Tim Winters has data on whether that rule is implemented today in practice; I'd assume the tests he runs might include that.

But I like Lee's analysis.

Tim