<div dir="ltr"><div>Fernando,</div><div><br></div><div>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).</div><div><br></div><div>"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.</div><div><br></div><div>Saludos,</div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">Uesley Corrêa - Analista de Telecomunicaciones</span></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>CEO Telecom ISP Solutions</div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jul 31, 2026 at 8:12 AM Fernando Frediani <<a href="mailto:fhfrediani@gmail.com">fhfrediani@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">O que desvia do padrão e das boas práticas deve ser chamado pelo nome.</div><div dir="auto">Não é porque "pra mim ou na minha rede funciona" que está bem feito.</div><div dir="auto"><br></div><div dir="auto">Acredito que a discussão é mais o que é o certo e o bem recomendado do que o que dá ou o que mandaram fazer.</div><div dir="auto"><br></div><div dir="auto">Saudações</div><div dir="auto">Fernando</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 31 Jul 2026, 07:48 Uesley Correa, <<a href="mailto:uesleycorrea@gmail.com" target="_blank">uesleycorrea@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hola!</div><div dir="auto"><br></div><div dir="auto">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:</div><div dir="auto"><br></div><div dir="auto">- 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;</div><div dir="auto">- 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?</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Saludos!</div><div><br clear="all"><br clear="all"><div><div dir="ltr" class="gmail_signature">Enviado do Gmail para iPad</div></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 31 Jul 2026 at 07:31 Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" rel="noreferrer" target="_blank">fhfrediani@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Olá Fernando<div dir="auto"><br></div><div dir="auto">É 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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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".</div><div dir="auto"><br></div><div dir="auto">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" ?</div></div><div dir="auto"><div dir="auto"><br></div><div dir="auto">Fernando</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 30 Jul 2026, 19:13 Fernando Gont, <<a href="mailto:fgont@si6networks.com" rel="noreferrer" target="_blank">fgont@si6networks.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 30/07/2026 06:33, jordi.palet--- vía LACNOG wrote:<br>
> <br>
>> El 25 jul 2026, a las 1:28, Fernando Gont <<a href="mailto:fgont@si6networks.com" rel="noreferrer noreferrer" target="_blank">fgont@si6networks.com</a>> escribió:<br>
>><br>
>> On 24/07/2026 19:28, Fernando Frediani wrote:<br>
>>> No estoy de acuerdo con algunos puntos.<br>
>>> Los firewalls existen por una razón. Que una dirección IP sea pública no significa que deba estar sin protección.<br>
>><br>
>> Nadie argumento eso.<br>
>><br>
>> El argumento fue otro: Nada es gratis.<br>
> <br>
> Ninguna evolución de nada, en la vida, es gratis!<br>
<br>
El concern suele tenerlo quien tiene que pagar la cuenta....  :-)<br>
<br>
<br>
<br>
>> 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),<br>
>><br>
> <br>
> 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.<br>
> <br>
>> Por otro lado, a partir del momento en que utilizas direccionamiento publico, quedas expuesto a todos los issues de renumbering (<a href="https://www.rfc-editor.org/rfc/rfc9096.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc9096.html</a>).  Mientras que si utilizas direccionamiento privado, eso no te afecta.<br>
>><br>
>><br>
> <br>
> 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.<br>
<br>
El problema es, justamente, que quien es afectado no controla eso. Asi <br>
de simple.<br>
<br>
<br>
<br>
>>> Y estoy de acuerdo en que no se debe fomentar ni enseñar NAT66 ni NPTv6,<br>
>>> 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.<br>
>><br>
>> Ahi es donde esta el error: estas aceptando a IPv6 como dogma.<br>
> <br>
> 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.<br>
<br>
A mi me parece una vision derrotista. :-)<br>
<br>
Por que alguien deberia aceptar como "dogma", algo desarrollado en un <br>
momento sin gran experiencia operacional (y en un entorno complemtamente <br>
diferente), y que en 30 años logro 50% de *trafico* (no necesariamente <br>
despliegue!)?<br>
<br>
<br>
Por el contrario: creo que hay que arreglar todo lo que hay para arreglar.<br>
<br>
Que IETF (6man en particular) pueda convivir felizmente con la idea que <br>
multihoming/multiaddressing no funciona, deberia espantarnos.<br>
<br>
<br>
<br>
><br>
>> 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.<br>
>> (encabezados de extension, DHCPv6 y SLAAC, etc.)<br>
 ><br>
> <br>
> 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.<br>
<br>
SLAAC vs DHCPv6 es debatible? :-)<br>
<br>
La situacion en materia de configuracion automatica se resume a: bien <br>
fea.  --- llegando a cosas tales como implementar registro dedirecciones <br>
en SLAAC.<br>
<br>
<br>
(Repito: los largos debates sostenidos en el tiempo sobre este tema me <br>
parecen de poca honra al tiempo que se nos ha dado en este planeta) -- <br>
lo que alguno llamaria "gente con mucho tiempo libre" o personas "sin <br>
problemas reaLes por resolver".<br>
<br>
Frecuentemente uno se queda con la idea que hay mas ganas de debetir -- <br>
por el debate en si -- que en solucionar problemas o hacerle la vida mas <br>
facil a quien quiera desplegar IPv6.<br>
<br>
Slds,<br>
-- <br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href="mailto:fgont@si6networks.com" rel="noreferrer noreferrer" target="_blank">fgont@si6networks.com</a><br>
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494<br>
<br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" rel="noreferrer noreferrer" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" rel="noreferrer" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div></div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" rel="noreferrer" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div>