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

[Timothy Winters <[e-mail]>]

On Fri, Feb 22, 2019 at 12:30 PM Tim Chown <[e-mail]> wrote:

> Hi,
>
> On 22 Feb 2019, at 17:04, Owen DeLong <[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.
>
So we test that IPv6 implementations set the address to two hours if the
address was higher then gets a low value (such as 1).   Currently there is
no way to make it less then two hours if a Rogue RA gets out and gives out
a longer address lifetime.

>
> But I like Lee's analysis.
>
> Tim
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>