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

[Owen DeLong <[e-mail]>]

>> I'm also not convinced
>> that there are sensible values for these lifetimes that are robust enough 
>> and at the same time responsive enough to deal with the issue at hand.
>> 
>> Reducing the lifetimes would help against build up of stale prefixes. If
>> they are set to a couple of hours.
> 
> I do agree that this is not a complete solution, but, as you correctly
> note, would help against build up of stale prefixes.

I do agree that 7 and 30 days, respectively are absurd timer default values.

I think we can take some lessons from IPv4 and DHCP here. A fairly common
lease time in the DHCP world is 3600 seconds (1 hour). This seems like a
reasonable default preferred lifetime and I would propose that 1 day (86400)
seconds may well be a reasonable default valid lifetime.

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.

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.

For

For the busy wifi scenario, the preferred lifetime of zero for the old PIO should be
sent many times and should be maintained in the configuration for at least
OldPreferredLifetime seconds. At the end of OldPreferredLifetime seconds,
if a host hasn’t seen the new RA, it will no longer matter as the last RA it saw
will have expired. It’s not ideal, but there really aren’t a lot of good options here
other than getting WiFi vendors to improve multicast reliability.

In your automated configuration management scenario, IMHO, the people
driving the automation have erred. The related case is, IMHO, a variant
of the exact same case and represents the same error. It is still operator
error regardless of whether the operator is driving an automation system,
or is directly configuring a router. At a certain point, we need to accept that
there is a limit to the acceptable gymnastics for the prevention of operator
error. The best colloquialism here is “If you make something completely
idiot proof, the world will invent a better idiot.”

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.

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.


Owen