[lacnog] Announcing Windows CLAT Public Preview

[Fernando Gont]

On 31/07/2026 13:46, jordi.palet--- vía LACNOG wrote:
>> El 30 jul 2026, a las 23:52, Fernando Gont <fgont en si6networks.com>
>> escribió:
>> 
>> On 30/07/2026 06:23, jordi.palet--- vía LACNOG wrote:
>>>> La premisa es simple: * Usar GUAs en los endpoints, cuando no
>>>> lo necesitas, termina siendo en muchos casos una mala idea: +
>>>> problemas de multihoming + problemas si tu operador renumera
>>>> tu CPE, + y tambien hace (obviamente) que esos dispositivos
>>>> sean direccionables desde Internet.
>>> Si estamos diciendo que los prefijos deben ser persistentes, el 
>>> operador no esta haciendo al 100% correctamente su trabajo.
>>> Están con mentalidad IPv4.
>> 
>> Dos cuestiones: 1. Hay multiples motivos por los cuales podes
>> terminar en flash-renumbering -- no hay un solo motivo.
>> 
>> 2. A quien le importa el motivo?  Si sos el host que se conecta a
>> la red, y eso es algo que no controlas, la cuestion de si el
>> operador esta haciendo bien su trabajo o no, si "esta con
>> mentalidad IPv4", etc., es irrelevante.
>> 
>> Imaginate el caso de una empresa que opera en multiples regiones/
>> paises. Tenes que tener una solucion al respecto, o deshabilitas
>> IPv6. -- Nadie va a salir a perseguir ISPs, analizar que
>> mentalidad tienen, o inclusive leer mis RFCs.
>> 
>> En el gran contexto de las cosas, las cosas funcionan bien, o no
>> lo hacen.
> 
> Así es, tu mismo lo has dicho. O se hacen bien o mejor no hacerlas,
> y eso es cuestión del ISP.

Vuelvo a lo mismo: vos, como usuario/cliente, no controlas al ISP.
Entonces, si tu ISP rota los prefijos, tenes dos opciones:

1. Buscar una solucion al problema, o,
2. Quedarte con una red que no funciona, y quejandote de que tu isp
trabaja bmal.


O bueno, la usual tercera: "deshabilitar IPv6".

Yo, por ejemplo en mi casa he solucionado slaac-renum con timers ultra
agresivos. No soluciona un monton de problemas de fondo... pero al menos
mitiga el problema.




> Si me pasa con un ISP y no con otro, podré decidir cambiar de ISP,
> mas si es una multinacional. Cada vez los usuarios son mas
> “expertos” en decidir si un ISP le conviene o no, así que es al
> propio ISP al que le compensa hacerlo de la forma mas apropiada y no
> necesariamente “a la antigua usanza”.

La mayoria de las empresa y personas no tienen tiempo para eso.




>>> El tema de que los endpoints sean direccionales depende de que
>>> en el CPE tengas activado por defecto un firewall, como debe
>>> ser. Si no tienes un firewal, aun cuando estuvieras haciendo NAT/
>>> NPT, serian direccionables. Es evidente el problema de
>>> multihoming, porque en IPv4 lo hemos resuelto con trampas como
>>> NAT,
>> 
>> Y a quien le importa eso?
>> 
>> El NAT es una solucione de ingenieria. Punto. Estamos hablando de 
>> ingenieria, no de filosofia.  Si algo soluciona un problema lo 
>> suficientemente bien, de forma cost-effective, es valido.
>> 
>> Tampoco pretendamos que IPv6 tiene un diseño limpio -- porque con
>> solo mirar la configuracion automatica en IPv6, uno se da cuenta
>> que no es el caso.
>> 
> 
> Discrepamos, no se que % del IETF, o de los ingenieros, o del mundo
> estaría de acuerdo con tu forma de verlo o con la mía, así que nos
> podemos ahorrar las divagaciones.

Todo depende del contexto, y del lugar de cada uno :-)

El "padre de la criatura" guramente o te va a decir que tiene problemas.

El que vendiendote una solucion compleja de vende 2x horas mas de 
ingenieria, probablemente tampoco.


Ahora, si el sapo te lo comes vos, y vas a tener que ir a explicarle a 
tu gente que cuando el ISP rote prefijos tal vez se queden sin internet, 
y que para hacer multihoming van a tener que ir a un RIR, y vas a tener 
que explicarle a dev-ops y IT slaac vs hcp y direcciones temporales vs 
estaticas y, y, ....

     ... te diria que en el general de las organizaciones, eso no funciona.

En particular si, "mientras que los paquetes se muevan" (sin importar el 
como), no se afecta el revenue de la empresa.




