[lacnog] Announcing Windows CLAT Public Preview

Jue Jun 11 04:19:29 -03 2026

Hola Henri,

Para que 464XLAT funcione, tiene que tener CLAT en el CPE o dispositivo, además de PLAT en la red.

CLAT nos es mas que un stateless NAT46, y puede estar implementado de diversos modos (incluyo no ser un CLAT sino una función equivalente como es el caso de HEv2 que se implementa en iOS - iOS implementa CLAT “completo” solo para el tethering). Incluso por la parte de IPv6, puede tener un /64 o usar un /128. En cuyo caso hace un stateful NAT44 antes del NAT46. Esto esta explicado en "4.8. CLAT Translation Considerations” del https://datatracker.ietf.org/doc/rfc8683/. De hecho en ese documento tienes muchos ejemplos de la ubicación del PLAT (para entender que no tiene porque estar en el ISP, puede estar en otra red, o en la red corporativa).

Por eso, es normal que cuando hay un CLAT “aparezca” el prefijo 192.0.0.0/29 (RFC7335). Sin embargo, eso no implica que sea IPv6-Mostly.
IPv6-Mostly requiere:
1) Uso de DHCPv4 opción 108 (RFC8925), tanto desde la red como en el cliente. Si ambos lo acuerdan, se desactiva IPv4 hacia la red (se mantiene dentro del host, igual que con 464XLAT).

Ambos, 464XLAT e IPv6-Mostly requieren:
2) Uso de NAT64 (RFC6146). Va a ser reemplazado por https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6146-bis/ (ya ha pasado el Last Call) que precisamente explica el uso de NAT64 en entornos como 464XLAT, IPv6-Mostly, etc.
3) Uso opcional de DNS64 (RFC6147), recomendado para evitar doble traducción y retardos, también explicado en RFC8683.

Si en el host hay necesidad de usar IPv4 (direcciones literales, aplicaciones solo IPv4, etc.), entonces se requiere CLAT. Como el Sistema Operativo no lo sabe de antemano, siempre se activa, aun cuando no se use y por eso activa ese prefijo IPv4, que son direcciones “privadas” IPv4 para traductores.

Cuando se implementa CLAT, se debería hacer self-synthesis, especialmente si de quiere hacer validación DNSSEC. Esto lo voy a aclarar en una nueva version del RFC6147 en la que estoy trabajando. En cualquier caso un DNS64 debe ser configurado con “break DNSSEC = no” (en BIND es por defecto), y quien lo opera debe decidir si necesita hacer exclusiones de uso de DNS64 en función de orígenes o destinos. En todos los años que lo he estado implementando en redes de producción no he visto la necesidad, pero en laboratorio se pueden demostrar casos.

En redes celulares, mi experiencia es que no se usa para adquirir el PREF64, ni RFC7050 ni RFC8781, sino que:
1) Hay mecanismos de información del DNS propios de 3GPP, con lo cual “comunican”, sin saberlo con un DNS que es DNS64.
2) Los dispositivos por defecto usan el WKP cuando no pueden aprenderlo de la red. Esto se puede ver incluso en CPEs, por ejemplo OpenWrt donde el WKP es configurado por defecto.

Ademas, he comprobado que la gran mayoría de implementaciones en redes de operadores (incluso los mas grandes del mundo), implementan incorrectamente RFC7050, el cual fue actualizado por RFC8880 que aclara la necesidad de crear la zona ipv4only.arpa en cada operador, con las direcciones IPv4 e IPv6, y sorpresa, a pesar de ser Standards Track, los operadores no lo leen, no lo hacen, lo que va en detrimento de la calidad de su red y carga innecesaria servidores de IANA. Por eso, y porque tiene mucho mas sentido y es mas predecible RFC8781, estoy trabajando en la posibilidad de retirar (“deprecate”) RFC7050/RFC8880 como estándares.

