Subject: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 08:59:33 -0300

Folks,

In this recent thread on cpe-slaac-renum, there was a proposal to add 
text to the draft, and I promised I would start a new thread just in 
case somebody missed the chance to review in the rather long thread.

This text is meant to reflect the comments from Philip, Lorenzo, and 
others (please do let me know if I misunderstood what you mean). The 
text is:

---- cut here ----
The Valid Lifetime and Preferred Lifetime of PIOs have direct impact on 
two different aspects:

* The amount of time hosts may end up employing stale network 
configuration information (see [draft-ietf-v6ops-slaac-renum]).

* The amount of time Customer Edge routers would need to persist trying 
to deprecate stale network configuration information (to handle cases 
where nodes miss Router Advertisements and thus still consider the stale 
information as valid).

As a result, CPE Routers SHOULD override the default "Preferred 
Lifetime" and "Valid Lifetime" values from [RFC4861], and employ shorter 
values to mitigate the aforementioned effect, while complying with the 
requirement from Section 2.1 of this document, and the recommendations 
in RFC7772. This document RECOMMENDS that Customer Edge Router set the 
Router Lifetime and PIO Preferred Lifetime to 2700 seconds (45 minutes) 
and the PIO Valid Lifetime to 86400 seconds (1 day).

We note that a CPE Router need not employ the (possibly long) DHCPv6-PD 
lease times in the Valid Lifetime and Preferred Lifetime of PIOs sent in 
Router Advertisements messages to advertise sub-prefixes of the leased 
prefix. Instead, CPE Routers SHOULD use shorter values for the Valid 
Lifetime and Preferred Lifetime of PIOs, since subsequent Router 
Advertisement messages will nevertheless refresh the associated 
lifetimes, leading to the same effective lifetimes as specified by the 
DHCPv6-lease time.
--- cut here ----

The above change tackles to different issues:

* Saner lifetimes that at least allow for proper garbage collection in a 
timelier manner.

* In the typical scenario (but depending on DHCPv6 server parameters), 
the DHCPv6-PD leased will be longer than the PIO lifetimes advertised by 
the CE Router, and the CE Router will renew the prefix lease well before 
the PIO lifetimes need to be adjusted/reduced (to avoid having PIO 
lifetimes that span past the dhcpv6-pd lease). The result is that, in 
practice, the CE Routers would send RAs that always contain the same 
lifetime values, thus avoiding the battery consumption problem mentioned 
by Lorenzo.

Thoughts?

Thanks!

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Apr 2020 14:57:39 +0000

A few comments:

1. One reason to cap the lifetime(s) in the CPE for RAs is that while the SP could adjust the lifetimes, that has a direct impact on the amount of DHCPv6 traffic as reducing the preferred lifetime will cause the renewals to occur more frequently. That is one reason why SPs do not use short preferred lifetimes. (Some SPs have many millions of CPEs.)

2. I do wonder whether leaving the valid lifetime alone is better than playing with both lifetimes. For most applications that don't require long lived addresses, it achieves the desired effect. For those that want long lived addresses, it allows for that (if case of outages longer than the capped valid lifetime) -- and if the application decides to try for a new address, it will use one in a new prefix if one was advertised.

- Bernie 

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Fernando Gont
Sent: Wednesday, April 8, 2020 8:00 AM
To: IPv6 Operations <[email-masked]>
Subject: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes

Folks,

In this recent thread on cpe-slaac-renum, there was a proposal to add text to the draft, and I promised I would start a new thread just in case somebody missed the chance to review in the rather long thread.

This text is meant to reflect the comments from Philip, Lorenzo, and others (please do let me know if I misunderstood what you mean). The text is:

---- cut here ----
The Valid Lifetime and Preferred Lifetime of PIOs have direct impact on two different aspects:

* The amount of time hosts may end up employing stale network configuration information (see [draft-ietf-v6ops-slaac-renum]).

* The amount of time Customer Edge routers would need to persist trying to deprecate stale network configuration information (to handle cases where nodes miss Router Advertisements and thus still consider the stale information as valid).

As a result, CPE Routers SHOULD override the default "Preferred Lifetime" and "Valid Lifetime" values from [RFC4861], and employ shorter values to mitigate the aforementioned effect, while complying with the requirement from Section 2.1 of this document, and the recommendations in RFC7772. This document RECOMMENDS that Customer Edge Router set the Router Lifetime and PIO Preferred Lifetime to 2700 seconds (45 minutes) and the PIO Valid Lifetime to 86400 seconds (1 day).

