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

[Lorenzo Colitti <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> 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 <
> [e-mail]> wrote:
>
>> Hi,
>>
>> I believe this is an important topic and the draft should be adopted by
>> the WG.
>>
>> This question:
>>
>> > 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:
>> > 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
>> >
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [e-mail]
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> >
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>