Respecto de tu último punto, en las redes residenciales, no hay un administrador de la red, que active opción 108 en el CPE (cuando el CPE lo soporte), pero aunque estuviera activado por defecto, creo que no hay ventaja perceptible. Si hay CLAT en el CPE, que un host active CLAT solo mejora en el sentido de reducir el uso de direcciones privadas en la LAN residencial, y la cuestión es ¿suele ser un problema la escasez de direcciones privadas en una LAN residencial? bajo mi punto de vista no. Y sin embargo se puede generar un inconveniente: Al deshabilitar en un host IPv4 hacia la LAN, si hay otros dispositivos IPv4-only en la LAN que necesitan hablar con ese host, esa comunicación requiere traducción, y lo que será raro es que se implemente un PLAT en el CPE o en esa red (lo que si que hace en una red empresarial el administrador). Tendríamos que ver si, por lo tanto, esa comunicación incluso será factible, tengo mis dudas (se hará todo el camino hasta el PLAT del operador y lo mismo con el regreso?), y en cualquier caso implica traducciones, retardos, overload, etc., innecesario. Es decir, llego a la conclusion de que, salvo que obliguemos a que el CPE implemente CLAT+PLAT, no tiene sentido, es contraproducente y genera una carga y retardo adicionales (además del consumo de radio, típicamente de WiFi e incluso eléctrico adicional).

Lo correcto, sin duda es que los CPEs implementen CLAT y evitamos todo esto. Si el host soporta IPv6-Mostly, usara dual-stack en una red residencial, y IPv6-Mostly en una red corporativa (que también habilite IPv6-Mostly con opción 108), todo de forma automática. Ejemplo el portátil de un profesor o alumno que lo usa en su casa y en su universidad.

Saludos,
Jordi

@jordipalet

