Subject: [v6ops] Fwd: WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

From: Fernando Gont <[email-masked]>
Date: Thu, 2 Apr 2020 15:49:49 -0300

Hello, folks,

Long time no hear! I hope all of you and your beloved ones are fine in 
these crazy times.

v6ops is WGLC'ing one of the documents 
(https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-01) we 
have authored to improve the reaction of SLAAC to renumbering events. 
This document contains recommendations for Customer Edge Routers.

For background, you may want to consult: 
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01

If you have any comments/feedback, please do let us know. If possible, 
on the v6ops list (https://www.ietf.org/mailman/listinfo/v6ops)

Thanks!

Cheers,
Fernando

-------- Forwarded Message --------
Subject: 	[v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum
Date: 	Mon, 30 Mar 2020 15:47:14 +0000
From: 	Ron Bonica <rbonica=[email-masked]>
To: 	[email-masked] <[email-masked]>

Folks,

This message initiates a WG Last Call on draft-ietf-v6ops-cpe-slaac-renum.

Please submit comments by April 13, 2020.

                                    Fred and Ron

Juniper Business Use Only

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Apr 2020 08:54:47 -0700

Yes. In short, we had several people say that the topic was something they wanted to kick around, so we made it a working group draft. Ron and I are now looking for working group comments on it, in the absence of which we can't tell the IESG there is support. Are there any opinions on this document?

> On Apr 2, 2020, at 11:49 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hello, folks,
> 
> Long time no hear! I hope all of you and your beloved ones are fine in these crazy times.
> 
> v6ops is WGLC'ing one of the documents (https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-01) we have authored to improve the reaction of SLAAC to renumbering events. This document contains recommendations for Customer Edge Routers.
> 
> For background, you may want to consult: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01
> 
> If you have any comments/feedback, please do let us know. If possible, on the v6ops list (https://www.ietf.org/mailman/listinfo/v6ops)
> 
> Thanks!
> 
> Cheers,
> Fernando
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 3 Apr 2020 16:43:12 +0000

Hi:

I think this is useful work and did send comments to Fernando offline as minor nit (as part of comment on another document). Sorry, as I missed the fact that this was in WGLC.

Basically, in section 2.2, I think it should be made clear how long any stale configuration must be "retained" to send in RAs to assure that information is properly deprecated - which is that it must be retained until the longest valid lifetime it was ever advertised with has elapsed.

The above suggestion is in line with a related discussion for the draft-gont-6man-slaac-renum document, where perhaps the CPE should cap the lifetimes it advertises in RAs. Though it may also be something to consider adding to Section 2.1 of cpe-slaac-renum (i.e., a CPE may cap the lifetimes advertised in RAs). The current text only says that they must not be greater than the (remaining) DHCP lifetimes.

And I also just noticed there is a need to clean up the reference that still points to the individual submission:

   [I-D.gont-v6ops-slaac-renum]
              Gont, F., Zorz, J., and R. Patterson, "Reaction of
              Stateless Address Autoconfiguration (SLAAC) to Flash-
              Renumbering Events", draft-gont-v6ops-slaac-renum-02 (work
              in progress), February 2020.

It is somewhat confusing with the 3 documents (draft-ietf-v6ops-cpe-slaac-renum, draft-ietf-v6ops-slaac-renum, draft-gont-6man-slaac-renum) as they have similar names.

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of Fred Baker
Sent: Friday, April 3, 2020 11:55 AM
To: IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

> e-mail: [email-masked] || [email-masked] PGP Fingerprint: 
> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 3 Apr 2020 09:45:21 -0700

Support.

This is a topic that is worthy of being covered in an informational RFC and the consideration in this draft
is well done.

Owen

> On Apr 3, 2020, at 09:43 , Bernie Volz (volz) <volz=[email-masked]> wrote:
> 
> Hi:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Apr 2020 09:23:34 +1300

Hmm. I tend to think of WGLC as last call for objections, when a WG document has been in discussion for a while. But if you're looking for support, yes, this is very useful and I have no further technical comments.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 4 Apr 2020 22:46:51 -0300

Hello, Bernie,

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

On 3/4/20 13:43, Bernie Volz (volz) wrote:
[..]>
> Basically, in section 2.2, I think it should be made clear how long any stale configuration must be "retained" to send in RAs to assure that information is properly deprecated - which is that it mu…

I've added this note as a rationale:

RATIONALE:
Hosts on the local network may employ addresses configured for the 
previously advertised prefixes for at most the "Valid Lifetime" of the 
corresponding PIO of the last received Router Advertisement message. 
Since Router Advertisement messages may be lost or fail to be received 
for various reasons, Customer Edge Routers need to try to deprecate 
stale prefixes for a period of time equal to the "Valid Lifetime" of the 
PIO employed when originally advertising the prefix.

I wonder if this document should say something about the actual lifetime 
values, as in:

"CPE Routers should consider employing "Preferred Lifetime" and "Valid 
Lifetime" values for the prefixes they advertise that are shorter than 
the recommended default values in RFC4861. If shorter lifetimes are 
employed, they SHOULD be selected according to the criteria in Section 
2.1 of this document, and the recommendations in RFC7772."

Thoughts?

> The above suggestion is in line with a related discussion for the draft-gont-6man-slaac-renum document, where perhaps the CPE should cap the lifetimes it advertises in RAs. Though it may also be so…

Any thoughts about the proposed text above?

>                in progress), February 2020.

You mean to remove the reference since so far it's still an individual 
submission?  (If so, that's fine for me).

> It is somewhat confusing with the 3 documents (draft-ietf-v6ops-cpe-slaac-renum, draft-ietf-v6ops-slaac-renum, draft-gont-6man-slaac-renum) as they have similar names.

I completely agree. In retrospective, this was a very bad choice on my 
side. :-(

Thanks!

Cheers,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 5 Apr 2020 12:51:33 +0000

Hi ... inline below (BV>).

- Bernie

> On Apr 4, 2020, at 10:04 PM, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Bernie,
> 
> Hosts on the local network may employ addresses configured for the previously advertised prefixes for at most the "Valid Lifetime" of the corresponding PIO of the last received Router Advertisement message. Since Router Advertisement messages may be lost or fail to be received for various reasons, Customer Edge Routers need to try to deprecate stale prefixes for a period of time equal to the "Valid Lifetime" of the PIO employed when originally advertising the prefix.
> 
BV> seems good
> 
> I wonder if this document should say something about the actual lifetime values, as in:
> 
> "CPE Routers should consider employing "Preferred Lifetime" and "Valid Lifetime" values for the prefixes they advertise that are shorter than the recommended default values in RFC4861. If shorter lifetimes are employed, they SHOULD be selected according to the criteria in Section 2.1 of this document, and the recommendations in RFC7772."
> 
BV> probably premature until discussions about this settle down? Also, not sure which prefixes this refers to — dhcp obtained ones likely use (remaining) lifetimes from dhcp. And if dhcp, are you trying to indicate that shorter of dhcp remaining and defaults be used?
> You mean to remove the reference since so far it's still an individual submission?  (If so, that's fine for me).
> 
> 
BV> The v6ops document is now draft-ietf? 6man one is still individual submission.
> I completely agree. In retrospective, this was a very bad choice on my side. :-(
> 
> Thanks!
> 
> Cheers,
> -- 
> Fernando Gont

---

From: Fernando Gont <[email-masked]>
Date: Sun, 5 Apr 2020 10:04:40 -0300

Hi, Bernie,

On 5/4/20 09:51, Bernie Volz (volz) wrote:
[...]
>> Hosts on the local network may employ addresses configured for the previously advertised prefixes for at most the "Valid Lifetime" of the corresponding PIO of the last received Router Advertisemen…

OK, will add this to the next rev.

> BV> probably premature until discussions about this settle down?

Certainly, I wasn't thinking about recommending any specific value, but 
rather to suggest that they may consider using values other than the 
default ones. (i.e., if they have the knobs, they should be in a 
position to select something that works).

> Also, not sure which prefixes this refers to — dhcp obtained ones likely use (remaining) lifetimes from dhcp. And if dhcp, are you trying to indicate 
> that shorter of dhcp remaining and defaults be used?

What I have in mind is this:
Lets say that, at time t0, you get leased a prefix for one month. One 
option is to advertise the prefix via a PIO with a lifetime of one month 
(and reducing lifetime over time).
Another option is to advertise the prefix on the local network with a 
lifetime of, say, one hour. You'd keep advertising the prefix as such, 
until you get to t0 + 1 month - 1 hour. At which point you'd be 
decreasing the lifetimes of your RAs.

The difference here is that if you use the complete lifetime of the 
prefix lease, you'd probably advertise an insanely long value that is 
harder to recover from. Whereas if you never use lifetimes longer than, 
say, one hour, in the presence of a router crash hosts would use stale 
information for, at most, one hour.

i.e. the lifetimes in RA packets do not need to reflect the total 
lifetime of the prefix lease.

> BV> The v6ops document is now draft-ietf? 6man one is still individual submission.

Sorry, my bad. I think you meant that we should simply replace the 
reference to individual submission with the draft-ietf version. Is that 
correct?

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

---

From: tom petch <[email-masked]>
Date: Mon, 6 Apr 2020 10:54:30 +0000

Fred,

tricky.  There is a MUST or two with no mention of RFC2119.

There are references to updated behaviour but no Updates.

There is an impressive list of Acknowledgements of which I would expect at least some to have a view, favourable or otherwise.

'is based.earlier versions' looks odd

but at the end of the day, it all looks sensible except that I do not have the exposure to this and so find it hard to judge especially as this area of IPv6 seems to be an endless saga of change and more change and will this itself be updated again in a few months time?  I do not know.

Tom Petch
________________________________________
From: v6ops <[email-masked]> on behalf of Fred Baker <[email-masked]>
Sent: 03 April 2020 16:54
To: IPv6 Operations
Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

---

From: [email-masked]
Date: Mon, 6 Apr 2020 14:57:05 +0200

> Please submit comments by April 13, 2020.

0) Remove the reference to the individual draft in introduction.

1) the document proposes a workaround for the case where the service provider does not renumber the network correctly.
It would be useful to add a paragraph in the introduction describing the "correct" procedure. This to ensure that a reader would not be confused and think this is how the DHCP PD mechanism is intended to work.
I don't think there is a reference for that, I'm not sure we have written down the correct DHCP PD behaviour when doing instant renumbering?
Something like: "A network provider that has to renumber a customer network, must continue to include the old prefix in DHCP PD messages with lifetimes set to 0 for a while, to ensure that stale prefix information can be expired on hosts attached to the network".

2) Rewrite the document as an update to RFC7084. Make the new requirements as WPD-<nn>

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 6 Apr 2020 22:19:45 +0900

