<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"></div><div dir="ltr"><p style="margin: 0px 0px 12px; font-style: normal; font-variant-caps: normal; font-width: normal; font-size: 20px; line-height: normal; font-family: "Times New Roman"; font-size-adjust: none; font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: normal; font-variant-emoji: normal; font-feature-settings: normal; font-optical-sizing: auto; font-variation-settings: normal; -webkit-text-stroke-width: 0px; -webkit-text-stroke-color: rgb(0, 0, 0);"><span style="font-kerning: none;">Uno de los aspectos más valiosos de los procesos técnicos abiertos es cuando el debate no se convierte en una competencia entre propuestas, sino en una construcción colectiva.</span></p>
<p style="margin: 0px 0px 12px; font-style: normal; font-variant-caps: normal; font-width: normal; font-size: 20px; line-height: normal; font-family: "Times New Roman"; font-size-adjust: none; font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: normal; font-variant-emoji: normal; font-feature-settings: normal; font-optical-sizing: auto; font-variation-settings: normal; -webkit-text-stroke-width: 0px; -webkit-text-stroke-color: rgb(0, 0, 0);"><span style="font-kerning: none;">En esta discusión sobre la renumeración en IPv6 se aprecia precisamente esa complementariedad: por un lado, mejorar el comportamiento de los protocolos para que los cambios de prefijos sean más rápidos y menos disruptivos; por otro, promover modelos operativos que reduzcan la necesidad de esos cambios mediante prefijos más persistentes. Son enfoques distintos, pero compatibles.</span></p>
<p style="margin: 0px 0px 12px; font-style: normal; font-variant-caps: normal; font-width: normal; font-size: 20px; line-height: normal; font-family: "Times New Roman"; font-size-adjust: none; font-kerning: auto; font-variant-alternates: normal; font-variant-ligatures: normal; font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-position: normal; font-variant-emoji: normal; font-feature-settings: normal; font-optical-sizing: auto; font-variation-settings: normal; -webkit-text-stroke-width: 0px; -webkit-text-stroke-color: rgb(0, 0, 0);"><span style="font-kerning: none;">Da gusto ver un intercambio donde las diferencias se abordan con argumentos técnicos sólidos, experiencia práctica y una comprensión profunda de la arquitectura de Internet. Así es como se construyen mejores estándares.</span></p><div><span style="font-kerning: none;">Carlos Vera</span></div></div><div dir="ltr"><br><blockquote type="cite">El 7 jul 2026, a la(s) 01:39, jordi.palet--- vía LACNOG <lacnog@lacnic.net> escribió:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">Hola Fernando,<div><br></div><div>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”).</div><div><br></div><div>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".</div><div><br id="lineBreakAtBeginningOfMessage"><div>
<div>Saludos,<br>Jordi<br><br>@jordipalet<br></div>
</div>
<div><br><a href="#" class="_AppleShowQuotedContentButton"><div style="height: 61px !important; overflow: hidden !important;"><blockquote type="cite" preoffsettop="1392" preoffsetheight="5070"><div>El 6 jul 2026, a las 23:33, Fernando Gont <fgont@si6networks.com> escribió:</div><br class="Apple-interchange-newline"><div><div>Hola, Doublas,<br><br><blockquote type="cite" __apple_fixed_attribute="true">On 06/07/2026 09:23, Douglas Fischer wrote:<br></blockquote><blockquote type="cite">Olá Gont!<br><Off-Topic>Peço gentilmente que hoje não falemos de futebol!<br>Muita dor de cabeça viking por aqui. haha </Off-Topic><br>Vou te fazer um pedido, e creio que isso pode ser uma oportunidade de esclarecer e angariar apoiadores...<br>- Esse Draft nasceu em 2020.<br>- Esse Draft está n a 14ª revisão oficial.<br>- Os threads de e-mail desse Draft são imensos, e alguns bem calorosos.<br></blockquote><br>Bienvenido a IETF. :-)<br><br><br><br><blockquote type="cite">Você poderia por gentileza explicar os pontos positivos e negativos no caso desse draft convergir a RFC?<br></blockquote><br>Si, el problema esta descripto aca:<br><br>* https://www.techtarget.com/searchnetworking/tip/Understanding-why-IPv6-renumbering-problems-occur<br><br>* https://www.internetsociety.org/blog/2019/02/slaac-renum-reaction/<br><br><br>De todos las soluciones, las que el documento actual mantiene son dos:<br><br>* Poner timers mas sensibles: los timers actuales son de, por ejemplo,<br> una semana o un mes, lo cual es obviamente ridiculo. -- y nosotros<br> bajamos estos timers a 1 hora, aproximadamente.<br><br>* Permitir que las implementaciones eliminen prefijos viejos cuando<br> recibien uno con un timer < 2 horas (esto actualmente lo prohibe le<br> especificacion).<br><br>* Aconsejar que toda la informacion de autoconfiguracion debe ser<br> enviada en un unico RA (o en la menor cantidad de RAs posibles).<br><br><br>Las soluciones se encuentran aqui:<br><br>* https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-14.html#name-improvements-to-stateless-a <br> (el principio de la Seccion 5 explica que es cada cosa, y para que).<br><br><br><br><br><blockquote type="cite">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.<br></blockquote><br><br>Hay mas cosas para resolver, igual.<br><br><br>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 )<br><br>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.<br><br><br><br>Slds<br>-- <br>Fernando Gont<br>SI6 Networks<br>e-mail: fgont@si6networks.com<br>PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494<br><br>_______________________________________________<br>LACNOG mailing list<br>LACNOG@lacnic.net<br>https://mail.lacnic.net/mailman/listinfo/lacnog<br>Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog<br></div></div></blockquote></div><div class="button">Mostrar contenido citado</div><div style="height: 61px !important; overflow: hidden !important;"><blockquote type="cite" preoffsettop="1392" preoffsetheight="5070"><div>El 6 jul 2026, a las 23:33, Fernando Gont <fgont@si6networks.com> escribió:</div><br class="Apple-interchange-newline"><div><div>Hola, Doublas,<br><br><blockquote type="cite" __apple_fixed_attribute="true">On 06/07/2026 09:23, Douglas Fischer wrote:<br></blockquote><blockquote type="cite">Olá Gont!<br><Off-Topic>Peço gentilmente que hoje não falemos de futebol!<br>Muita dor de cabeça viking por aqui. haha </Off-Topic><br>Vou te fazer um pedido, e creio que isso pode ser uma oportunidade de esclarecer e angariar apoiadores...<br>- Esse Draft nasceu em 2020.<br>- Esse Draft está n a 14ª revisão oficial.<br>- Os threads de e-mail desse Draft são imensos, e alguns bem calorosos.<br></blockquote><br>Bienvenido a IETF. :-)<br><br><br><br><blockquote type="cite">Você poderia por gentileza explicar os pontos positivos e negativos no caso desse draft convergir a RFC?<br></blockquote><br>Si, el problema esta descripto aca:<br><br>* https://www.techtarget.com/searchnetworking/tip/Understanding-why-IPv6-renumbering-problems-occur<br><br>* https://www.internetsociety.org/blog/2019/02/slaac-renum-reaction/<br><br><br>De todos las soluciones, las que el documento actual mantiene son dos:<br><br>* Poner timers mas sensibles: los timers actuales son de, por ejemplo,<br> una semana o un mes, lo cual es obviamente ridiculo. -- y nosotros<br> bajamos estos timers a 1 hora, aproximadamente.<br><br>* Permitir que las implementaciones eliminen prefijos viejos cuando<br> recibien uno con un timer < 2 horas (esto actualmente lo prohibe le<br> especificacion).<br><br>* Aconsejar que toda la informacion de autoconfiguracion debe ser<br> enviada en un unico RA (o en la menor cantidad de RAs posibles).<br><br><br>Las soluciones se encuentran aqui:<br><br>* https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-14.html#name-improvements-to-stateless-a <br> (el principio de la Seccion 5 explica que es cada cosa, y para que).<br><br><br><br><br><blockquote type="cite">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.<br></blockquote><br><br>Hay mas cosas para resolver, igual.<br><br><br>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 )<br><br>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.<br><br><br><br>Slds<br>-- <br>Fernando Gont<br>SI6 Networks<br>e-mail: fgont@si6networks.com<br>PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494<br><br>_______________________________________________<br>LACNOG mailing list<br>LACNOG@lacnic.net<br>https://mail.lacnic.net/mailman/listinfo/lacnog<br>Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog<br></div></div></blockquote></div></a><blockquote type="cite" preoffsettop="1392" preoffsetheight="5070" style="display: none;"><div>El 6 jul 2026, a las 23:33, Fernando Gont <fgont@si6networks.com> escribió:</div><br class="Apple-interchange-newline"><div><div>Hola, Doublas,<br><br><blockquote type="cite" __apple_fixed_attribute="true">On 06/07/2026 09:23, Douglas Fischer wrote:<br></blockquote><blockquote type="cite">Olá Gont!<br><Off-Topic>Peço gentilmente que hoje não falemos de futebol!<br>Muita dor de cabeça viking por aqui. haha </Off-Topic><br>Vou te fazer um pedido, e creio que isso pode ser uma oportunidade de esclarecer e angariar apoiadores...<br>- Esse Draft nasceu em 2020.<br>- Esse Draft está n a 14ª revisão oficial.<br>- Os threads de e-mail desse Draft são imensos, e alguns bem calorosos.<br></blockquote><br>Bienvenido a IETF. :-)<br><br><br><br><blockquote type="cite">Você poderia por gentileza explicar os pontos positivos e negativos no caso desse draft convergir a RFC?<br></blockquote><br>Si, el problema esta descripto aca:<br><br>* https://www.techtarget.com/searchnetworking/tip/Understanding-why-IPv6-renumbering-problems-occur<br><br>* https://www.internetsociety.org/blog/2019/02/slaac-renum-reaction/<br><br><br>De todos las soluciones, las que el documento actual mantiene son dos:<br><br>* Poner timers mas sensibles: los timers actuales son de, por ejemplo,<br> una semana o un mes, lo cual es obviamente ridiculo. -- y nosotros<br> bajamos estos timers a 1 hora, aproximadamente.<br><br>* Permitir que las implementaciones eliminen prefijos viejos cuando<br> recibien uno con un timer < 2 horas (esto actualmente lo prohibe le<br> especificacion).<br><br>* Aconsejar que toda la informacion de autoconfiguracion debe ser<br> enviada en un unico RA (o en la menor cantidad de RAs posibles).<br><br><br>Las soluciones se encuentran aqui:<br><br>* https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-14.html#name-improvements-to-stateless-a <br> (el principio de la Seccion 5 explica que es cada cosa, y para que).<br><br><br><br><br><blockquote type="cite">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.<br></blockquote><br><br>Hay mas cosas para resolver, igual.<br><br><br>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 )<br><br>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.<br><br><br><br>Slds<br>-- <br>Fernando Gont<br>SI6 Networks<br>e-mail: fgont@si6networks.com<br>PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494<br><br>_______________________________________________<br>LACNOG mailing list<br>LACNOG@lacnic.net<br>https://mail.lacnic.net/mailman/listinfo/lacnog<br>Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog<br></div></div></blockquote></div><br></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<span>http://www.theipv6company.com</span><br>
The IPv6 Company<br>
<br>
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.<br>
<br>
<span>_______________________________________________</span><br><span>LACNOG mailing list</span><br><span><span>LACNOG@lacnic.net</span></span><br><span><span>https://mail.lacnic.net/mailman/listinfo/lacnog</span></span><br><span>Cancelar suscripcion: <span>https://mail.lacnic.net/mailman/options/lacnog</span></span></div></blockquote></div></body></html>