[lacnog] [IPv6]I-D Action: draft-ietf-6man-slaac-renum-14.txt

[Henri Alves de Godoy]

Jordi,

A ideia de ter endereços IPv6 persistentes para o cliente acredito ser
inviável pois o host cliente arma automaticamente o IPv6 temporário por
padrão.  Para mim, para efeitos de auditoria e incidentes de segurança, o
endereço temporário (saída) é o mais importante e o que temos para
investigar e deve ser armazenado de alguma forma em algum log.   Diminuir o
tempo, aumenta a complexidade em fazer auditoria e dependendo dos
registros, os logs podem aumentar tambem.

Mas por outro lado, resolve, acredito eu, essa indisponibilidade de conexão
devido a mudança de prefixos e elimina os prefixos fantasmas que muitas
vezes um host apresenta.

Henri.



Em ter., 7 de jul. de 2026 às 03:39, jordi.palet--- vía LACNOG <
lacnog en lacnic.net> escreveu:

> Hola Fernando,
>
> Por aclarar conceptos. El objetivo del documento no es resolver la
> conectividad con multiples enlaces, sino que cambios en el prefijo
> asignado, sean resueltos de forma mas ágil (lo cual tampoco es infalible en
> el sentido de “instantáneo”).
>
> En cualquier caso, es obvio que hay que cambiar el paradigma respecto de
> IPv4 y pensar que si queremos que los usuarios puedan tener servicios
> estables (a ser posibles asociados a FQDNs), e incluso que esos servicios
> sean ofrecidos por el ISP o terceros que probablemente colaboren con el
> ISP, lo ideal es que los prefijos sean persistentes en un determinado
> enlace (para que no haya errores, en absoluto se pretende que el usuario
> que cambia su enlace o ubicación siga teniendo el mismo prefijo, eso podría
> depender de la oferta de servicios que quiera ofrecer el ISP, de como
> realiza la agregación, etc.). Eso evita la necesidad del “flash
> renumbering".
>
> Saludos,
> Jordi
>
> @jordipalet
>
> El 6 jul 2026, a las 23:33, Fernando Gont <fgont en si6networks.com>
> escribió:
>
> Hola, Doublas,
>
> On 06/07/2026 09:23, Douglas Fischer wrote:
>
> Olá Gont!
> <Off-Topic>Peço gentilmente que hoje não falemos de futebol!
> Muita dor de cabeça viking por aqui. haha </Off-Topic>
> Vou te fazer um pedido, e creio que isso pode ser uma oportunidade de
> esclarecer e angariar apoiadores...
> - Esse Draft nasceu em 2020.
> - Esse Draft está n a 14ª revisão oficial.
> - Os threads de e-mail desse Draft são imensos, e alguns bem calorosos.
>
>
> Bienvenido a IETF. :-)
>
>
>
> Você poderia por gentileza explicar os pontos positivos e negativos no
> caso desse draft convergir a RFC?
>
>
> Si, el problema esta descripto aca:
>
> *
> https://www.techtarget.com/searchnetworking/tip/Understanding-why-IPv6-renumbering-problems-occur
>
> * https://www.internetsociety.org/blog/2019/02/slaac-renum-reaction/
>
>
> De todos las soluciones, las que el documento actual mantiene son dos:
>
> * Poner timers mas sensibles: los timers actuales son de, por ejemplo,
>  una semana o un mes, lo cual es obviamente ridiculo. -- y nosotros
>  bajamos estos timers a 1 hora, aproximadamente.
>
> * Permitir que las implementaciones eliminen prefijos viejos cuando
>  recibien uno con un timer < 2 horas (esto actualmente lo prohibe le
>  especificacion).
>
> * Aconsejar que toda la informacion de autoconfiguracion debe ser
>  enviada en un unico RA (o en la menor cantidad de RAs posibles).
>
>
> Las soluciones se encuentran aqui:
>
> *
> https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-14.html#name-improvements-to-stateless-a
>  (el principio de la Seccion 5 explica que es cada cosa, y para que).
>
>
>
>
> P.S.: Se eu não estou fazendo confusão, eu tenho bastante esperança de que
> essa RFC vá ser a qual vai resolver de fato as brigas sobre usuário
> doméstico(sem link dedicado ou BGP) e múltiplos links de Internet.
>
>
>
> Hay mas cosas para resolver, igual.
>
>
> El proceso ha sido bastante vergonzoso, igual --  Incluyendo pedirnos que
> blanqueemos todo el documento en la version -00 del WG:
> https://datatracker.ietf.org/doc/draft-ietf-6man-slaac-renum/00/. (ver:
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-renum-00#section-4.1
> )
>
> Lo loco de el caso es que uno luego escucha, inclusive en estos pagos, lo
> maravilloso que es el proceso, como hay que participar desde la region,
> etc. --- claramente, toda una maquinaria para que no cambie nada, y para
> que las cosas sigan funcionando cexactamente de la misma forma.
>
>
>
> Slds
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont en si6networks.com
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>


--
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20260729/801cd2ee/attachment-0001.htm>