[lacnog] Announcing Windows CLAT Public Preview

[Fernando Gont]

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.




> 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.



> 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.



> 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.




>> * Por ende, si no lo necesitas, no lo haces.
> 
> Efectivamente, por ende, si no necesitas que un dispositivo sea
> direccionable, no abres puertos o la dirección completa en el
> firewall. Si tienes un servidor web, para empezar tendrá un
> dirección estable dentro del prefijo asignado, generalmente
> manualmente configurada, y abrirás exclusivamente los puertos 80 y
> 443 a esa dirección. Posiblemente agregarás en el firewall otras
> reglas como rate limiting, etc.


La discusion fue en el contexto de clientes. Si, en el caso de
servidores, esta barbaro que tengas direcciones publicas + firewall.

En el caso de clientes (ejemplo workstations), los problemas pesan mas
que las potenciales soluciones o use-cases.




> 
>> 
>> 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.




>>>> Cuando muchísimos operadores residenciales cambian los
>>>> prefijos IPv6 (no importa cada cuanto los cambian) muchas
>>>> cosas se “rompen” en una red interna. Se puede resolver con
>>>> DHCPv6 y NATv6 (o NAT66 con sus problemas) pero varios bien
>>>> conocidos sistemas operativos no soportan algunos de esos
>>>> protocolos.
>>> En IPv6, lo normal sería NO cambiar los prefijos.
>> 
>> No, no es lo normal. Hay muchos motivos: https://www.rfc-
>> editor.org/rfc/rfc8978.pdf
> 
> Diría que ese documento precisamente aboga por los prefijos
> persistentes.

No, no aboga por nada. Lo que dice basicamente es que hay multiples
razones por las cuales podes tener prefijos efimeros, muchas de las
cuales estan fuera de tu control. Y que por ende IPv6 deberia lidiar de
forma "graceful" con esos escenarios.

Eso es lo que el documento dice.



> 
>> 
>>> Este documento ha costado muchos años, pero parece que ahora
>>> finalmente, tiene “momentum” para que se pueda hacer el Last
>>> Call en poco tiempo: https://datatracker.ietf.org/doc/draft-ietf-
>>> v6ops-prefix-to-end-sites/ <https://datatracker.ietf.org/doc/
>>> draft-ietf-v6ops-prefix-to-end-sites/>
>> 
>> Ignorar la realidad operacional no ayuda a nadie.
> 
> La realidad operativa depende de la experiencia y a veces de
> decisiones que, desafortunadamente no son operativas, sino
> comerciales. La experiencia que hay es con IPv4, donde si o si,
> muchos operadores se vieron abocados a utilizar prefijos no-
> persistentes.


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.




>>> Por otro lado, dado que NAT66, NPTv6, y derivados no son
>>> estándares, sino implementaciones propietarias de fabricantes,
>>> no se garantiza la interoperabilidad. Son protocolos
>>> experimentales y los RFC experimentales dicen bien claro que NO
>>> DEBEN SER USADOS EN PRODUCCION.
>> 
>> IETF "especifico" los NATs cuando la realidad se la habia "llevado
>> puesta", luego de negarlos y negarlos.  Cual fue el outcome?  --
>> NAT fue y sigue siendo una tecnologia mucho mas desplegada que el
>> propio IPv6.
> 
> Los tiempos cambian, afortunadamente, aunque valga la redundancia,
> requiere tiempo. Caer en los mismos errores y problemas me parece
> que es poco inteligente.

Festejar un 50% de despliegue luego de 30 años excede mi concencion de
"optimismo".





>> 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?





>>> Hay que hacer un reset, desaprender IPv4 para aprender IPv6. No
>>> podemos seguir acarreando problemas y errores, por mucho que
>>> pensemos que era la solución mas fácil. No lo era, era un parche
>>> porque no había otro remedio.
>> 
>> Esta es exacamente una de las razones por la cual, 30+ años mas
>> tarde, el despliegue de IPv6 es lo que es:
>> 
>> * No hay que desaprender nada. Lo que se deberia haber impulsado
>> es reutilizar la mayor cantidad de conocimiento posible. -- es una 
>> estrategia mucho mas inteligente que pedirle a cualquier persona 
>> que tire por la borda 20+ años de experiencia en redes.
> 
> Cuando algunas costumbres de operación son incorrectas o no
> apropiadas para una nueva realidad, hay que cambiar la mentalidad.
> Vuelvo a insistir, en muchos casos esas costumbres son comerciales,
> no técnicas.

Llegado el caso, en todo caso es cuestion de "ajustar cosas puntuales",
y no de "desaprender", u "olvidar los conocimientos que tenemos de IPv4".

Y, en lo personal, deberia decir que eso deberia ocurrir en ambos
sentidos. La autoproclamacionde que "la forma IPv6 de hacer las cosas es
la forma correcta" es toxica y equivocada.



