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

[Mark Smith <[e-mail]>]

So in summary, the proposal is to update RFCs, change 100s of millions
of CPE implementations, and billions of IPv6 host implementations, to
accommodate some ISPs who want to cling to an obsolete dynamic and
dial up origin address provisioning model for always on Internet
connections?

Robustness is useful, however there needs to be a determined threshold
where, beyond that, the cost of adding robustness exceeds the cost of
properly fixing the problem that created the need for additional
robustness in the first place.

Making all CPE and all IPv6 hosts more robust to work around a problem
caused by some ISPs' address provisioning systems and models is going
to be far more expensive and incur costs on everybody (IETF, CPE
vendors and host vendors, and their customers who indirectly pay CPE
and host implementation costs), compared to those ISPs accepting that
IPv6 customers require persistent prefixes and paying the costs of
making changes to their own address provisioning systems.

On Sun, 27 Oct 2019, 15:48 Owen DeLong, <[e-mail]> 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.
>
>
>
>
>
> 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
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops