[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    draft-ietf-6man-slaac-renum: Router Configuration Variables
From:       Fernando Gont <fgont () si6networks ! com>
Date:       2020-09-03 13:09:58
Message-ID: 2c9a9258-2a2a-b67f-5189-a034b1b67cab () si6networks ! com
[Download RAW message or body]

Folks,

We continue discussing each of the mitigation proposals that we had in 
draft-gont-6man-slaac-renum.

The next one is about the default values to use by routers for the 
Preferred and Valid Lifetime of the PIOs they advertise.

The text below proposes to set the PIO lifetimes at routers as a 
function of the advertised Router Lifetime.

---- cut here ----
4.1.1.  Router Configuration Variables

    The default value for the "lifetime" parameters in PIOs is updated as
    follows:

       AdvPreferredLifetime: max(AdvDefaultLifetime, 3 *
       MaxRtrAdvInterval)

       AdvValidLifetime: 2 * max(AdvDefaultLifetime, 3 *
       MaxRtrAdvInterval)

    where:

    AdvPreferredLifetime:
       Value to be included in the "Preferred Lifetime" field of the PIO.

    AdvValidLifetime:
       Value to be included in the "Valid Lifetime" field of the PIO.

    AdvDefaultLifetime:
       Value of the "Router Lifetime" field of the Router Advertisement
       message that will carry the PIO.

    max():
       A function that outputs the maximum of its arguments.

    NOTE:
       [RFC4861] specifies AdvDefaultLifetime as 3 * MaxRtrAdvInterval
       (which defaults to 600 seconds).  This means that, when employing
       default values for MaxRtrAdvInterval, the Router Lifetime would be
       set to AdvPreferredLifetime (1800 seconds).  Thus, when employing
       the default values, or when manually setting AdvDefaultLifetime to
       a value smaller than 1800 seconds, AdvPreferredLifetime and
       AdvValidLifetime would be set to 1800 seconds (30 minutes) and
       3600 seconds (1 hour), respectively. We note that when
       implementing BCP202 [RFC7772] AdvDefaultLifetime will typically be
       in the range of 45-90 minutes, and therefore AdvPreferredLifetime
       will be in the range 45-90 minutes, while AdvValidLifetime will be
       in the range of 90-180 minutes.

    RATIONALE:

       *  The default values for PIO lifetimes should be such that, under
          normal circumstances (including some packet loss), the
          associated timers are refreshed/reset, but in the presence of
          network failures (such as network configuration information
          becoming stale), some fault recovering action (such as
          deprecating the corresponding addresses and subsequently
          removing them) is triggered.

       *  In the context of [RFC8028], where it is clear that the use of
          addresses configured for a given prefix is tied to the next-hop
          router that advertised the prefix, the "Preferred Lifetime" of
          a PIO should never be larger than the "Router Lifetime" of
          Router Advertisement messages.  Some leeway should be provided
          for the "Valid Lifetime" to cope with transient network
          problems.  As a result, this document updates [RFC4861] such
          that the default Valid Lifetime (AdvValidLifetime) and the
          default Preferred Lifetime (AdvPreferredLifetime) of PIOs are
          specified as a function of the default "Router Lifetime"
          (AdvDefaultLifetime) of Router Advertisement messages.  In the
          absence of RAs that refresh information, addresses configured
          for advertised prefixes become deprecated in a timelier manner,
          and thus Rule 3 of [RFC6724] will cause other configured
          addresses (if available) to be preferred.

       *  The expression above computes the maximum between
          AdvDefaultLifetime and "3 * MaxRtrAdvInterval" (the default
          value for AdvDefaultLifetime, as per [RFC4861]) to cope with
          the case where an operator might simply want to disable one
          local router for maintenance, without disabling the use of the
          corresponding prefixes on the local network (e.g., on a multi-
          router network).  [RFC4862] implementations would otherwise
          deprecate the corresponding prefixes.  Similarly, [RFC8028]
          would likely behave in the same way.
---- cut here ----

Note: I have tweaked the text we had in draft-gont-6man-slaac-renum-08 
to reflect the discussion we had in v6ops, and to point to BCP202/RFC7772.

Please do let us know what you think about the text above.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]