[lacnog] Announcing Windows CLAT Public Preview

Vie Jul 31 07:48:02 -03 2026

Hola!

Coincido con Fernando sobre “tiempo libre”. Como casi no lo tengo, leo
cuando puedo. Y veo que estamos como perros tras la cola. Yo me considero
evangelista de IPv6. Pero al fin del día, me baso en dos conceptos:

- autonomía de sistema. Si alguien es sistema autónomo, puedo recomendar e
indicar buenas prácticas. Pero él es quien va a decidir qué hacer en su
sistema autónomo. Y claro, convivir con consecuencias que puedan existir;
- el que paga la cuenta. Quien paga la cuenta, me paga para solucionar. El
no quiere saber si lo hago con IPv4, IPv6, IPv8 o fragmentos de roca lunar.
Nuevamente, puedo recomendarle mejores prácticas (de hecho, eso hace parte
de mi trabajo) pero si quien paga no está dispuesto, que hago yo?

En mi red personal, en mi sistema autónomo, las cosas andan como a mí me
gusta. De resto, aprendí a bailar como suena la canción.

Saludos!

Enviado do Gmail para iPad

On Fri, 31 Jul 2026 at 07:31 Fernando Frediani <fhfrediani en gmail.com> wrote:

> Olá Fernando
>
> É um pouco confuso pra mim compreender o que quer dizer quando fala de
> maneira tão pragmática sobre maneiras de implementação de IPv6, fora do que
> as RFCs e boas práticas recomendam e trata NAT66 e similares como
> ferramentas legítimas e aceitáveis para qualquer cenário.
>
> Vejo que não é e nem deve ser assim, principalmente em locais onde existem
> l pessoas buscando aprender como fazer da maneira correta e pessoas que são
> referência pública devem prpcurar ensinar qual é o caminho e as melhores
> práticas e que se basear no que o IETF produz faz sim sentido.
>
> Já é difícil para pessoas em geral que não são da área de telecomunicações
> e internet como nós aqui (em geral gerentes de TI, desenvolvedores, etc)
> entender redes e IPv6. Não me parece razoável dizer à eles que está tudo
> bem em fazer NAT66 "já que resolve um problema".
>
> Qual o sentido de desenvolver todo um trabalho no IETF, que leva meses ou
> até anos para virar padrão no intuito de que a Internet possa trabalhar em
> consenso e possa ser referência para vendors desenvolverem seus produtos se
> de maneira muito fácil ignora-se isso para "resolver um problema" ?
>
> Fernando
>
> On Thu, 30 Jul 2026, 19:13 Fernando Gont, <fgont en si6networks.com> wrote:
>
>> On 30/07/2026 06:33, jordi.palet--- vía LACNOG wrote:
>> >
>> >> El 25 jul 2026, a las 1:28, Fernando Gont <fgont en si6networks.com>
>> escribió:
>> >>
>> >> On 24/07/2026 19:28, Fernando Frediani wrote:
>> >>> 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.
>> >>
>> >> Nadie argumento eso.
>> >>
>> >> El argumento fue otro: Nada es gratis.
>> >
>> > Ninguna evolución de nada, en la vida, es gratis!
>>
>> El concern suele tenerlo quien tiene que pagar la cuenta....  :-)
>>
>>
>>
>> >> Cuando los sistemas no tienen direcciones publicas, precisas de que un
>> sistema este explicitamente traduciendo direcciones para que alguien llegue
>> al sistema en cuestion (fail-safe, default deny),
>> >>
>> >
>> > Que las direcciones sean públicas/globales o privadas no necesariamente
>> implica seguridad. Un router de borde o incorpora un firewall, o lo tiene
>> justo detrás.
>> >
>> >> Por otro lado, a partir del momento en que utilizas direccionamiento
>> publico, quedas expuesto a todos los issues de renumbering (
>> https://www.rfc-editor.org/rfc/rfc9096.html).  Mientras que si utilizas
>> direccionamiento privado, eso no te afecta.
>> >>
>> >>
>> >
>> > Pero te afectan otros, y hay que poner en la balanza si es mejor
>> prefijos persistentes, frente a prefijos globales y privadas y complejidad
>> añadida, cuando los prefijos persistentes, no suponen complejidad añadida,
>> porque el CPE igualmente debe tener firewall.
>>
>> El problema es, justamente, que quien es afectado no controla eso. Asi
>> de simple.
>>
>>
>>
>> >>> 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.
>> >>
>> >> Ahi es donde esta el error: estas aceptando a IPv6 como dogma.
>> >
>> > Lo que hacemos es aceptar la evolución que tenemos. Si en lugar de
>> IPv6, hubiera sido TP/IX, aceptaríamos igual esa evolución.
>>
>> A mi me parece una vision derrotista. :-)
>>
>> Por que alguien deberia aceptar como "dogma", algo desarrollado en un
>> momento sin gran experiencia operacional (y en un entorno complemtamente
>> diferente), y que en 30 años logro 50% de *trafico* (no necesariamente
>> despliegue!)?
>>
>>
>> Por el contrario: creo que hay que arreglar todo lo que hay para arreglar.
>>
>> Que IETF (6man en particular) pueda convivir felizmente con la idea que
>> multihoming/multiaddressing no funciona, deberia espantarnos.
>>
>>
>>
>> >
>> >> Repito lo mismo de antes: hay millones de cosas en IPv6 que nadie las
>> repetiria en un protocolo si hoy uno fuera a diseñar uno desde cero.
>> >> (encabezados de extension, DHCPv6 y SLAAC, etc.)
>>  >
>> >
>> > Debatible: diferentes personas tiene diferentes puntos de vista. El
>> consenso al que llegamos en IETF, hoy podría no ser el mismo, pero
>> podríamos caer en otros diseños que podríamos también debatir como erróneos.
>>
>> SLAAC vs DHCPv6 es debatible? :-)
>>
>> La situacion en materia de configuracion automatica se resume a: bien
>> fea.  --- llegando a cosas tales como implementar registro dedirecciones
>> en SLAAC.
>>
>>
>> (Repito: los largos debates sostenidos en el tiempo sobre este tema me
>> parecen de poca honra al tiempo que se nos ha dado en este planeta) --
>> lo que alguno llamaria "gente con mucho tiempo libre" o personas "sin
>> problemas reaLes por resolver".
>>
>> Frecuentemente uno se queda con la idea que hay mas ganas de debetir --
>> por el debate en si -- que en solucionar problemas o hacerle la vida mas
>> facil a quien quiera desplegar IPv6.
>>
>> Slds,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont en si6networks.com
>> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
> _______________________________________________
> 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/20260731/5c24d326/attachment-0001.htm>