Based on a fair amount of experience with this sort of thing, this
recommendation is risky:

      *  The lifetime values advertised for prefixes corresponding to a
         prefix leased via DHCPv6-PD should be dynamically updated
         (rather than static values), since otherwise the advertised
         lifetimes would eventually span past the DHCPv6-PD lease time.

The reason is that there are many routers in the field that send RAs much
too often. There are many devices that send RAs at the maximum permitted
rate of one every three seconds (ironically, I think the reason for this is
to prevent the very "client loses connectivity" roblem this draft is trying
to solve). On a phone or smaller device, processing packets every 3 seconds
will destroy battery life. But because phone manufacturers could not fix
routers in the field, they reacted to this in different ways.

   1. Drop all packets / all multicast packets / all RA packets when the
   "device is not in use" (e.g., screen is off). Maybe send an RS when the
   screen turns on again.
   2. Drop RAs that are received too soon after an identical RA.
   3. Drop RAs that are received too soon after a similar RA (e.g., same RA
   but with different lifetime values).

#1 basically breaks IPv6 almost completely, because RAs will time out and
expire. Even if the device sends an RS again when the screen turns on,
connectivity might have been broken while the screen was off, because the
device might have dropped one or more RAs with a critical update. Devices
do need connectivity while the screen is off - for example, to receive
incoming calls and chat messages. #3 works but not all manufacturers
implement it. Android does this by providing the source code of a bytecode
interpreter to chipset vendors and downloading bytecode to the
interpreter based on previously-received RAs, but some chipset vendors
don't support this. I don't think iOS supports this either. Many devices do
#2. It sort of works as long as the RAs are identical. This is pretty
common because it's easy to do in wifi firmware and pretty much all wifi
chipsets support fixed-function filtering.

By recommending that lifetimes should be dynamically updated, this draft
will defeat devices that do #2. Based on past experience, a likely outcome
is that manufacturers will react by switching to #1 and dropping all RAs.
We should try to avoid making this problem worse with this draft.

The safest way to do so would be to remove this text. A bit less safe would
be to say that the device must cease to send RAs if the RA lifetime is
below the DHCPv6 PD lifetime. A bit less safe would be to say here that the
device MUST respect RFC 7772 and only send RAs once every few minutes. (The
reason that this isn't super safe is that in a simple router that just
glues together dhcpcd and dnsmasq/radvd, it's not easy to implement. The
DHCPv6 client and the RA daemon are two separate pieces of software written
by different authors, so transferring the DHCPv6 lifetime to the RA
lifetime requires getting the two to collaborate.) +Timothy Winters
<[email-masked]> any other suggestions?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 6 Apr 2020 22:27:42 +0900

Has this text:

   o  A CE router sending RAs that advertise dynamically-learned
      prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on
      stable storage, the list of prefixes being advertised on each
      network segment, and the "A" and "L" flags of the corresponding
      PIOs.

been run past manufacturers of home gateways? Depending on how write many
cycles the flash allows, and on how low the prefix lifetimes are, this
might not be feasible on real products.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 6 Apr 2020 22:26:01 +0900

This text:

   o  Upon changes to the advertised prefixes, and after bootstrapping,
      the CE router advertising prefix information via SLAAC should
      proceed as follows:

      *  Any prefixes that were previously advertised via Router
         Advertisement (RA) messages, but that have now become stale,
         MUST be advertised with a "Valid Lifetime" and a "Preferred
         Lifetime" set to 0, and the "A" and "L" bits unchanged.

      *  The aforementioned advertisement SHOULD be performed for at
         least the "Valid Lifetime" previously employed for such prefix.

is risky because if the link is flapping, then there could be too many PIOs
in the RA, causing the packet to become too big. If the implementer does
not anticipate this problem, it will result in fragmentation (making it
unlikely that the RA will be received by clients) or just not sending RAs
entirely because the send operation fails with EMSGSIZE.

The text also does not say what to do with other data that's related to the
prefix, such as on-link DNS servers. Some routers will announce themselves
as the DNS server for the subnet by picking something like <prefix>::1 and
announcing it in RDNSS. That information is as stale as the prefixes
themselves.

---

From: [email-masked]
Date: Mon, 6 Apr 2020 15:47:35 +0200

> been run past manufacturers of home gateways? Depending on how write many cycles the flash allows, and on how low the prefix lifetimes are, this might not be feasible on real products.

ah, yes this was the comment I forgot.
This issue was brought up multiple times. The text has to be losened and more explanatory. Cause this is a no-go for lots of devices without persistent storage.

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 11:06:12 -0300

Lorenzo,

On 6/4/20 10:19, Lorenzo Colitti wrote:
>           lifetimes would eventually span past the DHCPv6-PD lease time..

As noted in the draft, these requirements are already part of RFC4862 
and RFC8415. THey are *existing* requirements which are referenced here, 
because they are of use to solve the problem at hand.

That said, I don't mind adding a reference to RFC7772.

> The safest way to do so would be to remove this text. A bit less safe 
> would be to say that the device must cease to send RAs if the RA 
> lifetime is below the DHCPv6 PD lifetime. A bit less safe would be to 
> say here that the device MUST respect RFC 7772 and only send RAs once 
> every few minutes. (The reason that this isn't super safe is that in a 
> simple router that just glues together dhcpcd and dnsmasq/radvd, it's 
> not easy to implement. The DHCPv6 client and the RA daemon are two 
> separate pieces of software written by different authors, so 
> transferring the DHCPv6 lifetime to the RA lifetime requires getting the 
> two to collaborate.) +Timothy Winters <mailto:[email-masked]> any 
> other suggestions?

FWIW, radvd already supports this, which support implemented by Mark 
Smith years ago.

Thanks,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 6 Apr 2020 14:13:48 +0000

Hi:

>Something like: "A network provider that has to renumber a customer network, must continue to include the old prefix in DHCP PD messages with lifetimes set to 0 for a while, to ensure that stale prefix information can be expired on hosts attached to the network

That would be a change to DHCPv6 as there is no such clear requirement in that specification. The "for a while" would be until the (longest communicated) valid lifetime would have expired.

What is being proposed is that the CPE remember this information.

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, April 6, 2020 8:57 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

Ole

---

From: [email-masked]
Date: Mon, 6 Apr 2020 16:18:28 +0200

Bernie,

> What is being proposed is that the CPE remember this information.

Why do you think it's a change to "DHCPv6"?
This is how DHCP PD has always worked.
The only difference between flash renumbering and normal renumbering is that there is no overlap in time between old and new prefix.

The CPE cannot in many cases remember the information. And it is the responsibility of the delegating entity to manage that information.
What is proposed in this draft is a workaround for an error case, that shouldn't have happened in the first place.
I don't mind us providing a band aid for it, but as I suggested let's make it clear what intended behaviour is.

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 11:20:08 -0300

On 6/4/20 10:26, Lorenzo Colitti wrote:
> is risky because if the link is flapping, then there could be too many 
> PIOs in the RA, causing the packet to become too big. If the implementer 
> does not anticipate this problem, it will result in fragmentation 
> (making it unlikely that the RA will be received by clients) or just not 
> sending RAs entirely because the send operation fails with EMSGSIZE.

Fair enough.

There are multiple possible ways forward here:

1) The CPE only announces the previous set of network configuration 
information. i.e., upon reboot, the CE Router will announce the new 
information, plus the possible stale one. If you reboot it again, same: 
it announce whatever has become the new set of information, and the 
previous one.

2) Note that advertising stale information should be limitted to the 
link's MTU.

