From fgont en si6networks.com  Tue Jun 30 16:31:19 2020
From: fgont en si6networks.com (Fernando Gont)
Date: Tue, 30 Jun 2020 16:31:19 -0300
Subject: [Lista ArNOG] Fwd: (fwd) Adoption Call for "Improving the
 Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash
 Renumbering Events"
In-Reply-To: <8022a231-4c1b-c157-1f8f-aba9301b9f50@si6networks.com>
References: <8022a231-4c1b-c157-1f8f-aba9301b9f50@si6networks.com>
Message-ID: <da185d20-d27e-3bcd-9291-973d8194a9a0@si6networks.com>

Estimados,

El 6man wg de IETF está haciendo el llamado a adopción de nuestro IETF 
Internet-Draft "Improving the Robustness of Stateless Address 
Autoconfiguration (SLAAC) to Flash Renumbering Events" 
(https://www.ietf.org/id/draft-gont-6man-slaac-renum-08.txt)

Este es uno de los documentos que he presentado en eventos anteriores, 
que intenta solucionar un problema reportado por ISPs.

Los comentarios son bienvenidos. Y quienes quieran/puedan participar del 
llamado a adopción, mas aun.

Saludos, y gracias!
Fernando




-------- Forwarded Message --------
Subject: (fwd) Adoption Call for "Improving the Robustness of Stateless 
Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
Date: Sun, 28 Jun 2020 22:58:02 -0300
From: Fernando Gont <fgont en si6networks.com>
To: IPv6 Hackers Mailing List <ipv6hackers en lists.si6networks.com>

Folks,

The 6man chairs have started a WG call for adoption of our document 
"Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) 
to Flash Renumbering Events" 
(https://www.ietf.org/id/draft-gont-6man-slaac-renum-08.txt)

Our document proposes protocol improvements such that SLAAC can 
gracefully deal with renumbering events. The associated problem 
statement can be found here: 
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum

If you have comments/feedback/opinions on the topic and/or about the 
adoption of our document as a 6man wg item, please consider 
participating in the ongoing consensus call: 
https://mailarchive.ietf.org/arch/msg/ipv6/YBnHoe9yqw0Five6ckAjDWgMpyE/

Please also check the clarifications I've made regarding the adoption 
call: 
https://mailarchive.ietf.org/arch/msg/ipv6/XfUtieXhAACPj92noFPD8XjuF-Q/

Thanks!

Cheers,
Fernando




-------- Forwarded Message --------
Subject: Adoption Call for "Improving the Robustness of Stateless 
Address Autoconfiguration (SLAAC) to Flash Renumbering Events"
Date: Fri, 26 Jun 2020 16:35:27 -0700
From: Bob Hinden <bob.hinden en gmail.com>
To: IPv6 List <ipv6 en ietf.org>
CC: Bob Hinden <bob.hinden en gmail.com>

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