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

[神明達哉 <[e-mail]>]

At Tue, 26 Feb 2019 07:43:00 -0300,
Fernando Gont <[e-mail]> wrote:

> > In the DHCP PD case they should also be counted down in real time.
> > And the lifetimes can be dynamically adjusted.
>
> They should. However, quite frequently the DHCPv6-PD part is a different
> piece of software from the ra{d,dvd} part. Both pieces are glued by some
> script, and the lifetime is *not* dynamically adjusted.

It's a clear violation of Section 18.2.10.1 of RFC8415:

      If the client uses a delegated prefix to configure addresses on
      interfaces on itself or other nodes behind it, the preferred and
      valid lifetimes of those addresses MUST be no longer than the
      remaining preferred and valid lifetimes, respectively, for the
      delegated prefix at any time.  In particular, if the delegated
      prefix or a prefix derived from it is advertised for stateless
      address autoconfiguration [RFC4862], the advertised preferred and
      valid lifetimes MUST NOT exceed the corresponding remaining
      lifetimes of the delegated prefix.

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.

Besides, I'm actually not so sure if it's so difficult to comply with
today's tools.  RFC4861 has the concept of dynamically decrementing
the advertised lifetimes as a protocol parameter (with a MAY):

                        AdvValidLifetime
[...]
                               - a time that decrements in real time,
                                 that is, one that will result in a
                                 Lifetime of zero at the specified time
                                 in the future, or
[...]
                        AdvPreferredLifetime
[...]
                               - a time that decrements in real time,
                                 that is, one that will result in a
                                 Lifetime of zero at a specified time in
                                 the future, or

and I suspect that non-negligible number of implementations support
this concept.  BSD's rtadvd does, apparently so does Linux radvd.
For these implementations, it's just a matter of configuration, even
if the DHCP-PD client and RA advertisement are implemented as
different pieces of software: a "script" takes the lifetimes from
DHCPv6 PD and dumps the RA configuration by setting AdvXXXLifetimes to
that values that decrement in real time.

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".

--
JINMEI, Tatuya