We note that a CPE Router need not employ the (possibly long) DHCPv6-PD lease times in the Valid Lifetime and Preferred Lifetime of PIOs sent in Router Advertisements messages to advertise sub-prefixes of the leased prefix. Instead, CPE Routers SHOULD use shorter values for the Valid Lifetime and Preferred Lifetime of PIOs, since subsequent Router Advertisement messages will nevertheless refresh the associated lifetimes, leading to the same effective lifetimes as specified by the DHCPv6-lease time.
--- cut here ----

* Saner lifetimes that at least allow for proper garbage collection in a timelier manner.

* In the typical scenario (but depending on DHCPv6 server parameters), the DHCPv6-PD leased will be longer than the PIO lifetimes advertised by the CE Router, and the CE Router will renew the prefix lease well before the PIO lifetimes need to be adjusted/reduced (to avoid having PIO lifetimes that span past the dhcpv6-pd lease). The result is that, in practice, the CE Routers would send RAs that always contain the same lifetime values, thus avoiding the battery consumption problem mentioned by Lorenzo.

Thoughts?

Thanks!

Cheers,

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 12:12:21 -0300

On 8/4/20 11:57, Bernie Volz (volz) wrote:
[...]
> 1. One reason to cap the lifetime(s) in the CPE for RAs is that while the SP could adjust the lifetimes, that has a direct impact on the amount of DHCPv6 traffic as reducing the preferred lifetime…

Agreed. Maybe one might add a sentence about this?

> 2. I do wonder whether leaving the valid lifetime alone is better than playing with both lifetimes. For most applications that don't require long lived addresses, it achieves the desired effect. Fo…

Reality is that, once you have an outage of over 15', all your TCP 
sessions will be aborted, anyway. So having long valid lifetimes will 
not buy you anything in that respect.

In that sense, you'd be well enough with a Valid Lifetime of 2 * Router 
Lifetime.

The reason why we left the Valid Lifetime to a rather long value (1 day) 
is mainly for the case where you want to use such prefix for local 
communications.

However, strictly speaking, you should be using link-locals for that 
(but I realize there are issues associated with the fact that they 
require an interface to be specified along with the address) or, better, 
you should be using ULAs.

I guess, if one wanted a finer-grained recommendation, one might unfold 
the recommendation for GUAs vs. ULAs. With GUAs, you want more timely 
information. With ULAs, you don't really care that much, because it's 
local addressing (isolated from your ISP).

Going back to your orignal comment: if you don't do garbage collection 
(i.e. reasonable Valid Lifetime) on your prefixes/addresses, then that 
means you wouldn't be able to communicate with the new "owner"/user of 
the prefix -- because you consider that prefix to be local/on-link.
I'm not saying that I think there's a lot of chances that you might 
need/want to communicate with the new user of the prefix. But if for 
some reason (plain bad luck? :-) ) you needed, then you couldn't.

(that's why you don't want one-month valid lifetimes for PIOs)

Thanks,

---

From: [email-masked]
Date: Wed, 8 Apr 2020 20:02:21 +0200

> Going back to your orignal comment: if you don't do garbage collection (i.e. reasonable Valid Lifetime) on your prefixes/addresses, then that means you wouldn't be able to communicate with the new "owner"/user of the prefix -- because you consider that prefix to be local/on-link.
> I'm not saying that I think there's a lot of chances that you might need/want to communicate with the new user of the prefix. But if for some reason (plain bad luck? :-) ) you needed, then you couldn't.
> 

No, that's why the delegator needs to remove those prefixes properly. I.e. by including them in DHCP with lifetime of 0.
In the flash renumbering case, the delegator will set the lifetime to 0 from whatever it was before. No need to "wait out" the lifetime.

Long valid lifetimes affect what you put in DNS as TTL for the record for example.

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Apr 2020 14:27:42 -0400

> Long valid lifetimes affect what you put in DNS as TTL for the record for example.

Okay, but you are talking about a very different operational use case.  This is how you would do things in a data center.

In the case of a CPE router, it’s not safe to assume the router won’t be unplugged or power cycled.  You probably don’t _want_ to use long TTLs on domain names, if any are published—e.g., for mDNS we use a TTL of 75 minutes, and do a refresh at 60 minutes; we do the same thing for Service Registration Protocol (DNS updates for DNSSD), although that’s not widely deployed at present.

