[lacnog] Announcing Windows CLAT Public Preview

Vie Jul 24 21:08:15 -03 2026

Fernando,

Yo creo que decir que usar un protocolo de la IETF no es una buena práctica
porque si, tampoco es una buena práctica. 😊

Nico

El El vie, jul 24, 2026 a la(s) 19:26, Fernando Frediani <
fhfrediani en gmail.com> escribió:

> 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>
> <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/>
> <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>
> <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/> <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>
> <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,
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20260724/3124f9c9/attachment-0001.htm>