>>> pero la realidad es que aunque esa es la tendencia, esto no es
>>> un problema *por el momento* en usuarios residenciales.
>> 
>> 1. Depende para quien. Para todo aquel que al menos en tiempos de 
>> pandemia quiso ahcer quick-and-dirty multihoming en la casa, fue
>> un problema -- concreto y real.
>> 
>> 2. Esto es definitivamente un problema real en entornos
>> enterprise.
>> 
>> 3. Y es un problema real para cualquier organizacion que opere,
>> por ejemplo, cosas autonomas -- IoT, robots, y similares.
> 
> Cualquier organización puede tener PI.

No es que no puedan. Es que no tienen ni 5' (*tiempo*/esfuerzo) para 
dedicarle a eso.

Repito: en la mayoria de esas organizaciones iIPv6 no ocupa ni la 
prioridad #20.




>>> En redes corporativas, independientemente de su tamaño, lo
>>> razonable es ir al RIR correspondiente y obtener tu propia
>>> asignación directa PI.
>> 
>> Razonable para quien?
>> 
>> En un sin-numero de organizaciones, esto es inviable.
> 
> Tendríamos que definir inviable. Económica y administrativamente es
> muy asequible. De hecho, puede ser algo que tramite el propio ISP o
> un consultor externo, no tiene porque haber conocimiento “técnico”
> en la organización.

Inviable= "tengo un sinfin de cosas con muchisima mas prioridad sobre la 
mesa, y el tema en cuestion no merece ni el tiempo ni esfuerzo".




>>>> En muchos casos, riesgos y complicaciones varias,
>>>> innecesarias.
>>> Sólo si el operador o quien proporcione el CPE instala uno que
>>> no tenga un firewall activado por defecto, ni mas ni menos
>>> exactamente igual que en el caso de IPv4.
>> 
>> En el caso de IPv4, es diferente: El NAT resulta en un firewall
>> por defecto que solo permite conexiones salientes.
>> 
>> 
> 
> Experimentos hace muchos años nos demostraban que no siempre era
> así. Por ejemplo muchos CPEs dejaban pasar “tal cual” el tráfico que
> no era TCP ni UDP, y por ende se podían hacer túneles 6in4
> (protocolo 41), o basados en ICMP, etc. 

Justamente :-)

Si estas traduciendo direcciones, con "dejarlo apsar" no alcanza. Y 
justamente el traficoq ue no es tcp/udp/icmp no sobrevive al NAT.






>> Repito: la realidad es la que es -- por decision, por omision, por 
>> error, por casualidad, o por lo que sea.
>> 
>> 
>> Si yo tengo un producto que se conecta a Internet via IPv6, mi
>> realidad operacional es el servicio que obtengo de mis ISPs -- el
>> porque lo hacen, me resulta bastante irrelevante.
> 
> Y si no estoy contento, o veo que otros lo tiene mejor resuelto, me
> puedo cambiar.

Y ahi volvemos: Prioridad para el mortal u organizacion promedio que 
IPv6 le funcione bien?  -43780634574347



>>>> Y no hace falta decirlo: IPv6 NAT *se usa en produccion* --
>>>> por mas que IETF argumente lo que quiera argumentar. Te digo
>>>> mas: quien sea que este usando Kubernetes con soporte IPv6 
>>>> (tal vez la minoria, ya que en la mayor cantidad de casos, el 
>>>> soporte IPv6 lo tienen deshabilitado), estan usando ULA + NAT. 
>>>> -- dato, no relato.
>>> Podemos enumerar cientos de implementaciones con fallos,
>>> errores, etc., eso no los hace una realidad que todos deban usar
>>> en el resto de implementaciones, mas bien una razón para huir de
>>> ello y utilizar soluciones mejores.
>> 
>> 
>> Dejame hacerte una pregunta directa, puntual, y clara: Si huis de
>> la implementacion de k8s con ULA + NAT, a donde huis? IPv4-only
>> kubernetes?
> 
> Creería que hay herramientas similares para poder hacerlo con
> docker, LXC. Pero no he dicho que no haya que usar k8s, mas cuando
> hasta donde recuerdo era un problema de implementaciones anteriores
> a 2025 (no estoy seguro de la fecha).

Antes no soportaban IPv6. Ahora lo soportan, pero con ULA+NAT.


Reitero mi pregunta: usas eso? o usas ipv4-only?

(el mismo tipo de debaet es aplicable a casi el resto de las cosas)




>>> Ayer de casualidad vi un programa en TV que hablaba de algunos 
>>> alcoholes que se hacían durante la ley seca utilizando técnicas 
>>> caseras, que incluso utilizaban ratas y otros animales muertos, 
>>> productos químicos insalubres, etc., para mejorar el sabor del 
>>> alcohol. Seguramente estaba buenísimo, no lo dudo, pero no era
>>> algo apropiado.
>> 
>> La diferencia radica en que en tal caso la ciencia soporta un
>> argumento o el otro, mientras que en el caso de IPv6 es mas bien
>> una cuestion de preferencia personal, grupal, u "history
>> artifact"?
>> 
>> Pequeña pero gran diferencia....
> 
> Bueno, entonces, la opción es que el que no quiera desplegar IPv6,
> no lo haga, nadie le obliga, que ponga decenas de niveles de CGN.