"1)" seems more appropriate to me. And at the end of the day you alway 
need to enfoce a limit on how much you store, and how much you advertise.

> The text also does not say what to do with other data that's related to 
> the prefix, such as on-link DNS servers. Some routers will announce 
> themselves as the DNS server for the subnet by picking something like 
> <prefix>::1 and announcing it in RDNSS. That information is as stale as 
> the prefixes themselves.

Presumably, that information is still usable. However, fair enough. We 
could also add a note about this (including RIOs), which my local CE 
Router sends to hosts.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 11:22:03 -0300

> This issue was brought up multiple times. The text has to be losened and more explanatory. Cause this is a no-go for lots of devices without persistent storage.

I do agree this should be losened to a SHOULD, since, as you note, there 
are valid reasons for which an implementation might not be able to do 
it.  Could you expand on what you mean by "explanatory"?

Thanks!

Cheers,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 6 Apr 2020 14:25:24 +0000

The question is how long this information has to be remembered and sent to the client. I don't think RFC8415 is that clear on this issue.

Yes, when the old PD is switched to a new PD, the server would be expected to send the old PD with 0 lifetimes. But how long will the server remember this is the key question and, for example if 30 days were remaining on the old PD, it should keep sending it for 30 days.

If you read the text of the proposed draft, it only puts a requirement on the CPE:

2.2.  Signaling Stale Configuration Information

   In order to phase-out stale configuration information:

- Bernie

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, April 6, 2020 10:18 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

Bernie,

Cheers,
Ole

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Apr 2020 10:49:03 -0400

> FWIW, radvd already supports this, which support implemented by Mark
We always see issues between DHCPv6 Client and RA daemon.  Fernando, I
don;'t think this applies to RA transmission and I will attest to the fact
this isn't used by current implementations.  When I last looked into this
about 30% of CPEs count down lifetimes correctly.  The rest transmit the
exact value received in the DHCP-PD.  I'm not sure what to do about the
field changing, as Lorenzo mentions it has become popular on devices to
check the RA is the same and drop it for battery sensitive situations.  If
we have values changing all the time, this will be impossible.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 12:12:44 -0300

On 6/4/20 11:49, Timothy Winters wrote:
[....]
>      > two to collaborate.) +Timothy Winters
>     <mailto:[email-masked] <mailto:[email-masked]>> any
>      > other suggestions?
> 
> don;'t think this applies to RA transmission and I will attest to the 
> fact this isn't used by current implementations.

Could you elaborate? What specifically doesn't apply to RA transmission?

> When I last looked 
> into this about 30% of CPEs count down lifetimes correctly.  The rest 
> transmit the exact value received in the DHCP-PD.  I'm not sure what to 
> do about the field changing, as Lorenzo mentions it has become popular 
> on devices to check the RA is the same and drop it for battery sensitive 
> situations.  If we have values changing all the time, this will be 
> impossible.

Note: If CE Routers Advertise the lifetimes as recommended in this 
document, the RAs will change only for the last "Valid Lifetime" seconds.

Or, please let me elaborate in a different way:

1) CE Routers can't just copy the lifetime from DHCPv6-PD, because 
otherwise, the first second after the first RA is sent, they would be 
announcing bogus RAs.
Say, if the DHCPv6-PD is one month. If you simply copy the lifetime from 
DHCPv6-PD, then, after 15 days, you'd be advertising a prefix that 
claims a lifetime 15 longer (double time!) than it really is.

2) Now, if, say, an implementation uses a shorter router lifetime (say, 
one hour, or the recommended default of 30 minutes), then only the last 
hour or half hour of the months will the announced PIO lifetimes be 
incorrect.

Thoughts?

Thanks,

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Apr 2020 11:34:47 -0400

> Could you elaborate? What specifically doesn't apply to RA transmission?
I'm not aware of any prefix/address lifetimes from DHCPv6 affecting RA
intervals.

> hour or half hour of the months will the announced PIO lifetimes be
Did you mean valid lifetime or router lifetime?

---

From: [email-masked]
Date: Mon, 6 Apr 2020 18:08:17 +0200

Bernie,

> The question is how long this information has to be remembered and sent to the client. I don't think RFC8415 is that clear on this issue.

RFC8415 doesn't seem to say much about renumbering at all. I guess from its perspective it's all operational.

> Yes, when the old PD is switched to a new PD, the server would be expected to send the old PD with 0 lifetimes. But how long will the server remember this is the key question and, for example if 30…

I don't think that necessarily follows.
The delegating server is allowed to change the lifetimes of the old prefix, so I would imagine it was only necessary to include the old prefix in one DHCP exchange.

>      network segment, and the "A" and "L" flags of the corresponding

Yes, and as I said that's a band-aid for a broken deployment.
And suggested that a paragraph explaining the correct renumbering procedure was added. To avoid confusion.
Not all CPEs are ever going to do this anyway. 

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 12:50:50 -0300

On 6/4/20 12:34, Timothy Winters wrote:
[...]
> I'm not aware of any prefix/address lifetimes from DHCPv6 affecting RA 

So, what happens if, say, the DHCPv6-PD is, say, two months? The set the 
Valid/Prefix Lifetime of PIOs to that value?

> Did you mean valid lifetime or router lifetime?

I meant: "If the implementations always set the PIO Valid Lifetime to 
the Router Lifetime, as suggested in draft-gont-6man-slaac-renum".

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 14:00:29 -0300

Hi, Ole,

On 6/4/20 13:08, [email-masked] wrote:
[...]
> The delegating server is allowed to change the lifetimes of the old prefix, so I would imagine it was only necessary to include the old prefix in one DHCP exchange.

Since the DHCPv6-PD client could come back anytime withing the DHCPv6-PD 
lease time of the stale prefix, the DHCPv6 server would need to remember 
this for such period of time. I assume that's what Bernie meant.

> Not all CPEs are ever going to do this anyway.

How about adding this:
    IPv6 network renumbering is expected to take place in a planned
    manner, with old/stale prefixes being phased-out via reduced prefix
    lifetimes while new prefixes (with normal lifetimes) are introduced.
    However, there are a number of scenarios that may lead to the so-
    called "flash-renumbering" events, where the prefix being employed on
    a network suddenly becomes invalid and replaced by a new prefix
    [I-D.ietf-v6ops-slaac-renum]. One of such scenarios is that in which
    a DHCPv6-server employs dynamic prefixes, and the Customer Edge
    Router crashes and reboots. The requirement in this section is meant
    to allow Customer Edge Routers to deprecate stale information in such
    scenarios.

to the RATIONALE in Section 2.2?

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Mon, 6 Apr 2020 19:26:40 +0200

Hi Fernando,

That text works for me. 

Cheers 
Ole

> On 6 Apr 2020, at 19:18, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Ole,
> 
> Since the DHCPv6-PD client could come back anytime withing the DHCPv6-PD lease time of the stale prefix, the DHCPv6 server would need to remember this for such period of time. I assume that's what Bernie meant.
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 14:48:15 -0300

> This issue was brought up multiple times. The text has to be losened and more explanatory. Cause this is a no-go for lots of devices without persistent storage.

How about changing this requirement to "SHOULD", and add this note to 
the RATIONALE of the corresponding section:

"The requirement in this section is conveyed as a "SHOULD" (as opposed 
to a "MUST"), since we acknowledge that the availability of stable 
storage to record the information may represent a challenge for some 
implementations."
?

Thanks!

Cheers,

---

From: [email-masked]
Date: Mon, 6 Apr 2020 21:20:50 +0200

>> I'm not aware of any prefix/address lifetimes from DHCPv6 affecting RA intervals.
> 
> So, what happens if, say, the DHCPv6-PD is, say, two months? The set the Valid/Prefix Lifetime of PIOs to that value?

Yes, counting down in real time:

As specified in 4861:

AdvValidLifetime
                             The value to be placed in the Valid
                             Lifetime in the Prefix Information option,
                             in seconds.  The designated value of all
                             1's (0xffffffff) represents infinity.
                             Implementations MAY allow AdvValidLifetime
                             to be specified in two ways:

                               - a time that decrements in real time,
                                 that is, one that will result in a
                                 Lifetime of zero at the specified time
                                 in the future, or

                               - a fixed time that stays the same in
                                 consecutive advertisements.

                             Default: 2592000 seconds (30 days), fixed
                             (i.e., stays the same in consecutive
                             advertisements).

Cheers,
Ole

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Apr 2020 15:25:07 -0400

> Valid/Prefix Lifetime of PIOs to that value?
 Yes at the moment.

> the Router Lifetime, as suggested in draft-gont-6man-slaac-renum".

Right, the thing that concerns me about this is CPEs use all kinds of
interesting values for router lifetime.  I guess it's a smaller value by
definition (9000 seconds).

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 16:31:42 -0300

[...]

Yes. That's what I meant, and what also RFC8415 requires. But LOrenzo 
was arguing against...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 16:37:13 -0300

On 6/4/20 16:25, Timothy Winters wrote:
> 
> 
> On Mon, Apr 6, 2020 at 12:38 PM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

