<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hola Henri,<div><br></div><div>En absoluto estoy diciendo que nunca podamos completar la transición, pero en diferentes países, hay diferentes ritmos de renovación, por ejemplo de SmartTVs, en gran medida dependiendo de los ingresos de los hogares.</div><div><br></div><div>La cuestión importante es que no es posible, al menos con los estándares actuales, hacer una transición completa a IPv6-only sino se cuenta con IPv6-only en el CPE residencial. Sería absurdo, a estas alturas, desarrollar nuevos estándares para que la transición se hiciera desde los hosts (implicaría retrasar la transición al menos 5 años mas). Los ISPs *hoy* deben usar IPv6-only en el acceso, y para ello se require un CPE que lo soporte, con lo cual esa “dependencia” del CPE es necesaria.</div><div><br></div><div>Los ISPs son los responsables, en gran medida, del retraso que hemos tenido en la disponibilidad de CPEs con 464XLAT. Si nos fijamos en las redes móviles, los ISPs dijeron queremos IPv6-only y los fabricantes de dispositivos lo tuvieron listo en meses.</div><div><br></div><div>Si un ISP tiene un proveedor de CPEs que no colabora, debe buscar alternativas, igual que lo hace cuando un proveedor de cualquier otra parte de la red no cumple con lo que necesita. Es mas, hay ya al menos una docena de fabricantes de CPEs que tienen soporte de 464XLAT y no en un modelo, sino en multiples modelos. Eso sin contar la posibilidad cualquier dispositivo con OpenWRT.</div><div><br></div><div>La excusa no puede ser:</div><div>1) “tengo menos herramientas” para gestionar mi red con este otro CPE, porque un programador Linux las porta o incluso desarrolla a medida por muy poco dinero.</div><div>2) “cambiar” los CPEs es costoso, porque ni siquiera hace falta cambiarlos, se pueden actualizar en remoto desde el firmware actual a OpenWRT.</div><div>3) Por si esto fuera poco, en varios clientes hemos desarrollado modelos de negocio que demuestran que pasar el 60-70-80% de tu tráfico a IPv6, mejorando las velocidad en un 40% (estudios varios demuestran que IPv6 es un 40% más rápido en completar http get, al evitar NAT y BR en data center) aun cuando suponga reemplazar los CPEs de forma progresiva, ofreciendo a los clientes puertos gigabit o 2.5gbps, mejor WiFi, triple-play, y un sinfín de opciones, se paga el coste de la transición, además, puedes empezar a transferir parte de tus direcciones IPv4 (si esperas bajan de precio y no será tan buen negocio). Incluso en algunas ocasiones los clientes están dispuestos a pagar una “parte” del coste de la renovación del CPE con tal de mejorar el WiFi, acceder servicios adicionales (seguridad de los hogares, cámaras, etc.).</div><div><br></div><div>No hay excusas, solo es cuestión de que más y más ISPs presionen a sus proveedores de CPEs, o busquen alternativas, que las hay.</div><div><br id="lineBreakAtBeginningOfMessage"><div>
<div>Saludos,<br>Jordi<br><br>@jordipalet<br><br></div>
</div>
<div><br><blockquote type="cite"><div>El 20 nov 2025, a las 15:22, Henri Alves de Godoy <henri.godoy@fca.unicamp.br> escribió:</div><br class="Apple-interchange-newline"><div><div dir="ltr">Obrigado Jordi, pelos seus comentários bem completos e pela sua visão sobre o assunto, compreendo e concordo em boa parte com ela.<div><br></div><div>Eu entendo o cenário das residências, o legado dos dispositivos só IPv4, e todo o peso operacional disso. Mas eu penso que hoje não podemos achar normal a ideia de que os dispositivos em uma residência nunca vão sair do IPv4. Se esperarmos que todos os dispositivos IPv4 morrerem, vamos dizer assim, para avançar, então a transição completa nunca vai acontecer. </div><div><br></div><div>Eu penso e vejo que não podemos continuar dependendo do CPE como ponto central da transição mais. Acredito que o tempo já passou. O mercado de CPE é lento e perdeu o timing da transição. </div><div><br></div><div>Com relação ao tópico e o assunto do anúncio da Microsoft, isso muda completamente a lógica da transição que estamos acostumados. Tirar a dependência da CPE reduz a complexidade e leva a transição direta para o host, onde vemos que a evolução agora ocorre de forma mais rápida e acredito que seja uma tendência.</div><div><br></div><div>Vamos aguardar as cenas dos próximos capítulos !! ;-)</div><div><br></div><div>Abraços !<br>Henri.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Em qui., 20 de nov. de 2025 às 05:48, jordi.palet--- vía LACNOG <<a href="mailto:lacnog@lacnic.net">lacnog@lacnic.net</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hola Henri,<div><br></div><div>(y con esto también contesto a Fernando)<br><div><br></div><div>Aunque coincido en en pare con lo que indicas si hablamos de redes corporativas, discrepo en algo que creo que es muy importante: La necesidad de soporte de CLAT en CPEs residenciales.</div><div><br></div><div>El soporte de CLAT en una interfaz de red móvil, es muy importante para que el dispositivo pueda funcionar en redes celulares (e incluso hacer tethering), ya que cada ve mas redes de este tipo son IPv6-only. Por eso Microsoft rápidamente incorporó CLAT para estas interfaces (ademas, ellos tenían un SO móvil que también lo requería).</div><div><br></div><div>El soporte de CLAT en interfaces Ethernet, Wifi, etc., SOLO es importante en redes empresariales y solo si van acompañadas de despliegue de soporte de PREF64 (señalización del prefijo NAT64 mediante RA, RFC8781) y de DHCP option 108 (RFC8925). El objetivo es IPv6-Mostly, que no es lo mismo que IPv6-only. IPv6-mostly permite al hosts decidir que si no necesita IPv4, no lo active. Esto es un entorno “managed” en el que hay una operación activa de la red, y por lo tanto el administrador sabe que no hay dispositivos IPv4-only que puedan quedar inalcanzables por hosts IPv6-mostlly.</div><div><br></div><div>Porque lo hace Microsoft ahora? Primero porque la estandarización se completo para IPv6-mostly. Segundo porque grandes clientes (corporativos, no usuarios finales), que creo que son los que mas aportan en sus cuentas se lo han pedido masivamente en una encuesta que se hizo, pero que en realidad creo que se sabía el resultado. Esos grandes clientes son gobiernos o entidades públicas que han legislado para hacer una transición hacia IPv6-only (y que requiere en ocasiones un paso por IPv6-mostly), por ejemplo el DoD o el Gobierno Federal.</div><div><br></div><div>En una red residencial (no digo las nuestras que hacemos “pruebas”, sino usuarios “normales"), IPv6-mostly, hoy por hoy, no es viable y por lo tanto CLAT en esos equipos no aporta nada, de hecho no se activará. La razón es sencilla, si el CPE no tiene soporte de PREF64 y de option 108, teniendo en cuenta que el CPE por defecto estará configurado en las LANs con IPv4-only o con dual-stack y que en esas redes aún existen dispositivos que son IPv4-only (impresoras, cámaras, smartTVs, dispositivos que funcionan con clouds IPv4-only, etc.), los host, aún teniendo CLAT, no pueden *desactivar IPv4*, porque no podrían comunicar con todos esos dispositivos en la red residencial con IPv4.</div><div><br></div><div>Sería muy muy muy sorprendente, que si los fabricantes de CPEs no han incluido soporte de CLAT, si hayan incorporado PREF64 y option 108, que son protocolos mas modernos. Pero como digo, aunque así fuera, los hosts no deberían configurarse en estos casos con IPv6-mostly, porque perderían la conexión con IPv4 en la red local (en una red corporativa esto es gestionado, y en el peor de los casos, por ejemplo hay firewalls o stateless NAT64 incluso stateful NAT64 internos para evitar esto).</div><div><br></div><div>Además, para que CLAT pueda funcionar, el operador debe tener NAT64 (PLAT) y configurar adecuadamente el CPE (PREF64). Es decir, no tiene mucho sentido que un operador instale NAT64, si los CPEs no tienen CLAT, porque en ese caso el operador esta usando dual-stack, o IPv4-only, o bien otros mecanismos de transición que son incompatibles con 464XLAT.</div><div><br></div><div>Conclusión: No es posible evitar la necesidad de CLAT en los CPEs. Es necesario que TODOS presionemos a los fabricantes de CPEs para que incorporen sino el RFC8585 completo, al menos la parte de 464XLAT (de hecho con esto basta). Creo que hoy por hoy no tiene sentido ningún otro mecanismo de transición que no sea 464XLAT, y eso permite al operador ofrecer backup de redes de banda ancha fijas a través de redes móviles de forma transparente y sin operar multiples mecanismos de transición, que supone una gran complejidad y coste.</div><div><br></div><div>En las redes LAN residenciales la doble-pila es imperativa, salvo que “mueran” todos los dispositivos locales que sean IPv4-only. Y la mayoría de los usuario desconocen este detalla y por lo tanto no habilitarán option 108 (cuando los CPEs lo incorporen). Quizás en algunos años los CPEs incorporen option 108 activado por defecto, pero hoy en día seria contraproducente y supondría llamadas al help desk de los operadores que es un coste que no pueden asumir, mas cuando no les corresponde porque esos dispositivos del hogar no los proporcionan ellos.</div><div><br></div><div>Saludos,</div><div><div><div>Jordi<br><br>@jordipalet<br><br></div>
</div>
<div><br><blockquote type="cite"><div>El 19 nov 2025, a las 16:11, Henri Alves de Godoy vía LACNOG <<a href="mailto:lacnog@lacnic.net" target="_blank">lacnog@lacnic.net</a>> escribió:</div><br><div><div dir="ltr">Bom dia, algumas considerações sobre a notícia, muito aguardada.<div><div><br></div><div>A chegada do CLAT aos sistemas operacionais (agora no Windows) confirma uma tendência que já comentei algumas vezes, que é a migração do CLAT das CPEs para os próprios sistemas operacionais. Isso reduz a complexidade, simplifica a vida das operadoras e garante compatibilidade diretamente no dispositivo, não mais dependente da CPE. É o caminho mais natural e em larga escala, já que aqui no Brasil, o CLAT nas CPE não deu muito certo, como esperávamos.</div><div><br></div><div>Eu entendo, na minha visão, que o CLAT no Windows finalmente viabiliza o caminho completo para o IPv6-only no desktop, com compatibilidade real. Ou seja, estamos aqui falando do 464XLAT, que é a arquitetura final pensada para ambientes realmente IPv6-only. Para garantir compatibilidade com aplicativos que ainda carregam IPv4 literal, entra em cena o CLAT no host, complementando com o PLAT/NAT64 na rede. </div><div><br></div><div>
Por isso acho que vale reforçar uma distinção técnica fundamental.</div><div><br></div><div>No IPv6-mostly, o host pode ainda ter IPv4, mas o objetivo é, resumidamente, se o sistema operacional suporta IPv6, ele deve usar apenas IPv6 sempre que possível, deixando o PLAT/NAT64 resolver o que ainda precisa de IPv4. Nesse caso não se usa o CLAT e nem se realiza 464XLAT. Então o CLAT do Windows não será utilizado.</div><div><br></div><div>São dois estágios diferentes, duas arquiteturas diferentes, se entendi direito, por favor me corrijam caso tenham outro entendimento.</div><div><br></div><div>Tenho percebido também que o mecanismo PLAT/NAT64 ganhou força com o avanço do IPv6-mostly. Portanto quanto mais serviços e avanços com adoção do IPv6, menos uso dos mecanismos de tradução usaremos. O caminho para os avanços é um dia, não sei quando, não depender mais dos mecanismos de transição, insistir em trabalhar com pilha dupla não é muito prático. </div><div><br></div><div>Abraços !<br>Henri.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qua., 19 de nov. de 2025 às 10:28, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div><p>Isso é realmente algo muito esperado.</p><p>Nunca consegui entender por que, por tanto tempo a Microsoft
tinha suporte à CLAT porém apenas à interfaces WWAN e não a Wired
or Wifi.<br>
Tomara que seja um ponto de inflexão em acostumar mais tanto
usuários quanto administradores de TI em configurarem mais redes
IPv6-mostly</p><p>Fernando Frediani</p>
<div>On 11/19/2025 9:31 AM, Alejandro Acosta
wrote:<br>
</div>
<blockquote type="cite"><p>FYI</p>
<div><br>
<br>
-------- Forwarded Message --------
<table cellpadding="0" cellspacing="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="">Subject:
</th>
<td>[v6ops] Windows CLAT Enters Private Preview: A
Milestone for IPv6 Adoption | Microsoft Community Hub</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="">Date:
</th>
<td>Wed, 19 Nov 2025 10:07:46 +0800 (GMT+08:00)</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="">From:
</th>
<td>李星 <a href="mailto:xing=40cernet.edu.cn@dmarc.ietf.org" target="_blank"><xing=40cernet.edu.cn@dmarc.ietf.org></a></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="">To: </th>
<td><a href="mailto:v6ops@ietf.org" target="_blank">v6ops@ietf.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
A very good news for IPv6-only and IPv6-mostly<br>
<br>
<a href="https://techcommunity.microsoft.com/blog/NetworkingBlog/windows-clat-enters-private-preview-a-milestone-for-ipv6-adoption/4459534" target="_blank">https://techcommunity.microsoft.com/blog/NetworkingBlog/windows-clat-enters-private-preview-a-milestone-for-ipv6-adoption/4459534</a>
_______________________________________________<br>
v6ops mailing list -- <a href="mailto:v6ops@ietf.org" target="_blank">v6ops@ietf.org</a><br>
To unsubscribe send an email to <a href="mailto:v6ops-leave@ietf.org" target="_blank">v6ops-leave@ietf.org</a><br>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LACNOG mailing list
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><img width="420" height="127" src="https://ci3.googleusercontent.com/mail-sig/AIorK4y46kkRvCpAMdinHijHNmlXWyL4L3BEzwJmxsbtJANj-VtOAqdNz0cIvzYqkHx9ILVpq1N04LB7TzsT"><br></div></div>
_______________________________________________<br>LACNOG mailing list<br><a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br><a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br></div></blockquote></div><br></div></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a href="http://www.theipv6company.com/" target="_blank">http://www.theipv6company.com</a><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>
</div>_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><img width="420" height="127" src="https://ci3.googleusercontent.com/mail-sig/AIorK4y46kkRvCpAMdinHijHNmlXWyL4L3BEzwJmxsbtJANj-VtOAqdNz0cIvzYqkHx9ILVpq1N04LB7TzsT"><br></div></div>
</div></blockquote></div><br></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<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>
</body></html>