Subject: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"

From: Bob Hinden <[email-masked]>
Date: Fri, 26 Jun 2020 16:35:27 -0700

This message starts a two week 6MAN call on adopting:

 Title:          Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events
 Authors:        F. Gont, J. Zorz, R. Patterson
 File Name:      draft-gont-6man-slaac-renum-08
 Document date:  2020-05-18

 https://tools.ietf.org/html/draft-gont-6man-slaac-renum

as a working group item. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on 10 July 2020.

There has been a lot of discussion on this draft, the chairs have some concerns with this document being adopted, but wanted the w.g. to express its opinion.  Our concerns include:

This document proposes significant changes to SLAAC to fix what could be seen as an implementation problem in some edge routers.  This will affect all IPv6 nodes, not only the ones communicating with these edge routers.  This part of IPv6 is a mature standard.   It is not clear we should modify all IPv6 hosts to deal with one corner case that may break other things allowed by the standard.

The changes proposed will make SLAAC more active, the changes include:

 o Reducing the default Valid Lifetime and Preferred Lifetime of PIOs
 o Caps the received Valid Lifetime and Preferred Lifetime of PIOs.
 o Frequent retransmission of configuration information
 o Routers send all options in RA messages

Some additional questions for the w.g. to consider:
 o Are there better approaches to address the underlying issue?
 o Do the proposed changes work in all deployments?
 o Are some proposed changes worth advancing even if the entirety may not be? If so, which ones?

We would like the w.g. to consider and comment on these issues when responding to this adoption call.

Bob & Ole
6man co-chairs

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Jun 2020 16:03:00 +1200

Hi,

I believe this is an important topic and the draft should be adopted by the WG.

> o Do the proposed changes work in all deployments?

is very important and I don't think we can ever know the answer. So in my opinion the whole document needs to be treated as a SHOULD, with clear understanding of what SHOULD means in the IETF: 
  "there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

I'd like to see a clear statement about this at the beginning of section 4 ("Improvements to Stateless Address Autoconfiguration (SLAAC)") and I suggest that the single MUST in the text should really be a SHOULD.

Regards
   Brian Carpenter

On 27-Jun-20 11:35, Bob Hinden wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Jun 2020 01:15:08 -0400

Bob & Ole

The one main concern I do have as stated is that the flash renumbering
event is a unique corner case for home or SOHO broadband users.

We recently went through prior to this draft with Fernando on the 4941bis
review after many thread and going through various scenarios and operations
issues and finally came up with a solid update to change the VL & PL to 2
days.  We took into account long lived connections and operational impact
of having many addresses and strived to strike a solid balance between
broadband  and enterprise use cases.

This drafts update is a drastic change to 4941bis VL PL lifetimes which we
spent a considerable amount of time on coming to consensus.

Since the flash renumbering is such a corner case I think we really have to
vet the impact of changes in all other scenarios.  Also the fact that users
at home are causal users not business critical that can result in revenue
loss I think that would be a consideration.

Also maybe having a v6ops draft that talks about corners case issues which
below does exist.

https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum-08

I am not in favor of adopting this draft as it is a small corner case being
addressed and I am afraid of the fall out from impact in all other use
cases.

Gyan

On Sun, Jun 28, 2020 at 12:03 AM Brian E Carpenter <
[email-masked]> wrote:

> is very important and I don't think we can ever know the answer. So in my
> opinion the whole document needs to be treated as a SHOULD, with clear
> understanding of what SHOULD means in the IETF:
>   "there
> I'd like to see a clear statement about this at the beginning of section 4
> ("Improvements to Stateless Address Autoconfiguration (SLAAC)") and I
> suggest that the single MUST in the text should really be a SHOULD.
>
> Regards
>    Brian Carpenter
>
> >  Title:          Improving the Robustness of Stateless Address
> Autoconfiguration (SLAAC) to Flash Renumbering Events
> > as a working group item. Substantive comments and statements of support
> for adopting this document should be directed to the mailing list.
> Editorial suggestions can be sent to the authors.  This adoption call will
> end on 10 July 2020.
> >
> > There has been a lot of discussion on this draft, the chairs have some
> concerns with this document being adopted, but wanted the w.g. to express
> its opinion.  Our concerns include:
> >
> > This document proposes significant changes to SLAAC to fix what could be
> seen as an implementation problem in some edge routers.  This will affect
> all IPv6 nodes, not only the ones communicating with these edge routers.
> This part of IPv6 is a mature standard.   It is not clear we should modify
> all IPv6 hosts to deal with one corner case that may break other things
> allowed by the standard.
> >
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Jun 2020 01:40:33 -0400

The draft states it is updating RFC 4861 and 4862 the PIO SLAAC VL PL to be
much lower to prevent the corner case of stale address issue.

It does not update the privacy extension update to RFC 4941 correct?

I do still have a lot of reservations even then with updating the VL PL on
the PIO prefixes to very low to solve a corner case that has existed since
Day 1.

A lot of enterprise and service providers disable the temporary address for
operational simplicity and use the PIO slaac for all communication.  I
think with RFC 4941bis update that will change.

I wonder if instead of tackling this renumbering issue on the host end
point broadband user perspective, maybe dealing with the renumbering event
with a how the broadband provider has these renumbering events that impact
the end customer.  I think maybe this should be delt with at the source of
the issue which is the broadband carrier. We are paying for service and the
carrier needs to deliver and provide that resilience and not impact the
customer.

I can bring this up on NANOG.

Gyan

On Sun, Jun 28, 2020 at 1:15 AM Gyan Mishra <[email-masked]> wrote:

> Since the flash renumbering is such a corner case I think we really have
> to vet the impact of changes in all other scenarios.  Also the fact that
> users at home are causal users not business critical that can result in
> revenue loss I think that would be a consideration.
>
> I am not in favor of adopting this draft as it is a small corner case
> being addressed and I am afraid of the fall out from impact in all other
> use cases.
>
> Gyan
>
>
>
>
>> I'd like to see a clear statement about this at the beginning of section
>> 4 ("Improvements to Stateless Address Autoconfiguration (SLAAC)") and I
>> > This document proposes significant changes to SLAAC to fix what could
>> be seen as an implementation problem in some edge routers.  This will
>> affect all IPv6 nodes, not only the ones communicating with these edge
>> routers.  This part of IPv6 is a mature standard.   It is not clear we
>> should modify all IPv6 hosts to deal with one corner case that may break
>> other things allowed by the standard.
>> >

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 28 Jun 2020 02:45:26 -0400