What lifetime do they use for the PIOs say, 15 days after receiving the 
one-month lease? Still 30 days? -- that seems very broken. And yet 
another way for these problems to appear.

>      >     Say, if the DHCPv6-PD is one month. If you simply copy the
>     lifetime
>      >     from

9000 seconds is actually the longest possible value. The default Router 
Lifetime is, according to RFC4861, 1800 seconds (30 minutes). The math 
and recommendation in RFC7772 somehow makes the default value in RFC4841 
non-compliant -- I guess one takes that as "rough numbers", and 
considers 30 minutes to be within the recommendations in RFC7772.

That said, the text I had suggested does include a reference to RFC7772.

Thoughts?

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Apr 2020 15:55:31 -0400

> another way for these problems to appear.
About 70% don't count down so they would say two months in your example.

> >      >     document, the RAs will change only for the last "Valid
> Lifetime"
> >      >     seconds.
> >      >

 I think this can help, and would recommend going with RFC 7772 which says
between 45 to 90 mins.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 17:15:16 -0300

On 6/4/20 16:55, Timothy Winters wrote:
[---]
>      >     So, what happens if, say, the DHCPv6-PD is, say, two months?
>     The set
>      >     the

Your data is *very* valuable. It agrees what I had seen (although I 
hadn't seen so many CPEs as to be able to produce stats). It is good to 
keep in mind, and I believe it serves as a good motivator for Section 2.1.

[...]
>   I think this can help, and would recommend going with RFC 7772 which 
> says between 45 to 90 mins.

I'd probably stick with 45' or the RFC4861 default of '30 (which somehow 
begs the question of how the default spec value can be outside a BCP..). 
After all, in the light of RFC7772 45' is good enough -- and the 
increased Router Lifetime also comes at a price.

Thoughts?

Thanks again!

Cheers,

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Apr 2020 16:44:38 -0400

> increased Router Lifetime also comes at a price.

Works for me.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 6 Apr 2020 13:46:31 -0700

> On Apr 6, 2020, at 1:15 PM, Fernando Gont <[email-masked]> wrote:
> 
> Your data is *very* valuable. It agrees what I had seen (although I hadn't seen so many CPEs as to be able to produce stats). It is good to keep in mind, and I believe it serves as a good motivator for Section 2.1.
> 
> 
> […]

In theory, a DHCP Server or a Router which is advertising SLAAC PIOs from a DHCP IA_PD should not advertise a valid lifetime in excess of the remaining valid time on the lease.

In practice, there are likely many sloppy CPE implementations which simply copy the value from the original IA_PD lifetime specifications and advertise that until they can’t. As such, the “safe” thing is definitely to continue supporting the prefix for 2xMAX_VALID_LIFETIME after it has been removed from leases or PIOs.

Owen

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 6 Apr 2020 21:15:32 +0000

Hi - inline (BV>).

- Bernie

On 4/6/20, 1:18 PM, "Fernando Gont" <[email-masked]> wrote:

    Hi, Ole,

  
BV> Correct. The server would be obligated to retain it until the (longest) valid lifetime it had sent the client expired. The question is how the server knows when a DHCP exchange is complete (just because it sent a Reply is not a guarantee the client received it). And, if it does use that then the issue is that this doesn't help the CPE if it rebooted after this (or even) several exchanges as there could still be clients behind the CPE that have not received an updated RA with the deprecated prefix.

    How about adding this:

    Thanks,

---

From: Owen DeLong <[email-masked]>
Date: Mon, 6 Apr 2020 14:46:19 -0700

> On Apr 6, 2020, at 6:19 AM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> Based on a fair amount of experience with this sort of thing, this recommendation is risky:
> 
> The reason is that there are many routers in the field that send RAs much too often. There are many devices that send RAs at the maximum permitted rate of one every three seconds (ironically, I think the reason for this is to prevent the very "client loses connectivity" roblem this draft is trying to solve). On a phone or smaller device, processing packets every 3 seconds will destroy battery life. But because phone manufacturers could not fix routers in the field, they reacted to this in different ways.
> Drop all packets / all multicast packets / all RA packets when the "device is not in use" (e.g., screen is off). Maybe send an RS when the screen turns on again.

Broken, as you say, but not really impacted by this proposal.
> Drop RAs that are received too soon after an identical RA.
> Drop RAs that are received too soon after a similar RA (e.g., same RA but with different lifetime values).
> #1 basically breaks IPv6 almost completely, because RAs will time out and expire. Even if the device sends an RS again when the screen turns on, connectivity might have been broken while the screen was off, because the device might have dropped one or more RAs with a critical update. Devices do need connectivity while the screen is off - for example, to receive incoming calls and chat messages. #3 works but not all manufacturers implement it. Android does this by providing the source code of a bytecode interpreter to chipset vendors and downloading bytecode to the interpreter based on previously-received RAs, but some chipset vendors don't support this. I don't think iOS supports this either. Many devices do #2. It sort of works as long as the RAs are identical. This is pretty common because it's easy to do in wifi firmware and pretty much all wifi chipsets support fixed-function filtering.

Sure…

> By recommending that lifetimes should be dynamically updated, this draft will defeat devices that do #2. Based on past experience, a likely outcome is that manufacturers will react by switching to #1 and dropping all RAs. We should try to avoid making this problem worse with this draft.

But if you don’t update the lifetimes, then you’re handing out PIOs that contain a lifetime beyond the end of the IA_PD lease.

Could we perhaps recommend sending out PIOs that are 1/4 or 1/3 of the original IA_PD lease so long as the lease is renewed and then dynamically counting down to 0 such that the PIO never contains a lifetime longer than the IA_PD validity?

This should provide a best of both worlds… Until the IA_PD expires without renewal, the PIO should contain a fixed lifetime, but in the (rare) case where a prefix is expiring, we sacrifice some battery life to avoid a loss of connectivity.

Alternatively, perhaps stop issuing PIOs for an IA_PD which has invaded that last fraction of its lifetime?

> The safest way to do so would be to remove this text. A bit less safe would be to say that the device must cease to send RAs if the RA lifetime is below the DHCPv6 PD lifetime. A bit less safe would be to say here that the device MUST respect RFC 7772 and only send RAs once every few minutes. (The reason that this isn't super safe is that in a simple router that just glues together dhcpcd and dnsmasq/radvd, it's not easy to implement. The DHCPv6 client and the RA daemon are two separate pieces of software written by different authors, so transferring the DHCPv6 lifetime to the RA lifetime requires getting the two to collaborate.) +Timothy Winters <mailto:[email-masked]> any other suggestions?

I’m all for sending RAs less frequently.

I’m not in favor of RA lifetimes exceeding the DHCPv6 PD lifetime as you advocate at the beginning of this paragraph. That seems absurd.

Owen

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 18:23:03 -0300

On 6/4/20 18:15, Bernie Volz (volz) wrote:
[....]
> BV> Correct. The server would be obligated to retain it until the (longest) valid lifetime it had sent the client expired. The question is how the server knows when a DHCP exchange is complete (jus…

Completely agree. If anything, this would relieve the CPE from having to 
store the leased prefix themselves, but:

1) Since the CPE can't know a priori if the DHCPv6 server will, it 
should record the prefix in order to fail on the safe side.

2) I'm curious what typical CPEs do upon receipt of multiple prefixes 
via DHCPv6-PD, and also what they do if they receive them, but some have 
zero lifetimes. (I wouldn't surprise if they only use one, and even less 
surprised if PIOs with zero lifetimes are simply dropped). Tim?

Thanks!

Cheers,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 6 Apr 2020 22:04:57 +0000

BTW: And problem to ponder ...

CPE has no storage.

DHCPv6 sends PDs, one (or some) with 0 lifetimes. Other(s) with non-zero lifetimes.

So, what should a CPE do? How long should it continue to send out the RAs with PIOs regarding the prefixes with 0 lifetimes?

It would have to do this until it stopped receiving the PDs with 0 lifetimes in a Reply to a Request, Renew, or Rebind. This is because the CPE would have no knowledge of the original lifetime and when that PD could safely stop being advertised. And, the DHCPv6 messaging has no way to communicate what the original (remaining) lifetime may have been.

So, wouldn't this need to be documented somewhere? Or is this something we think everyone implementing a CPE would understand it needs to do?

- Bernie

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Monday, April 6, 2020 5:23 PM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]; Timothy Winters <[email-masked]>
Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

> BV> Correct. The server would be obligated to retain it until the (longest) valid lifetime it had sent the client expired. The question is how the server knows when a DHCP exchange is complete (jus…

Completely agree. If anything, this would relieve the CPE from having to store the leased prefix themselves, but:

1) Since the CPE can't know a priori if the DHCPv6 server will, it should record the prefix in order to fail on the safe side.

2) I'm curious what typical CPEs do upon receipt of multiple prefixes via DHCPv6-PD, and also what they do if they receive them, but some have zero lifetimes. (I wouldn't surprise if they only use one, and even less surprised if PIOs with zero lifetimes are simply dropped). Tim?

Thanks!

Cheers,

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Apr 2020 19:37:02 -0400

On Mon, Apr 6, 2020 at 5:48 PM Fernando Gont <[email-masked]> wrote:

> > BV> Correct. The server would be obligated to retain it until the
> (longest) valid lifetime it had sent the client expired. The question is
> how the server knows when a DHCP exchange is complete (just because it sent
> a Reply is not a guarantee the client received it). And, if it does use
> that then the issue is that this doesn't help the CPE if it rebooted after
> this (or even) several exchanges as there could still be clients behind the
> CPE that have not received an updated RA with the deprecated prefix.
>
IPv6 Ready has a test for Prefix Change that sends IA_PDs with one valid
and one with zero.  So we test and IPv6 Ready Logo CE Routers do this
perfectly.  When I was at the lab this was the most failed test case, in
all the ways you can imagine.  I came to really hate this test case over
the last 4 four years.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 20:46:47 -0300

On 6/4/20 20:37, Timothy Winters wrote:
[...]
> all the ways you can imagine.  I came to really hate this test case over 

Failed on the CPE side, router side, or both? And... any idea if this 
ever improved significantly? Or show we still assume CPEs to be buggy in 
this respect?

Thanks!

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Apr 2020 22:48:43 +0900

On Tue, Apr 7, 2020 at 6:47 AM Owen DeLong <[email-masked]> wrote:

> But if you don’t update the lifetimes, then you’re handing out PIOs that
> contain a lifetime beyond the end of the IA_PD lease.
>
> Could we perhaps recommend sending out PIOs that are 1/4 or 1/3 of the
> original IA_PD lease so long as the lease is renewed and then dynamically
> counting down to 0 such that the PIO never contains a lifetime longer than
> the IA_PD validity?
>
> This should provide a best of both worlds… Until the IA_PD expires without
> renewal, the PIO should contain a fixed lifetime, but in the (rare) case
> where a prefix is expiring, we sacrifice some battery life to avoid a loss
> of connectivity.
>

Why can't we go even further and just suggest that the maximum lifetimes be
capped to some reasonable value, such as a few hours or a day?

---

From: Timothy Winters <[email-masked]>
Date: Tue, 7 Apr 2020 09:56:46 -0400

On Tue, Apr 7, 2020 at 9:50 AM Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

>> This should provide a best of both worlds… Until the IA_PD expires
>> without renewal, the PIO should contain a fixed lifetime, but in the (rare)
>> case where a prefix is expiring, we sacrifice some battery life to avoid a
>> loss of connectivity.
>>
>
> Why can't we go even further and just suggest that the maximum lifetimes
> be capped to some reasonable value, such as a few hours or a day?
>
I think this is what I think makes the most sense.  Do operators think
there is a reason to have the super long addresses?

---

From: [email-masked]
Date: Tue, 7 Apr 2020 15:59:36 +0200

> Why can't we go even further and just suggest that the maximum lifetimes be capped to some reasonable value, such as a few hours or a day?
> I think this is what I think makes the most sense.  Do operators think there is a reason to have the super long addresses?

Like cap them to 64 bit you mean? ;-)

Users think there are many reasons to have long lived addresses.
I think this idea of trying to make address lifetimes act as dead timers for reachability severely broken.

Routing != Addressing.

Cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Apr 2020 23:05:41 +0900

> for reachability severely broken.

To be clear: I'm not suggesting the maximum lifetime be capped within the
router. I'm suggesting the maximum lifetime be capped *in the RA*. In other
words, if an ISP announces a lifetime of 100 years, the RA would still
contain something like 9000 seconds, 86400 seconds, or whatever value we
pick. So yes - if the router went away for more than 9000/86400/... seconds
the addresses would become invalid. Rationale: I think an address isn't
very useful if you can't use it to receive packets. (I know you don't agree
with me on this, but others might.)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 7 Apr 2020 14:11:42 +0000

Yup, that is exactly what I thought was being suggested and I think makes good sense.

The only harm that using capped lifetimes (instead of the full PD lifetime) is that if the CPE device itself goes down, the GLAs may be lost prematurely. If the CPE is operating, it will continue to send out RAs (until the lifetime expires).

And with caps sufficiently high, TCP connections will almost certainly have timed out by the time the capped lifetimes expires.

  *   Bernie

From: v6ops <[email-masked]> On Behalf Of Lorenzo Colitti
Sent: Tuesday, April 7, 2020 10:06 AM
To: Ole Troan <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

Routing != Addressing.

