Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Fernando Gont <[e-mail]>]

On 26/2/19 16:13, 神明達哉 wrote:
> At Tue, 26 Feb 2019 14:35:20 -0300,
> Fernando Gont <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> > while we cannot completely ignore non-compliant implementations (if
>> > any) in practice, IMO the existence of violators shouldn't be the
>> > primary reason for tweaking the protocol.
>>
>> Which specific tweak are you referring to?
> 
> Changing the default value of AdvPreferredLifetime and
> AdvPreferredLifetime currently defined in in RFC4861.

The rationale for that it's what's in the I-D, namely:

   RATIONALE:

      *  In the context of [RFC8028], where it is clear that use of
         addresses configured for a given prefix is tied to using the
         next-hop router that advertised the prefix, neither the
         "Preferred Lifetime" or the "Valid Lifetime" of a PIO should
         never be larger than the "Router Lifetime" (AdvDefaultLifetime)
         of Router Advertisement messages.

      *  As a result, this document updates [RFC4861] such that the
         default Valid Lifetime (AdvValidLifetime) and Preferred
         Lifetime (AdvPreferredLifetime) of PIOs are specified as a
         function of the "Router Lifetime" (AdvDefaultLifetime) of
         Router Advertisement messages.

      *  This document reduces the maximum time between unsolicited RAs
         (MaxRtrAdvInterval), which indirectly specifies the minimum
         time between unsolicited RAs (MinRtrAdvInterval) and the Router
         Lifetime (AdvDefaultLifetime), to improve the ability of hosts
         to recover from fault scenarios.

      *  Lacking RAs that refresh information, addresses configured for
         advertised prefixes become un-preferred in a timelier manner,
         and thus Rule 3 of [RFC6724] causes other configured addresses
         (if available) to be used instead.

      *  Reducing the Valid Lifetime and Preferred Lifetimes of PIOs
         limits the amount of time hosts may use stale prefixes, and
         also limits the amount of time that a stale prefix needs to be
         advertised with a lifetime of "0" on the local network (see
         Section 12 of [RFC4861]).



[....]
> The question is specifically how those script put the pieces together.
> As long as the "RA piece" supports the "decrement in real time" part
> of RFC4861, not using it is a mere bug of those scripts (in that it at
> least violates Section 18.2.10.1 of RFC8415).  My point here is that
> the existence of buggy implementation (if it exists at all) doesn't
> seem to be a strong justification of updating the spec.

Agreed. As noted above, *that* is *not* the motivation.




>> > I don't necessarily oppose to the idea of revising the default prefix
>> > lifetimes currently specified in RFC4861.  The growing deployment of
>> > mobile environments may justify an update, for example.  But the
>> > discussion should be based on accurate understanding of what's
>> > possible with the current specification and actual implementations,
>> > rather than speculative "red herring".
>>
>> Tee only thing that I mentioned is that the CPE should be prepared to
>> "deprecate" a prefix for "Valid Lifetime". -- a local ISP recently
>> reported that they employ DHCPv6-PD times of over a month. IN those
>> cases, the spec you reference is complied with, and what I mention above
>> is the case: -- if there-s a carsh-and-reboot scenario, the CPE should
>> (in theory) be prepared to deprecate a prefix for "Valid LIfetime". --
>> whether in practice you can get away with firing a few RAs is a
>> different thing.
> 
> In that case I'd rather see a point in what Ole keeps saying: either
> the ISP should use a much shorter DHCPv6-PD prefix lifetimes in the

in the order of... how many minutes?


> first place or they shouldn't change the delegated prefix.  I'm not
> saying this to argue there's nothing we can/should do for such a broken
> operation.  But this case seems weak as a justification to change the
> default lifetime values in RFC4861.

The justification is noted above.  Regarding "broken operation"... the
survey referenced in our I-D notes that 37% of the surveyed ISPs do
dynamic prefixes. Blaming the ISPs is not really going to improve user
experience...


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