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

[Lorenzo Colitti <[e-mail]>]

FWIW, from a host implementer perspective, DecrementLifetimes is a bad idea
since it makes it harder to drop duplicate RAs in firmware and thus has
substantial battery impact.

True story: many ISP routers use a maximum advertisement interval of 3
seconds in order to fix unreachability and IPv6 brokenness problems. In
order to avoid draining the battery after 12 hours of this, phone
manufacturers reacted by either dropping all RAs (or even all IPv6
packets!) when the screen is off, or putting RA filtering in firmware. Then
some routers decided to use DecrementLifetimes as well. Firmware RA
filtering couldn't match the RAs any more and the phone manufacturers
probably reacted by dropping all RAs again.

In order to fix this problem on Android we had to write a bytecode
interpreter and get wifi chipset manufacturers to insert it into their
firmware so we could push filtering rules to the chipset at runtime. Many
chipset manufacturers still haven't adopted this though.

Please don't do this if you care about mobile devices having correct IPv6
implementations and acceptable battery life.

On Tue, Feb 26, 2019 at 8:09 PM Mark Smith <[e-mail]> wrote:

>
>
> On Tue., 26 Feb. 2019, 22:00 Fernando Gont, <[e-mail]> wrote:
>
>> On 26/2/19 07:13, Ole Troan wrote:
>> > Fernando,
>> >
>> >>>> On 25 Feb 2019, at 18:36, Fernando Gont <[e-mail]>
>> wrote:
>> >>>>
>> >>>> On 25/2/19 07:32, Richard Patterson wrote:
>> >>>>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont <[e-mail]>
>> wrote:
>> >>>>>
>> >>>>>> * As per RFC4862, it turns out that you cannot remove a stale
>> prefix vy
>> >>>>>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current
>> standards,
>> >>>>>> not even the CPEs can (even if they wanted to) do something to fix
>> the
>> >>>>>> problem.
>> >>>>>
>> >>>>> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but
>> >>>>> the Preferred Lifetime can.  So we can't invalidate the prefix, but
>> we
>> >>>>> can deprecate it so it's not used for new outbound sessions.   This
>> is
>> >>>>> what we've implemented in our CPEs, after an unavoidable change in
>> >>>>> prefix, and it seems to have mitigated (or reduced the impact of)
>> the
>> >>>>> issue.
>> >>>>
>> >>>> Agreed. That said, with the current default lifetime values, things
>> >>>> become tricky:
>> >>>> At least in theory, you should be sending such RAs for "Valid
>> Lifetime"
>> >>>> seconds. With a default of one month, that means that, in theory, you
>> >>>> should be sending such RAs for a month. And if there are multiple
>> >>>> crash-and-reboot events, you should advertise each of the stale
>> >>>> prefixes. (I assume the CPE just records the last one)
>> >>>
>> >>> When / where was the default Valid Lifetime chosen to be one month?
>> >>
>> >> Section 6.2.1 of RFC 4861:
>> >>
>> >>      AdvPrefixList
>> >>                     A list of prefixes to be placed in Prefix
>> >>                     Information options in Router Advertisement
>> >>                     messages sent from the interface.
>> >>
>> >>                     Default: all prefixes that the router advertises
>> >>                     via routing protocols as being on-link for the
>> >>                     interface from which the advertisement is sent.
>> >>                     The link-local prefix SHOULD NOT be included in the
>> >>                     list of advertised prefixes.
>> >>
>> >>                     Each prefix has an associated:
>> >>
>> >>                        AdvValidLifetime
>> >>                             The value to be placed in the Valid
>> >>                             Lifetime in the Prefix Information option,
>> >>                             in seconds.  The designated value of all
>> >>                             1's (0xffffffff) represents infinity.
>> >>                             Implementations MAY allow AdvValidLifetime
>> >>                             to be specified in two ways:
>> >>
>> >>                               - 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
>> >>
>> >>                               - a fixed time that stays the same in
>> >>                                 consecutive advertisements.
>> >>
>> >>                             Default: 2592000 seconds (30 days), fixed
>> >>                             (i.e., stays the same in consecutive
>> >>                             advertisements).
>> >
>> >
>> > Red herring.
>> >
>> > RA lifetimes cannot be longer than the DHCP PD lifetimes.
>>
>> I don't disagree with you.
>>
>>
>> > 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.
>>
>
> There is a knob in 'radvd' to do and suit that, the PD triggered/driven
> script just needs to do a bit of radvd.conf modification, stopping,
> starting, and signalling.
>
>
> *DecrementLifetimes* *on*|*off*
>
> This option causes radvd to decrement the values of the preferred and
> valid lifetimes for the prefix over time. The lifetimes are decremented by
> the number of seconds since the last RA.. If radvd receives a SIGUSR1
> signal, it will reset the values of the preferred and valid lifetimes back
> to the initial values used by radvd when it started. If radvd never
> receives a SIGUSR1 signal, it will continue to decrement the lifetimes
> until the preferred lifetime reaches zero. After a final RA with a zero
> value preferred lifetime, radvd will cease to announce the prefix. If a
> SIGUSR1 signal then causes the lifetimes to be reset, the prefix will then
> re-appear in the RAs.
>
> This option is intended to be used in conjunction with a DHCPv6 client
> that is using the Identity Association for Prefix Delegation (IA_PD) option
> to acquire a prefix from a Delegating Router for use by a Requesting
> Router. In this scenario, the prefix(es) from within the delegated prefix
> that are announced by radvd would age in parallel with and at the same rate
> as the delegated prefix, and expire at approximately the same time, if the
> delegated prefix's life isn't extended.
>
> See RFC3633, "IPv6 Prefix Options for Dynamic Host Configuration Protocol
> (DHCP) version 6".
>
> Default: off
>
>
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: [e-mail]
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>