>> * En retrospectiva, es claramente un error (entendible a partir de 
>> sucesos historicos), haber cambiado tantas cosas para,
>> basicamente, hacer lo mismo que en IPv4, solo que con direcciones
>> mas grandes.
> 
> Discrepamos, lo que es un error es no querer adaptarse.

El error depende de donde lo mires.

Porque si la gran mayoria de personal con conocimeinto de redes tiene
20/30/40 años de experiencia de IPv4, y e Internet no puede actualmente
prescindir de IPv4, claramente IPv6 no esta en posicion de poder para
exigir quien debe adaptarse.

En muchos entornos donde he desplegado IPv6, justamente lo hago desde
esa optica: causarle la menor cantidad de problemas y stress al resto
del equipo.  Y en muchos de dichos entornos, la alternativa a eso
hubiera sido IPv4-only.




> 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....




> En cualquier campo de la vida o de la ingeniería, hay
> “operatividades” que no son correctas, o que se van adecuando al
> cambio de los tiempos y del conocimiento, y claro que cuesta mucho
> cambiar la mentalidad, pero hay que hacerlo.

Discrepo, completamente.

Y de nuevo, un reality check: Para el publico, y una gran candidad de 
organizaciones, IPv6 no ocupa siquiera la prioridad numero #20.




> La diferencia es que en todos esos campos casi siempre se termina
> haciendo por legislación. 

A fuerza de pistola, digamos? :-)



> En Internet nos hemos dado el beneficio de
> “ser libres de la ley y la regulación”, pero eso conlleva grandes
> ventajas para los operadores (libertad casi absoluta) pero muchos
> inconvenientes para los usuarios finales. Creo en la des-regulación
> de Internet, pero también creo que la regulación, los gobiernos,
> tienen una obligación para defender a los usuarios finales, y lo que
> suele ocurrir, es que si se hace algo mal, con el tiempo, se termina
> regulando para hacerlo mejor (no siempre bien, pero eso es otro
> debate).

Nuevamente:
1. Impacto concreto para el usuario?

2. Que hay de los problemas que se *intrudicen* para el usuario?

3. Quien y porque decide el como y el cuando, y con que criterio?





>> * Si uno fuera a rediseñar IPv6 hoy en dia, poco de lo que hay en
>> el diseño actual quedaria en el diseño final. Entonces, dejemos de 
>> vender que IPv6 es la tecnologia de networking revolucionaria o 
>> superadora, por que no lo es. -- esta bien argumentado desde hace
>> mas de 25 años, inclusive en libros, tales como el el
>> "Interconnections" de Perlman.
>> 
> 
> Creo que son discusiones filosóficas, y que cuando tomamos un
> camino, acarreamos con lo bueno y lo malo. Otro camino pudiera haber
> sido peor. Creo que es difícil que lleguemos a saberlo.

Muchas cosas no son filosoficas. Radia Perlman y John Day, por ejemplo, 
plantean cuestiones bien pragmaticas.


Ejemplo: es "filosofico" el lio que tiene IPv6 en materia de 
configuracion automatica?

En absoluto. Es un producto que en aprte radica en sucesos historicos 
(DHCP se desarrollo *luego* que slaac), en no querer corrergir eso, y en 
un grupito de gente queriendo imponer -- cual Pinocho el dia que 
descubrio que estaba hecho de madera -- su forma preferida de 
implementar configuracion automatica.


Por otro lado, cosas tales como multiples direcciones + happy eyeballs + 
source address selection tienen un grado de complejidad terriblemente 
alto -- usualmente resultando en un comportamiento erratico y no 
deterministico.  -- en otras palabras, algo ingnierilmente *muy malo*.




>> * Y si nos vamos a poner en "no podemos seguir acarrreando 
>> problemas"... la realidad es que, mas alla del mayor espacio de 
>> direcciones (y en consecuencia tener la posibilidad de asignar
>> direcciones globales donde uno lo requiera), IPv6 no soluciona
>> otros problemas... sino que en algunas atreas, inclusive introduce
>> problemas nuevos.
>> 
> 
> IPv4 ha tenido y sigue teniendo muchos problemas. La diferencia es
> que tenemos mas experiencia, pero esa experiencia no debe de ser
> aplicada siempre de forma “literal” a nuevas tecnologías.

Lo que aprendimos en 30 años es que las direcciones deberian haber sido 
mas largas? :-)




>> * No conozco una sola cosa perceptible por el usuario final que
>> dependa del despliegue IPv6. Tampoco conozco mucha cosa
>> "innovadora" que este dependiendo de IPv6 (pese a las historias o
>> use-cases de ciencia-ficcion que estamos acostumbrados a
>> escuchar). Por este motivo, muchas organizaciones terminan
>> desplegando IPv6 de forma que "todo cambie lo menos posible" (o,
>> inclusive, si y solo si las cosas cambian lo minimo posible). O,
>> ante la falta de soluciones a problemas concretos, terminan
>> postergando el despliegue. (modulo el tipo de organizaciones antes
>> mencionado).
> 
> Tiempo al tiempo. Muchas tecnologías no necesariamente han
> manifestado mejoras tangibles o al menos de forma inmediata, y sin
> embargo, evolucionamos.
> 
> A mi también me gusta “no dejes para mañana lo que puedas hacer
> hoy”, pero no siempre se puede!

