[lacnog] Announcing Windows CLAT Public Preview

Vie Jul 31 08:11:45 -03 2026

Uesley, acredito que talvez exista uma confusão sobre o que é o certo e o
que é possível fazer dentro da realidade de cada um.

O fato não ter tempo não torna nem normaliza dizer para as pessoas em geral
que não há problema com aquela prática. Ela segue sendo errada ou no mínimo
não recomendada e isso deve ser dito de maneira bem clara para que os
envolvidos tenham ciência de que estão deliberadamente desviando do caminho
que é a melhor prática e nem é o mais indicado para aqueles que buscam
fazer direito.

Entende que quem não tem tempo ou o cliente não liga que aquela não é a
maneira correta não faz aquela prática se tornar normal e principalnente em
foruns onde pessoas buscam aprender qual é o certo isso não deve ser
estimulado.

O que desvia do padrão e das boas práticas deve ser chamado pelo nome.
Não é porque "pra mim ou na minha rede funciona" que está bem feito.

Acredito que a discussão é mais o que é o certo e o bem recomendado do que
o que dá ou o que mandaram fazer.

Saudações
Fernando

On Fri, 31 Jul 2026, 07:48 Uesley Correa, <uesleycorrea en gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/cb9c9657/attachment.htm>