To be clear: I'm not suggesting the maximum lifetime be capped within the router. I'm suggesting the maximum lifetime be capped *in the RA*. In other words, if an ISP announces a lifetime of 100 years, the RA would still contain something like 9000 seconds, 86400 seconds, or whatever value we pick. So yes - if the router went away for more than 9000/86400/... seconds the addresses would become invalid. Rationale: I think an address isn't very useful if you can't use it to receive packets. (I know you don't agree with me on this, but others might.)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Apr 2020 10:13:42 -0400

> I think this idea of trying to make address lifetimes act as dead timers for reachability severely broken.

I think that in principle this is true, but I’m not sure that it follows in practice.  What should we be doing instead?  Or was this just a miscommunication, per Lorenzo’s clarifying message?

My experience with this tends to make me want to agree with Lorenzo.  The longer a PIO prefix lifetime is, the longer things are broken when the router stops advertising the prefix without deprecating it.  OTOH, it’s _always_ going to be too long, so as you say, we really want a better way to detect that we have a problem.  Right now if one device remembers a stale on-link prefix that another device has not seen, the first device may choose that stale prefix during source address selection, and of course since the second device doesn’t see it as on-link, this will fail.

How do we quickly detect this failure?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 7 Apr 2020 14:17:33 +0000

BTW: Perhaps just the preferred lifetime should be capped?

  *   Bernie

From: v6ops <[email-masked]> On Behalf Of Bernie Volz (volz)
Sent: Tuesday, April 7, 2020 10:12 AM
To: Lorenzo Colitti <lorenzo=[email-masked]>; Ole Troan <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

  *   Bernie

Routing != Addressing.

---

From: [email-masked]
Date: Tue, 7 Apr 2020 16:36:25 +0200

Ted,

> How do we quickly detect this failure?

Exactly. It doesn't much matter if the prefix lifetime is 100 years or two hours. The user isn't going to sit around for that time anyway.

slaac-renum solves a small corner case of this problem space.
I suggest the rest of that discussion happens in 6man.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Apr 2020 13:26:56 -0300

On 7/4/20 11:05, Lorenzo Colitti wrote:
>      > Why can't we go even further and just suggest that the maximum
>     lifetimes be capped to some reasonable value, such as a few hours or
>     a day?
>      > I think this is what I think makes the most sense.  Do operators
>     think there is a reason to have the super long addresses?
> 
> To be clear: I'm not suggesting the maximum lifetime be capped within 
> the router. I'm suggesting the maximum lifetime be capped *in the RA*. 
> In other words, if an ISP announces a lifetime of 100 years, the RA 
> would still contain something like 9000 seconds, 86400 seconds, or 
> whatever value we pick. So yes - if the router went away for more than 
> 9000/86400/... seconds the addresses would become invalid. Rationale: I 
> think an address isn't very useful if you can't use it to receive 
> packets. (I know you don't agree with me on this, but others might.)

FWIW, I agree with that idea. And that's the rationale for my suggestion 
in the other email.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Apr 2020 13:23:22 -0300

On 7/4/20 10:48, Lorenzo Colitti wrote:
> On Tue, Apr 7, 2020 at 6:47 AM Owen DeLong <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>>     By recommending that lifetimes should be dynamically updated, this
>>     draft will defeat devices that do #2. Based on past experience, a
>>     likely outcome is that manufacturers will react by switching to #1
>>     and dropping all RAs. We should try to avoid making this problem
>>     worse with this draft.
>     But if you don’t update the lifetimes, then you’re handing out PIOs
>     that contain a lifetime beyond the end of the IA_PD lease.
> 
>     Could we perhaps recommend sending out PIOs that are 1/4 or 1/3 of
>     the original IA_PD lease so long as the lease is renewed and then
>     dynamically counting down to 0 such that the PIO never contains a
>     lifetime longer than the IA_PD validity?
> 
>     without renewal, the PIO should contain a fixed lifetime, but in the
>     (rare) case where a prefix is expiring, we sacrifice some battery
>     life to avoid a loss of connectivity.
> 
> 

Yes, that's indeed the outcome of this discussion. I will repost the 
corresponding proposed text in a separate thread, since it might have 
got lost in the recent flood of emails. But, essentially, the idea was 
to set the Preferred Lifetime and Valid Lifetime of PIOs to the Router 
Lifetime and X * Router Lifetime, respectively, and also hinting RFC7772.

(If the lifetimes are kept short enough (as indicated), and the prefix 
is renewed before any of those lifetimes expire, you wouldn't even need 
to change the PIO lifetimes you advertise on the LAN side)

Would that work for you?

Thanks,

---

From: [email-masked]
Date: Tue, 7 Apr 2020 19:27:58 +0200

Lorenzo,

> To be clear: I'm not suggesting the maximum lifetime be capped within the router. I'm suggesting the maximum lifetime be capped *in the RA*. In other words, if an ISP announces a lifetime of 100 ye…

What problem does this solve?

(and I doubt v6ops is the place to for this.)

Cheers,
Ole

---

From: Owen DeLong <[email-masked]>
Date: Tue, 7 Apr 2020 14:29:53 -0700

> On Apr 6, 2020, at 15:04 , Bernie Volz (volz) <volz=[email-masked]> wrote:
> 

Uh, then where do they keep their updatable firmware, exactly?

> So, what should a CPE do? How long should it continue to send out the RAs with PIOs regarding the prefixes with 0 lifetimes?

For a PD with 0 lifetime, it should apply the prefix to its interfaces and route packets to/from that prefix. It should not put them in PIOs.

This way, clients that have lifetime left from previous PIOs are not disabled, but new clients are given the most current information.

> It would have to do this until it stopped receiving the PDs with 0 lifetimes in a Reply to a Request, Renew, or Rebind. This is because the CPE would have no knowledge of the original lifetime and…

Yes. Hence the preference that the device record the information locally.

> So, wouldn't this need to be documented somewhere? Or is this something we think everyone implementing a CPE would understand it needs to do?

It would be good to add this to the document, IMHO.

Fernando?

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 7 Apr 2020 14:32:46 -0700

> On Apr 6, 2020, at 16:46 , Fernando Gont <[email-masked]> wrote:
> 
>> IPv6 Ready has a test for Prefix Change that sends IA_PDs with one valid and one with zero.  So we test and IPv6 Ready Logo CE Routers do this perfectly.  When I was at the lab this was the most failed test case, in all the ways you can imagine.  I came to really hate this test case over the last 4 four years.
> 
> Failed on the CPE side, router side, or both? And... any idea if this ever improved significantly? Or show we still assume CPEs to be buggy in this respect?

In general, it is relatively safe to assume that CPEs will be buggy in pretty much every respect.

New CPEs frequently recycle long dead bugs in my experience.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 7 Apr 2020 14:34:25 -0700

> On Apr 7, 2020, at 06:48 , Lorenzo Colitti <[email-masked]> wrote:
> 
> On Tue, Apr 7, 2020 at 6:47 AM Owen DeLong <[email-masked] <mailto:[email-masked]>> wrote:

I have no objection to that… However, once the PD lifetime drops below this value, whatever it is, RAs shouldn’t be advertising a larger number and therefore have to dynamically adjust as it counts down.

Owen

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Apr 2020 20:26:15 -0300

> Exactly. It doesn't much matter if the prefix lifetime is 100 years or two hours. The user isn't going to sit around for that time anyway.

Reducing the preferred lifetime essentially improves the time it takes 
to deprecate and subsequently eliminate addresses corresponding to a 
router that simply disappears.

It's not perfect, but it way better than what we currently have. (but 
see below).

> slaac-renum solves a small corner case of this problem space.

slaac-renum mitigates the case described above, *and* also solves in a 
very efficient and timely manner handle the case where e.g. a CE Router 
crashes and reboots. I'm not sure what's your definition of corner-case 
-- but this is a very common scenario. And, as it should be clear from 
this discussion, there are multiple reasons for which such scenarios 
could take place (CPE crashes and reboots, CPE announces PIOs with a 
lifetime that spans past the DHCPv6-PD lease, etc.)

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 Apr 2020 01:47:05 +0200

Fernando,

> On 8 Apr 2020, at 01:29, Fernando Gont <[email-masked]> wrote:
> 
> Reducing the preferred lifetime essentially improves the time it takes to deprecate and subsequently eliminate addresses corresponding to a router that simply disappears.
> 
> It's not perfect, but it way better than what we currently have. (but see below).

It’s a fool’s errand to think you will fix this with short lifetimes.
Either they are so short that they expire during a link flap or they will regardless be so long that it’s beyond an acceptable wait time for a user. 

> slaac-renum mitigates the case described above, *and* also solves in a very efficient and timely manner handle the case where e.g. a CE Router crashes and reboots. I'm not sure what's your definition of corner-case -- but this is a very common scenario. And, as it should be clear from this discussion, there are multiple reasons for which such scenarios could take place (CPE crashes and reboots, CPE announces PIOs with a lifetime that spans past the DHCPv6-PD lease, etc.)

Not sure what you mean by the case of a cpe crashing and rebooting and why that should matter. 

And may I remind you that ipv6 hosts are used in a diverse set of networks.

Cheers 
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Apr 2020 20:02:50 -0400

It would probably work better to factor preferred lifetimes into source address selection. iOS, if two source addresses are otherwise equivalent, pick the one that’s valid longer. 

This does argue for capping valid lifetimes in RAs. 

We could also sort by time of most recent RA. 

> On Apr 7, 2020, at 19:47, Ole Troan <[email-masked]> wrote:
> 
> Fernando,
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Apr 2020 21:30:48 -0300

On 7/4/20 20:47, Ole Troan wrote:
[....]
> It’s a fool’s errand to think you will fix this with short lifetimes.

It mitigates the problem -- it doesn't eliminate it.

We have timers. We are just not using them appropriately. 
What's the point of having PL and VL lifetimes in a way that they will 
never go off in any meaningful timeframe?

The PL lifetime could even be reduce to less than the Router Lifetime. 
At the end of the day, that only changes which addresses you'd use for 
new connections. If you have another fresher address, that'd me you'd 
use that address. And if you don't have any other addresses, you'd use 
the deprectated ones: they are still valid, and you have no better 
alternatives.

> Either they are so short that they expire during a link flap or they will regardless be so long that it’s beyond an acceptable wait time for a user.

Please see below.

> Not sure what you mean by the case of a cpe crashing and rebooting and why that should matter.

Because you receive RAs from the same router that had sent the now stale 
network configuration information. Hence, the algorithms from Section 
4.5 of draft-gont-6man-slaac-renum will deprecate the information in a 
timely manner.

And that's one of the most common scenarios for the problem discussed in 
draft-ietf-v6ops-slaac-renum.

> And may I remind you that ipv6 hosts are used in a diverse set of networks.

No need to remind me of that. That has been well considered.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Apr 2020 21:00:12 -0400

If two addresses are equivalent, why is it a problem to alternate between them?

> On Apr 7, 2020, at 20:56, Fernando Gont <[email-masked]> wrote:
> 
> On 7/4/20 21:02, Ted Lemon wrote:
> Nope. That does not make sense, for two reasons:
> 
> Two routers might be advertising PIOs with different Preferred Lifetimes. And the "algorithm" you'd propose would always pick the address with eh longer lifetime, when the specific lifetime value has no intrinsic meaning.
> 
> Then, if your counter-proposal is to prefer "the last advertised PIO", then that guarantee that source addresses will flap, which is undesirable.
> 
> In fact, this has been proposed and analyzed. See: https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#appendix-B.2
> 
> 
> 
> I responded the above before reading this :-) (because we did consider that option).
> 
> Thanks!
> 
> Cheers,
> -- 
> Fernando Gont
> SI6 Networks

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Apr 2020 21:56:16 -0300

Two routers might be advertising PIOs with different Preferred 
Lifetimes. And the "algorithm" you'd propose would always pick the 
address with eh longer lifetime, when the specific lifetime value has no 
intrinsic meaning.

Then, if your counter-proposal is to prefer "the last advertised PIO", 
then that guarantee that source addresses will flap, which is undesirable.

In fact, this has been proposed and analyzed. See: 
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06#appendix-B.2

> We could also sort by time of most recent RA.

I responded the above before reading this :-) (because we did consider 
that option).

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Apr 2020 22:45:58 -0300

> If two addresses are equivalent, why is it a problem to alternate between them?

Undeterministic (PIA to be trouble-shoot) behavour. You try once, it 
works, you try 1 minute later, it doesn't. To the extent that it's 
possible, you want to avoid that.

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 Apr 2020 10:06:15 +0200

Fernando,

> On 8 Apr 2020, at 02:56, Fernando Gont <[email-masked]> wrote:
> 
> We have timers. We are just not using them appropriately. What's the point of having PL and VL lifetimes in a way that they will never go off in any meaningful timeframe?

No. You are proposing to use the prefix timers for something they were never designed for. 

It doesn’t mitigate “the issue” well enough. We need to look elsewhere.

Cheers 
Ole

> 
> The PL lifetime could even be reduce to less than the Router Lifetime. At the end of the day, that only changes which addresses you'd use for new connections. If you have another fresher address, that'd me you'd use that address. And if you don't have any other addresses, you'd use the deprectated ones: they are still valid, and you have no better alternatives.
> 
> 
> 
> Because you receive RAs from the same router that had sent the now stale network configuration information. Hence, the algorithms from Section 4.5 of draft-gont-6man-slaac-renum will deprecate the information in a timely manner.
> 
> And that's one of the most common scenarios for the problem discussed in draft-ietf-v6ops-slaac-renum.
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 05:32:07 -0300

> No. You are proposing to use the prefix timers for something they were never designed for.

1) I'm proposing to use prefix timers... for timing out timers :-)

The Preferred Lifetime, to deprecate an otherwise preferred prefix.
The Valid Lifetime, to invalidate the prefix.

Just of curiousity, may I ask what do you think they are meant for? (of 
course, wasting them by using huge values not being a valid option).

