Owen DeLong <owen@xxxxxxxxxx> writes: > This depends. Certainly a host which still has active flows using the > old address will not automatically terminate those flows. Further, > longest lifetime is not even listed as a source address selection > criteria in RFC6724. Even if it were added, it would likely be > subordinate to rule 8 (use longest matching prefix) in which case, a > source address that was not deprecated and which had more left hand > bits in common with the destination address would be preferred over > one that does not. > > While it may initially seem logical to prefer the longest remaining > lifetime, there are a number of flaws with this approach and indeed, > one of them is that the longer lifetime may belong to the older > prefix. > > Consider the scenario where as part of renumbering a group of > customers, an ISP decides to also shorten the preferred and valid > lifetimes on the new prefix to simplify their future maintenance > procedures. Where the previous prefix may remain valid for up to 7 > days with a preferred lifetime of 24 hours, they issue new prefixes > with a preferred lifetime of only 3 hours and a valid lifetime of only > 24 hours. In such a case, using your proposed longest lifetime would > actually cause hosts to essentially ignore the new prefix, possibly as > long as the better part of a week. > > There is also the possibility to instead of longest lifetime, consider > the most recently refreshed prefix, but if there are more than one > router on the segment, this could create a sort of flapping behavior > between source addresses which would also be undesirable. And it might well be worth putting a precis of this in the document, as explaining why a lot of approaches will not be satisfactory. > As such, it seems that your comment is more based on a > misunderstanding of the relationship between SLAAC and HAs than it is > based on a need for clarification within the document. I'd say "a lack of understanding of the relationship between SLAAC and HAs". Being a Gen-ART reviewer, my position is that of someone who is not read in to the protocols in question, and thus able to identify points where people who are not read in to the protocols are going to get lost. But another thread contains what I consider to be a good solution to this point. > Despite the fact that RFCs prohibit hosts from reducing the valid > lifetime to less than 2 hours in response to a received RA, some > routers do send such RAs and some hosts do (in violation of the > standards) deprecate the prefixes accordingly. This is kind of a > no-win situation because if you deprecate the prefix, you have > weaponized (spoofed) RAs as a mechanism to tell a host to deprecate a > prefix. OTOH, if you don’t deprecate the prefix, you have a situation > where the user may well be suffering for at least two hours with a > non-functional stale prefix. It seems like this is one of those annoying facts about the universe that is really relevant to the discussion in the document. But I don't recall it being stated anywhere. Indeed, I would promote it as "Can we define a better solution so we can convince implementors to stop doing this?" >> 2.4. Lack of Explicit Signaling about Stale Information >> >> [...] such signaling would be mostly ignored. >> >> This needs clarification why it is "mostly" rather than "always". > > Because the original standards are ambiguous and so the result is somewhat > implementation dependent. Some implementations also behave “differently” > depending on circumstance and/or configuration. Probably worth stating explicitly. > In this case, timely is most about user perception. If the now dysfunctional > address remains in use long enough for the user to become annoyed (or arguably > even notice), then recovery is not timely. Since the definition of timely in > this case is actually subjective, I’m not sure that such clarification is > practical or useful. I agree. But if timliness has no really solid definition, why does the text firmly assert that certain particular values, without qualificaton, are not timely? Dale -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
