[lacnog] Announcing Windows CLAT Public Preview

Mie Jun 17 11:08:21 -03 2026

Hola Nico,

Contesto entre líneas.

Saludos,
Jordi

@jordipalet

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

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

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/

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.

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.

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

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

Esto no lo entendí … hablamos de IPv6 o IPv4?

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

Hay un análisis en un documento que compara IPv4 e IPv6 en este aspecto:
https://datatracker.ietf.org/doc/rfc4864/

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.

> 
> Un poco filosófico si, pero es la realidad también.
> 
> Nico
> 
> 
> 
> El El mié, jun 17, 2026 a la(s) 09:10, Carlos Martinez <carlos en lacnic.net <mailto:carlos en lacnic.net>> escribió:
>> 
>> Hola Nico 
>> 
>> ¿Que seria bien lo que hay que resolver?
>> 
>> Si es un fabricante en particular, prendamoslo fuego aca. 
>> 
>> 
>> /Carlos
>> 
>> --
>> Sent from Canary <https://canarymail.io/>
>> 
>> On Wednesday, Jun 17, 2026 at 8:39 AM, Nicolas Antoniello <nantoniello en gmail.com <mailto:nantoniello en gmail.com>> wrote:
>> Hola a todos,
>> 
>> Muy interesante la discusión!
>> 
>> 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.
>> 
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

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.

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20260617/a07a065d/attachment.htm>