These days at home most endpoints are not always on and are mobile and not
stationary and maybe in sleep mode.  So when endpoint is used for the
duration of the internet connection they power up or come out of sleep mode
and maybe getting a new address.

Most providers use PD to delegate the address to broadband customers.

If a renumbering event happened quick way to recover would be to reload the
router.

I would think the renumbering event is not that often and hopefully happens
when the mobile device is powered off or in sleep mode.

Also what if mobile devices getting PIO slaac were powered off when not in
use to mitigate probability of renumbering event.

Could this be renumbering issue be addressed by HomeNet with best practices
for home users?

Gyan

On Sun, Jun 28, 2020 at 1:40 AM Gyan Mishra <[email-masked]> wrote:

>
> The draft states it is updating RFC 4861 and 4862 the PIO SLAAC VL PL to
> be much lower to prevent the corner case of stale address issue.
>
> A lot of enterprise and service providers disable the temporary address
> for operational simplicity and use the PIO slaac for all communication.  I
>> This drafts update is a drastic change to 4941bis VL PL lifetimes which
>> we spent a considerable amount of time on coming to consensus.
>>
>> Also maybe having a v6ops draft that talks about corners case issues
>> which below does exist.
>>
>>> is very important and I don't think we can ever know the answer. So in
>>> my opinion the whole document needs to be treated as a SHOULD, with clear
>>> > as a working group item. Substantive comments and statements of
>>> support for adopting this document should be directed to the mailing list.

*Gyan Mishra*

---

From: Tim Chown <[email-masked]>
Date: Sun, 28 Jun 2020 21:46:09 +0100

I support adoption.

> On 27 Jun 2020, at 00:35, Bob Hinden <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Sun, 28 Jun 2020 22:48:52 -0300

Hello, Gyan,

> event is a unique corner case for home or SOHO broadband users.

This is incorrect. Please see: 
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum

> We recently went through prior to this draft with Fernando on the 
> 4941bis review after many thread and going through various scenarios and 
> operations issues and finally came up with a solid update to change the 
> VL & PL to 2 days.  We took into account long lived connections and 
> operational impact of having many addresses and strived to strike a 
> solid balance between broadband  and enterprise use cases.
> 

This is incorrect. The RFC4941/RFC4941bis VL/PL values enforce a maximum 
preferred lifetime and valid lifetime. This means that even if the 
corresponding prefixes keep being announced with non-zero PL and VL, you 
will still unprefer the corresponding addresses, and eventually 
invalidate the corresponding addresses.

OTOH, the PL and VL you advertise in RAs simply mean "these are the 
maximum values you should use until you hear from me again". Since RAs 
are routinely transmitted as per RFC4862, these timers will be 
refreshed. Only when there's an actual network failure will there be any 
practical difference.

> Also maybe having a v6ops draft that talks about corners case issues 

Would you mind elaborating on what you mean by "corner case"? Operators 
have repeatedly noted on the v6ops list that these scenarios do happen. 
And as noted in another email, work on this topic was indeed triggered 
by an ISP that asked for guidance while dealing with this issues.

https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum should make it 
evident that this is a general issue with SLAAC, as opposed to a "corner 
case" that happens in one particular scenario.

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Sun, 28 Jun 2020 22:40:02 -0300

Hello, Bob,

Thanks for starting the WG call for adoption!

While I do expect participants to read through the document and make
their own judgement, some of the statements in your email below seem a 
bit inaccurate or misleading. So I felt like clarifying some of the 
points you have raised.

Please see in-line....

On 26/6/20 20:35, Bob Hinden wrote:
[....]
> be seen as an implementation problem in some edge routers.

Firstly, this is not an implementation problem, but a protocol-based 
problem: SLAAC does not react gracefully to flash renumbering events.

The problem does not arise in one particular scenario, but it's actually 
a general issue with the protocol. Please see: 
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01

Secondly, I don't think any of the four items you list below are 
significant changes to SLAAC. Namely:

* "Reducing the default Valid Lifetime and Preferred Lifetime of PIOs"

I would assume that the reason the protocol conveys time values in 
protocol fields is so that they can be changed. Otherwise they would be 
hardcoded in the protocol, and not communicated via PDUs/packets.

* "Cap the received lifetimes"

There is nothing in SLAAC that forces nodes to keep addresses for the 
PL/VL advertised in RAs. In fact, RFC4941 already leverages this fact 
(by configuring addresses that employ effective lifetimes that are 
shorter than the ones advertised in RAs). There are a couple of special 
cases that need to be taken care of, which the latest rev of this 
document already does.

* "Frequent retransmission of configuration information"

This is misleading. Firstly, Section 4.3 of the document recommends 
resending configuration information *upon interface initialization* -- 
i.e., this applies only when an interface is initialized, and not during 
regular operation, so to speak. Secondly, This behavior is allowed by 
RFC4861 already ("MAY transmit..")... so I'm not sure why you'd deem 
this as a significant change.

* "Routers send all options in RA messages"

This document recommends that routers send all *PIOs* in the same RA. As 
reported by Tim Winters, this essentially matches all running code.

> This will
> affect all IPv6 nodes, not only the ones communicating with these
> edge routers.  This part of IPv6 is a mature standard.   It is not
> clear we should modify all IPv6 hosts to deal with one corner case
> that may break other things allowed by the standard.

I will note that this is not a corner case, but actually a general issue 
of SLAAC that has concrete operational implications. The problem (and 
some of the possible scenarios where it may arise) is discussed in 
detail in: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum

There have been other previous efforts that have tried to deal with some 
of the possible scenarios where this may arise, which include:

* Protocol update proposals: Jen's "Default Address Selection and Subnet
   Renumbering", draft-linkova-6man-default-addr-selection-update-00
  (work in progress), March 2017.

* Router implementations such as Fritzbox: 
https://www.si6networks.com/2016/02/16/quiz-weird-ipv6-traffic-on-the-local-network-updated-with-solution/

* Operational mitigations: RIPE-690 document: 
https://www.ripe.net/publications/docs/ripe-690

Several operators have repeatedly noted on the v6ops list why these 
scenarios may occur. And, in fact, work on this document was started in 
response to an ISP asking for guidance on how to deal with this problem.

Last, but not least, the whole point of adopting a document (as in this 
case), is for the WG to work on it, and if there's any aspect of the 
current proposal that needs to be improved or changed, modify the 
document accordingly.

> o Caps the received Valid Lifetime and Preferred Lifetime of PIOs. o
> Frequent retransmission of configuration information o Routers send
> all options in RA messages

Would you mind elaborating on what you mean by the changes "making SLAAC 
more active"?

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Jun 2020 14:10:46 +1200

On 29-Jun-20 13:48, Fernando Gont wrote:
...

> by an ISP that asked for guidance while dealing with this issues.

I'll repeat something I think I said many months ago. While I was in an
apartment that had a defective POTS twisted pair (eventually traced to
water ingress to a defective junction point under the road), I had multiple
ADSL resets every rainy day for months, and because of my ISP's policy
that led to multiple flash renumberings per day.

Yes, OK, it shouldn't happen but it does happen.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Jun 2020 12:54:02 +0900

I do not support adoption because I think this document will make SLAAC
more complicated, harder to implement, harder to evolve, and less
effective, and that this is the wrong trade-off to make because, as Gyan
says, this is essentially a corner case.

As I pointed out at
https://mailarchive.ietf.org/arch/msg/ipv6/1yimPGA9Eq8h0eS0LH22jy8ezwg/ , I
don't think draft-ietf-v6ops-slaac-renum convincingly makes the case that
this is a widespread problem. Many of the issues reported in that draft
involve either standards violations (e.g., flash renumbering while there is
a valid, unexpired DHCPv6 lease) or configuration errors (like an automated
push system that pushes an invalid configuration).

I do agree that some of the tweaks in this document make sense, but with
the exception of the "allow zero valid lifetime" tweak, it looks like they
are most or all operational tweaks that already allowed by the standards,
and thus could easily be published as v6ops recommendations without having
to update the standards.

But most importantly, I believe the fundamental change proposed by this
document (the text in section 4.5) is harmful for several reasons.

1. It complicates SLAAC in several ways. It requires hosts to keep track of
a lot more state. It associates PIOs with a particular router not just for
the purpose of routing but also for the purpose of lifetime processing. It
seems to special-case ULA prefixes, treating them differently from non-ULA
prefixes, and even tying them together ("Only RAs that advertise Global
Unicast prefixes may deprecate Global Unicast Addresses (GUAs), while only
RAs that advertise Unique Local prefixes may deprecate Unique Local
Addresses (ULAs)").

2. it attempts to detect network changes using heuristics which I think
will be brittle in the field, in particular, in the presence of packet
loss. We must bear in mind that many handheld devices intentionally drop
significant percentages of multicast traffic (upwards of 50%), when on
Wi-Fi networks because not listening to multicast traffic at every beacon
interval provides very substantial battery savings.

3. It only considers PIOs. But SLAAC can convey many parameters that are
specific to the given network or given router. The most obvious example
would be if a router advertises, say, a PIO of 2001:db8::/64 and RDNSS
servers of 2001:db8::cafe and 2001:db8::beef. (This is, for example, what
Android does when acting as a router for hotspot purposes.) Even if the
host correctly deprecates the PIOs, the host will still have a broken DNS
configuration. Fixing this would require complicating the already brittle
and complex heuristics in this document, and will require tying together
options like RDNSS and PIO that are currently not tied together in any way.
But there are many other options that would need to be treated in this way
in order to solve the problem with this approach. For example, the PREF64
option is potentially dependent on the network attachment. How would the
heuristics need to change for that option?

4. A consequence of #3 above is that any *new* option we define also needs
to update the heuristics, and needs rules on when and how to invalidate it,
potentially by being tied to other options that are already considered by
the heuristics. This means it will be more difficult to add new options to
SLAAC in the future. Further, if we do not carefully consider these
heuristics when adding other options, we'll end up with bugs in the
standards. An example of such a bug is already present in this draft: the
heuristics make assumptions on other parts of the standards, for example
they depend on the value of MaxRtrAdvertisementInterval.  But 1800 seconds
is incorrect, the correct number is in RFC 8319 and is 65535 seconds. This
is such a big difference (a factor of 36!) as to call into question the
correctness of the algorithm that depends on it, even in the draft as it
currently stands.

Instead of advancing this document I would suggest writing an operational
document suggesting best practices for configurations. If we think that
some of those best practices (even if allowed by the standards already)
require tweaks to the standards, then I think we could have a new, small
document making those minor changes. We probably already need such a
document for the "allow zero valid lifetimes in PIOs" tweak.

Cheers,
Lorenzo

On Sun, Jun 28, 2020 at 2:15 PM Gyan Mishra <[email-masked]> wrote:

>> suggest that the single MUST in the text should really be a SHOULD..
>>
>> Regards
>>    Brian Carpenter
>>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Jun 2020 02:42:49 -0300

On 29/6/20 00:54, Lorenzo Colitti wrote:
[...]
> 
> As I pointed out at 
> https://mailarchive.ietf.org/arch/msg/ipv6/1yimPGA9Eq8h0eS0LH22jy8ezwg/
>  , I don't think draft-ietf-v6ops-slaac-renum convincingly makes the
> case that this is a widespread problem. Many of the issues reported
> in that draft involve either standards violations (e.g., flash
> renumbering while there is a valid, unexpired DHCPv6 lease) or
> configuration errors (like an automated push system that pushes an
> invalid configuration).

I don't think shifting blame to e.g. the ISP will result in a better 
user experience.

That said,
    [UK-NOF]   Palet, J., "IPv6 Deployment Survey (Residential/Household
               Services) How IPv6 is being deployed?", UK NOF 39, January
               2018,
               <https://indico.uknof.org.uk/event/41/contributions/542/
               attachments/712/866/bcop-ipv6-prefix-v9.pdf>.

reports that 37% of of responding ISPs do dynamic prefixes. That seems 
pretty widespread to me. (not to mention the other possible scenarios).

