[lacnog] Announcing Windows CLAT Public Preview

Vie Jul 31 10:18:54 -03 2026

Fernando,

O tempo aqui referido é o tempo de ficar debatendo na lista o "sexo dos
anjos". Me parece muita perda de tempo discutir coisas que não levarão a
uma definição concreta até porque, essa definição não existe. Cada cenário
é um e deve ser analisado pelo profissional responsável por ela. Concordo
que se deve ressaltar o que é boa prática e o que não é, dando ao cliente a
clareza necessária dos riscos envolvidos em não seguir uma boa prática. E o
que é uma boa prática? Se um protocolo existe, foi desenhado pra uma
aplicação mas na minha concepção não deve ser, seria isso considerado uma
prática errada? E no final, cabe a quem paga (dono da rede, infraestrutura,
empresa e etc) decidir o que ele quer que seja feito. E ao profissional
decidir fazer ou não, informando ao cliente o motivo da decisão. Eu lido
com empresas de diferentes países e diferentes realidades e entenda: cada
realidade é uma e não existe uma verdade absoluta. Só o fato de achar que
existe essa verdade, já fecha nossos olhos e ouvidos para entender e
absorver a realidade de quem está sentindo a dor e deseja resolvê-la da
maneira mais rápida, cômoda e econômica (nem sempre nessa ordem).

"Nem tudo que é certo, é certo todo o tempo e nem tudo que é errado, é
errado todo o tempo." Essa expressão, que não sei se existe em algum lugar
além da minha cabeça, me ensinou muito sobre a vida real fora da minha
bolha.

Saludos,

Uesley Corrêa - Analista de Telecomunicaciones
CEO Telecom ISP Solutions

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

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