So in this case, where your device may be power cycled and lose its state, or where the end user may simply unplug one device and plug in another, having a really long preferred lifetime makes zero sense.  Obviously, having a shorter lifetime does not solve the problem of cleaning up stale prefixes fast enough to prevent routing problems, but we still want those stale prefixes to be cleaned up.  As you say, there are two different issues here.  Reasonably short address lifetimes avoids keeping addresses around for a month when they are stale and aren’t going to be explicitly deprecated.  For source address selection and route selection, this doesn’t help, but it’s still worth doing.

---

From: [email-masked]
Date: Wed, 8 Apr 2020 20:37:55 +0200

Ted,

> So in this case, where your device may be power cycled and lose its state, or where the end user may simply unplug one device and plug in another, having a really long preferred lifetime makes zero…

You seem to be implying something here.
Why does it matter if a CPE is unplugged or power cycled? (Well, apart from the obvious of being unable to forward packets for the duration).

Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Apr 2020 14:43:29 -0400

> Why does it matter if a CPE is unplugged or power cycled? (Well, apart from the obvious of being unable to forward packets for the duration).

It matters if the CPE doesn’t maintain state between power cycles, and gets a different prefix when it comes back. And it matters if the CPE is swapped out without a clean shutdown that would result in the prefix being deprecated, and subsequently gets a different prefix from the ISP.   In both of these cases, we want the old prefix to go away sooner than a month.  This doesn’t absolve us of having to do the work to make sure that things work while that prefix is still present, but we should also be letting it die cleanly.

I suppose the counterargument would be that if it’s still valid, we still want to use it for existing connections, but it seems unlikely that this could work in either of the situations I’m describing.

---

From: [email-masked]
Date: Wed, 8 Apr 2020 20:56:00 +0200

> I suppose the counterargument would be that if it’s still valid, we still want to use it for existing connections, but it seems unlikely that this could work in either of the situations I’m describ…

Right, so the broken operational practice of flash renumbering without deprecating the old prefix approach to PD.
Let's make clear that's neither the recommended nor the typical way ISPs operate their networks.

In a typicaly deployment swapping CPEs or power cycling them does of course not affect the delegated prefix.

Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Apr 2020 15:03:47 -0400

On Apr 8, 2020, at 2:56 PM, [email-masked] wrote:
>>>> power cycled.  You probably don’t _want_ to use long TTLs on domain names, if any are published—e.g., for mDNS we use a TTL of 75 minutes, and do a refresh at 60 minutes; we do the same thing for Service Registration Protocol (DNS updates for DNSSD), although that’s not widely deployed at present.
>>>> 

Is it true that this is flash renumbering?  Where in the PD spec does it say that the server has to give the same CP (customer premises) the same prefix?  How does it identify the CP if the CPE has changed?  I know that there are ways to do that, but there is no RFC I know of that says how to do that, or that requires that this be done.

Does the PD spec say that the ISP has to give the CPE the same prefix, assuming that it _can_ identify it?

As I said earlier, I think it’s the case that if a PD is issued, the DHCP server has to honor it until it’s no longer valid, but unless we require that it return the same prefix in this case when the CPE device doesn’t explicitly ask for it, there is a significant gap here.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 16:16:51 -0300

On 8/4/20 15:56, [email-masked] wrote:
> Let's make clear that's neither the recommended nor the typical way ISPs operate their network
This seems to disagree with your claim: 
https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf

Thanks,

---

From: [email-masked]
Date: Wed, 8 Apr 2020 21:17:40 +0200

> As I said earlier, I think it’s the case that if a PD is issued, the DHCP server has to honor it until it’s no longer valid, but unless we require that it return the same prefix in this case when t…

Sorry, I don't see the gap.
All deployments I am aware of use the remote-id / option-82 equivalent option to identify subscribers.
Most operators are a lot more clueful about this than us here.

Think of PD as a contract. The ISP promises to lease the prefix to the subscriber for the time stated.
The ISP can still do flash renumbering (although that's likely to induce a customer call) in two ways.
One, just ignore it's earlier promise and give the subscriber a new prefix (which introduces all the problems Fernado wants to use prefix lifetimes to solve), or it can include the old prefix with lifetimes 0 (violating it's earlier promise, but at least being explicit) and advertise a new prefix.