Ahi es a donde voy: al mortal promedio no le quita ni 5' de sueño.
Ni lo quiere, ni lo deja de querer. -- es irrelevante para su vida, digamos.

Y justamente por eso, si es que "se hace facil, anda al menos como IPv4, 
y mas o menos entiendo como funciona", se despliegue.  Pero cuando la 
cuestion comienza a alejarse de esos ejes, no.


La gente y las organizaciones tienen cuestiones mas apremiantes que 
resolver como apra dedicarle demasiado tiempo a este tema.




> Por mi parte retiraría DHCPv6 (o dejaría solo DHCPv6-PD) y

En un ambiente enterprise, nadie quiere SLAAC, ni direcciones temporales.

Por otro lado, slaac es chatty, y drena la bateria de los moviles.



>>>> * Con el tiempo, mientras muchos siguen con esa especie de 
>>>> "cruazada IPv6" con posturas fundamentalistas (que inclusiven 
>>>> obedecen a "principios" *fabricados*), IPv6 inclusive se
>>>> vuelve menos interesante: sin ir mas lejos, hace años uno de
>>>> los ejemplos/ argumentos de momento era la limitacion en
>>>> cantidad de conexiones concurrentes TCP que implicaba IPv4 --
>>>> con el ejemplo clasico de cuantas conexiones TCP eran
>>>> necesarias para renderizar un mapa en Google. Que paso en el
>>>> medio? -- QUIC.
>>> Creo que no son cruzadas, sino irse preparando, sin prisa pero
>>> sin pausa. Como he indicado antes, todo requiere tiempo e ir
>>> adquiriendo experiencia. Cosas que antes podían verse como
>>> adecuadas o “aceptables” no siempre lo son siempre.
>> 
>> No existe tal "colectivo" ("nos") apra el caso de una empresa. La
>> empresa toma us propias decisiones, con el mismo criterio que toma
>> muchisimas otras deciciones.
> 
> Así es, decisiones económicas, y si afectan al usuario, al final el
> gobierno/regulador tendrá que entrar a defenderlo.

Lo que le afecta al usuario es el precio que le cobran por el acceso a 
Internet ;-)





>>> Eso siempre ha sido así. Hay fabricantes que han caído por no
>>> hacer las cosas como las necesitaba el mercado. Otros tardan,
>>> pero se adaptan, pero esta claro que si los consumidores (y aquí
>>> en el caso de CPEs suelen ser los ISPs) no piden e insisten en
>>> lo que es de recibo, sólo curre con pocos fabricantes, y por
>>> tanto la oferta puede no ser tan competitiva.
>> 
>> Alguien presiono a alguiena adoptar TCP/IP?
> 
> Si quieres participar en concursos públicos, si quieres conectarte
> al resto de Internet, etc. ...

Reitero: la adopcion de TCP/IP no fue a punta de pistola.




>> Alguien presiona a las empresas hoy en dia a adoptar IA?
>> 
> 
> El mercado, la competencia? Ni mas ni menos que lo que les ocurre a
> los ISPs.

Entonces, por que fomentas "mandatos de los gobiernos"?  Que tal deja 
rque el mercado se autoregule, tambien?






>> Vuelvo a la cuestion de contexto: la gran mayoria de la gente y
>> organizaciones no tienen el lujo (?) que tenemos nosotros de
>> dedicar tanto tiempo a IPv6.
>> 
>> 
>> 
> 
> Crees que cuando cambia la regulación de normas de construcción, de
> seguridad en el trabajo, de tratamiento de los alimentos, etc.,
> alguien tiene el lujo de poder dedicar el tiempo a estudiarlo? pero
> se ven obligados, primero no hay regulación, pero termina
> habiéndola. Es totalmente comparable. Me repito: evolución.

No comparemos cosas sin sentido. No podes comparar 
regulacion/reglamentaciones vinculadas con safety, con el despliegue de 
ipv6.



>> * Tirarle millones de detalles y problemas (slaac-renum, src
>> address selection, SLAAC, y otros) a equipos que tienen otras
>> cuestiones mucho mas centrales y prioritarias que atender.
>> 
>> 
>> (Como analogia, si el dia de mañana Ferrari quisiera ser un
>> producto masivo, deberia tener la capacidad de amigarse con la
>> idea de vender autos negros, grises, azules (y otros tantos) )
>> 
> 
> Por eso se ofreció SLAAC y DHCPv6. buena comparación!
> 
> No se si es comparable algo “estético” con algo técnico. SLAAC
> frente a DHCPv6 es un cambio de chip (por no repetir lo no literal
> de “desaprender”).

Hasta hace unos 10 años, mas o menos, con SLAAC no podias ni configurar 
el servidor DNS recursivo.

En serio, Jordi, la cuestion no resiste analisis.

Pero bueno... por algo el despliegue esta como esta 30 aos despues....

-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494