> But most importantly, I believe the fundamental change proposed by
> this document (the text in section 4.5) is harmful for several
> reasons.
> 
> 1. It complicates SLAAC in several ways. It requires hosts to keep
> track of a lot more state. It associates PIOs with a particular
> router not just for the purpose of routing but also for the purpose
> of lifetime processing. It seems to special-case ULA prefixes,
> treating them differently from non-ULA prefixes, and even tying them
> together ("Only RAs that advertise Global Unicast prefixes may
> deprecate Global Unicast Addresses (GUAs), while only RAs that
> advertise Unique Local prefixes may deprecate Unique Local Addresses
> (ULAs)").

The mitigation in Section 4.5 requires only one additional variable per
advertised prefix: LTA_LA (a timestamp of when the prefix was last
advertised). Is that the "a lot more state" you are referring to?

> 2. it attempts to detect network changes using heuristics which I
> think will be brittle in the field, in particular, in the presence of
> packet loss. We must bear in mind that many handheld devices
> intentionally drop significant percentages of multicast traffic
> (upwards of 50%), when on Wi-Fi networks because not listening to
> multicast traffic at every beacon interval provides very substantial
> battery savings.

Could you please elaborate on why you think this would make
implementations brittle?

If such devices can successfully employ SLAAC, there's no reason
why the proposes mitigation would make them more brittle. Simply pick
LTA_DEPRECATE and LTA_INVALID that suits you.

> 3. It only considers PIOs. But SLAAC can convey many parameters that
> are specific to the given network or given router. The most obvious
> example would be if a router advertises, say, a PIO of 2001:db8::/64
> and RDNSS servers of 2001:db8::cafe and 2001:db8::beef. (This is, for
> example, what Android does when acting as a router for hotspot
> purposes.) Even if the host correctly deprecates the PIOs, the host
> will still have a broken DNS configuration. Fixing this would require
> complicating the already brittle and complex heuristics in this
> document, and will require tying together options like RDNSS and PIO
> that are currently not tied together in any way. But there are many
> other options that would need to be treated in this way in order to
> solve the problem with this approach. For example, the PREF64 option
> is potentially dependent on the network attachment. How would the

1) The point of the WG adopting a document is for the WG to work on it.
It is not necessarily an indication that the document in question is
already complete.

2) When it comes to the specific example you've cited, I'd say:
    * Quite normally, you have multiple configured RDNSS servers, for
redundancy purposes. So you presumably already have code to use a 
different RDNSS if the current one doesn't work. So, in that light, the 
existing code will take care of it.
    * That said, it would be sensible to set and cap the RDNSS lifetimes
a la Section 4.1.2, and, similarly, set the lifetime as a function of
the Router Lifetime. This will help with the associated garbage 
collection. -- i.e., one might want to incorporate this into the document.
    * If one wanted to further improve/fine tune this with the same logic
as in Section 4.5, the idea would be simple: if the same router
advertises a new RDNSS, but not the existing ones, simply reduce the old
RDNSS lifetimes. However, as per the previous bullets, hosts are already
expected to deal with a list of RDNSS, and use the ones that work.

> 4. A consequence of #3 above is that any *new* option we define also
>  needs to update the heuristics, and needs rules on when and how to 
> invalidate it, potentially by being tied to other options that are 
> already considered by the heuristics.

They need not. If nodes can gracefully deal with stale information
provided by such options, there's no need to invalidate them, and hence
no need for heuristics. OTOH, if hosts are not able to deal gracefully
with stale information provided by such options, and you don't devise a
mechanism to take care of such old information, then you have a broken
protocol.

> This means it will be more difficult to add new options to SLAAC in
> the future. Further, if we do not carefully consider these heuristics
> when adding other options, we'll end up with bugs in the standards.
> An example of such a bug is already present in this draft: the
> heuristics make assumptions on other parts of the standards, for
> example they depend on the value of MaxRtrAdvertisementInterval.  But
> 1800 seconds is incorrect, the correct number is in RFC 8319 and is
> 65535 seconds. This is such a big difference (a factor of 36!) as to
> call into question the correctness of the algorithm that depends on
> it, even in the draft as it currently stands.

Thanks for the note, we will correct that in the next rev.

That said, that doesn't affect the algorithm. If one wanted to be 
super-conservative, one could simply change LTA_INVALID_DEFAULT to 
65535, as you have noted (at the end of the day, the most important 
thing is to unprefer the addresses). That said, with the recommendation 
in Section 4.4, using 1800 (the value that we are currently employing, 
instead of RFC65535) would still be safe.

> Instead of advancing this document I would suggest writing an 
> operational document suggesting best practices for configurations. If
> we think that some of those best practices (even if allowed by the 
> standards already) require tweaks to the standards, then I think we 
> could have a new, small document making those minor changes. We
> probably already need such a document for the "allow zero valid
> lifetimes in PIOs" tweak.

There are a few things to note here:

1) Currently, some specs have "default" values, and at times there are 
BCPs that have "recommended" values -- such as the default "Router 
Lifetime" specified in RFC4861, and the "recommended" values in RFC7772. 
As someone at the last RIPE IPv6 meeting, default values essentially 
turn out to be "these values any sane person would override to something 
else". So, for the values in Section 4.1.1, I'd rather have a Std Track 
document that specifies sensible default values, rather than having a 
Std Track document that specifies inappropriate default values, and an 
operational document that somehow overrides the default values with 
something sensible.

2) In that light, this document contains what we think are required 
tweaks to the standards to improve the reaction of slaac to renumbering 
events.

3) I would expect that the decision to adopt this document does not 
necessarily imply that the document is published "as is", but rather 
than we use this document as a starting point. As part of such work, we 
(wg) might decide to change some things, drop some of the proposed 
mitigations, or split the document into smaller pieces.

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

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 29 Jun 2020 14:51:05 +0800

As an access approach, ADSL has nearly vanished due to being replaced by optical access in some countries. Since the electrical characteristics of optical access is stabler than that of copper line, I think the resets with optical rarely happens in rainy days.　:-)

Chongfeng Xie

From: Brian E Carpenter
Date: 2020-06-29 10:10
To: Fernando Gont; Gyan Mishra
CC: Bob Hinden; IPv6 List
Subject: Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
On 29-Jun-20 13:48, Fernando Gont wrote:
...

 
 
    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Jun 2020 16:49:55 +0900

> pretty widespread to me. (not to mention the other possible scenarios).

Please read the substance of the email I linked earlier. For example: for
the problem to occur it is not sufficient that there be flash renumbering.
The problem only occurs if there is a flash renumbering AND a crash with
loss of state AND layer 2 remains up. I stand by my assertion is that that
is a rare case

> advertised). Is that the "a lot more state" you are referring to?

It *is* a lot more state compared to what implementations keep now. Right
now, there's only the two lifetimes. In theory there's also the router that
advertised the prefix, but I believe most popular implementations don't
actually store that (it's only required for rule 5.5, and AFAIK only
Windows implements rule 5.5).

> LTA_DEPRECATE and LTA_INVALID that suits you.

And how do I determine "what suits me"? Can an implementation pick the same
value and have it work well on all networks? It seems to me that it can't,
because there are lots of variables that cannot be determined without
accumulating state on previous network behaviour such as packet loss and RA
frequency. It seems pretty clear that 5 seconds is not great in most
scenarios because if RAs are sent infrequently, then a single lost RA will
cause the device to conclude that some address is no longer preferred
(which by the way isn't really very useful because as long as there is an
active TCP connection on a deprecated address, that connection will remain
stuck for potentially tens of seconds or even minutes; but new connections
will instead use some other prefix, or even use IPv4).

