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

[Owen DeLong <[e-mail]>]

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


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

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.

I agree that it’s a bit of a corner case and it’s certainly not an ideal way
to configure a network, but it is not entirely unlikely to happen in the
real world, it is within the current RFCs, it is valid functionality and it
is not broken by the expected behaviors today.

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

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

Owen