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

From: Owen DeLong <[email-masked]>
Date: Thu, 3 Sep 2020 01:59:48 -0700

> On Aug 30, 2020, at 6:14 PM, Dale Worley via Datatracker <[email-masked]> 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

---

From: Owen DeLong <[email-masked]>
Date: Thu, 3 Sep 2020 01:59:48 -0700

Owen

---

From: Ole Troan <[email-masked]>
Date: Thu, 3 Sep 2020 12:14:26 +0200

> On 3 Sep 2020, at 11:03, Owen DeLong <[email-masked]> wrote:
> 

Just wanted to correct this misunderstanding. The PIO is used for on-link determination and would therefore typically be present, independently of SLAAC being enabled for the prefix or not. 

Cheers 
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 3 Sep 2020 12:14:26 +0200

Cheers 
Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 03 Sep 2020 13:16:22 +0200

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

The obvious thing to do is to make sure that the old prefix is deprecated.
Existing flows can continue to use the old address because explictly select
that address as source address, new flows that let the system select an
address will get the new prefix.

> 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 dont deprecate the prefix, you have a
> situation where the user may well be suffering for at least two

There are two lifetimes: the preferred lifetime and the valid lifetime.
The two hour limit only applies to the valid lifetime. (RFC 4862,
Section 5.5.3)

So an address can always be deprecated (preferred lifetime is zero),
but it will remain valid for 2 hours or the current valid lifetime,
which ever is less.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 03 Sep 2020 13:16:22 +0200

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Sep 2020 09:32:22 -0300

Hello, Dale,

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

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

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

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

> forget their previous configuration, rather than withdrawing it

Will do.

> or a statement made that such a discussion needs to be undertaken as

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.

> addressing it configures.  So the described mechanism needs to be

How about s/invalidate/deprecate/?

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

> paragraph, and it would be clearer just starting with "Under problematic

Not sure what you mean. Could you clarify?

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

> but no such standard has been discussed.  > It's also unclear why this
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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Sep 2020 09:32:22 -0300

Hello, Dale,

Please see: 

Would that do?

Will do.

Thanks!

Regards,

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 03 Sep 2020 21:11:31 -0400

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

You're welcome!

To be clear, I'm not disagreeing with you about any of this as questions
of *fact*, but rather saying that these points are obscure to people who
aren't familiar with the practicalities, and it may help the work to
explicate them.

> Lifetimes smaller than two hours.

OK, but it would seem to be a violation for a router to advertise a
Valid Lifetime of X unless it had obtained from its upstream provider a
guarantee that it owned that prefix for X.  Since there's never a
guarantee that a host will be able to "hear otherwise" in the future,
it's never safe to give a host an assignment that extends beyond the
time that you know it's valid.  ...  I suspect that in fact routers
don't adhere to this rule, but if so, it seems like something you should
underline as being one root cause, and perhaps list it as an item to be
investigated in future work.

> https://tools.ietf.org/html/draft-ietf-6man-slaac-renum-01#appendix-A.2 

I see the point.  But it seems to me that the sentence should be
modified to "may", unless the current practices cause continuing use of
the previous prefix to be *more likely*.  In the latter case, you
probably want to insert the reference you give.

> Prefix Information Options (PIOs) sent in Router Advertisement (RA) 

Yes, I was starting to suspect that SLAAC and RA were actually the same
thing.  Though I'd un-passive-ize it by writing:

"In IPv6 Stateless address autoconfiguration (SLAAC) [RFC4862], routers
convey to hosts on their networks information about prefixes to be
employed for address configuration via Prefix Information Options (PIOs)
sent in Router Advertisement (RA) messages".

> values probably to a half of the current values.

Of course, the question is intrinsically vague.  But section 3.2 lists
specific values, giving no particular ratinale, and then states "they
will not lead to a timely recovery from the problem discussed in this
document."  It seems like a remarkably concrete assertion; literally,
the statement is absolute.  And also, if those values aren't
satisfactory, why does the document mention them?  It would seem more
useful to give values that one wanted to propose as giving timely
action, and then note that there are tradeoffs and other values may be
better in various situations.

> How about s/invalidate/deprecate/?