I forgot to mention that this proposal also substantially complicates the
state machine by tying addresses to each other. Right now, from a SLAAC
point of view, each address is independent. Its lifetime can change if an
RA is received, but other than that, whether it is deprecated or not does
not depend on the state of other addresses on the interface. This document
would change that.

> It is not necessarily an indication that the document in question is

Yup. But I don't think the approach taken by this document is a promising
one. I think it adds too much complexity compared to the advantages that it
brings, and most importantly, it places a burden on future design work in
this area as well.

> expected to deal with a list of RDNSS, and use the ones that work.

Sure, we can fix that problem with more complexity. Like I said, if we
apply the approach taken in this document for PIOs to DNS, then we need
more rules, and more logic, and more dependencies between options. My main
concern with this approach is that we have to deal with this complexity for
all current options, and likely future options as well.

> mechanism to take care of such old information, then you have a broken

But that's exactly my point. Who decides the answer to the "if" in your
sentence above? And who writes the documents that inform implementations of
how to deal gracefully with stale information? The WG when working on those
future options, right? So we're adding more work to the WG whenever we
define new options.

> operational document that somehow overrides the default values with

Setting defaults seems much more appropriate for an operational document
than a standards track - particularly because a standards track document
refers to all implementations, whereas operational documents can change the
defaults based on the scenario that is being deployed. But if there is
consensus in this WG to change the defaults of the existing standards, then
that's fine.

> tweaks to the standards to improve the reaction of slaac to renumbering

Right, but apart from the tweaks, the document also contains pretty
fundamental changes to how SLAAC works. This is the work that I don't think
we should take on.

> mitigations, or split the document into smaller pieces.

Yup. Like I said, most of the document consists of simple tweaks that in
many cases are already allowed by existing standards. That definitely seems
publishable.

Another much simpler approach that could be taken to solve this problem is
to recommend that if a host receives an RA where previous prefix(es) - or
more in general, previous options - have disappeared, then it should
attempt to re-check that information's validity in some way (e.g., by
attempting off-link connectivity).

Cheers,
Lorenzo

---

From: Tim Chown <[email-masked]>
Date: Mon, 29 Jun 2020 09:49:47 +0100

On 29 Jun 2020, at 08:49, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> <snip>
> 
> Yup. Like I said, most of the document consists of simple tweaks that in many cases are already allowed by existing standards. That definitely seems publishable.

I don’t think adoption means we would include everything in the document in the final version that is published.  If “most of the document” contains advice you think is publishable, then should we not adopt and work on consensus on what is in the final version?

I do agree that data on evidence of the problem would be welcomed.  The user experience may be protected by other mechanisms such as happy eyeballs.

> Another much simpler approach that could be taken to solve this problem is to recommend that if a host receives an RA where previous prefix(es) - or more in general, previous options - have disappeared, then it should attempt to re-check that information's validity in some way (e.g., by attempting off-link connectivity).

That would seem to be one good bit of advice to include.

Best wishes,
Tim

---

From: Sander Steffann <[email-masked]>
Date: Mon, 29 Jun 2020 13:31:20 +0200

Hi,

On 29-06-2020 08:51, [email-masked] wrote:
> As an access approach, ADSL has nearly vanished due to being replaced by
> optical access in some countries.

In some countries: yes. In many countries ADSL and VDSL are extremely
common. In some countries ADSL is the upcoming technology and many
people still use dial-up.

Don't assume the luxuries some of us have as being normal :)

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 29 Jun 2020 12:48:35 +0100

Tim Chown wrote on 29/06/2020 09:49:
> I don’t think adoption means we would include everything in the
> document in the final version that is published.  If “most of the
> document” contains advice you think is publishable, then should we
> not adopt and work on consensus on what is in the final version?

Completely - adoption does not mean publication.  It just means that 
there's rough consensus that the draft is worth working on.

I'd like to see this draft adopted.  It deals with real world 
implementation problems.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Mon, 29 Jun 2020 14:19:20 +0200

>seen as an implementation problem in some edge routers.  This will 

I support adoption.

Just like PMTU blackholes, in theory, flash renumbering should not exist, but
in practice it does.

If we don't add support for flash renumbering, we can end up in a similar
sitation as PMTU blackholes: people start adding all kinds of weird workarounds
that overall make the system more complex.

> o Routers send all options in RA messages

I don't particularly agree with all choices made in the draft. And some 
stuff could be redundant. If a host can handle flash renumbering on its own,
then there is not much need to change valid and preferred lifetimes.

There are alternatives that don't need a router to send all options in one
RA message.

>not be? If so, which ones?

I think the key part of the draft is where the host figures out from received
RAs that a flash renumbering is going on. And change to valid and preferred
lifetimes is second to that.

I think the current proposed changes need some more work.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jun 2020 09:00:37 +1200

Hi Lorenzo,
On 29-Jun-20 19:49, Lorenzo Colitti wrote:
> On Mon, Jun 29, 2020 at 2:43 PM Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Please read the substance of the email I linked earlier. For example: for the problem to occur it is not sufficient that there be flash renumbering. The problem only occurs if there is a flash renumbering AND a crash with loss of state AND layer 2 remains up. 

Assuming you mean loss of state in the CE router, my experience was that an ADSL disconnect/reconnect did apparently cause loss of state. And my Windows host didn't seem to treat a short break in WiFi connectivity without a change of SSID as a layer 2 failure.

Past tense because I am no longer on ADSL and have a brand new CE router, so I cannot reproduce the effect. Anyone who is on ADSL can try it though, by briefly unplugging the relevant RJ11.

    Brian

