draft-ietf-6man-slaac-renum: Text for the heuristics (Section 4.5)

[Fernando Gont <[e-mail]>]

Folks,

As discussed during my presentation at the last 6man wg meeting, this is 
the text for the heuristics to deprecate stale information:

Your input/reviews will be highly appreciated!

---- cut here ----
4.5.  Recovery from Stale Configuration Information without Explicit
       Signaling

    This section specifies an algorithm, "Lifetime Avoidance Algorithm"
    (LTA), that allows hosts to infer when previously-advertised
    information (such as autoconfiguration prefixes) has become stale,
    such that the stale configuration information can be deprecated in a
    timelier manner.  Most of the value of this algorithm is in being
    able to mitigate the problem discussed in [RFC8978] at hosts
    themselves, without relying on updates of the behavior of local
    routers.

    The algorithm consists of two conceptual building-blocks:

    *  Detection of possible configuration change

    *  Validation/Refresh of configuration information

    Possible configuration changes can be inferred when a SLAAC router
    (as identified by its link-local address) ceases to advertise a
    previously-advertised information.  In such scenarios, nodes should
    poll the local router via unicasted Router Solicitations (RS) to
    verify that the router in question has indeed ceased to advertise the
    aforementioned information.  And, in such cases the associated
    configuration information may be discarded.

    Please note that in the context of multi-prefix/multi-router networks
    [RFC8028] [RFC8504], SLAAC configuration information should be
    associated with each advertising router.  Thus, when a router ceases
    to advertise some configuration information:

    *  If this was the only router advertising the aforementioned
       information, the associated information should be discarded.

    *  If other routers were advertising the aforementioned information,
       this information should simply be dis-associated with the router
       that ceased to advertise it, and the fate of this information (and
       configured resources) should depend solely on the routers that
       continue advertising it.

    Implementation of this kind of heuristic allows a timelier reaction
    to network configuration changes even in scenarios where there is no
    explicit signaling from the network, thus improving robustness.

    As discussed in Section 4.4, [RFC4861] does not require routers to
    convey all RA options in the same message.  Therefore, the algorithm
    specified in this section is designed such that it can cope with this
    corner case that, while not found in the deployed Internet, could
    still theoretically exist.

4.5.1.  Target Neighbor Discovery Options

    The LTA algorithm SHOULD be applied to the following Neighbor
    Discovery options:

    *  Prefix Information Option [RFC4861]

    *  Route Information Option (RIO) [RFC4191]

    *  DNS Search Options (RDNSSO) [RFC8106]

    *  DNS Search List Options (DNSSLO) [RFC8106]

4.5.2.  Configuration Variables and Local State Information

    In the context of multi-prefix/multi-router networks [RFC8028]
    [RFC8504], each option from Section 4.5.1 is associated with each
    advertising SLAAC router.

    NOTE:
       Throughout this specification, each router is identified by its
       link-local address.

    Additionally, hosts will augment state information for each option
    with a timestamp (OPT_LAST variable bellow) that records the time at
    which the option was last advertised by a particular router.

    NOTE:
       While not strictly required, we note that existing implementations
       may already record the last time an option was advertised by a
       given router as a possible implementation approach to be able to
       compute the remaining lifetime of the option.

    The algorithm employs the following variables:

    LTA_MODE:
       A boolean variable associated with each SLAAC advertising router
       that specifies whether the local host is currently performing the
       LTA algorithm for that router.  It is initialized to FALSE.

    LTA_LAST:
       A variable associated with each SLAAC advertising router that
       stores the time (in seconds) when the local host last entered the
       LTA algorithm for this router.  It is initialized to 0.

    RS_LAST:
       A variable associated with each SLAAC advertising router that
       stores the time (in seconds) when the local host last sent a
       unicasted Router Solicitation to the router in question.  It is
       initialized to 0.

    RS_COUNT:
       A variable associated with each SLAAC advertising router that
       stores the number of unicasted Router Solicitations that have been
       set to the associated router since the last time the LTA algorithm
       was executed.  It is initialized to 0.

    RS_COUNT_MAX:
       A configuration variable specifying the maximum number of
       unicasted Router Solicitations that a host will send to a SLAAC
       advertising router as part of the LTA algorithm.  It defaults to
       1.

    RS_RNDTIME:
       A host-wide variable specifying a random amount of time the host
       should wait before sending the first unicasted Router Solicitation
       message to a SLAAC router as part of the LTA algorithm.  It should
       be initialized to a value in the range from 0 to 10 seconds when
       the system is bootstrapped.

    RS_TIMEOUT:
       A host-wide variable specifying the amount of time to wait for a
       response to a unicasted Router Solicitation sent as part of the
       LTA algorithm.

    OPT_LAST:
       A timestamp associated with each option (from Section 4.5.1)
       received from each SLAAC advertising router.  It is set to the
       current system time.

    RA_WIN:
       A host-wide configuration variable specifying a time window over
       which a SLAAC advertising router may convey all SLAAC
       configuration information.  It is meant to cope with the
       theoretical case where a router may spread SLAAC information over
       several RA messages.  It defaults to 3 seconds.

    LTA_CYCLE:
       This variable accounts for the maximum time that may elapse for
       the entire LTA algorithm.  It is used as a shortcut throughout the
       algorithm.  Its value is computed as:
       LTA_CYCLE=RA_WIN+RS_RNDTIME+RS_COUNT_MAX*RS_TIMEOUT.

4.5.3.  Algorithm Specification

    Initialization when a new SLAAC advertising router is learned:

        LTA_MODE=FALSE
        LTA_LAST=0
        RS_LAST=0
        RS_COUNT=0
        LTA_CYCLE=RA_WIN+RS_RNDTIME+RS_COUNT_MAX*RS_TIMEOUT

    Upon receipt of a Router Advertisement message, and after normal
    processing of the message, perform the following actions:

        TIME= time()

        For each option advertised by this router in the received RA:
            OPT_LAST= time()


        IF LTA_MODE==FALSE && TIME > (LTA_LAST+LTA_CYCLE)
            IF the RA is missing any previously-received information:
                LTA_MODE=TRUE
                LTA_LAST=TIME

    Time-driven events:

        IF LTA_MODE==TRUE:
            TIME=time()

            IF TIME > (LTA_LAST + RA_WIN + RS_RNDTIME) && TIME >
                    (RS_LAST + RS_TIMEOUT) && RS_COUNT < RS_COUNT_MAX:
                SendRS()
                RS_LAST=TIME
                RS_COUNT++

            IF TIME >  (LTA_LAST + LTA_CYCLE)
                Disaasociate any options for which OPT_LAST < LTA_LAST
                LTA_MODE= FALSE
                RS_COUNT=0

    NOTES:

    *  time() is a monotonically-increasing counter that is incremented
       once per second, and is employed to measure time.

    *  SendRS() is a function sends a unicasted Router Solicitation
       message to the target router (subject to sending rules in
       [RFC4861]).
---- cut here ----

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494