<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;">Hola Nico,<div><br></div><div>Contesto entre líneas.</div><div><br id="lineBreakAtBeginningOfMessage"><div>
<div>Saludos,<br>Jordi<br><br>@jordipalet<br></div>
</div>
<div><br><blockquote type="cite"><div>El 17 jun 2026, a las 14:28, Nicolas Antoniello <nantoniello@gmail.com> escribió:</div><br class="Apple-interchange-newline"><div><div dir="auto">Hay algunas cosas que las implementaciones actuales e incluso la recomendación de protocolos no refleja la realidad de la mayoría.</div><div dir="auto"><br></div><div dir="auto">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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Se están haciendo despliegues de millones de dispositivos (por ejemplo contadores de gas, agua, electricidad) con IoT IPv6 y sin problema.</div><br><blockquote type="cite"><div><div dir="auto"><br></div><div dir="auto">Cuando muchísimos operadores residenciales cambian los prefijos IPv6 (no importa cada cuanto los cambian) muchas cosas se “rompen” en una red interna.</div><div dir="auto">Se puede resolver con DHCPv6 y NATv6 (o NAT66 con sus problemas) pero varios bien conocidos sistemas operativos no soportan algunos de esos protocolos.</div></div></blockquote><div><br></div><div>En IPv6, lo normal sería NO cambiar los prefijos. Es un error que hemos acarreado de IPv4. En IPv4 la lógica de cambiar los prefijos inicialmente era por las conexiones dial-up, escasez de direcciones, etc. En IPv6 la recomendación es que los prefijos sean persistentes.</div><div><br></div><div>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:</div><div><a href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/">https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><br><blockquote type="cite"><div><div dir="auto">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.</div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div><div dir="auto">¿Por qué tengo que seguir usando direccionamiento privado IPv4 internamente en mi red para poder hacer las cosas relativamente simple y que funcionen sin mayores inconvenientes? </div></div></blockquote><div><br></div><div>Esto no lo entendí … hablamos de IPv6 o IPv4?</div><br><blockquote type="cite"><div><div dir="auto">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.</div></div></blockquote><div><br></div><div>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. 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.</div><div><br></div><div>Hay un análisis en un documento que compara IPv4 e IPv6 en este aspecto:</div><div><a href="https://datatracker.ietf.org/doc/rfc4864/">https://datatracker.ietf.org/doc/rfc4864/</a></div><div><br></div><div>Este documento me ha sido “asignado” para editar una nueva versión/actualización. Uno de los autores, Brian Carpenter se ha comprometido a revisarlo y ayudar, y los demás autores ya dieron el “ok” para proceder sin ellos. Tengo previsto tener una primera versión en la semana 1-2 de Julio para que se presente en el IETF de final de Julio en Viena.</div><div><br></div><br><blockquote type="cite"><div><div dir="auto"><br></div><div dir="auto">Un poco filosófico si, pero es la realidad también.</div><div dir="auto"><br></div><div dir="auto">Nico</div><div dir="auto"><br></div><div dir="auto"><br></div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">El El mié, jun 17, 2026 a la(s) 09:10, Carlos Martinez <<a href="mailto:carlos@lacnic.net">carlos@lacnic.net</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div style="font-family: Helvetica; font-size: 16px;"><img id="m_916364960117489190555B0A1F90D59744DA673A450227CF94D" alt="" width="0px" src="https://receipts.canarymail.io/track/9822A36445DBCA6769D55D7B5135D32B_55B0A1F90D59744DA673A450227CF94D.png" height="0px"><div id="m_9163649601174891905CanaryBody" dir="auto"> <div> Hola Nico </div><div><br></div><div>¿Que seria bien lo que hay que resolver?</div> <div><br></div><div>Si es un fabricante en particular, prendamoslo fuego aca. </div><div><br></div><div><br></div><div>/Carlos</div><div><br></div></div><div id="m_9163649601174891905CanarySig"><div><div style="font-family:Helvetica">--<br>Sent from <a href="https://canarymail.io/" target="_blank">Canary</a></div> <div><br></div> </div> </div></div><div style="font-family: Helvetica; font-size: 16px;"> <div id="m_9163649601174891905CanaryDropbox"> </div> <blockquote id="m_9163649601174891905CanaryBlockquote"> <div> <div>On Wednesday, Jun 17, 2026 at 8:39 AM, Nicolas Antoniello <<a href="mailto:nantoniello@gmail.com" target="_blank">nantoniello@gmail.com</a>> wrote:<br></div> <div><div dir="auto">Hola a todos,</div><div dir="auto"><br></div><div dir="auto">Muy interesante la discusión!</div><div dir="auto"><br></div><div dir="auto">Agrego y sigo pensando que hasta que no se resuelva bien el tema de IPv6 en redes domésticas (residenciales) siempre va a faltar bastante para poder completar la transición, sin importar cuantos protocolos IPv6 despleguemos a nivel de ISP o Enterprise.</div></div></div></blockquote></div><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></div><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>