> I stand by my assertion is that that is a rare case
>  
> 
> It *is* a lot more state compared to what implementations keep now. Right now, there's only the two lifetimes.. In theory there's also the router that advertised the prefix, but I believe most popular implementations don't actually store that (it's only required for rule 5.5, and AFAIK only Windows implements rule 5.5).
>  
> 
> And how do I determine "what suits me"? Can an implementation pick the same value and have it work well on all networks? It seems to me that it can't, because there are lots of variables that cannot be determined without accumulating state on previous network behaviour such as packet loss and RA frequency. It seems pretty clear that 5 seconds is not great in most scenarios because if RAs are sent infrequently, then a single lost RA will cause the device to conclude that some address is no longer preferred (which by the way isn't really very useful because as long as there is an active TCP connection on a deprecated address, that connection will remain stuck for potentially tens of seconds or even minutes; but new connections will instead use some other prefix, or even use IPv4).
> 
> I forgot to mention that this proposal also substantially complicates the state machine by tying addresses to each other. Right now, from a SLAAC point of view, each address is independent. Its lifetime can change if an RA is received, but other than that, whether it is deprecated or not does not depend on the state of other addresses on the interface. This document would change that.
>  
> 
> Yup. But I don't think the approach taken by this document is a promising one. I think it adds too much complexity compared to the advantages that it brings, and most importantly, it places a burden on future design work in this area as well.
>  
> 
> Sure, we can fix that problem with more complexity. Like I said, if we apply the approach taken in this document for PIOs to DNS, then we need more rules, and more logic, and more dependencies between options. My main concern with this approach is that we have to deal with this complexity for all current options, and likely future options as well.
>  
> 
> But that's exactly my point. Who decides the answer to the "if" in your sentence above? And who writes the documents that inform implementations of how to deal gracefully with stale information? The WG when working on those future options, right? So we're adding more work to the WG whenever we define new options.
>  
> 
> Setting defaults seems much more appropriate for an operational document than a standards track - particularly because a standards track document refers to all implementations, whereas operational documents can change the defaults based on the scenario that is being deployed. But if there is consensus in this WG to change the defaults of the existing standards, then that's fine.
>  
> 
> Right, but apart from the tweaks, the document also contains pretty fundamental changes to how SLAAC works.. This is the work that I don't think we should take on.
>  
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 30 Jun 2020 08:03:19 +1000

> Past tense because I am no longer on ADSL and have a brand new CE router, so I cannot reproduce the effect. Anyone who is on ADSL can try it though, by briefly unplugging the relevant RJ11.

I think that is going to be CPE and also ADSL DSLAM dependent.

Ericsson DSLAMs used to spoof a PPPoE PADT on behalf of the customer's
PPPoE session and send it to the BRAS/BNG if the ADSL link when down,
causing unnecessary session terminations if the loss of ADSL was a
link flap ("drop out") and recovered within 30 seconds.

PPP(oE) keep alives (LCP Echo Request/Replies) were best set to
tolerate an ADSL link flap, so sessions weren't dropped, however this
hidden feature of these DSLAMS defeated that. Eventually that setting
became exposed in the Ericsson DSLAM management software so it could
be disabled.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 30 Jun 2020 10:03:25 +0900

On Tue, Jun 30, 2020 at 6:00 AM Brian E Carpenter <
[email-masked]> wrote:

> > Please read the substance of the email I linked earlier. For example:
> for the problem to occur it is not sufficient that there be flash
> renumbering. The problem only occurs if there is a flash renumbering AND a
> crash with loss of state AND layer 2 remains up.
>
> Assuming you mean loss of state in the CE router, my experience was that
> an ADSL disconnect/reconnect did apparently cause loss of state. And my
> Windows host didn't seem to treat a short break in WiFi connectivity
> without a change of SSID as a layer 2 failure.
>

Right, but in that case the router (and should) can send router
advertisements that tell hosts that the old prefix is gone. There is no
loss of state.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Jun 2020 04:10:27 -0300

On 29/6/20 03:51, [email-masked] wrote:
> optical access in some countries. Since the electrical characteristics 
> of optical access is stabler than that of copper line, I think the 
> resets with optical rarely happens in rainy days.　:-)

Resets happen for many reasons. For many non-technical users, resetting 
(unplug&re-plug) is normally the first thing they'll do when trying to 
"fix the Internet". For instance, a local ISP runs has a phone menu 
that, for many/most issues, causes your ISP-managed CPE to be reset (!).

It also happens that, as a result of storms, you may get blackouts in 
some -- but not all -- electrical "phases".

---

From: Erik Kline <[email-masked]>
Date: Mon, 29 Jun 2020 21:16:27 -0700

> That would seem to be one good bit of advice to include.

<no hats>

I'll repeat my previous recommendation that a host can unicast an NS
from any of its GUAs in a suspected lost PIO for the router's
link-local address to the link-local address of the router.  Treat it
like NUD -- RRUD, return routing unreachability detection.

Active measures, I feel, may prove more reliable.

