<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Olá Jordi</p>
<p>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.<br>
É 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.</p>
<p>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.</p>
<p>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.</p>
<p>Fernando Frediani</p>
<div class="moz-cite-prefix">On 11/20/2025 5:48 AM, jordi.palet---
vía LACNOG wrote:<br>
</div>
<blockquote type="cite"
cite="mid:B6B61D11-6B5A-49B1-9003-4B7E70477394@consulintel.es">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hola Henri,
<div><br>
</div>
<div>(y con esto también contesto a Fernando)<br>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Saludos,</div>
<div>
<div>
<div>Jordi<br>
<br>
@jordipalet<br>
<br>
</div>
</div>
<div><br>
<blockquote type="cite">
<div>El 19 nov 2025, a las 16:11, Henri Alves de Godoy vía
LACNOG <a class="moz-txt-link-rfc2396E" href="mailto:lacnog@lacnic.net"><lacnog@lacnic.net></a> escribió:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">Bom dia, algumas considerações sobre a
notícia, muito aguardada.
<div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>
Por isso acho que vale reforçar uma distinção
técnica fundamental.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>São dois estágios diferentes, duas arquiteturas
diferentes, se entendi direito, por favor me
corrijam caso tenham outro entendimento.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>Abraços !<br>
Henri.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">Em qua., 19 de nov.
de 2025 às 10:28, Fernando Frediani <<a
href="mailto:fhfrediani@gmail.com"
moz-do-not-send="true"
class="moz-txt-link-freetext">fhfrediani@gmail.com</a>>
escreveu:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Isso é realmente algo muito esperado.</p>
<p>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.<br>
Tomara que seja um ponto de inflexão em
acostumar mais tanto usuários quanto
administradores de TI em configurarem mais redes
IPv6-mostly</p>
<p>Fernando Frediani</p>
<div>On 11/19/2025 9:31 AM, Alejandro Acosta
wrote:<br>
</div>
<blockquote type="cite">
<p>FYI</p>
<div><br>
<br>
-------- Forwarded Message --------
<table cellpadding="0" cellspacing="0"
border="0">
<tbody>
<tr>
<th valign="BASELINE" align="RIGHT"
nowrap="nowrap">Subject: </th>
<td>[v6ops] Windows CLAT Enters Private
Preview: A Milestone for IPv6 Adoption
| Microsoft Community Hub</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT"
nowrap="nowrap">Date: </th>
<td>Wed, 19 Nov 2025 10:07:46 +0800
(GMT+08:00)</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT"
nowrap="nowrap">From: </th>
<td>李星 <a
href="mailto:xing=40cernet.edu.cn@dmarc.ietf.org" target="_blank"
moz-do-not-send="true"><xing=40cernet.edu.cn@dmarc.ietf.org></a></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT"
nowrap="nowrap">To: </th>
<td><a href="mailto:v6ops@ietf.org"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">v6ops@ietf.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
A very good news for IPv6-only and IPv6-mostly<br>
<br>
<a
href="https://techcommunity.microsoft.com/blog/NetworkingBlog/windows-clat-enters-private-preview-a-milestone-for-ipv6-adoption/4459534"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://techcommunity.microsoft.com/blog/NetworkingBlog/windows-clat-enters-private-preview-a-milestone-for-ipv6-adoption/4459534</a>
_______________________________________________<br>
v6ops mailing list -- <a
href="mailto:v6ops@ietf.org" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">v6ops@ietf.org</a><br>
To unsubscribe send an email to <a
href="mailto:v6ops-leave@ietf.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">v6ops-leave@ietf.org</a><br>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LACNOG mailing list
<a href="mailto:LACNOG@lacnic.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">LACNOG@lacnic.net</a>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">LACNOG@lacnic.net</a><br>
<a
href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote>
</div>
<div><br clear="all">
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr"><img width="420" height="127"
src="https://ci3.googleusercontent.com/mail-sig/AIorK4y46kkRvCpAMdinHijHNmlXWyL4L3BEzwJmxsbtJANj-VtOAqdNz0cIvzYqkHx9ILVpq1N04LB7TzsT"
moz-do-not-send="true"><br>
</div>
</div>
_______________________________________________<br>
LACNOG mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><br>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion:
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com">http://www.theipv6company.com</a><br>
The IPv6 Company<br>
<br>
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.<br>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</body>
</html>