Cheers,
Ole

---

From: [email-masked]
Date: Wed, 8 Apr 2020 21:20:43 +0200

> This seems to disagree with your claim: https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf

That presentation recommends persistent prefixes. My point exactly.

Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Apr 2020 19:27:51 +0000

> All deployments I am aware of use the remote-id / option-82 equivalent option to identify subscribers

Yes, that identifies the subscriber. But that is not the same as identifying the CPE. We do, after all, have a client identifier option (1) which is based on the DUID.

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, April 8, 2020 3:18 PM
To: Ted Lemon <[email-masked]>
Cc: Fernando Gont <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 16:29:51 -0300

On 8/4/20 16:20, [email-masked] wrote:
[...]
> That presentation recommends persistent prefixes. My point exactly.

You seem to read what you want to read: this presentation that 37% of 
the responding ISPs employ dynamic prefixes.

Yes, the presentation recommends stable prefixes. -- we also recommend 
IPv6 deployment (such recommendation hasn't avoided the problem we are 
trying to solve, in a similar vein that our recomendation to deploy IPv6 
hasn't materialized as expected).

Reality check?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Apr 2020 19:32:11 +0000

And, I should have added ... how does the SP know that you replaced your CPE instead of adding a second.

At least in some deployments (such as DOCSIS) there's nothing necessarily that precludes you from having multiple CPEs behind a CM.

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 8, 2020 3:28 PM
To: [email-masked]; Ted Lemon <[email-masked]>
Cc: Fernando Gont <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, April 8, 2020 3:18 PM
To: Ted Lemon <[email-masked]>
Cc: Fernando Gont <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] cpe-slaac-renum: Proposed text for prefix lifetimes

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Apr 2020 15:32:18 -0400

> One, just ignore it's earlier promise and give the subscriber a new prefix (which introduces all the problems Fernado wants to use prefix lifetimes to solve), or it can include the old prefix with…

I’m trying to figure out why this is such an utterly unsatisfying response.  Yes, I get that in the ideal case, which is what you are describing here, there is no problem.  But you are missing _all_ of the edge cases.  And you’re assuming that things on a home network are a lot cleaner than I think is safe to assume.

So yes, in the case you describe, where everything is done correctly, there is no problem.  I would not expect to see the persistent prefix problem routinely.  But I think it’s worth designing for—there are a lot of reasons why renumbering might happen in a way that is not as clean as you’re saying it should be, and we ought to handle it gracefully when it happens.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Wed, 08 Apr 2020 20:40:09 +0100

On 8 Apr 2020, at 19:56, [email-masked] wrote:

> Right, so the broken operational practice of flash renumbering without 
> deprecating the old prefix approach to PD.

Yes, please let this be made very clear!

> course not affect the delegated prefix.

Based on a sample size on one ISP, this is not true in my experience.

What I find is that any domestic power outage of about 15 minutes
or more involves renumbering, even though my router is configured
to send a hint for the prefix I want to re-use.

Such events occur perhaps once in a year or two: frequently enough
to be a nuisance, but not so frequently that I have a
well-established SOP for dealing with them.

/Niall

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 8 Apr 2020 19:44:32 +0000

Hi:

Ole, perhaps if there was a concrete proposal for an alternative approach, we would go there? So maybe this debate needs to be put on hold a bit to allow alternative approaches to come about. Though as stated earlier, some of this has been discussed for a while and I don't think there are any yet?

- Bernie

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 17:25:36 -0300

Hello, Niall,

Thanks a lot for your feedback! In-line...

[...]
> to send a hint for the prefix I want to re-use.

Indeed, that's in-line with the data that we have.

> well-established SOP for dealing with them.

In many parts this may happen easily once a week. So you might imagine 
the hassle this represents.

Thanks!

Cheers,

---

From: [email-masked]
Date: Wed, 8 Apr 2020 22:46:55 +0200

> So yes, in the case you describe, where everything is done correctly, there is no problem.  I would not expect to see the persistent prefix problem routinely.  But I think it’s worth designing for—…

s/ideal/typical/

This small problem has a couple of simple solutions:
 - change to an ISP that operate better
 - the CPE sends back an ICMP in these cases, it's just for the host to act upon it

You might find the response unsatisfying, because I think we need to focus on the wider problem. A solution to that would regardless solve the case above.

A host that has multiple addresses with different reachability is typical in IPv6. Every host is essentially multihomed. With ephemeral addresses.
The case you describe above is not any different from that. The host-stack/application needs to react to the connection not making progress and try a different SA/DA pair.
Similarly on initial connection.

You don't solve that problem by tweaking prefix lifetimes.

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 18:19:18 -0300

Hi, Bernie,

> Ole, perhaps if there was a concrete proposal for an alternative approach, we would go there? So maybe this debate needs to be put on hold a bit to allow alternative approaches to come about. Thoug…

We have discussed this for over a year now. Ole has repeatedly argued 
that this is not a problem, or that this is not a problem worth solving, 
because the networks that face these problems suffer from the 
incompetence/lack of knowledge of their admins/operators (even after 
multiple-statements from operators on why these scenarios take place). 
He deems these occurrences as rare, while concrete data and anecdotal 
evidence suggests 40% of deployments doing dynamic addresses. In such 
scenarios, he argues that the user should switch ISPs, when in so many 
different places I know of, there is no other ISP to switch to.

Now, the topic has been debated for over a year now. Nobody prevented 
anybody to come up with something better.. and as you correctly note, 
nobody did.

On our side, we kept working on this. A few folks (Jen and Philip to 
name a few) found flaws in our early proposal, and suggested 
improvements, which we did our best to incorporate.