And an alternative to timer manipulation might be 6724 policy table
manipulation (e.g. something like add an entry for the PIO with
precedence "precedenceOf(::/0) - 1" and/or a new label, given the
table in 6724#2.1)?  I have not spent enough time thinking through the
implications of this, though.

</>

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 30 Jun 2020 09:54:18 +0400

> Yes, OK, it shouldn't happen but it does happen.

Dynamic IPv6 is a real pain to deal with. This was pushed as a
"business" decision to
avoid customers from hosting their own services at home in Mauritius.

[I keep pushing for static ipv6 for home users and explaining to local
ISPs that this is a bad
business decision as the cost of electricity is too high to bother
hosting a server at home.]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 30 Jun 2020 07:29:28 +0000

Hello Bob:

I see 2 distinct parts in the draft. On the one hand, the draft describes a problem and the state of the IPv6 signaling, can and cannot do with the lifetimes in RAs. I believe that this is really useful to the community and can be a strong base to frame the solution.

Then the draft jumps to a proposition to solve the issue. I see controversy on the solution part because indeed there can be several ways to either signal the host that it should renumber or leave it to the host to figure that out quickly. 

I'll note that the host is impacted whatever; there are few major OSes but a great many brands of CPEs; that the host OS may be refreshed faster than CPEs, some of which are just plugged on the phone line till fiber shows up. This means a great many (failure) combinations and a very slow path to the problem globally solved if we need to change both sides. So a host-only change like Erik's variation of NUD makes a lot of sense to me. A policy recommendation to the ISPs to keep the prefix stable within the original advertised lifetime seems also like a good idea.

All in all, I believe that there should be several solution drafts proposed and then the group would decide what's the best approach.

My vote here is to split the doc to remove the solution piece and make that a separate draft; then adapt the problem statement and discuss the rest.

Keep safe,

Pascal

> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
> Sent: samedi 27 juin 2020 01:35
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> Subject: Adoption Call for "Improving the Robustness of Stateless Address
> Autoconfiguration (SLAAC) to Flash Renumbering Events"
> 
> as a working group item. Substantive comments and statements of support for
> adopting this document should be directed to the mailing list.  Editorial
> suggestions can be sent to the authors.  This adoption call will end on 10 July
> 2020.
> 
> There has been a lot of discussion on this draft, the chairs have some concerns
> with this document being adopted, but wanted the w.g. to express its opinion.
> Our concerns include:
> 
> This document proposes significant changes to SLAAC to fix what could be seen
> as an implementation problem in some edge routers.  This will affect all IPv6
> nodes, not only the ones communicating with these edge routers.  This part of
> IPv6 is a mature standard.   It is not clear we should modify all IPv6 hosts to
> deal with one corner case that may break other things allowed by the standard.
> 
>  o Reducing the default Valid Lifetime and Preferred Lifetime of PIOs  o Caps
> the received Valid Lifetime and Preferred Lifetime of PIOs.
>  o Frequent retransmission of configuration information  o Routers send all
> options in RA messages
>

---

From: Philip Homburg <[email-masked]>
Date: Tue, 30 Jun 2020 16:13:26 +0200

> I'll repeat my previous recommendation that a host can unicast an
> NS from any of its GUAs in a suspected lost PIO for the router's
> link-local address to the link-local address of the router.  Treat
> it like NUD -- RRUD, return routing unreachability detection.

Personally I think that this is too complex for what it brings. However,
such a feature may have unexpected benefits. So I think it worth adding
this to the draft as an alternative to be able to see what a fully worked out
proposal would look like.

A slight variation that might work, is for a host to perfom NUD on the router's
address using the source address it is going to use. In that case the host
would not wait for a RA to arrive but always do that. 

The added complexity is that the host would have to do NUD per source address.
The added benefit is that the host would always verify that a particular source
address works for a given next hop.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jun 2020 14:34:43 -0300

On 29/6/20 04:49, Lorenzo Colitti wrote:
> renumbering. The problem only occurs if there is a flash renumbering AND 
> a crash with loss of state AND layer 2 remains up. I stand by my 
> assertion is that that is a rare case

Use of CPE+switch, or CPE+range extender is quite common. Not sure why 
you'd deem such scenarios as "rare". Also, there is no requirement, 
IIRC/AFAICT, that a "link down" event causes previous information to be 
discarded. -- i.e., there was even an example about TCP retransmissions 
in Stevens' TCPv1 book whether the author would unplug one of the 
endpoints, show TCP'd exponential backoff, the replug the endpoint, and 
everything would go back to normal.

FWIW, it might be worth adding a note about this to this doc. e.g. "Upon 
link-down events, SLAAC implementations are expected to verify the 
fershness of the network configuration information employed before the 
"link down event".

> It *is* a lot more state compared to what implementations keep now.
> 
> Right now, there's only the two lifetimes.. In theory there's also the 
> router that advertised the prefix, but I believe most popular 
> implementations don't actually store that (it's only required for rule 
> 5.5, and AFAIK only Windows implements rule 5.5).

Most current IPv6 implementations are broken when it comes to 
multi-prefix scenarios. In order to fix that, they need to implement 
RFC8028.
And in the context of RFC8028, requiring this extra time-stamp is a no 
brainer..

In any case, this document is a recommendation. "SHOULD" if you wish. 
You may not implement it if, for some reason, you don't want to.

> And how do I determine "what suits me"? Can an implementation pick the 
> same value and have it work well on all networks? 

Sure. Set LTA_INVALID to the advertised Router Lifetime (or 2*Router 
Lifetime, if you want to be overly conservative). This will be enough to 
do the associated garbage collection earlier than the current "1 month".

For un-preferring addresses, you do not need to pick any timer value.

> It seems to me that it 
> can't, because there are lots of variables that cannot be determined 
> without accumulating state on previous network behaviour such as packet 
> loss and RA frequency. It seems pretty clear that 5 seconds is not great 
> in most scenarios because if RAs are sent infrequently, then a single 
> lost RA will cause the device to conclude that some address is no longer 
> preferred (which by the way isn't really very useful because as long as 
> there is an active TCP connection on a deprecated address, that 
> connection will remain stuck for potentially tens of seconds or even 
> minutes; but new connections will instead use some other prefix, or even 
> use IPv4).

The 5-second value is meant to address the *theoretical* case where PIOs 
are split among multiple RAs. In the real world, they are not. So if you 
receive one RA that does not include the previous PIO, but includes a 
new one, you might as well unprefer the stale address without even 
waiting for the five seconds.

[.....]
> Yup. But I don't think the approach taken by this document is a 
> promising one. I think it adds too much complexity compared to the 
> advantages that it brings, and most importantly, it places a burden on 
> future design work in this area as well.

The advantage that it brings is that hosts may now do more appropriate 
use of available addresses, as well as unprefer and discard stale 
addresses that would otherwise lay around forever. I do think that's a 
significant advantage: robustness.

Nobody requires that any future design (e.g. other option 
specifications) do something similar. In fact, implementations are even 
free of not implementing this specification if they have reasons not to 
do so.

> more rules, and more logic, and more dependencies between options. My 
> main concern with this approach is that we have to deal with this 
> complexity for all current options, and likely future options as well.

Address information is the most critical piece: that's why this document 
focuses on that. If the wg wanted to do something similar for other 
options, that's the wg's call -- but that's not what we're currently 
proposing.

> sentence above? And who writes the documents that inform implementations 
> of how to deal gracefully with stale information? The WG when working on 
> those future options, right? So we're adding more work to the WG 
> whenever we define new options.

SLAAC does a bad job at dealing with stale information -- well, 
actually, it doesn't do the job at all.

So, if you are writing a spec, you should consider that there are going 
to be scenarios where information becomes stale, and will be laying 
around for ages. Then, you might:

1) Ignore the issue,

2) Claim that this should not or will not happen -- knowing that it does 
and it will (so this is basically #1 above), or,

3) Specify something that is robust

Being lazy is nice, but usually doesn't solve problems.

> refers to all implementations, whereas operational documents can change 
> the defaults based on the scenario that is being deployed. 

I believe it's fine to have an operational document if a specific 
deployment scenario warrants overriding the default values.

But the default values have to be sane in the first place. I don't think 
that's the case with the current PIO PL/VL default values.

> But if there 
> is consensus in this WG to change the defaults of the existing 
> standards, then that's fine.
> 
> fundamental changes to how SLAAC works.. This is the work that I don't 
> think we should take on.

So, in the hopes of making progress, how about this: please do let us 
know what's the part(s) that you object to (I assume Section 4.5?). -- 
You don't need to shoot down the entire document just because there's 
one part of it that you disagree with.

In fact, "adoption" means, indeed, that the wg will work on the 
document, and that the document will reflect the WG's view. It doesn't 
even mean that what's in Section 4.5 (or even a variation of it) will 
end up being published.

