[lacnog] Announcing Windows CLAT Public Preview
Fernando Frediani
fhfrediani en gmail.com
Mar Jun 16 11:38:58 -03 2026
Em tempo Henri: acredito que ambos ISP e CPE fazem sentido.
PLAT no ISP é o normal e esperado, independente do CLAT rodas na CPE ou
no Sistema Operacional do usuário.
Já na CPE não se pode chamar de PLAT mas de outra coisa(certo?). Ainda
sim acho muito válido a CPE ser capaz de traduzir para o mundo externo
porém apenas quando for NAT46 (para quando o device é legado IPv4-only
mas o destino possui suporte à IPv6) e não ao contrário. NAT64 precisará
continuar seguindo para o PLAT do ISP, principalmente sabendo que hoje
em dia cada vez menos CPEs recebem IPv4 Público.
Fernando
On 6/16/2026 9:04 AM, Henri Alves de Godoy wrote:
> Talvez, uma das grandes discussões futuras será onde se deve localizar
> el PLAT em cenários residenciais ? Na nuvem, no ISP ou CPE ?
>
> Para responder acredito que teremos que avançar nas medições, por isso
> a contribuição da comunidade é muito importante.
>
> Abraços
> Henri.
>
> Em ter., 16 de jun. de 2026 às 08:46, jordi.palet--- vía LACNOG
> <lacnog en lacnic.net> escreveu:
>
> Eso es, lo comente 3-4 emails atrás … Pero, aunque no hay mucha
> dificultad, es mas complejo implementar PLAT en un CPE que CLAT,
> no te parece? No le veo el sentido … En todo caso implementaría
> ambos: Ambos están con open source, el trabajo es una mera
> decisión (y obviamente pruebas para verificara que se ha integrado
> bien en el firmware del CPE).
>
> Como indique, es una cuestión de decisión de los fabricantes por
> “dólares”, presión del mercado, presión de los clientes, presión
> de la competencia …
>
> Saludos,
> Jordi
>
> @jordipalet
>
>> El 16 jun 2026, a las 13:35, Henri Alves de Godoy
>> <henri.godoy en fca.unicamp.br> escribió:
>>
>> Jordi, e se o PLAT estiver dentro de cada uma das residências, ao
>> invés de utilizar o PLAT do ISP. ? Acredito que podemos
>> resolver dessa forma, assim como aqui no meu cenário o PLAT fica
>> local na vlan da rede wifi ou cabeada.
>>
>> Henri.
>>
>> Em ter., 16 de jun. de 2026 às 08:23, jordi.palet--- vía LACNOG
>> <lacnog en lacnic.net> escreveu:
>>
>> Hola Douglas,
>>
>> En ningún momento he negado que lo mas importante es la
>> satisfacción del cliente final. Lo que intento explicar
>> *precisamente* es que con IPv6-Mostly NO se cumple ese
>> objetivo, más bien al contrario.
>>
>> IPv6-Mostly ha sido diseñado para redes gestionadas
>> (enterprise networks), donde un administrador decide en que
>> segmentos se aplica y en cuales no, o si por ejemplo no
>> existen impresoras que sean solo IPv4, o si las hay,
>> implementa un regla en la red bien para que esas impresoras
>> sean accesibles, por ejemplo mediante un stateless NAT64
>> delante de ellas, o bien realizando una traducción con
>> WKP+RFC1819 (esta siendo estandarizado en este momento) en el
>> stateful NAT64 *de la red enterprise*. Lo que no tiene
>> sentido es que ese trafico *salga* de la red para llegar al
>> stateful NAT64 del ISP, y vuelva a entrar como IPv4 y
>> viceversa en el camino contrario, etc.
>>
>> Saludos,
>> Jordi
>>
>> @jordipalet
>>
>>> El 16 jun 2026, a las 13:08, Douglas Fischer
>>> <fischerdouglas en gmail.com> escribió:
>>>
>>> Reconhecer que a satisfação do usuário final é mais
>>> importante que o ego de dizer que usa protocolo/metodologia
>>> A ou B é primordial.
>>>
>>> Em ter., 16 de jun. de 2026 às 07:41, jordi.palet--- vía
>>> LACNOG <lacnog en lacnic.net> escreveu:
>>>
>>> Hola Henri,
>>>
>>> Creo que no hace falta simularlo para comprender porque
>>> no funciona.
>>>
>>> Si en las LANs residenciales algunos dispositivos
>>> mediante opción 108 dejan de usar IPv4, pero hay otros
>>> dispositivos que solo usan IPv4, esta claro que no hay
>>> comunicación entre ellos. No te parece?
>>>
>>> Ahora bien, si quires probarlo, tienes que asegurarte de
>>> tener, por ejemplo, una impresora que solo tenga IPv4. Y
>>> que el host con el que quieras acceder a ella, este en
>>> modo “IPv6-Mostly”. En lugar de una impresora, puede
>>> haber muchos otros dispositivos que comuniquen
>>> localmente, ejemplo cámaras RTSP, dispositivos de
>>> domótica, etc. Hay que asegurarse que no usen IPv6, o
>>> que no usen “cloud”. En cualquier caso, para hacer bien
>>> esta prueba, habría que desactivar IPv4 en la WAN del
>>> router, no se si tienes un entorno residencial que ya te
>>> ofrezca 464XLAT o cualquier otro mecanismo del RFC8585.
>>>
>>> También podría simular este entorno en un laboratorio
>>> virtual o en la red de la Universidad, donde si puedes
>>> provisionar una LAN con IPv6-only supongo.
>>>
>>> Pero como dije antes, creo que es evidente, que si el
>>> host solo habla IPv6 (IPv6-Mostly) y la impresora solo
>>> IPv4 …. “no se ven, no se pueden hablar”.
>>>
>>> En un teléfono celular (UE), cuando el teléfono usa
>>> 464XLAT, dicho UE solo se comunica con la red. Hay 2 casos:
>>> 1) iOS: NO usa CLAT, en su lugar HEv2 (RFC8305), usa
>>> algo equivalente a “bump in the host”, que hace la misma
>>> función y “self-synthesis” para general el AAAA.
>>> 2) Android: Usa CLAT.
>>>
>>> Ahora bien, si el teléfono activa el tethering para
>>> compartir datos con otros dispositivos, como el UE
>>> recibe un /64 de la red movil, por medio de RA, se usa
>>> “prefix sharing” (RFC7278), *CONVIRTIENDO* al UE en un
>>> *CPE* (ademas de mantenerse como “host”). Y de nuevo hay
>>> 2 casos:
>>> 1) iOS: Se activa CLAT (solo para los tethered devices,
>>> el UE como “host” sigue usando HEv2).
>>> 2) Android: Usa CLAT para ambos, tethered devices y el
>>> propio UE.
>>>
>>> El caso de un CPE que tenga enlace celular con 464XLAT
>>> es equivalente a un teléfono haciendo tethering, con la
>>> salvedad de que ahí el operador puede usar DHCPv6-PD
>>> para provisionar un /48 al CPE. Hay que recordar que
>>> aunque el uso de DHCPv6-PD esta estandarizado por 3GPP,
>>> no es común su implementación por parte de muchos
>>> fabricantes ni en UEs, ni en dispositivos de la red PS.
>>>
>>> Hay que tener en cuenta que para activar 464XLAT en iOS,
>>> y más aun CLAT, para el tethering, es necesario que el
>>> operador firme un contrato con Apple a través de su
>>> enlace, con pruebas previas de la calidad de la red
>>> IPv6, etc., etc. Apple es muy exigente y lenta en todo
>>> este proceso, porque quiere garantizar la calidad del
>>> servicio a sus clientes.
>>>
>>> Todo esto no es solo información teórica, sino
>>> experiencia en cientos de despliegues en los que he
>>> participado.
>>>
>>> Saludos,
>>> Jordi
>>>
>>> @jordipalet
>>>
>>>> El 16 jun 2026, a las 12:10, Henri Alves de Godoy
>>>> <henri.godoy en fca.unicamp.br> escribió:
>>>>
>>>> Hola Jordi,
>>>>
>>>> Vou tentar simular no meu ambiente ipv6-mostly esse
>>>> cenário residencial, para poder te responder como seria
>>>> essa compatibilidade de acesso e o caminho na prática.
>>>>
>>>> Com relação à operadora Vivo, vou tambem tentar
>>>> capturar a sinalização que é enviada. Achei um tal de
>>>> PCAPdroid que deve resolver a forma de captura.
>>>>
>>>> Mas como os aparelhos móveis com Android e iOS estão
>>>> montando o CLAT automaticamente, é praticamente certo
>>>> que a operadora está sinalizando um ambiente
>>>> favorável para que a rede continue a operar em ipv6-only.
>>>>
>>>> Abraços.
>>>>
>>>> Em ter., 16 de jun. de 2026 às 04:59, jordi.palet---
>>>> vía LACNOG <lacnog en lacnic.net> escreveu:
>>>>
>>>> Hola Douglas,
>>>>
>>>> He participado en cientos de despliegues con
>>>> 464XLAT y en ninguno he tenido esos problemas que
>>>> mencionas, supongo que puede ser cuestión de
>>>> calidad del producto, y como siempre, experiencia y
>>>> conocimiento.
>>>>
>>>> De todos modos la cuestión sigue siendo:
>>>> Si no usas CLAT en el CPE, y usas IPv6-Mostly
>>>> (asumiendo que en el CPE implementas opción 108,
>>>> etc.), como resuelves la comunicación con IPv4
>>>> entre los nodos de la red residencial (por ejemplo
>>>> impresoras, SmartTVs, etc. con solo-IPv4) y nodos
>>>> que usan IPv6-Mostly (y por tanto dejan de usar IPv4)?
>>>>
>>>> Insisto que IPv6-Mostly esta pensado para entornos
>>>> “managed”, es decir, redes corporativas.
>>>>
>>>> Saludos,
>>>> Jordi
>>>>
>>>> @jordipalet
>>>>
>>>>> El 15 jun 2026, a las 22:17, Douglas Fischer
>>>>> <fischerdouglas en gmail.com> escribió:
>>>>>
>>>>> Eu já ouvi maravilhas e já ouvi xingamentos
>>>>> terríveis sobre o cenário de 464XLAT.
>>>>>
>>>>> Dentro do MEU espectro de amostragem, 100% dos
>>>>> casos de reclamação por parte de operadores de
>>>>> rede o cenário era CLAT feito na CPE.
>>>>> E esses mesmos que reclamavam desse cenário
>>>>> disseram-me que nos casos onde o CLAT era feito no
>>>>> endpoint não tinham reclamações.
>>>>>
>>>>> Em qui., 11 de jun. de 2026 às 13:09,
>>>>> jordi.palet--- vía LACNOG <lacnog en lacnic.net>
>>>>> escreveu:
>>>>>
>>>>>> Essa transparência é que vejo como uma
>>>>>> vantagem e também benefício, mesmo em
>>>>>> cenários residenciais. Concorda ?
>>>>>>
>>>>>>
>>>>> Concordo em gênero, número, e grau!
>>>>> O motivo dessa minha intensa concordância é que o
>>>>> cliente não quer (e nem tem a obrigação) de saber
>>>>> se é o CLAT do CPE ou se é o CLAT do Android ou do
>>>>> Windows. O que ele quer saber é se funciona ou não.
>>>>> E mesmo para cenários residenciais, uma simples
>>>>> informação como "o problema acontece no APP que
>>>>> roda no android, mas não acontece no APP que roda
>>>>> no windows." "Ou na smarttv, ou no iphone, ou no
>>>>> MAC." faz toda a diferença.
>>>>>
>>>>> Reconhecer que a satisfação do usuário final é
>>>>> mais importante que o ego de dizer que usa
>>>>> protocolo/metodologia A ou B é primordial.
>>>>>
>>>>> O que acredito que vamos ver agora é redes que
>>>>> foram implantadas com DualStack passarem
>>>>> implementar o IPv6 Mostly, e com isso a parcela de
>>>>> IPv4 nativo passante na rede ir diminuindo, sendo
>>>>> substituída por CLAT no endpoint com PLAT.
>>>>>
>>>>> E com isso, naturalmente o número de portas
>>>>> públicas vai diminuir, e eventualmente até a banda
>>>>> demanda também vai ir reduzindo.
>>>>>
>>>>>
>>>>> --
>>>>> Douglas Fernando Fischer
>>>>> Engº de Controle e Automação
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>
>>>
>>> **********************************************
>>> 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
>>>
>>>
>>>
>>> --
>>> Douglas Fernando Fischer
>>> Engº de Controle e Automação
>>
>>
>> **********************************************
>> 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
>>
>>
>>
>> --
>>
>
>
> **********************************************
> 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
>
>
>
> --
>
>
> _______________________________________________
> 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/20260616/8fb5e051/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG