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

[Owen DeLong <[e-mail]>]

> On Oct 31, 2019, at 12:13 PM, Fernando Gont <[e-mail]> wrote:
> 
> 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)

From the context of my thinking at the time of writing the original reply,
“this document” referred to draft-gont-6man-slaac-renum. Apolgies
for my lack of clarity as you have apparently interpreted it differently.

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

That’s definitely not how I interpreted the I-D and I would strongly encourage
you to review and update the I-D for clarity in this area. I’m actually still not
100% convinced that this is correct behavior. It also places additional burdens
on hosts to track all routers associated with a given prefix rather than merely
tracking candidate default gateways, RIO data, and one set of prefix timers
utilizing the most recently received timer refreshes.

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

With the above clarification, I think it can be done and is less likely to break
things. However, it does place a significant additional tracking burden on the
host which I’m not entirely convinced is a desirable situation. Especially in the
case of a resource-constrained host which is using SLAAC to avoid the overhead
of DHCP.

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

Thanks!

Owen