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

Jue Nov 20 11:22:02 -03 2025

Obrigado Jordi, pelos seus comentários bem completos e pela sua visão sobre
o assunto, compreendo e concordo em boa parte com ela.

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.

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.

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.

Vamos aguardar as cenas dos próximos capítulos !!  ;-)

Abraços !
Henri.

Em qui., 20 de nov. de 2025 às 05:48, jordi.palet--- vía LACNOG <
lacnog en lacnic.net> escreveu:

> 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> 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>
>> <xing=40cernet.edu.cn en dmarc.ietf.org>
>> To: 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
>> To unsubscribe send an email to v6ops-leave en ietf.org
>>
>> _______________________________________________
>> LACNOG mailing listLACNOG en lacnic.nethttps://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
>>
>
>
> --
>
> _______________________________________________
> 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/20251120/2a7680f9/attachment-0001.htm>