[lacnog] Announcing Windows CLAT Public Preview

Vie Jul 24 19:28:06 -03 2026

No estoy de acuerdo con algunos puntos.
Los firewalls existen por una razón. Que una dirección IP sea pública no 
significa que deba estar sin protección.

Y estoy de acuerdo en que no se debe fomentar ni enseñar NAT66 ni NPTv6, 
ya que no son buenas prácticas y van en contra del espíritu de IPv6. Que 
alguien las use y funcionen no significa que sean correctas.

Fernando

On 7/24/2026 7:09 PM, Fernando Gont wrote:
>
> 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,
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20260724/8a549486/attachment-0001.htm>