> On Aug 30, 2020, at 6:14 PM, Dale Worley via Datatracker <nore...@ietf.org> > wrote: > > Reviewer: Dale Worley > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-v6ops-slaac-renum-03 > Reviewer: Dale R. Worley > Review Date: > IETF LC End Date: 2020-09-09 > IESG Telechat date: [not set] > > Summary: > > This draft is basically ready for publication, but has nits that > should be fixed before publication. > > Overall, the draft is fine, but there are various places where the > wording could be amplified or improved to make matters clearer to the > less-well-prepared reader (like me). > > Minor issues: > > There is one technical aspect that doesn't seem to be addressed > explicitly: Given that a router should never advertise a prefix via > SLAAC that extends beyond the lease time it has received via DHCP, > even if the router is restarted and it receives a new prefix via DHCP, > the old prefix remains delegated to the network for the remainder of > its lease time, and in a way, it remains *valid* for the hosts to use > addresses derived from the old prefix for the remainder of the > lifetime they received from SLAAC. The existence of this document > shows that such usage does not work well, but perhaps there is some > place early in the discussion where it can be made clear that validity > is not sufficient in practice. > > Nits/editorial comments: > > 1. Introduction > > [...] but will normally retain and actively employ the addresses > configured for the previously-advertised prefix, since their > associated Preferred Lifetime and Valid Lifetime allow them to do > so. > > Naively, it seems like the new prefix will almost always have longer > lifetime values than the old prefix, and given that this seems to be > how orderly renumbering causes hosts to transition from using the old > prefix to the new prefix, it's not clear how hosts "will normally > ... actively employ the addresses configured for the > previously-advertised prefix". Naively, hosts only seem to be > permitted to employ the old prefix, but the preferred behavior would > be to use the new prefix whenever possible.
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. > o During the planned network renumbering, a router may be configured > to send an RA with the Preferred Lifetime for the "old" Prefix > Information Option (PIO) set to zero and the new PIO having non- > zero Preferred Lifetime. > > This sentence reminds me: There are a number of places where PIO is > mentioned. My understanding from here is that PIO is only used in RA, > so for simplicity/clarity, mentions of PIO should always include that > they are within RAs, so that the reader remember that all prefix > announcements are either RAs or SLAAC. Conversely, if PIOs are used > both by SLAAC and RAs, that should be emphasized early on, so the > reader knows that later mentions of PIOs apply to both protocols > equally. Then again, perhaps RAs are messages within SLAAC, in which > case that should be made clear. In any case, the document should > state the relationship between SLAAC, RA, and PIO. SLAAC is not so much a protocol as an Address Selection/Generation algorithm. SLAAC does not have any packet formats of its own, but instead depends entirely on the IPv6 Neighbor Discovery packets (RS, RA, NS, NA) for its operations. A PIO is the part of an RA that provides details about a prefix for SLAAC. A network which does not support SLAAC will likely not have PIOs in its RAs. If a PIO is present, its sole purpose is to provide information about a prefix which may be considered by SLAAC (though the PIO may indicate that the prefix in question should NOT be used for address generation). 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. > o Automated device config management system performs periodic config > pushes to network devices. If such a push results in changing the > subnet configured on a particular network, hosts attached to that > network would not get notified about the subnet change, and their > addresses from the "old" prefix will not be deprecated. > > Naively it seems than when a router receives such a config push, it > would as a matter of course tell the attached hosts that the prefix it > gave to the hosts is no longer configured, as indeed, that prefix is > no longer configured. I think you want to add some statement that > when routers receive config pushes they often(?) simply immediately > forget their previous configuration, rather than withdrawing it > gracefully. There is no mechanism in SLAAC for withdrawing a prefix gracefully other than to stop advertising it in PIOs with in RAs and wait for the longest issued valid time to expire. The protocol does not support mechanisms for the router to withdraw the prefix gracefully on a more immediate timescale. Indeed, that is the crux of one of the problems being described in this document. However, the significant changes to SLAAC that would be necessary in order to support such graceful withdrawal are beyond the scope of this document and indeed beyond the scope of this WG as I understand it. > In various places, "timely" and derived words are used. In some > places, the text asserts that certain intervals are not timely (in an > absolute sense) without any discussion about what the standard of > timeliness is. It seems that some such discussion needs to be made, > or a statement made that such a discussion needs to be undertaken as > part of the work. > > Some devices have implemented ad-hoc mechanisms to address this > problem, such as sending RAs to invalidate apparently-stale > prefixes [...] > > This seems to contradict the statement in section 2.3 that an RA > cannot effectively reduce the Valid Lifetime of a prefix (as > maintained by a host) to zero: "Item e) [...] specifies that an RA > may never reduce the "RemainingLifetime" to less than two hours." > Indeed, a crux of this document is that there is no way for a router > to immediately invalidate the use of a prefix on a network whose > addressing it configures. So the described mechanism needs to be > clarified. 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. > > 2.2. Default Timer Values in IPv6 Stateless Address Autoconfiguration > > For obvious reasons, the whole point of using timers in this way is > that, in problematic scenarios, they trigger some recovery action. > > I think you want to expand this by saying "This action should minimize > the time the fault is visible to higher levels of the protocol stack, > or ideally, prevent it from becoming visible." Possibly move this > above the preceding paragraph, and extend that paragraph with > "Ideally, retransmission enables the higher-level protocol to proceed > without disruption, only delay." I’m not so sure about this one. Will give it more thought. > > Under normal network conditions, these timers will be reset/refreshed > to the default values. However, under problematic circumstances, > > It seems like the first sentence is not to the point of this > paragraph, and it would be clearer just starting with "Under problematic > circumstances ...". I disagree. I think that explaining the normal and expected behavior provides context for how and why the other situations are different and that lacking such context would make the document less clear and less useful. > > 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. > 3.2. SLAAC Parameter Tweaking > > However, while the aforementioned values are an improvement > over the default values specified in [RFC4861], they will not > lead to a timely recovery from the problem discussed in this > document. > > As mentioned above, this implies an absolute standard of timeliness, > but no such standard has been discussed. It's also unclear why this > document chose the particular values listed, given that it considers > them too long. Why not just propose values that would give acceptable > behavior? 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. As to proposing values that would give acceptable behavior, such values would be out of range for the protocol specification as written and there are significant other tradeoffs associated with making various SLAAC times sufficiently short as to resolve this particular problem. Owen _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