2) During the early versions of 6man-slaac-renum, I happened to talk 
with William Simpson, one of the original authors. He seems to disagree 
with you.

3) Besides the above to bullets, I'm not sure how "...they were never 
designed for" becomes a technical argument against the proposal on the 
table.

> It doesn’t mitigate “the issue” well enough. We need to look elsewhere.

6man-slaac-renum contains a number of improvements to mitigate the 
issue. All of them contribute in a good way towards the ultimate goal.

Having insanely long timeouts means you don't even do a bare minimum 
garbage collection.

I don't think we need to look elsewhere. What's in the group of 
slaac-renum documents does a good job in dealing with the problem we 
have on the table, in a way that's incrementally deployable and improves 
the situation without requiring that everyones updates.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 05:43:07 -0300

On 8/4/20 05:32, Fernando Gont wrote:
>>> We have timers. We are just not using them appropriately. What's the 
>>> point of having PL and VL lifetimes in a way that they will never go 
>>> off in any meaningful timeframe?
>>

Of course I meant "timing out prefixes"....

---

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

Fernando,

> Just of curiousity, may I ask what do you think they are meant for? (of course, wasting them by using huge values not being a valid option).

They are meant to support renumbering.

> 2) During the early versions of 6man-slaac-renum, I happened to talk with William Simpson, one of the original authors. He seems to disagree with you.
> 
> 3) Besides the above to bullets, I'm not sure how "...they were never designed for" becomes a technical argument against the proposal on the table.
> 
> 
> 
> 6man-slaac-renum contains a number of improvements to mitigate the issue. All of them contribute in a good way towards the ultimate goal.
> 
> Having insanely long timeouts means you don't even do a bare minimum garbage collection.
> 
> I don't think we need to look elsewhere. What's in the group of slaac-renum documents does a good job in dealing with the problem we have on the table, in a way that's incrementally deployable and improves the situation without requiring that everyones updates.

slaac-renum tries to solve operational brokenness by tweaking the protocol. Suggesting all IPv6 implementations should change, and thereby become more brittle, is not a tradeoff I'm willingto make.
What's described in slaac-renum isn't a protocol problem.

Ole

---

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

>What's described in slaac-renum isn't a protocol problem.

And, isn't that why it is in v6ops? Discussing lifetime values is an operational consideration; the protocol already provides for supporting whatever lifetimes are selected (provided they meet the protocol requirements such as preferred <=valid, ...).

- Bernie

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, April 8, 2020 9:55 AM
To: Fernando Gont <[email-masked]>
Cc: Lorenzo Colitti <lorenzo=[email-masked]>; [email-masked]; Timothy Winters <[email-masked]>
Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

Fernando,

Ole

---

From: [email-masked]
Date: Wed, 8 Apr 2020 16:09:57 +0200

> And, isn't that why it is in v6ops? Discussing lifetime values is an operational consideration; the protocol already provides for supporting whatever lifetimes are selected (provided they meet the…

As explained earlier using prefix timers to affect routing doesn't work well.
For fast convergence the timers need to be so short, so that the addresses will not survive a link-flap, or even the shortes of hiccups in the access link.
Too long and convergence is so slow that the user gives up.
Plus of course the multitude of other cases where this does not solve the problem.

This proposal also ignores all the correct deployments of PD, where the operator honours the lifetimes he sets and wants the hosts to have access to those lifetimes.

addressing != routing.

Ole

---

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

> They are meant to support renumbering.

Part of renumbering is phasing out prefixes. And this is what we are 
doing here.

> slaac-renum tries to solve operational brokenness by tweaking the protocol. Suggesting all IPv6 implementations should change, and thereby become more brittle, 

Certainly the opposite: A network is really brittle if just because a 
CPE Router crashes and reboots, the network breaks.

slaac-renum improves robustness. Even in the presence of cheap CPE, 
things do work.

I have no idea how you could possibly consider a network to be robust 
when in order for things to work, a lot of things need to happened in 
the way you expect, and a lot of elements you don't even have control 
of, need to function perfectly well.

A core design principle of the Internet is that as long as there is a 
working path from source to destination, communications survive possible 
outages.

> is not a tradeoff I'm willingto make.

I respect that you may have a different opinion and disagree.

Now, splitting your role as a participant, and your role as wg char, may 
we have a wg call on draft-gont-6man-slaac-renum at 6man?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 11:13:58 -0300

> And, isn't that why it is in v6ops? Discussing lifetime values is an operational consideration; the protocol already provides for supporting whatever lifetimes are selected (provided they meet the…

I *think* Ole is referring to one of the three documents on the topic, 
draft-gont-6man-slaac-renum, targetted at 6man, that contains protocol 
updates.

---

From: [email-masked]
Date: Wed, 8 Apr 2020 16:29:15 +0200

> Part of renumbering is phasing out prefixes. And this is what we are doing here.

No you are not.
If you were doing renumbering, then you'd get two prefixes in DHCP PD. One old expired (lifetimes 0), one new with lifetimes > 0.
If that simple operational rule was followed, then none of these tweaks are required. (At least for this purpose).

> Certainly the opposite: A network is really brittle if just because a CPE Router crashes and reboots, the network breaks.
> 
> slaac-renum improves robustness. Even in the presence of cheap CPE, things do work.
> 
> I have no idea how you could possibly consider a network to be robust when in order for things to work, a lot of things need to happened in the way you expect, and a lot of elements you don't even have control of, need to function perfectly well.
> 
> A core design principle of the Internet is that as long as there is a working path from source to destination, communications survive possible outages.

Oh, I'm not saying that we shouldn't make host behaviour more robust. Rather the contrary. I'm just saying I don't think the proposed changes are the right ones.
Let me see if I find some spare time to write down how I would like it to work. Don't hold your breath.

> Now, splitting your role as a participant, and your role as wg char, may we have a wg call on draft-gont-6man-slaac-renum at 6man?

If you want me to put my chair hat on, then you need to take that to the 6man list.

Cheers,
Ole

---

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

Yeah .. it was buried in the text and easy to miss ... the Subject is v6ops and the list was v6ops, so I thought it was in reference to that and glanced over the "6man" in the document in the text.

Fixed Tim's email address.

- Bernie

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Wednesday, April 8, 2020 10:14 AM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]
Cc: [email-masked]; Lorenzo Colitti <[email-masked]>; Timothy Winters <[email-masked]>
Subject: Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

> And, isn't that why it is in v6ops? Discussing lifetime values is an operational consideration; the protocol already provides for supporting whatever lifetimes are selected (provided they meet the…

I *think* Ole is referring to one of the three documents on the topic, draft-gont-6man-slaac-renum, targetted at 6man, that contains protocol updates.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 11:43:00 -0300

On 8/4/20 11:19, Ted Lemon wrote:
[....]
> 
> Having the host keep a prefix around for a month in the absence of a single RA during that month seems like nonsensical behavior.  >
> If the prefix is to be valid for a month, presumably communication will be occurring frequently during that month; if it is not, then in what sense is the prefix valid?
> 
> What is the motivation for such long lifetimes?.

Not sure about the motivation. But it makes as much sense as putting an 
setting a clock alarm to wake up 2000 years from now. :-)

---

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

>> Part of renumbering is phasing out prefixes. And this is what we are doing here.

Let's agree to disagree.

I put a timer for addresses. Unless there's any sort of signal that the 
configuration is current in a veeery reasonable period of time, I phase 
out the prefix.

> If you were doing renumbering, then you'd get two prefixes in DHCP PD. One old expired (lifetimes 0), one new with lifetimes > 0.

This was already discussed on this mailing list. Please read 
draft-ietf-v6ops-slaac-renum. Many operators have already spoke up on 
the topic. I don't have much to add in addition to what has already been 
said.

> If that simple operational rule was followed, then none of these tweaks are required. (At least for this purpose).

If folks had follow the simple operational plan that everyone enables 
v6, and then when everyone could simply disable IPv4, we would have 
deployed v6 20 years ago, and we wouldn't have the ..load of 
transition/co-existence mechanisms that we have.

But hey, engineering is a bit about solving problems in the real world, 
rather than complaining that the problems are not solvable because the 
planet should actually be spinning in the opposite direction.

> Let me see if I find some spare time to write down how I would like it to work. Don't hold your breath.

We have been discussing this problem for over one year now.

> If you want me to put my chair hat on, then you need to take that to the 6man list.

I did, indeed: 
https://mailarchive.ietf.org/arch/msg/ipv6/qO_vGJrDVMOC1fnOGa8DquONOAs/ 
(at least for the second time).

Thanks,

---

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

> They are meant to support renumbering.

Ole, isn’t that exactly what we’re discussing here?

I think you’re holding to the rather narrow definition of renumbering as something that is in the control of the ISP, and so therefore anticipating the possibility of a renumbering event that is not in the control of the ISP seems out of scope.

But the reality is that the “operator” here is the CPE gateway, not the ISP.  The CPE gateway may have multiple upstream connections.  It can’t necessarily assume that promises made by the upstream will be kept.  And so anticipating the possibility of a renumbering event and keeping timers short enough that they can be expired reasonably quickly in the event of an actual renumbering event, while keeping them long enough that they don’t flap, seems like a reasonable thing for a CPE to do.

