[lacnog] Announcing Windows CLAT Public Preview

Vie Jul 24 19:09:23 -03 2026

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.

* Por ende, si no lo necesitas, no lo haces.

En muchos casos, riesgos y complicaciones varias, innecesarias.

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

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

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

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.

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

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

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

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

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

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

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

    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.

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

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

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

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

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