If I understand correctly, the only part of the document that you object 
to is Section 4.5. Is that correct?  Then, if so, we are agreeing on a 
lot, already. So why not progress the parts we all agree with, and 
discuss/debate the parts we don't?

> many cases are already allowed by existing standards. That definitely 
> seems publishable.

Then, let's progress those. And try to resolve or find alternatives for 
the others (Section 4.5, if I understand correctly).

> Another much simpler approach that could be taken to solve this problem 
> is to recommend that if a host receives an RA where previous prefix(es) 
> - or more in general, previous options - have disappeared, then it 
> should attempt to re-check that information's validity in some way 
> (e.g., by attempting off-link connectivity).

That is indeed an option. FWIW, we have tried to focus, specifically, on 
detecting stale information passively (refrain from generating extra 
traffic), and limiting ourselves to inferring when information becomes 
stale.

The problem with e.g. checking information validity as in "attempt 
off-link connectivity" is that, conceptually speaking, you are checking 
much more than whether the information is stale. (e.g. if off-link 
connectivity fails, that's not necessarily an indication that the 
information is stale).

So, in that light, one might want to check information validity by 
sending an unicasted RA to the Router as a final check to see if the 
information has indeed vanished/become stale.

In any case, discussing this sort of thing, and agreeing or something, 
is indeed the point of wg adoption: having the wg work on the document, 
and output something that reflects wg consensus.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jun 2020 14:59:50 -0300

> like NUD -- RRUD, return routing unreachability detection.

That's indeed possible. In fact, we did consider this, but were so far 
relying on subsequent unsolicited RAs (for actually invalidating an 
address).

One can certainly augment the current algorithm, and recommend that 
e.g., such an NS is sent at the very same time a missing option is 
detected, and one might even also recommend that another one be sent 
upon LTA_INVALID/2 seconds (i.e., before an address is actually eliminated).

> implications of this, though.

I'd need to give this more proper thought, but, of the top of my head:

* In the context of RFC8028, you need still need to dis-associate the 
prefix with the router that has ceased to advertise it. i.e., if you 
have multiple routers advertising the prefix, if one of them ceases to 
advertise it you don't need to stop using it for new connections, but 
just e.g. stop sending such packets to the router that has ceased to 
advertise the prefix (send them to any other router that has advertised it).

* I believe that the "preferred/unpreferred" status already provide what 
we need. The underlying issue is that, in practice, the 
"preferred/unpreferred" status is meaningless, because it's associated 
with timers that are set to such long values that they will never go off 
in any meaningful timeframe.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jun 2020 15:32:32 -0300

Hello, Pascal,

On 30/6/20 04:29, Pascal Thubert (pthubert) wrote:
> Hello Bob:
> 
> I see 2 distinct parts in the draft. On the one hand, the draft
> describes a problem and the state of the IPv6 signaling, can and
> cannot do with the lifetimes in RAs. I believe that this is really
> useful to the community and can be a strong base to frame the
> solution.
> 
> Then the draft jumps to a proposition to solve the issue. I see
> controversy on the solution part because indeed there can be several
> ways to either signal the host that it should renumber or leave it to
> the host to figure that out quickly.

FWIW, what this document is trying to do is to tweak the protocol, and 
implement mitigations, in a way that the problem in question can be 
mitigated without the need for both the local host and the local router 
to implement a new behavior.

In that light, any kind of signaling by the router would required 
changes to both the router (to send the signal) and the host (to process 
it), making it a no starter for what we are trying to achieve. We are 
trying to improve the situation for hosts where their local router will 
not be updated in any sensible time frame, as well as for hosts that 
will not be updated, but may attach to a network where the local router 
has been updated.

> I'll note that the host is impacted whatever; there are few major
> OSes but a great many brands of CPEs; that the host OS may be
> refreshed faster than CPEs, some of which are just plugged on the
> phone line till fiber shows up. This means a great many (failure)
> combinations and a very slow path to the problem globally solved if
> we need to change both sides. So a host-only change like Erik's
> variation of NUD makes a lot of sense to me. 

We are trying to do both.

> A policy recommendation
> to the ISPs to keep the prefix stable within the original advertised
> lifetime seems also like a good idea.

We are doing that in: draft-ietf-v6ops-slaac-renum. That said, that's 
just one of the possible scenarios.

> All in all, I believe that there should be several solution drafts
> proposed and then the group would decide what's the best approach.

This problem (along with this document) has been discussed for over a 
year now.

The only bit where there seems to be differing opinions is on Section 
4.5 (but not the rest of the document).

And regarding Section 4.5 itself, I believe our differences are rather 
minor. For example, it seems we all agree that an RA that has ceased to 
advertise a PIO send an implicit signal (which you might use to unprefer 
or invalidate prefixes, or trigger an active text of the information).

    We might have small variations in this area ranging from reacting
    to such RA at once (since all existing implementations don't split
    RAs), to "wait for a few seconds before reacting, just in case" (as
    in the current version of the document) to try to "measure if the
    router is splitting RAs, and then use that information when deciding
    to react to the RA).

Then small variations regarding whether to react passively (as in the 
current version of the document), or whether to do some sort of active 
testing (either against the local router, or against an off-link system).

These possible variations and details do indeed to need to be worked 
out. But I believe they reflect a lot of points of agreement, already.

Thanks!

Cheers,

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jun 2020 15:25:15 -0400

I think that we have a rough consensus that there are events that seem to
cause long-connecting devices (such as desktops, TVs, appliances) to
sometimes fail to notice when there is a renumber.
("Short-connecting" devices like phones tend to join/leave often enough that
they usually get recent info. and they get tested more for this)

It seems that for the non-flash case, that there is a lack of complete
testing/implementation for the various cases, most of which are probably
already dealt with given proper implementation of the protocols.
The result is that many of us see renumbers which do not get deployed
smoothly, and we assume a flash renumber when in some cases, it was not.
("Your failure to plan ahead is not an emergency to me")

The result is that the urgency of this situation varies by experience, and by
quality of implementation.  It seems that if we had an RFC that dealt with
the **FLASH** renumbering situation, that by construction, devices that dealt
with that would also deal smoothly with the planned renumering situation.
(Didn't we have an entire WG at one point to renumbering? I think it didn't
end that successfully, but that was during years I spent less time on IETF)

As Erik points out, I think that there a number of active measures that can
mitigate the situation without changes to RAs, but I also think that we can
plan long term such that each end of the conversation is trying to make
things go smooth.

To clarify: I think we should adopt this document, provided we can more
constructive understand that we do not all see the same part of the Elephant.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-