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

Jue Nov 20 05:48:10 -03 2025

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> 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
> 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/1d3c8dd3/attachment-0001.htm>