Having the host keep a prefix around for a month in the absence of a single RA during that month seems like nonsensical behavior.  If the prefix is to be valid for a month, presumably communication will be occurring frequently during that month; if it is not, then in what sense is the prefix valid?

What is the motivation for such long lifetimes?

---

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

And, there is nothing that requires PD to use the lifetimes received from the DHCP server in router advertisements.

RFC8415 has:

   If the client uses a delegated prefix to configure addresses on
   interfaces on itself or other nodes behind it, the preferred and
   valid lifetimes of those addresses MUST be no longer than the
   remaining preferred and valid lifetimes, respectively, for the
   delegated prefix at any time.  In particular, if the delegated prefix
   or a prefix derived from it is advertised for stateless address
   autoconfiguration [RFC4862], the advertised preferred and valid
   lifetimes MUST NOT exceed the corresponding remaining lifetimes of
   the delegated prefix.

So, the lifetimes can be shorter.

- Bernie

---

From: [email-masked]
Date: Wed, 8 Apr 2020 19:57:04 +0200

> I put a timer for addresses. Unless there's any sort of signal that the configuration is current in a veeery reasonable period of time, I phase out the prefix.

I think you are mixing what you are proposing in 6man with what you are proposing in v6ops.
The current draft in v6ops is reasonable, if the review comments I posted are included.
The added text on lifetimes in this document is not.

> This was already discussed on this mailing list. Please read draft-ietf-v6ops-slaac-renum. Many operators have already spoke up on the topic. I don't have much to add in addition to what has already been said.
> 
> 
> 
> If folks had follow the simple operational plan that everyone enables v6, and then when everyone could simply disable IPv4, we would have deployed v6 20 years ago, and we wouldn't have the ..load of transition/co-existence mechanisms that we have.
> 
> But hey, engineering is a bit about solving problems in the real world, rather than complaining that the problems are not solvable because the planet should actually be spinning in the opposite direction.

I take it being condecending is your way of saying you have run out of arguments?

The point is that there are many ways of misconfiguring or doing the mechanics of prefix delegation wrong.
That doesn't mean we should adapt the standards to accommodate who do not do it the way it is specified.
Especially when those operational practices have bad implications on end-users, and the mitigations proposed are potentially risky for the majority who will never see a network "operated" this way.

> We have been discussing this problem for over one year now.

Yes, you have.
> I did, indeed: https://mailarchive.ietf.org/arch/msg/ipv6/qO_vGJrDVMOC1fnOGa8DquONOAs/ (at least for the second time).

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 15:28:46 -0300

> The current draft in v6ops is reasonable, if the review comments I posted are included.

Not sure what the "review comments you posted" are. I had responded with 
proposed text to address your comments. Are you referring to that? If 
so, yes of course that will be incorporated.

> The added text on lifetimes in this document is not.

The text on lifetimes was suggested in the WGLC thread. Please, even if 
you disagree, respond on that thread, because this one has deviated from 
the v6ops document for a while now. Of course I have my own view on the 
topic. BUt I don't mind the outcome -- the point is to have that 
discussed in the separate thread, so that we can agree on *something*. 
Also, whatever you object about the proposed text, please mark it clearly.

Now, going back to the 6man document, it essentially has two parts:
1) Using appropriate lifetimes
2) Inferring stale information.

#1 is similar to the new proposed text for the document you seem to 
object. -- And I don't see what, specifically, you object about it.

#2 Not sure what you don't like about it.

[...]
> I take it being condecending is your way of saying you have run out of arguments?

Clearly not. I wasn't being condescending. I was actually saying that 
quite often one need to solve scenarios that, on paper, don't take 
place. But in practice, they do. So you tell me that you have a paper 
that says how to do renumbering -- that's great, and I like it.

But at the same time, we have people telling us, that they have real 
world scenarios that our current protocols, as is, don't handle 
properly. And in many cases (such as a user who's ISP does dynamic 
prefixes, or who has a CPE that announces PIO lifetimes past the PD 
lease), they have no control over the elements that trigger such scenarios.

* In the best interest of v6ops, and in the best interest of 6man, we 
probably want, to the extent that is possible, that our protocols handle 
such scenarios gracefully. -- in a way, you could even frame this in 
Postel's principle. (handle in a gracefully manner scenarios that you 
thing shouldn't happen).

* We do a bad service to the ISP that want to deploy IPv6 and face these 
problems while deploying (this work was indeed triggered by an ISP 
deploying IPv6) -- it's a hassle they have to deal with, and it's calls 
they are going to get. And also, because if they are "lucky", the 
traffic they expected to go over IPv6, will go over IPv4 -- exactly the 
opposite of what they were expecting.

* And we do a bad service to the user, because if as soon as the ISP 
turns on IPv6, his/her connections gets stalled frequently, and the 
users somehow realizes that that happened since the ISP enabled IPv6 
that's another one that goes into the basket of -> disable IPv6.

> That doesn't mean we should adapt the standards to accommodate who do not do it the way it is specified.

I don't see the point of repeating what a number of operators mentioned 
on this list already: there are multiple scenarios for which 
flash-renumbering may happen.

> Especially when those operational practices have bad implications on end-users, and the mitigations proposed are potentially risky for the majority who will never see a network "operated" this way.

You claim "this is potentially risky". Could you please elaborate what, 
specifically, you think is risky? And what's the scenario where what's 
being proposed would fail?

>> We have been discussing this problem for over one year now.

No, not "me". We as a group. I understand that you probably have your 
own view on the topic. But I do believe that, ultimately, it is the 
*wg's* decision what to do with documents.

So... why can't the wg be polled about it?

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Apr 2020 07:04:00 +1000

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

> It would probably work better to factor preferred lifetimes into source
> address selection. iOS, if two source addresses are otherwise equivalent,
> pick the one that’s valid longer.
>

That would only work if all addresses started out with the same initial
valid lifetimes, and hosts learned/configured all addresses at the same
moment, so that the current valid lifetime is comparable across the
addresses.

That may not be the case since initial lifetimes are a network operator
settable parameter rather than an IETF constant, and different routers on a
link can come and go and advertise different prefixes with different
initial valid lifetimes.

Regards,
Mark.

> >>>> I think that in principle this is true, but I’m not sure that it
> follows in practice.  What should we be doing instead?  Or was this just a
> miscommunication, per Lorenzo’s clarifying message?
> >>>>
> >>>> My experience with this tends to make me want to agree with Lorenzo.
> The longer a PIO prefix lifetime is, the longer things are broken when the
> router stops advertising the prefix without deprecating it.  OTOH, it’s
> _always_ going to be too long, so as you say, we really want a better way
> to detect that we have a problem.  Right now if one device remembers a
> stale on-link prefix that another device has not seen, the first device may
> choose that stale prefix during source address selection, and of course
> since the second device doesn’t see it as on-link, this will fail.
> >>>>
> >>> Exactly. It doesn't much matter if the prefix lifetime is 100 years or
> two hours. The user isn't going to sit around for that time anyway.
> >>
> to deprecate and subsequently eliminate addresses corresponding to a router
> that simply disappears.
> >>
> > Either they are so short that they expire during a link flap or they
> will regardless be so long that it’s beyond an acceptable wait time for a
> user.
> >
> >
> crashes and reboots. I'm not sure what's your definition of corner-case --
> but this is a very common scenario. And, as it should be clear from this
> discussion, there are multiple reasons for which such scenarios could take
> place (CPE crashes and reboots, CPE announces PIOs with a lifetime that
> spans past the DHCPv6-PD lease, etc.)
> >

---

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

On Apr 8, 2020, at 5:04 PM, Mark Smith <[email-masked]> wrote:
> That would only work if all addresses started out with the same initial valid lifetimes, and hosts learned/configured all addresses at the same moment, so that the current valid lifetime is comparable across the addresses.
> 
> That may not be the case since initial lifetimes are a network operator settable parameter rather than an IETF constant, and different routers on a link can come and go and advertise different prefixes with different initial valid lifetimes.

I understand the math, but if the CPE is capping prefix lifetimes, and ISPs are sending long-lived prefixes, then this won’t actually be a problem in practice.

To address Fernando’s point about flapping, one way to deal with this is to assume that routers will advertise at least every ten minutes, and only when the difference in preferred lifetimes is greater than ten minutes do we prefer the longer lifetime.

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Apr 2020 17:40:55 -0700

Sounds hopeful.

Sent using a machine that autocorrects in interesting ways...

> On Apr 8, 2020, at 10:57 AM, [email-masked] wrote:
> 
> 
>>

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Apr 2020 12:07:57 -0700

For the record, this discussion has closed, and Ron sent a note this morning opening a new WGLC. Fernando has opened a thread in which he is verifying that changes he is making address the points raised. I expect he will post a new draft in a week or two. I will query those who responded in that thread and convince myself that they are happy with the changes, run a quick WGVLC (working group very last call) on the list, and then be looking for a draft shepherd as described in IETF processes.

> On Mar 30, 2020, at 8:47 AM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Folks,
>