<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br><div><blockquote type="cite"><div>El 25 jul 2026, a las 2:08, Nicolas Antoniello <nantoniello@gmail.com> escribió:</div><br class="Apple-interchange-newline"><div><div dir="auto">Fernando,</div><div dir="auto"><br></div><div dir="auto">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. 😊</div></div></blockquote><div><br></div><div>Usar un protocolo *experimental*, por mucho que sea un RFC (experimental), lo dice el propio RFC, no es una buena práctica.</div><div><br></div><div>La cuestión es que quizás entendemos que cualquier RFC es “lo que hay que hacer” por el simple hecho de ser un RFC y no siempre es así. Muchos RFCs documentan cosas para “jugar” con ellas y puede que lleguen a ser estándares (normalmente con lo aprendido jugando, no tal cual), pero generalmente no es el caso.</div><br><blockquote type="cite"><div><div dir="auto"><br></div><div dir="auto">Nico</div><div dir="auto"><br></div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">El El vie, jul 24, 2026 a la(s) 19:26, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com">fhfrediani@gmail.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div><p>No estoy de acuerdo con algunos puntos.<br>
Los firewalls existen por una razón. Que una dirección IP sea
pública no significa que deba estar sin protección.<br>
<br>
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.</p></div><div><p>Fernando</p>
<div>On 7/24/2026 7:09 PM, Fernando Gont
wrote:<br>
</div>
<blockquote type="cite">
<br>
On 17/06/2026 11:08, jordi.palet--- vía LACNOG wrote:
<br>
<blockquote type="cite">
<br>
<blockquote type="cite">El 17 jun 2026, a las 14:28, Nicolas
Antoniello <a href="mailto:nantoniello@gmail.com" target="_blank"><nantoniello@gmail.com></a> escribió:
<br>
<br>
Hay algunas cosas que las implementaciones actuales e incluso
la recomendación de protocolos no refleja la realidad de la
mayoría.
<br>
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
<br>
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.
<br>
<br>
Se están haciendo despliegues de millones de dispositivos (por
ejemplo contadores de gas, agua, electricidad) con IoT IPv6 y
sin problema.
<br>
</blockquote>
<br>
La premisa es simple:
<br>
<br>
* Usar GUAs en los endpoints, cuando no lo necesitas, termina
siendo en muchos casos una mala idea:
<br>
+ problemas de multihoming
<br>
+ problemas si tu operador renumera tu CPE,
<br>
+ y tambien hace (obviamente) que esos dispositivos sean
<br>
direccionables desde Internet.
<br>
<br>
* Por ende, si no lo necesitas, no lo haces.
<br>
<br>
En muchos casos, riesgos y complicaciones varias, innecesarias.
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">Cuando muchísimos operadores
residenciales cambian los prefijos IPv6 (no importa cada
cuanto los cambian) muchas cosas se “rompen” en una red
interna.
<br>
Se puede resolver con DHCPv6 y NATv6 (o NAT66 con sus
problemas) pero varios bien conocidos sistemas operativos no
soportan algunos de esos protocolos.
<br>
</blockquote>
<br>
En IPv6, lo normal sería NO cambiar los prefijos.
<br>
</blockquote>
<br>
No, no es lo normal. Hay muchos motivos:
<a href="https://www.rfc-editor.org/rfc/rfc8978.pdf" target="_blank">https://www.rfc-editor.org/rfc/rfc8978.pdf</a>
<br>
<br>
<br>
<br>
<blockquote type="cite">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:
<br>
<a href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/</a>
<a href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/" target="_blank"><https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/></a><br>
</blockquote>
<br>
Ignorar la realidad operacional no ayuda a nadie.
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
<br>
<br>
Y no hace falta decirlo: IPv6 NAT *se usa en produccion* -- por
mas que IETF argumente lo que quiera argumentar.
<br>
<br>
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.
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
Esta es exacamente una de las razones por la cual, 30+ años mas
tarde, el despliegue de IPv6 es lo que es:
<br>
<br>
* No hay que desaprender nada. Lo que se deberia haber impulsado
es
<br>
reutilizar la mayor cantidad de conocimiento posible. -- es una
<br>
estrategia mucho mas inteligente que pedirle a cualquier
persona
<br>
que tire por la borda 20+ años de experiencia en redes.
<br>
<br>
* En retrospectiva, es claramente un error (entendible a partir
de
<br>
sucesos historicos), haber cambiado tantas cosas para,
basicamente,
<br>
hacer lo mismo que en IPv4, solo que con direcciones mas
grandes.
<br>
<br>
* Si uno fuera a rediseñar IPv6 hoy en dia, poco de lo que hay en
el
<br>
diseño actual quedaria en el diseño final. Entonces, dejemos de
<br>
vender que IPv6 es la tecnologia de networking revolucionaria o
<br>
superadora, por que no lo es. -- esta bien argumentado desde
hace mas
<br>
de 25 años, inclusive en libros, tales como el el
"Interconnections"
<br>
de Perlman.
<br>
<br>
* Y si nos vamos a poner en "no podemos seguir acarrreando
<br>
problemas"... la realidad es que, mas alla del mayor espacio de
<br>
direcciones (y en consecuencia tener la posibilidad
<br>
de asignar direcciones globales donde uno lo requiera), IPv6 no
<br>
soluciona otros problemas... sino que en algunas atreas,
inclusive
<br>
introduce problemas nuevos.
<br>
<br>
* A veces se me ocurre que muchos de los problemas asociados
tienen que
<br>
ver con unaposible falta de humildad y realismo respecto del
lugar
<br>
que las cosas ocupan: Si, seguramente para un ISP o para una
CDN el
<br>
tema de IPv6 sea una cuestion central. Pero para cualquier otra
<br>
organizacion para la que su core business no sea "mover
paquetes",
<br>
IPv6 no esta ni en el "top 10" de prioridades. -- comparar, por
<br>
ejemplo, la centralidad que tienen hoy en dia temas como IA,
con
<br>
la no centralidad que tienen temas como IPv6. (Ya nadie tuvo
<br>
que publicar mandatos, prender fuego deptos, o presionar
vendors
<br>
para que asi ocurra).
<br>
<br>
Entonces, toda idea debe ser pasada por este filtro. Esperar
que
<br>
algunas una de dichas organizaciones se pongan a navegar por
las 10+
<br>
tecnologias de transicion fallidas, para terminar en la
tecnologia
<br>
"estrella" de momento, debates desconectados del mundo real
como
<br>
SLAAC vs DHCPv6, etc, es desconocer esa realidad.
<br>
<br>
* No conozco una sola cosa perceptible por el usuario final que
dependa
<br>
del despliegue IPv6. Tampoco conozco mucha cosa "innovadora"
que
<br>
este dependiendo de IPv6 (pese a las historias o use-cases de
<br>
ciencia-ficcion que estamos acostumbrados a escuchar). Por este
<br>
motivo, muchas organizaciones terminan desplegando IPv6 de
forma
<br>
que "todo cambie lo menos posible" (o, inclusive, si y solo si
<br>
las cosas cambian lo minimo posible). O, ante la falta de
soluciones
<br>
a problemas concretos, terminan postergando el despliegue.
(modulo
<br>
el tipo de organizaciones antes mencionado).
<br>
<br>
* Con el tiempo, mientras muchos siguen con esa especie de
"cruazada
<br>
IPv6" con posturas fundamentalistas (que inclusiven obedecen a
<br>
"principios" *fabricados*), IPv6 inclusive se vuelve menos
<br>
interesante: sin ir mas lejos, hace años uno de los
<br>
ejemplos/argumentos de momento era la limitacion en cantidad de
<br>
conexiones concurrentes TCP que implicaba IPv4 -- con el
ejemplo
<br>
clasico de cuantas conexiones TCP eran necesarias para
renderizar un
<br>
mapa en Google. Que paso en el medio? -- QUIC.
<br>
<br>
* En esta lista/thread he escuchado/leido cosas tales como
comparar a
<br>
un NAT con una enfermedad, sacar a fabricantes del mercado, o
<br>
"presionar". En lo personal, creeria que todo el mundo podria
sacar
<br>
alguna leccion en base al "state of affairs" del despliegue de
IPv6.
<br>
<br>
Si para empujar el despliegue hace falta "salir a presionar
<br>
fabricantes", publicar mandatos para que los gobiernos
<br>
fuercen el despliegue, o "sacar del mercado a un fabricante",
me
<br>
atreveria a pensar que estamos por el camino equivocado, y que
hay
<br>
algo que no estamos leyendo.
<br>
<br>
* Mas que negar problemas, lo que hay que hacer es trabajar en
<br>
solucionar los problemas que hay para solucionar. En lo
personal
<br>
he trabajado en la solucion de una buena cantidad de cosas
<br>
(datapoint:
<a href="https://datatracker.ietf.org/person/Fernando%20Gont" target="_blank"><https://datatracker.ietf.org/person/Fernando%20Gont></a>),
<br>
y nadie se sumo.
<br>
<br>
E inclusive en este aspecto, aclaro: Esto es aplicable a quien
tiene
<br>
un interes particular en el despliegue de IPv6. Porque tampoco
uno
<br>
puede imaginarse o pretender que el individuo promedio se ponga
a
<br>
dedicar horas y horas en discusiones en el grupo de IETF o
similares.
<br>
<br>
No por una cuestion que sea algo complejo ni mucho menos, sino
mas
<br>
bien porque el mortal promedio (cuyo trabajo no depende
directamente
<br>
del despliegue de ipv6 o de hacerlo mejor), normalmente
prefiere
<br>
honrar el tiempo que tiene en este planeta haciendo otras
cosas,
<br>
desde dormir, a juntarse con amigos, apsar tiempo en familia, o
<br>
viendo un partido de futbol.
<br>
<br>
<br>
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.
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
Brindemos por los proximos 30+ años de "despliegue" de IPv6,
entonces.
<br>
<br>
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.
<br>
<br>
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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. </blockquote>
<br>
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).
<br>
<br>
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
<br>
Toda una cantidad de cosas que veo (y tengo que lidiar con) en el
dia a dia:
<br>
<br>
* GitHub sin IPv6
<br>
* AWS sin PTRs para direcciones IPv6
<br>
* GCP metadata endpoint solo disponible en IPv4 en redes
dual-stack
<br>
* Slack sin IPv6
<br>
<br>
... 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.
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">Hay un análisis en un documento que
compara IPv4 e IPv6 en este aspecto:
<br>
<a href="https://datatracker.ietf.org/doc/rfc4864/" target="_blank">https://datatracker.ietf.org/doc/rfc4864/</a>
<a href="https://datatracker.ietf.org/doc/rfc4864/" target="_blank"><https://datatracker.ietf.org/ doc/rfc4864/></a>
<br>
</blockquote>
<br>
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.
<br>
<br>
<br>
No hay que perder de vista que se supone que estamos haciendo es
ingenieria: solucionar problemas mediante soluciones
economicamente viables.
<br>
<br>
Ni tampoco perder de vista esta obra maestra de Russell:
<a href="https://www.youtube.com/watch?v=ihaB8AFOhZo" target="_blank"><https://www.youtube.com/watch?v=ihaB8AFOhZo></a>
<br>
<br>
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".
<br>
<br>
Slds,
<br>
</blockquote>
</div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div></div>
_______________________________________________<br>LACNOG mailing list<br>LACNOG@lacnic.net<br>https://mail.lacnic.net/mailman/listinfo/lacnog<br>Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog<br></div></blockquote></div><br><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<br>
The IPv6 Company<br>
<br>
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.<br>
<br>
</body></html>