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

[Gyan Mishra <[e-mail]>]

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

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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