Todo depende del cuando y dode:

* Si se trata de armar algo en tu casa con fines ludicos, perfecto.

* En un gobierno o institucion educativa, para bien o para mal,
   usualmente tambien tenes ese margen.

* Ahora, en un entorno corporativo, algo que requiere muchos esfuerzo y
   tiempo (etc., etc., etc.,) sin un impacto concreto en revenue, l
   a cuestion no funciona. -- asi de simple.


Y aclaro (por enesima): no es una cuestion si estoy de acuerdo (o no) o 
si me gusta (o no). Es lo que la realidad indica.




>> * 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.



>> Si para empujar el despliegue hace falta "salir a presionar 
>> fabricantes", publicar mandatos para que los gobiernos fuercen el
>> despliegue, o "sacar del mercado a un fabricante", me atreveria a
>> pensar que estamos por el camino equivocado, y que hay algo que no
>> estamos leyendo.
 >> >
> 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?

Alguien presiona a las empresas hoy en dia a adoptar IA?


(Creo que todos conocemos la respuestas a ambas preguntas).



>>>> El tema del uso de ULAs interno y NATv6 uno a uno (no SLAAC)
>>>> no está muy bien aceitado en la mayoría de los sistemas
>>>> operativos de routers domésticos por ejemplo, entonces no se
>>>> puede usar correctamente en muchos casos.
>>> Claro, ni lo estará por el momento. En IETF el consenso hasta
>>> ahora (y se ha revisado hace menos de 2 años), es que es dar un
>>> paso a tras, y no debe dejar de ser algo experimental.
>> 
>> Brindemos por los proximos 30+ años de "despliegue" de IPv6,
>> entonces.
>> 
>> Es justamente esta postura, intransigente, la que ha hecho que el
>> despliegue de IPv6 haya distado bastante de "exitoso" -- porque
>> convengamos que si estamos festejando un %50 de despliegue luego
>> de 30 años, con buena cantidad de estrategias fallidas, no hay
>> mucho por festejar.
> 
> A mi también me duele que vayamos tan lento, ya lo he dicho antes,
> pero nos encontramos ante decisiones mas comerciales que técnicas, y
> eso pasa en todos los aspectos de la vida y el trabajo.

Toda solucion de ingenieria tiene que contemplar tanto lso aspectos 
tecnicos como economicos.




>>> Para eso no hubiéramos desarrollado IPv6, mantén CGN en tu red y
>>> poco a poco desconéctate del resto del mundo que ha optado ya en
>>> el 65-70% por IPv6.
>> 
>> No se puede tapar el sol con la mano. Hoy dia podes deshabilitar
>> IPv6 en el mundo empresarial, y todo sigue como si nada. Lo cual
>> obviamente no es el caso para IPv4.
>> 
>> Toda una cantidad de cosas que veo (y tengo que lidiar con) en el
>> dia a dia:
>> 
>> * GitHub sin IPv6 * AWS sin PTRs para direcciones IPv6 * GCP
>> metadata endpoint solo disponible en IPv4 en redes dual-stack *
>> Slack sin IPv6
>> 
>> ... y la lista continua, incluyendo GCP fallando de maneras
>> ridiculas, porque en distntas partes de la plataforma comparaban
>> las direcciones en formatos de presentacion diferentes.
> 
> Es evidente, que falta camino por andar, nadie lo ha negado.

Es que todo se resume a lo mismo:
* Del lado del usuario, "todo esto no me funciona... asi que.. por que
   voy a gastar mi tiempo en esto?"

* Del lado del vendor "No necesito IPv6 para mantener mis clientes o
   ganas nuevos".



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.





> Por eso lo estoy actualizando! Muchos documentos de IETF necesitan
> evolucionar, es normal, y ocurre con IPv4 y con cualquier protocolo:
> Internet evoluciona, igual que lo hace todo el mundo y hay que
> adaptarse, no permanecer en la operatividad a la que estamos
> acostumbrados. De nuevo y no literal “hay que desaprender”.

El problema para cuando uno toma ciertas cosas como dogma.

Cuando alguien parte de la base de "el nat es maloooooooo!", termina 
"rascandose con la mano izquierda".

Para determinadas coass, el NAT es puede ser una solucion simple y 
cost-effective. Si uno parte de la premisa que "hay que evitar NAT a 
toda cosa", ya se empieza mal. -- y el resultado termina siendo la 
no-adopcion.


Yo soy partidario que, en todo caso, algun tipo de despliegue 
(incluyendo con NAT, donde sea conveniente) es mejor que:

* Un no-despliegue (es decir, IPv4-only)

* 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) )


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