Re: [Gen-art] Genart last call review of draft-ietf-v6ops-slaac-renum-03

[Fernando Gont <[e-mail]>]

Hello, Dale,

Thanks so much for your feedback! Please find my responses in-line....

On 30/8/20 22:14, Dale Worley via Datatracker 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.

Flash renumbering essentially breaks that premise.

In all of the scenarios discussed in Section 1, a prefix that was 
originally valid, has become invalid.

In principle, when a prefix is advertised via SLAAC, it means "you can 
use this prefix for 'Valid Lifetime', unless you hear otherwise from 
me". For a number of reasons, hosts may not hear otherwise from the 
router -- whether because the router fails to signal that condition, or 
because hosts fail to receive that notification. Besides, as noted in 
the document, the current spec prevents hosts from honoring Valid 
Lifetimes smaller than two hours.



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

Not really. Different routers may employ different lifetimes for the 
prefixes they advertise. And a given router may also employ different 
lifetimes for the different prefixes it advertises. So comparing the 
advertised lifetimes of two different prefixes is not meaningful.

Please see: 
https://tools.ietf.org/html/draft-ietf-6man-slaac-renum-01#appendix-A.2 
for further details.



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

FWIW, I would expect that part to be somehow addressed by including 
RFC4861 and RFC4862 as normative references.

That said, I guess one could add something like this to the Intro:

"IPv6 Stateless address autoconfiguration (SLAAC) [RFC4862] conveys 
information about prefixes to be employed for address configuration via 
Prefix Information Options (PIOs) sent in Router Advertisement (RA) 
messages".

Would that do?



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

Will do.



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

There's not really a standard for timeliness. Throughout the document, 
whenever we refer to something as "timely" we mean: "a period of time 
that seems sensible to the user".

For example, at come I use this:
  Prefix                   : xxxxxxxxxxxxxxxx::/64
   On-link                 :          Yes
   Autonomous address conf.:          Yes
   Valid time              :         1800 (0x00000708) seconds
   Pref. time              :          900 (0x00000384) seconds

That is, 30 minutes for the valid lifetime, and 15 minutes for the 
preferred lifetime.

I have experienced the problem described in our document recently. 
However, it only happens (if it does), when I reboot my router. Since 
that, whether explicitly or implicitly (as a result of a blackout) is 
not happening frequently 15' (at most) to prefer a newer address or 30' 
(at most) to completely get rid of old addresses is good enough.

If the problem happened more frequently, I would certainly reduce such 
values probably to a half of the current values.



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

How about s/invalidate/deprecate/?




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

FWIW, we're not really delving into such details, but rather simply 
noting that, whenever you use a timer in a protocol, you do it in a way 
that the timer goes off at a time when there's direct correlation with 
an associated event (e.g. "something is wrong") - that's irrespective of 
whether the fault is visible by the upper layers or not.

Put another way: there is no point in setting a timer if the timer will 
go off at a time that will likely have no correlation with the event 
that caused the timer to go off, or at a time where addressing the issue 
that caused the timer to go off does not make sense anymore.

e.g., you wouldn't set TCP's RTO to 30 days...




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

Not sure what you mean. Could you clarify?



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

Here we mean that, in practice, the signal is ignored. (the packet *is* 
received and processed, but as per the current specs, hosts would reduce 
the Valid Lifetime further than two hours). Nowadays, there are 
implementations that are not compliant with the specs in this respect.. 
so some implementations would honor the signal, while others would not.



> 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?
Please see my note about regarding "timeliness".

The values represent a tradeoff. As you reduce them, you increase 
responsiveness, but also typically lower robustness with respect to 
packet loss. And if you retransmit RAs more frequently, you e.g. harm 
battery life of mobile devices.

So this are values that result in prefixes being deprecated in a 
timelier manner, while being within the current specs and BCPs 
(RFC4861/RFC7772).  If needed, we could note this, or add a reference to 
[draft-ietf-v6ops-cpe-slaac-renum] where we discuss this.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492