[v6ops] Genart last call review of draft-ietf-v6ops-slaac-renum-03

[Dale Worley via Datatracker <[e-mail]>]

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.

   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.

   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.

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.

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

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

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

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?

[END]