We also discussed this with as many operators (this was discussed, IIRC, 
in RIPE, UKNOF, LACNOG..) and developers as possible, and received very 
positive feedback. And we also took the time to produce implementations 
of some of the improvements we propose (please see: 
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#section-6), 
or discuss this with developers that might want to improve SLAAC.

Maybe in order to honor the motto of "we reject kings", it would be time 
for the working group to be polled for adoption of this document. 
Certainly not to rubber-stamp it, but to continue polishing and 
improving it where/as appropriate.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Apr 2020 18:08:42 -0400

> s/ideal/typical/

NO.  You don’t get to assert what is typical. Your assertion doesn’t match what I am seeing from my own ISP, and apparently I am not alone in that.  And designing network protocols so that they only work in typical circumstances is not good practice.
> - change to an ISP that operate better

I have one choice of ISP.

> - the CPE sends back an ICMP in these cases, it's just for the host to act upon it

Can you explain this a bit more?

> You might find the response unsatisfying, because I think we need to focus on the wider problem. A solution to that would regardless solve the case above.

Porque no los dos?

> You don't solve that problem by tweaking prefix lifetimes.

And I didn’t say you did.  I said, I would like it if stale prefixes that aren’t coming back would be gc’d more rapidly than once every month.

I agree that just gc-ing stale prefixes doesn’t solve the problems you mention here.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 20:19:24 -0300

> I agree that just gc-ing stale prefixes doesn’t solve the problems you mention here.

It's explained here: 
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#appendix-B.1

And the idea is broken.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Apr 2020 19:33:18 -0400

I agree with your analysis about ICMPv6—thanks for that.  I think that the source address selection solution can work, though—it just requires a slightly more clever algorithm than the one you proposed and then rejected.  I described it in another message.

One thing that could be done with source address selection is that if an address fails the test I described (choose the loser only if its preferred lifetime is ten minutes longer than the incumbent), you could send a router solicit for the router that advertised that prefix; if there’s no response to the solicit, then deprecate the prefix, and when there are no more references to any address on the prefix, gc any remaining addresses on that prefix and the prefix itself.

Sent from my iPad

> On Apr 8, 2020, at 7:21 PM, Fernando Gont <[email-masked]> wrote:
> 
> It's explained here: https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#appendix-B.1
> 
> And the idea is broken.
> 
> 
> -- 
> Fernando Gont
> SI6 Networks

---

From: Owen DeLong <[email-masked]>
Date: Wed, 8 Apr 2020 16:38:49 -0700

If you don’t cap the valid lifetime, you won’t solve the battery life problem raised by Lorenzo, because RAs will be constantly counting down.

IMHO, it’s better to cap both lifetimes locally. As long as the router remains up, it’s going to get refreshed by the fresh RA anyway. I think that the lifetimes should be long enough that most CPE outages would likely be addressed (e.g. 9000 seconds = 2.5 hours, or, if you want to be more conservative, 86400 seconds = 1 full day).

If your only CPE went down for a day and nobody fixed it, loss of long-lived local flows is probably going to be the least of your problems.

These SHOULD be recommended values with a requirements for manufacturers to pick sane defaults for their target audience. Administrators SHOULD be able to configure different values according to their preferences.

Owen

> On Apr 8, 2020, at 07:57 , Bernie Volz (volz) <volz=[email-masked]> wrote:
> 
> A few comments:
>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 8 Apr 2020 16:47:29 -0700

If you have added a second, how would the ISP know whether it’s duplicate infrastructure for redundancy or phased swap (in which case you still want to delegate the same prefix) vs. a second independent set of networks (in which case a unique prefix would be necessary)?

Owen

> On Apr 8, 2020, at 12:32 , Bernie Volz (volz) <volz=[email-masked]> wrote:
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 9 Apr 2020 00:07:22 +0000

>    If you don’t cap the valid lifetime, you won’t solve the battery life problem raised by Lorenzo, because RAs will be constantly counting down.

Not sure I understand this. Yes, the valid lifetime in the RA would be changing, but how does that matter if the RA comes anyway? Either you sleep ignoring RAs or you are up and processing them. Also, if you cap the valid lifetime at 2.5 hours, an RA at time X has a lifetime which ends a X + 2.5h, and if another RA comes 1 minute later with a capped valid lifetime, it will now ends at X + 1m + 2.5h. How does this save battery life as it still is a time change?

The only way you would avoid a change in time is if the CPE also only updated the lifetime in the RAs periodically (i.e., send 2.5h, keep it counting down and at say 1.25h, reset to the 2.5h). Though even this is flawed as the lifetimes are relative and depending on when packets are received/processed and the clocks tick, you may have small (a few seconds) drift anyway.

Not sure why a device needs to listen to RAs while it wants to sleep. When it wakes up, it can always do an RS (if it finds it hasn't moved as the Wifi is still there). This seems to be what https://www.rfc-editor.org/rfc/rfc6775.html#section-5.8.2 suggests to do.

- Bernie

On 4/8/20, 7:39 PM, "Owen DeLong" <[email-masked]> wrote:

    

    Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 8 Apr 2020 17:22:11 -0700

> On Apr 8, 2020, at 17:07 , Bernie Volz (volz) <[email-masked]> wrote:
> 

Without getting too deep into reiterating Lorenzo’s message, apparently there’s an optimization in a lot of portable/mobile devices that ignores duplicate RAs where nothing has changed using a lot less power than it takes to process a new RA.

If the RA valid lifetime is decrementing, then the phone will process it as a new RA.

Apparently the phone isn’t doing any math, just a straight compare of the original RA and the current one.

> The only way you would avoid a change in time is if the CPE also only updated the lifetime in the RAs periodically (i.e., send 2.5h, keep it counting down and at say 1.25h, reset to the 2.5h). Thou…

Or if you simply ignore the RA since it’s identical to the previous one. Yes, this means that the lifetime doesn’t get reset, but I’m guessing that phones using this optimization probably trigger an RS when the timers get close to 0.

Not sure of the details, feel free to ask Lorenzo.

> Not sure why a device needs to listen to RAs while it wants to sleep. When it wakes up, it can always do an RS (if it finds it hasn't moved as the Wifi is still there). This seems to be what https:…

IMHO, that’s perfectly fine, too. Again, it was a concern expressed by Lorenzo. If you have further questions on it, ask him. Nonetheless, by capping the valid timer, we get a few gains and I still don’t see a disadvantage to doin it.

Owen

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 21:33:01 -0300

Hello, Bernie,

> Not sure I understand this. Yes, the valid lifetime in the RA would be changing, but how does that matter if the RA comes anyway? Either you sleep ignoring RAs or you are up and processing them. Al…

Lorenzo explained that, somehow, if the RA is always the same, they can 
avoid waking up the mobile upon receipt of each RA. If the contents the 
RA change, this fails.

So,to illustrate the two extremes:
If the DHCP lease time is 1000 seconds (no reall.just for illustrative 
purposes), and you want RAs to reflect the total lifetime, then at time 
0 you'd send an RA/PIO of 1000, at time 1 an RA/PIO of 999, etc (i.e. 
the contents change all teh time).

Now, if you cap the PIO lifetimes to 100, then if the lease is 1000s, 
you'd advertise an RA/PIO of 100, at time 1 (while the "internally 
computed· lifetime at the CPE is 999), you still advertise an RA/PIO of 
100. *Only* at time 901 (and if you hadn't tried to RENEW the lease), 
you'd had to reduce the PIO lifetimes to 99, then 98, etc.,
But if the lease is renewed before both the PIO preferred and valid 
lifetime seconds have elapsed, you'd always send RAs with the same 
values. And this seems to be big savings for mobile phones.

That's how I understood the issue, at least. But Lorenzo or other folks 
might be in a better position to correct me or clarify further...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 21:57:34 -0300

> I agree with your analysis about ICMPv6—thanks for that.  I think that the source address selection solution can work, though—it just requires a slightly more clever algorithm than the one you prop…

FWIW, to be honest, the one described in the document had been proposed 
by Jen. So that's "the only one" that had been discussed, and hence made 
it into the appendix.

> One thing that could be done with source address selection is that if an address fails the test I described (choose the loser only if its preferred lifetime is ten minutes longer than the incumbent…

I will dig and try to find the specific message. Or, if you know which 
one it is, please do fwd to me.

There are two things to note here:
THe problem with comparing lifetimes is that:
1) In order to be able to compare two PIOs from e.g. two different CPES, 
you depend on both of them capping the PIO lifetimes (for the lifetimes 
to be comparable). And then you also need the host-side update.

This means that if update the host (simple, and doable in a timely 
manner) but are not employing updated CPEs, the mitigation doesn't work. 
(If I'm understanding it correctly).

OTOH, the algorithms from Section 4.5 of the draft only require 
host-side changes. As long as you implement them at the host, you 
already received the benefits.

In particular, the algorithm from section 4.5.1 is really striaghtforward:

  * Upon receipt of an RA that advertises new prefixes but not the 
previous one, you deprecate (un-prefer) the prefix/address (the I-D says 
to actually set the PL to a couple of seconds to accommodate the 
thoretical case where the information might be split into multiple RAs.. 
but in practice you wouldn't even need to wait at all). And you also set 
the Valid Lifetime to a value in the order one or a few dozen minutes 
(so, if meanwhile you receive an RA advertising the prefix, the 
addresses get refreshed... and otherwise, after that time has elapsed, 
you'd remove/invalidate them).

IN the typical case where e.g. the CPE crashes and reboots, as soon as 
the CPE has bootstrapped, the first initial RA will provve both a new 
prefix, but also deprecate (unprefer) the previous one. SO the only 
waiting time would be the dozen minutes or so for the address to be 
invalidated.

Of course, you could even augment this, and instead of passively waiting 
for a dozen minutes, you could send an RS after 5 minutes or so. But, 
unless I'm missing something, there wouldn't seem much to be gained.

FWIW, I see RFC6724 as doing the right thing. IMO the problem is that in 
current implementations, the preferred/deprecated "implict flag" is 
severely broken: the use og insanely long lifetimes really means that 
you don't really keep track of whether adresses are preferred or not: 
for all meaningul purposes all addresses are considered "preferred" 
(well, except the temporary addresses that you phase out)

If I have misunderstood your algorithm, please do let me know -- we're 
not married with any specific value, and meant to do the best we can.

Thanks!

Cheers,

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Apr 2020 21:09:53 -0400

You’re right about the two-cpe case.

Sent from my iPad

> On Apr 8, 2020, at 8:58 PM, Fernando Gont <[email-masked]> wrote:
> 
> FWIW, to be honest, the one described in the document had been proposed by Jen. So that's "the only one" that had been discussed, and hence made it into the appendix.
> 
> 
> I will dig and try to find the specific message. Or, if you know which one it is, please do fwd to me.
> 
> 1) In order to be able to compare two PIOs from e.g. two different CPES, you depend on both of them capping the PIO lifetimes (for the lifetimes to be comparable). And then you also need the host-side update.
> 
> This means that if update the host (simple, and doable in a timely manner) but are not employing updated CPEs, the mitigation doesn't work. (If I'm understanding it correctly).
> 
> OTOH, the algorithms from Section 4.5 of the draft only require host-side changes. As long as you implement them at the host, you already received the benefits.
> 
> 
> * Upon receipt of an RA that advertises new prefixes but not the previous one, you deprecate (un-prefer) the prefix/address (the I-D says to actually set the PL to a couple of seconds to accommodate the thoretical case where the information might be split into multiple RAs.. but in practice you wouldn't even need to wait at all). And you also set the Valid Lifetime to a value in the order one or a few dozen minutes (so, if meanwhile you receive an RA advertising the prefix, the addresses get refreshed... and otherwise, after that time has elapsed, you'd remove/invalidate them).
> 
> 
> IN the typical case where e.g. the CPE crashes and reboots, as soon as the CPE has bootstrapped, the first initial RA will provve both a new prefix, but also deprecate (unprefer) the previous one. SO the only waiting time would be the dozen minutes or so for the address to be invalidated.
> 
> Of course, you could even augment this, and instead of passively waiting for a dozen minutes, you could send an RS after 5 minutes or so. But, unless I'm missing something, there wouldn't seem much to be gained.
> 
> 
> FWIW, I see RFC6724 as doing the right thing. IMO the problem is that in current implementations, the preferred/deprecated "implict flag" is severely broken: the use og insanely long lifetimes really means that you don't really keep track of whether adresses are preferred or not: for all meaningul purposes all addresses are considered "preferred" (well, except the temporary addresses that you phase out)
> 
> 
> If I have misunderstood your algorithm, please do let me know -- we're not married with any specific value, and meant to do the best we can.
> 
> Thanks!
> 
> Cheers,
> -- 
> Fernando Gont
> SI6 Networks

---

From: Erik Kline <[email-masked]>
Date: Sun, 12 Apr 2020 20:09:16 -0700

Were slaac-renum and cpe-slaac-renum originally the same document but a
recommendation was made to split them?

If not, I personally don't see a problem with one ops document that both
describes the problem and provides operational recommendations that could
help ameliorate the issue.

But if a doc split was recommended I certainly don't want to reopen that
discussion.

On Wed, Apr 8, 2020 at 6:10 PM Ted Lemon <[email-masked]> wrote:

> >> I agree with your analysis about ICMPv6—thanks for that.  I think that
> the source address selection solution can work, though—it just requires a
> slightly more clever algorithm than the one you proposed and then
> rejected.  I described it in another message.
> >
> by Jen. So that's "the only one" that had been discussed, and hence made it
> into the appendix.
> >
> >
> >> One thing that could be done with source address selection is that if
> an address fails the test I described (choose the loser only if its
> preferred lifetime is ten minutes longer than the incumbent), you could
> send a router solicit for the router that advertised that prefix; if
> there’s no response to the solicit, then deprecate the prefix, and when
> there are no more references to any address on the prefix, gc any remaining
> addresses on that prefix and the prefix itself.
> >
> you depend on both of them capping the PIO lifetimes (for the lifetimes to
> be comparable). And then you also need the host-side update.
> >
> host-side changes. As long as you implement them at the host, you already
> received the benefits.
> >
> >
> previous one, you deprecate (un-prefer) the prefix/address (the I-D says to
> actually set the PL to a couple of seconds to accommodate the thoretical
> case where the information might be split into multiple RAs.. but in
> practice you wouldn't even need to wait at all). And you also set the Valid
> Lifetime to a value in the order one or a few dozen minutes (so, if
> meanwhile you receive an RA advertising the prefix, the addresses get
> refreshed... and otherwise, after that time has elapsed, you'd
> remove/invalidate them).
> >
> >
> prefix, but also deprecate (unprefer) the previous one. SO the only waiting
> time would be the dozen minutes or so for the address to be invalidated.
> >
> severely broken: the use og insanely long lifetimes really means that you
> don't really keep track of whether adresses are preferred or not: for all
> meaningul purposes all addresses are considered "preferred" (well, except
> the temporary addresses that you phase out)
> >
> >

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Apr 2020 00:46:18 -0300

Hello, Erik,

> recommendation was made to split them?

Yes, exactly. Originally it was a single document. Subsequently, upon 
suggestion of multiple wg participants, we were asked to split it into 
three:

* draft-ietf-v6ops-slaac-renum: Problem statement and operational
                                 mitigations.

* draft-ietf-vops-cpe-slaac-renum: CE Router reqs.

* draft-gont-6man-slaac-renum: Protocol updates.

[..]
> But if a doc split was recommended I certainly don't want to reopen that 

Yep, it was recommended. And a number of folks (Jen at others) were 
happy with the split.

Thanks,