> El 10 jun 2026, a las 21:27, Henri Alves de Godoy <henri.godoy en fca.unicamp.br> escribió:
> 
> 
> 
> Em qua., 10 de jun. de 2026 às 15:34, jordi.palet--- vía LACNOG <lacnog en lacnic.net <mailto:lacnog en lacnic.net>> escreveu:
>> Hola Henri (y respondo también a Fernando en cierto modo),
>> 
>> No creo que Vivo este usando IPv6-Mostly. Seguramente es 464XLAT, es decir IPv6-only + IPv4aaS.
> 
> Pode ser que sim ou não, mas a ideia que se passa é que nos sistemas operacionais que testei com a operadora móvel Vivo, em Android e iOS, o CLAT se armou automaticamente. 
> 
> Android recebeu um 192.0.0.4/29 <http://192.0.0.4/29> para a interface CLAT.  
> 
> E no iOS recebeu um 192.0.0.2/29 <http://192.0.0.2/29>.
> 
> É claro, eu nao consegui sniffar a rede para verificar a interrupção do DORA, nem comprovar o PREF 64 no radv.
>  
>> 
>> No debemos confundirlos! Precisamente por eso una y otra vez insistí en: https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ (que esta en proceso de adopción como WG item, después de muchos años de debates)
>> 
>> Como intente explicar antes, el beneficiario real de IPv6-Mostly son las redes corporativas. No tiene sentido en redes residenciales, salvo que haya 100% de seguridad que ninguna app o dispositivo que no disponga de CLAT (en el propio OS) no tiene soporte nativo de IPv6.
>> 
> 
> É aí que fica mais interessante essa arquitetura. Redes corporativas ou campus, conseguimos um controle maior dos dispositivos finais.  Mas mesmo que seja sinalizado nas redes residenciais as condições de armar um CLAT,  quem suportar que se arma, quem não suportar continua com dual-stack e o DORA completa normalmente sua entrega.  Essa transparência é que vejo como uma vantagem e também benefício, mesmo em cenários residenciais.  Concorda ?
> 
>  
>> Igualmente en las redes móviles, no se podría usar, dado que no se usa DHCP (aunque es una opción de 3GPP nunca ha sido implementada por fabricantes, al menos no de forma generalizada para UEs que son teléfonos).  Sólo he visto usar DHCP (PD) cuando el dispositivo en lugar de ser un teléfono móvil es un router con conexión celular, ejemplo caso de T-Mobile que usa también 464XLAT para llegar con banda ancha celular donde no llega la fibra.
>> 
>> Saludos,
>> Jordi
>> 
> 
> Henri.
>  
>> @jordipalet
>> 
>> 
>>> El 10 jun 2026, a las 20:20, Henri Alves de Godoy <henri.godoy en fca.unicamp.br <mailto:henri.godoy en fca.unicamp.br>> escribió:
>>> 
>>> Ola Frediani, tudo bem ?
>>> 
>>> Em qua., 10 de jun. de 2026 às 14:49, Fernando Frediani <fhfrediani en gmail.com <mailto:fhfrediani en gmail.com>> escreveu:
>>>> Olá Henri
>>>> 
>>>> Obrigado por compartilhar. Sem dúvida um grands avanço.
>>>> 
>>>> Porém a primeira coisa que me vem em mente é a necessidade do ISP está com PLAT bem implementado e não apenas isso mas também sinalizar Option 108 e PREF 64 na CPE para os clientes na LAN.
>>> 
>>> Sim, um PLAT bem implementado é importante, seja ele no hardware ou em algum lugar como serviço. 
>>> 
>>> A operadora Vivo é a que eu conheço que está com IPv6-Mostly na rede móvel.  Na rede fixa, não conheço nenhum ISP que tenha sido implantado.  Seria até interessante ver se algum ISP se interessa em fazer esse cenário na rede fixa, para termos um feedback sobre as sinalizações na LAN do usuário residencial e o tráfego.  
>>> 
>>>> 
>>>> Se por um lado dispensana necessidsde de cliente CLAT na CPE ainda é necessária essa sinalização ali, o que é mais fácil.
>>>> 
>>>> Porém entendo que quando esse tráfego - que é transportado dentro de pacotes IPv6 dentro do backbone do ISP - ainda possa sair em IPv4 para o mundo externo mesmo onde o destino possuam suporte à IPv6.
>>>> 
>>>> Nesse sentido una solução na linha do que eu comentei durante onpainel no último FTL ainda sim me parece interessante e que sjea capaz de pegar tráfego que seria originalmente IPv4-only (principalmente de dispositivos legados), fazer um NAT46 e fazet fluir em IPv6 na internet que tem relação con aquela draf que o Jordi e Alejandro estão trabalhando juntos.
>>> 
>>> Foi enviado novamente o draft para comentários. 
>>>  
>>>> 
>>>> No final CLAT na CPE ou no host são traduções da mesma maneira e com ganhos ligeiramente diferentes.
>>> 
>>> Também seria um caso de estudo e comparativo bem interessante mesmo tentar medir os ganhos nesses tipos de cenários. 
>>> 
>>>  
>>>> 
>>>> Fetnando Frediani
>>> 
>>> Abraços !
>>> Henri
>>>  
>>>> 
>>>> On Wed, 10 Jun 2026, 12:44 Henri Alves de Godoy, <henri.godoy en fca.unicamp.br <mailto:henri.godoy en fca.unicamp.br>> wrote:
>>>>> Oi Douglas,
>>>>> 
>>>>> Em qua., 10 de jun. de 2026 às 12:08, Douglas Fischer <fischerdouglas en gmail.com <mailto:fischerdouglas en gmail.com>> escreveu:
>>>>>> Imagino que muitos tenham ouvido/lido no passado sobre uma hipotética estagnação no progresso da adoção de IPv6.
>>>>>> 
>>>>>> "Vai subir até uns 30-40% e vai parar aí."
>>>>>> "Depois que chegar em 40-50% nunca mais vai sair disso".
>>>>>> Lembram disso?
>>>>>> Não eram exatamente essas as frases, mas algo similar a isso.
>>>>>> 
>>>>>> Bom... Aqui no meu coração... Eu acredito que essa adoção do CLAT no Windows será o gatilho para que o IPv4 passe realmente a ser legado em mais uns 4 anos.
>>>>> 
>>>>> Sim, vai contribuir bastante para que possamos diminuir o uso de IPv4 na rede e baixar muito o uso. Estou apostando nisso, longe de qualquer maldade que às vezes brincamos, mas porque realmente queremos uma Internet que ofereça ao usuário final, alunos, condições de desenvolvimento de pesquisas, com a melhor experiência e desempenho possível.
>>>>>  
>>>>>> Num nível desnecessário para mais de 90% das pessoas comuns.
>>>>>> 
>>>>>> "Mas Douglas, por que você coloca tanta esperança nisso?"
>>>>>> Para o CLAT funcionar, ele precisa do PLAT.
>>>>>> E quantos provedores vocês conhecem que tem PLAT implementado?
>>>>>> E se não tiver PLAT, o CLAT não entra em funcionamento.
>>>>> 
>>>>> Para complementar Douglas, o CLAT automático só é habilitado quando a rede é sinalizada que tem condições para seguir com IPv6 somente. Portanto, além do PLAT, temos que sinalizar a Option 108 e PREF 64 via radvd.  Esses são os 3 componentes essenciais.
>>>>>  
>>>>>> 
>>>>>> "Aaaa Douglas, você acha que o tráfego de Windows tem tanto impacto assim?"
>>>>>> Naaaaa! Não acho não!
>>>>>> Mas, considerando o perfil comportamental do usuário de Windows, em especial no escopo corporativo, acredito que demandas decorrentes sobre esse PLAT vão bater nos serviços de suporte dos ISPs.
>>>>>> E esse movimento vai gerar massa crítica para que PLATs sejam implementados atendendo a demanda de Windows, Android, e todos os demais dispositivos que já estão com o CLAT pronto.
>>>>> 
>>>>> Eu acredito que desde que os ISPs avancem no sentido de oferecer a sua rede com condições de ativação do CLAT, como citei acima, podemos ter sim um grande aumento de tráfego em IPv6, para subir ainda mais que 50% na adoção.
>>>>> 
>>>>> Android, MacOS e iOS, já estão preparados com CLAT há alguns anos. 
>>>>> 
>>>>>> 
>>>>>> Aquele elétron que faltava para a massa crítica.
>>>>>> Agora meu amigo @Henri Alves de Godoy <mailto:henri.godoy en fca.unicamp.br> é a hora que vou começar a bater junto com você sobre não ficar só na pilha dupla.
>>>>> 
>>>>> Sim, a pilha dupla que foi o incentivo de transição de entrada, vamos dizer assim, temos que evoluir.  Operar uma rede com 2 versões não é o ideal.  Posso citar alguns problemas que estamos tendo em correlacionar os diferentes tráfegos com relação a auditoria, logs e incidentes.  Além do que, dá a impressão que o trabalho de transição terminou, o que não é verdade.
>>>>> 
>>>>> Vamos focar nisso também Douglas, e hoje temos condições para finalizar a transição em breve.  Sim, eu sou bem otimista. :-))
>>>>>  
>>>>> Abraços
>>>>> Henri.
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Em qua., 10 de jun. de 2026 às 08:17, Henri Alves de Godoy <henri.godoy en fca.unicamp.br <mailto:henri.godoy en fca.unicamp.br>> escreveu:
>>>>>>> Bom dia a todos ,
>>>>>>> Estamos nos aproximando de um avanço bastante significativo para a transição do usuário final para IPv6, algo que considero um dos marcos mais importantes dos últimos anos.
>>>>>>> 
>>>>>>> https://techcommunity.microsoft.com/blog/networkingblog/announcing-windows-clat-public-preview/4506046
>>>>>>> 
>>>>>>> A Microsoft anunciou a prévia pública do Windows CLAT. O que significa isso ?  Ahhh muita coisa.
>>>>>>> 
>>>>>>> Na prática, isso permite que aplicações IPv4 continuem funcionando em redes IPv6-only, reduzindo significativamente a dependência de conectividade IPv4.  Aleluia e Amém !
>>>>>>> 
>>>>>>> A própria Microsoft destaca que o CLAT foi o recurso IPv6 mais solicitado pela comunidade durante uma pesquisa realizada sobre migração para IPv6. 
>>>>>>> 
>>>>>>> Por muitos anos discutimos que a ausência de CLAT no Windows era um dos obstáculos para adoção mais ampla de ambientes IPv6 em redes corporativas, acadêmicas e de acesso. Agora estamos vendo esse cenário mudar.
>>>>>>> 
>>>>>>> Creio que essa é uma mudança que afetará todos nós. Quem já possui IPv6 bem implementado estará em uma posição confortável. Quem ainda trata IPv6 como um projeto futuro poderá sentir a pressão muito mais cedo do que imagina.
>>>>>>> 
>>>>>>> Abraços !
>>>>>>> 
>>>>>>> --
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Douglas Fernando Fischer
>>>>>> Engº de Controle e Automação
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> _______________________________________________
>>>>> 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
> 
> 
> 
> --
> 

**********************************************
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/20260611/86b92dff/attachment-0001.htm>