[lacnog] [v6ops] Windows CLAT Enters Private Preview: A Milestone for IPv6 Adoption | Microsoft Community Hub

Jue Nov 20 10:00:54 -03 2025

Hola Fernando,

Respondiendo a algunos de tus puntos. Efectivamente, si hay un CLAT en el CPE, el CLAT del SO no necesita “activarse”, eso funciona bien en las implementaciones que he probado, así que no hay problema. Esto cambia si se envía la opción 108: es lo que se espera y funciona también bien.

Los SoC mas habituales para CPEs, hace tiempo que contemplan por hardware (flow off-loading) tanto NAT44 como NAT46. Pero ademas, aunque no fuera así, ten en cuenta que NAT46 (CLAT) es stateless, y por si fuera poco, las últimas versiones de kernel de Linux (mayoría de los CPEs son basados en Linux), tienen soporte software flow off-loading, que prácticamente ofrece las mismas prestaciones (para los anchos de banda habituales en GPON).

Por ejemplo, uno de los SoC mas competitivos (en precio/prestaciones) y creo que con mayor cuota de mercado el Mediatek MT7621A, ofrece 5 puertos Gigabit, dual core, WiFi 5, y hardware flow off-loading hasta 2Gbps. Además, tiene la ventaja de que Mediatek es muy abierta y colabora con Linux, a diferencia de otros fabricantes que no tienen Open Source para sus SDKs.

https://www.mediatek.com/products/home-networking/mt7621

Tengo clientes que usan CPEs basados en este SoC, con costes sin necesidad de volumen demasiado grande de 15 USD (+ importación), con OpenWRT con CLAT.

Saludos,
Jordi

@jordipalet

> El 20 nov 2025, a las 13:16, Fernando Frediani <fhfrediani en gmail.com> escribió:
> 
> Olá Jordi
> 
> Também pensei sobre este assunto e sigo na linha de que CLAT é sim importante inclusive dentro da CPE para facilitar o deploy de 464XLAT e abstrair isso do usuário que atrás da CPE vai continuar recebendo Dual-Stack normal (que inclusive é sempre importante para equipamentos legados). Lembre-se de quão significativo é o tráfego gerado por clientes residenciais em um cenário como esse.
> É bom que cada vez mais Sistema Operacionais venham com suporte à CLAT para trazer isso ainda mais próximo do usuário, mas não não houver a CPE pode sim capturar esse tráfego todos e transportar em cima de IPv6 até o PLAT.
> 
> Veja, para não confundir algo que pode parecer similar, uma coisa é a CPE ter um daemon CLAT que possui uma dummy interface para encapsular todo o tráfego IPv4-only que recebe da LAN e outra é a CPE ter a capacidade de sinalizar PREF64 ou Option 108 para os dispositivos atrás dela. Para esse segundo caso é algo à se pensar e discutir se também seria válido ter ambos os mecanismos, mas em essência são cenários ligeiramente diferentes.
> 
> Um outro ponto importante à se observar também no CLAT dentro da CPE é garantir que todo tráfego encapsulado ali seja feito da maneira mais eficiente, com offload para o chip correto, similar com o que é feito atualmente com NAT44 em muitos modelos que possuem feature de offload de NAT embedded.
> 
> Fernando Frediani
> 
> On 11/20/2025 5:48 AM, jordi.palet--- vía LACNOG wrote:
>> Hola Henri,
>> 
>> (y con esto también contesto a Fernando)
>> 
>> 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.
>> 
>> 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).
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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).
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> Saludos,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>>> El 19 nov 2025, a las 16:11, Henri Alves de Godoy vía LACNOG <lacnog en lacnic.net> <mailto:lacnog en lacnic.net> escribió:
>>> 
>>> Bom dia, algumas considerações sobre a notícia, muito aguardada.
>>> 
>>> 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.
>>> 
>>> 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.  
>>> 
>>> Por isso acho que vale reforçar uma distinção técnica fundamental.
>>> 
>>> 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.
>>> 
>>> São dois estágios diferentes, duas arquiteturas diferentes, se entendi direito, por favor me corrijam caso tenham outro entendimento.
>>> 
>>> 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.  
>>> 
>>> Abraços !
>>> Henri.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Em qua., 19 de nov. de 2025 às 10:28, Fernando Frediani <fhfrediani en gmail.com <mailto:fhfrediani en gmail.com>> escreveu:
>>>> Isso é realmente algo muito esperado.
>>>> 
>>>> 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.
>>>> Tomara que seja um ponto de inflexão em acostumar mais tanto usuários quanto administradores de TI em configurarem mais redes IPv6-mostly
>>>> 
>>>> Fernando Frediani
>>>> 
>>>> On 11/19/2025 9:31 AM, Alejandro Acosta wrote:
>>>>> FYI
>>>>> 
>>>>> 
>>>>> 
>>>>> -------- Forwarded Message --------
>>>>> Subject: 	[v6ops] Windows CLAT Enters Private Preview: A Milestone for IPv6 Adoption | Microsoft Community Hub
>>>>> Date:	Wed, 19 Nov 2025 10:07:46 +0800 (GMT+08:00)
>>>>> From:	李星 <xing=40cernet.edu.cn en dmarc.ietf.org> <mailto:xing=40cernet.edu.cn en dmarc.ietf.org>
>>>>> To:	v6ops en ietf.org <mailto:v6ops en ietf.org>
>>>>> 
>>>>> A very good news for IPv6-only and IPv6-mostly
>>>>> 
>>>>> https://techcommunity.microsoft.com/blog/NetworkingBlog/windows-clat-enters-private-preview-a-milestone-for-ipv6-adoption/4459534 _______________________________________________
>>>>> v6ops mailing list -- v6ops en ietf.org <mailto:v6ops en ietf.org>
>>>>> To unsubscribe send an email to v6ops-leave en ietf.org <mailto:v6ops-leave en ietf.org>
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> LACNOG mailing list
>>>>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>> _______________________________________________
>>>> LACNOG mailing list
>>>> LACNOG en lacnic.net <mailto:LACNOG en lacnic.net>
>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>> 
>>> 
>>> 
>>> --
>>> 
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net <mailto: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 <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 <mailto:LACNOG en lacnic.net>
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
> _______________________________________________
> 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.

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20251120/89d8883e/attachment-0001.htm>
------------ próxima parte ------------
Se ha borrado un mensaje adjunto que no está en formato texto plano...
Nombre     : favicon.ico
Tipo       : image/vnd.microsoft.icon
Tamaño     : 4286 bytes
Descripción: no disponible
Url        : <https://mail.lacnic.net/pipermail/lacnog/attachments/20251120/89d8883e/attachment-0001.ico>