Skip to main content

Last Call Review of draft-ietf-v6ops-slaac-renum-03
review-ietf-v6ops-slaac-renum-03-opsdir-lc-schoenwaelder-2020-09-09-00

Request Review of draft-ietf-v6ops-slaac-renum
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2020-09-09
Requested 2020-08-26
Authors Fernando Gont , Jan Zorz , Richard Patterson
I-D last updated 2020-09-09
Completed reviews Secdir Last Call review of -03 by Klaas Wierenga (diff)
Genart Last Call review of -03 by Dale R. Worley (diff)
Opsdir Last Call review of -03 by Jürgen Schönwälder (diff)
Iotdir Telechat review of -04 by Ted Lemon (diff)
Intdir Telechat review of -04 by Sheng Jiang (diff)
Assignment Reviewer Jürgen Schönwälder
State Completed
Request Last Call review on draft-ietf-v6ops-slaac-renum by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/2ihgH9_u6rdB7zVgdrtEf4u2r-M
Reviewed revision 03 (document currently at 05)
Result Has issues
Completed 2020-09-09
review-ietf-v6ops-slaac-renum-03-opsdir-lc-schoenwaelder-2020-09-09-00
I have reviewed draft-ietf-v6ops-slaac-renum-03 as part of the ops-dir
review efforts. The document addresses a problem that is of certain
operational relevance. This document is labeled as informational.

Perhaps indicate a bit earlier what unacceptably long means, i.e. we
are talking about days and weeks. The scenarios described read a bit
like somewhat rare events and hence it is useful for the reader to
have an idea what unacceptably long means in such events. (BTW, I find
the scenario not described at the beginning where a router announces
SLAAC lifetimes that are not synchronized with obtained prefix
lifetimes operationally the more tricky problem since this can lead to
regular failures.)

Section 2.2 seems to confuse soft-state (this is what a learned IPv6
prefix is for me) with certain protocol timers. There are many places
where protocols use soft-state and implementations use timers to purge
or refresh soft-state. That timers generally do not go off in normal
conditions is not really correct in this context, DHCP leases are
renewed when their lifetime expires, a normal operation. IP address
mappings to Ethernet addresses expire when their lifetime timer goes
off. Switches purge forwarding state regularly when forwarding entries
expire. Cached DNS name to IP resolutions expire. The only problem
here seems to be that a lifetime of 7 days / 30 days is a bit
ridiculous. Is anyone shipping the RFC 4861 defaults? The few
implementations I have seen do use a bit more reasonable defaults.  I
think this section should be rewritten to replace the "timer going off
is associated with a failure" text with a discussion of	soft-state in
other protocols. (Section 2.2 is why I ticked 'has issues'.)

Isn't a part of the solution (other than moving to less ridiculous
default) that SLAAC hosts experiencing connectivity problems should
try to validate the prefix that they have learned (and if the
validation fails move to a newly learned prefix)? Involving the hosts
in a resolution of the problem may be	more robust than expecting that
something in the network takes care of invalidating stale soft-state.
Well, this comment is likely outside the scope of this problem
statement document.