[lacnog] Announcing Windows CLAT Public Preview

[jordi.palet en consulintel.es]

> El 25 jul 2026, a las 0:09, Fernando Gont <fernando en gont.com.ar> escribió:
> 
> 
> On 17/06/2026 11:08, jordi.palet--- vía LACNOG wrote:
>>> El 17 jun 2026, a las 14:28, Nicolas Antoniello <nantoniello en gmail.com> escribió:
>>> 
>>> Hay algunas cosas que las implementaciones actuales e incluso la recomendación de protocolos no refleja la realidad de la mayoría.
>>> 
>>> Por ejemplo, la premisa casi fundamentalista de que IPv6 debe ser perseguir siempre conectividad end-to-end sin traslaciones ha llevado a que sea muy difícil en la práctica (en muchísimos casos) el mantener por ejemplo una red de IoT con IPv6 operando sin problemas.
>> No entiendo bien el problema, y no se me ha dado el caso, quizás porque no lo he entendido bien. Si aportas mas detalle lo centramos.
>> IPv6 tiene la premisa end-to-end, pero eso no quiere decir que no puedas configurar diversos segmentos de una red para que estén aislados, por medio de reglas de firewall, ya no solo entre diversas partes de una red local, sino incluso el acceso a Internet.
>> Se están haciendo despliegues de millones de dispositivos (por ejemplo contadores de gas, agua, electricidad) con IoT IPv6 y sin problema.
> 
> 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.

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, pero la realidad es que aunque esa es la tendencia, esto no es un problema *por el momento* en usuarios residenciales. En redes corporativas, independientemente de su tamaño, lo razonable es ir al RIR correspondiente y obtener tu propia asignación directa PI.

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

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

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

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

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

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

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

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

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.

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.

La diferencia es que en todos esos campos casi siempre se termina haciendo por legislación. 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).

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

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

Como poníamos ratas en el alcohol, esta bien seguir haciéndolo, no sabíamos si se moría alguien por eso, pero daba igual, o amianto en polvos de talco que genera cancer por mucho que la industria diga que no, hay estudios que lo contradicen, y ante la duda, mejor evitarlo.

Todo lo nuevo conlleva pros y contras y hay que adaptarse.

> * A veces se me ocurre que muchos de los problemas asociados tienen que
>   ver con unaposible falta de humildad y realismo respecto del lugar
>   que las cosas ocupan: Si, seguramente para un ISP o para una CDN el
>   tema de IPv6 sea una cuestion central. Pero para cualquier otra
>   organizacion para la que su core business no sea "mover paquetes",
>   IPv6 no esta ni en el "top 10" de prioridades. -- comparar, por
>   ejemplo, la centralidad que tienen hoy en dia temas como IA, con
>   la no centralidad que tienen temas como IPv6.  (Ya nadie tuvo
>   que publicar mandatos, prender fuego deptos, o presionar vendors
>   para que asi ocurra).
> 
>   Entonces, toda idea debe ser pasada por este filtro. Esperar que
>   algunas una de dichas organizaciones se pongan a navegar por las 10+
>   tecnologias de transicion fallidas, para terminar en la tecnologia
>   "estrella" de momento, debates desconectados del mundo real como
>   SLAAC vs DHCPv6, etc, es desconocer esa realidad.
> 
> * 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!

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

> * En esta lista/thread he escuchado/leido cosas tales como comparar a
>   un NAT con una enfermedad, sacar a fabricantes del mercado, o
>   "presionar".  En lo personal, creeria que todo el mundo podria sacar
>   alguna leccion en base al "state of affairs" del despliegue de IPv6.
> 

Como tu decías antes, no son relatos, sino datos. Mas del 50% del tráfico sin contar con China. Según los datos que ellos dan (difícilmente comprobables pero estadísticamente creíbles), estamos mas cerca dl 70% que del 50% si sumamos China.

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

