Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Fernando Gont <[e-mail]>]

On 27/10/19 01:48, Owen DeLong wrote:
>>> It is worth noting that these values are tunable by the administrator
>>> and the
>>> RFC suggested defaults should never be a hard-coded value.
>>>
>>> With the following exception, I don’t advocate modifying this on the
>>> client
>>> side:
>>> +Section 5.5.3 of RFC4862 should be amended to specifically
>>> allow the immediate deprecation of a prefix by sending a valid
>>> lifetime of 0 seconds. Hosts should be required to honor
>>> this as a signal that the prefix is no longer valid.
>>
>> Could you please elaborate on this one?
> 
> I’m not sure what I could do to elaborate. The addition of a specific
> call-out that
> even if the current behavior of ≤2 hours = 2 hours is to be preserved,
> there should
> be a special case for “0 seconds” which causes the prefix to be immediately
> deprecated with extreme prejudice.
> 
> Hosts should be required to treat an RA containing a prefix with a 0 second
> valid lifetime as an invalid prefix and immediately deprecate it from
> the interface
> if it is in use.

OK, so you do agree with the proposed change? (in
draft-gont-6man-slaac-renum, not in *this* document)




>>> I do think that generally speaking, your proposed modifications to
>>> CPE and
>>> router behavior should be standardized and implemented.
>>>
>>>> A better mitigation is to affect the preferred and possibly the valid
>>>> lifetimes in response to consecutive RAs from the same router that lack
>>>> the original (stale) prefix. e.g., after two consecutive RAs that do not
>>>> contain the existing prefix, reduce the preferred lifetime. After two
>>>> additional RAs, reduce the valid lifetime.
>>>
>>> In the crash scenarios you describe, you’re assuming a single router on
>>> the network or
>>> at least only one router announcing the prefix(es) in question with no
>>> persistent
>>> memory of the prefixes it was announcing across a reboot. In such a
>>> scenario,
>>> it seems to me that the following are also likely valid assumptions:
>>>
>>> +The network has significant excess bandwidth compared to demand.
>>> +The small overhead of frequent RAs and short lifetimes is probably
>>> an acceptable tradeoff in this environment.
>>>
>>> However, there are lots of other scenarios in the world where those
>>> assumptions
>>> won’t hold true and we should not seek to solve this problem (which is
>>> generally
>>> applicable to residential and SMB environments) at the expense of all of
>>> those
>>> other professionally administered environments.
>>
>> Even with the default RA frequency, if you were to unprefer a prefix
>> upon, say, second RA that doesn't advertise it, and say, remove the
>> prefix after many other RAs are received, that would be a *big*
>> improvement to what we have now.
> 
> I don’t like this idea because I can think of some scenarios where you
> may receive multiple RAs from router A not containing the prefix in the
> same time frame that router B has not sent an additional RA containing
> the prefix, but it will do so in its next RA.

Maybe it wasn't clear in the I-D, but the basic idea is:
If you receive multiple RAs from router A that do not advertise the
prefix, then you disassociate such prefix with router A. If nobody else
is advertising the prefix, you'd deprecate it. If other routers are
advertising it, this would not change the status quo of the prefix wrt
such other routers.


> There is no requirement for all routers on the same link to provide the
> same set of PIOs, nor are they required to use the same advertisement
> timers.

Agreed. Please see above.






>>> In section 3.2.1, you advocate setting the A and L bits to their
>>> previous values
>>> for prefixes which are being deprecated. IMHO, this is incorrect and the
>>> announcements calling for immediate deprecation should also indicate that
>>> the prefix should no longer be auto-configured and should no longer be
>>> considered on-link.
>>
>> Not sure I follow. Could you please elaborate?
> 
> Sure… In section 3.2.1 of your document, you advocate that if the previously
> valid PIOs were set A=1 and/or L=1, then those values of the A and L bits
> should be preserved in the RAs sent to deprecate them.
> 
> My argument is that since you are attempting to make this a prefix that
> hosts
> will no longer autoconfigure (A) and will no longer consider on-link
> (L), that
> in reality, regardless of the previous state of the A and L bits in the RAs
> announcing the prefix in a valid PIO, the new RAs since the prefix has been
> deprecated should be sent with A=0, L=0 in order to signal the host
> that this prefix should not be auto configured and should no longer be
> considered on-link.

You really make a good point. I will go through RFC4861 and see what's
the current expected behaviour in such case.





>>> Is there some unfortunate widely deployed behavior that interacts poorly
>>> with setting A and L to 0 for these previously valid prefixes?
>>>
>>> Finally, An editorial note… In Section 3, you state “Finally, Section
>>> 2.5 analyzes…”
>>> I believe this is intended to be a reference to section 3.2.2.
>>
>> Nope. Section 3.2.2 talks about the interaction between dhcpv6-pd and
>> slaac. BUt it is section 2.5 that discusses other considerations for
>> dynamic/stable prefixes. For example, stable prefixes are not nice for
>> privacy.
> 
> 
> Fair enough, but in that case, I don’t think I would put it after the
> description of section 3.2,
> nor would I use the word “Finally” as a lead-in to a back-reference.

Will tweak the text accordingly.

Thanks!

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