What I'm trying to get at is that the routers might send such RAs, but
since the hosts are rquired to not act on them, it should have no effect
and it isn't really a mechanism.  In particular, I suspect that some
routers send messages like this (which they shouldn't), and some hosts
violate the standard (or at least extend it) by acting on those messages
(either by abandoning the prefix or by deprecating it relative to other
prefixes).  Whatever it is should be explicated, because it's not in the
RFCs, but it is part of current practice.

> Not sure what you mean. Could you clarify?

I was thinking of updating the text to read:

   Under problematic circumstances,
   such as where the corresponding network information has become ...

The previous sentence is "Under normal network conditions, these timers
will be reset/refreshed to the default values." and to include it would
require some reworing, and I'm not sure it would add enough value to be
worth it.  In particular, the previous sentences talk about the default
values that are put into PIOs, which of course are not themselves reset
or refreshed.  So you'd have to say "Under normal network conditions,
the Pref. Life. and Val. Life. timers in hosts are periodically
reset/refreshed to the values in the PIOs, which are usually the default
values."

> received and processed, but as per the current specs, hosts would reduce 
assuming that there is "not" here:                                 ^
> so some implementations would honor the signal, while others would not.

IMO it would be quite useful to mention here that there are noncompliant
implementations, and if possible, describe how they are noncompliant.
Because that's part of the landscape within which this work is needed.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 03 Sep 2020 21:11:31 -0400

You're welcome!

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 03 Sep 2020 22:40:26 -0400

Owen DeLong <[email-masked]> 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.

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

> depending on circumstance and/or configuration.

Probably worth stating explicitly.

> this case is actually subjective, I’m not sure that such clarification is

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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 03 Sep 2020 22:40:26 -0400

Dale

---

From: Fernando Gont <[email-masked]>
Date: Sun, 6 Sep 2020 09:40:33 -0300

Hello, Dale,

> aren't familiar with the practicalities, and it may help the work to

Thanks for raising them! -- I'm all for improving the document where 
possible...

>> Lifetimes smallerFernando AND Gont than two hours.
> 
> guarantee that it owned that prefix for X.

In e.g. the case of the home router scenario, the home router does 
obtain a promise from the upstream. However, at some point some event 
happens (see the bulleted list in Section 1), and the promise is broken.

It is not that the systems involved were meant to break the promise, but 
rather that the operational reality caused the promise to be broken.

Should we add something like:

"We note that while IPv6 network renumbering is expected to take place 
in a planned manner, flash-renumbering scenarios such as the ones 
described above are nevertheless an operational reality."

?

>  Since there's never a

Please see above.

> probably want to insert the reference you give.

Yep, current practice makes it more likely. Note: I wouldn't mind 
including the reference. However, as noted in the referenced Section, 
such text is expected to be removed before publication....

That aside, I wonder which part you think would need clarification:
* Why nodes don't pick the source address based on the lifetime value?
* Why they keep using the first address?

> sent in Router Advertisement (RA) messages".

May I simplify the text as:
"In IPv6 Stateless address autoconfiguration (SLAAC) [RFC4862], routers
convey information about prefixes to be employed for address 
configuration via Prefix Information Options (PIOs) sent in Router 
Advertisement (RA) messages".

?

>>     Autonomous adFernando AND Gontdress conf.:          Yes
> document." 

How about changing that sentence to:
  "  However, while the aforementioned values represent an improvement
     over the default values specified in [RFC4861], they represent a 
trade-off among a number of factors, including responsiveness, possible 
impact on the battery life of connected devices [RFC7772], etc. Thus, 
they may or may not provide sufficient mitigation to the problem 
discussed in this document.
"

?

> It seems like a remarkably concrete assertion; literally,

Please let me know if the above would work better...

> RFCs, but it is part of current practice.

In retrospective, maybe the text was a bit imprecise in this respect.

It should probably have said:

"Some devices have implemented ad-hoc mechanisms to try to mitigate this
problem, such as sending RAs with a Preferred Lifetime of zero and a 
small Valid Lifetime to try to deprecate and phase out the 
apparently-stale prefixes"

Indeed, that's what the box being referenced is doing: 
https://www.si6networks.com/2016/02/16/quiz-weird-ipv6-traffic-on-the-local-network-updated-with-solution/

Thoughts?

> reset/refreshed to the values in the PIOs, which are usually the default

This seems to convey a different meaning... What we mean to say, in line 
with the earlier discussion on the use of timers is:: "when everything 
is okay, these timers will be refreshed. NOw.. if there's any problem, 
these timers will cause addresses to be deprecated at [X], and be 
invalidated at [Y]".

Am I missing something?

> Because that's part of the landscape within which this work is needed.

Since the currently-non-compliant behavior is being proposed in a 6man 
wg document (draft-ietf-6man-slaac-renum), how about adding this 
parenthetical note:

"  NOTE: Some implementations, such as [Linux-kernel], do not comply 
with this requirement from [RFC4862], but rather honor any value 
conveyed in a PIO, as proposed in [draft-ietf-6man-slaac-renum]."

Thoughts?

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 6 Sep 2020 09:40:33 -0300

Hello, Dale,

?

Please see above.

?

?

Thoughts?

Am I missing something?

Thoughts?

Thanks!

Regards,

---

From: Owen DeLong <[email-masked]>
Date: Wed, 30 Sep 2020 19:14:44 -0700

> but it will remain valid for 2 hours or the current valid lifetime,

Yes, I conflated some terms… Sorry…

To be clear:

Some routers send PIOs in RAs with a valid lifetime of 0 and some systems erroneously process that and invalidate said prefix. This violates RFC4862 and is a potential DOS vector. If you invalidate the prefix, you have weaponized RAs as discussed in RFC4862.

A deprecated valid prefix that actually should be invalid will cause less suffering than a non-deprecated prefix in the same circumstance, but the no-win situation I was describing remains.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 30 Sep 2020 19:14:44 -0700

To be clear:

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 30 Sep 2020 20:23:31 -0700

> text firmly assert that certain particular values, without qualificaton,

One can be quite certain that a user will not wait for 3 days for a web page to load without being certain whether the user will wait 30 seconds, 1 minute, 3 minutes, or even 1 hour.

It’s very easy to call 3 days untimely in such a case. It is very hard to draw a clear line among the lower values.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 30 Sep 2020 20:23:31 -0700

Owen