> * Mas que negar problemas, lo que hay que hacer es trabajar en
>   solucionar los problemas que hay para solucionar. En lo personal
>   he trabajado en la solucion de una buena cantidad de cosas
>   (datapoint: <https://datatracker.ietf.org/person/Fernando%20Gont>),
>   y nadie se sumo.
> 
>   E inclusive en este aspecto, aclaro: Esto es aplicable a quien tiene
>   un interes particular en el despliegue de IPv6. Porque tampoco uno
>   puede imaginarse o pretender que el individuo promedio se ponga a
>   dedicar horas y horas en discusiones en el grupo de IETF o similares.
> 
>   No por una cuestion que sea algo complejo ni mucho menos, sino mas
>   bien porque el mortal promedio (cuyo trabajo no depende directamente
>   del despliegue de ipv6 o de hacerlo mejor), normalmente prefiere
>   honrar el tiempo que tiene en este planeta haciendo otras cosas,
>   desde dormir, a juntarse con amigos, apsar tiempo en familia, o
>   viendo un partido de futbol.
> 
> 
> Por si vale la aclaracion: lo de arriba no es trashear el diseño original de IPv6 ni mucho menos -- lo cual carece de sentido: la realidad es que estamos hablando de una tecnologia de 30+ años... por lo cual no deberia sorprender a nadie que, 30´años mas tarde, con unas cuantas lecciones aprendidas, y con un entorno de despliegue muy diferente al entorno en el cual IPv6 fue diseñado, hayan muchas cosas que no "cierren".  -- Imaginense a alguien impulsando hoy en dia la adopcion de gopher, por ejemplo.
> 
> 
> 
> 
>>> 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.

> 
>>> Para mí hay aún una especie de fracaso en simplificar las cosas para los usuarios residenciales de IPv6 y que funcionen sin mayores inconvenientes o sin que las personas requieran ser la clase de “bicho” de redes que somos nosotros. Eso que (lo voy a decir) el direccionamiento privado y el NAT en IPv4 había resuelto bastante bien para la mayoría de los usuarios no creo que sea una realidad aún para IPv6.
>> El direccionamiento privado en IPv4 (y NAT) no fue una decisión “consciente” de protocolo, sino de implementar un parche “rápido” para que Internet pudiera seguir creciendo hasta que tuviéramos mas direcciones. No creo que el deseo sea “como este parcha funciona, aunque rompe cosas”, repliquémoslo.
> 
> Muchas de las cosas que NAT rompe, ya estaban rotas por diseño: como ser, por ejemplo, transmitir direcciones IP en un protocolo de aplicacion (como ser por ejemplo el caso de FTP).
> 
> 

Concurrimos, y eso refuerza lo que he hablado. Ha habido formas de desarrollar incorrectas, en este caso “mezclando” capas. Olvidemos las malas prácticas y aprendamos de las buenas que la evolución de cualquier cosa conlleva. Buenas prácticas en IPv4 (no siempre porque fueran buenas sino únicas formas de hacerlo), no siempre aplican a IPv6. Cuando decimos que hay que desaprender IPv4, no hay que tomarlo al 100% literal, sino que hay que pensar hasta que punto prácticas operacionales con IPv4 es necesario mantenerlas en IPv6 o deben ser modificadas y adaptadas.

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

> 
> 
>> Hay un análisis en un documento que compara IPv4 e IPv6 en este aspecto:
>> https://datatracker.ietf.org/doc/rfc4864/ <https://datatracker.ietf.org/ doc/rfc4864/>
> 
> Ese el perfecto ejemplo: fijate cual es la alternativa de "topology hiding sin NAT" que propone ese RFC. Nadie en su sano juicio utilizaria eso.
> 

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

> 
> No hay que perder de vista que se supone que estamos haciendo es ingenieria: solucionar problemas mediante soluciones economicamente viables.
> 
> Ni tampoco perder de vista esta obra maestra de Russell: <https://www.youtube.com/watch?v=ihaB8AFOhZo>
> 
> P.S.: Hago consultoria con IPv6, he dedicado mucho tiempo a IPv6 y a mejorarlo (lo cual esta bien plasmado en un sinnumero de RFCs), y claramente me beneficia que todo el mundo despliegue IPv6 hasta en la sopa. Pero como dijo el gran Diego Armando, "la pelota no se mancha".
> 
> Slds,
> -- 
> Fernando Gont
> e-mail: fernando en gont.com.ar
> PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01
> 


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