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

Jue Jul 30 12:17:04 -03 2026

Obrigado Jordi pelos esclarecimentos.

Eu estava com outras preocupações na cabeça, no caso com relação a
auditoria e incidentes de segurança e posso ter misturado os assuntos.

Abraços !
Henri.

Em qui., 30 de jul. de 2026 às 04:23, jordi.palet--- vía LACNOG <
lacnog en lacnic.net> escreveu:

> Hola Henri,
>
> Creo que no estamos hablando de lo mismo.
>
> Se trata de prefijos persistentes con DHCPv6-PD hacia el CPE. Eso no
> implica que los clientes con direcciones o prefijos asignados mediante
> SLAAC o DHCPv6 (menos habitual), pueden tener direcciones diferentes, no
> persistentes, cambiantes, etc.
>
> Si tu tienes siempre el mismo prefijo desde tu operador, en el mismo
> enlace físico (o mismo punto de agregación), tal y como ya lo hacen muchos
> operadores en el mundo (para IPv6, no para IPv4), podrás tener algunos
> servicios o clientes dentro de la red que ofrecen servicios estables, por
> ejemplo, tu propio NAS, tus sistemas de seguridad o videovigilancia,
> servicios de domótica u otros que no necesiten Cloud, etc., y por ende
> evitamos el problema del “flash renumbering”.
>
> Cuando un operador ofrece prefijos persistentes, facilita muchas cosas,
> incluso en su propio beneficio. Por ejemplo, ya no necesita hacer un login
> como le exige la ley y almacenar millones de datos de conexiones con cada
> cambio de prefijo, puede ofrecer servicios adicionales de una forma mucho
> mas fácil al cliente, o puede trabajar con terceras partes para ofrecer
> dichos servicios, se pueden configurar de forma estable FQDNs (evitando así
> DNS dinámico que depende de terceras partes), permite una configuración
> estable mas sencilla de seguridad en firewall, etc.
>
> Otra cuestión importante es que los sistemas de reputación se vuelven más
> fiables, lo que de nuevo es un beneficio para todas las partes.
>
> Por el lado económico, ofrecer prefijos persistentes es un incentivo para
> los clientes para permanecer en el mismo operador, aún cuando otros puedan
> ofrecer servicios mas baratos, porque el hecho de cambiar por unos pocos
> dólares ya no compensa.
>
> Saludos,
> Jordi
>
> @jordipalet
>
> El 29 jul 2026, a las 20:41, Henri Alves de Godoy <
> henri.godoy en fca.unicamp.br> escribió:
>
> 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
>>
>
>
> --
>
>
>
> **********************************************
> 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/20260730/5b1ee8e7/attachment-0001.htm>