[lacnog] Announcing Windows CLAT Public Preview
Nicolas Antoniello
nantoniello en gmail.com
Mie Jun 17 08:39:37 -03 2026
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.
Nico
El El mié, jun 17, 2026 a la(s) 04:16, jordi.palet--- vía LACNOG <
lacnog en lacnic.net> escribió:
> Hola Henri,
>
> Creo que el problema de esta discusión es partir de una premisa que no es
> correcta. No se si esta perfectamente claro al 100% en los documentos del
> IETF de IPv6-Mostly que esta diseñado para redes enterprise, pero si que
> tengo claro que es así por las discusiones que hemos tenido durante años al
> respecto, y ademas, siempre hemos hablado de “managed networks” (eso creo
> que si esta en los documentos).
>
> El RFC8925, que es de donde parte la opción 108, indica claramente que
> habla de los problemas de desplegar IPv6-only LANs, y luego usa “networks”
> para referirse a estar redes. Creo que esto no es el caso en redes
> residenciales. Además como una de las razones para usar 108 se refiere a la
> reducción del uso de direcciones IPv4-privadas. Esto no es algo que sea un
> problema en redes residenciales.
>
> Se habla también de la necesidad del PLAT local, y algo que no se si
> mencione antes, si se usa IPv6-Mostly, la rede de acceso tiene que
> mantenerse como dual-stack, con lo cual el ISP sigue teniendo que mantener
> o bien suficientes direcciones IPv4 públicas o bien CGN. En cambio con
> IPv6-only with IPv4aaS (464XLAT), sustituye (o reconfigura, generalmente
> puede ser el mismo dispositivo) el CGN como NAT64, y ademas con la ventaja
> de que el pool de direcciones IPv4 publicas que se necesita es muy inferior
> al caso de CGN.
>
> Por lo demás concuerdo contigo en tus comentarios, solo la salvedad de que
> CLAT en Android e iOS (incluso Windows en interfaces 3G), ocurrió hace
> muchos años (2013-2014), porque las redes móviles eran el primer usuario,
> sin descartar las redes residenciales. IPv6-Mostly esta “naciendo” porque
> nos hacía falta facilitar el despliegue de IPv6 en redes enterprise.
>
> Algo en lo que no concuerdo es el ciclo de renovación de los dispositivos
> antiguos. No todos los usuarios tienen el mismo poder adquisitivo para
> poder reemplazar esas antiguas impresoras, cámaras, smartTVs, etc. y muchas
> veces duran mas de 10 años (de hecho eso mismo les pasa a los CPEs, que
> muchas veces duran mucho mas!).
>
> Por cierto que en NANOG se ha comentado también el uso de IPv6-Mostly en
> residenciales, y antes que yo respondiera, ya ha habido alguien que ha
> confirmado que eso es incorrecto y que no se puede si hay dispositivos
> IPv4-only.
>
> Saludos,
> Jordi
>
> @jordipalet
>
> El 17 jun 2026, a las 0:33, Henri Alves de Godoy <
> henri.godoy en fca.unicamp.br> escribió:
>
> Boa noite a todos,
>
> Lendo atentamente todos os comentários ao longo do dia, a impressão que
> tenho é que a ideia central do IPv6-Mostly é justamente caminharmos para
> uma rede majoritariamente IPv6, reduzindo gradualmente a dependência de
> IPv4 nativo até que ele deixe de ser necessário para a maior parte dos
> usuários.
>
> Quando trazemos essa discussão para o cenário residencial, percebo que
> grande parte do debate acaba se concentrando na compatibilidade local com
> dispositivos legados, como impressoras, câmeras, Smart TVs que ainda operam
> apenas em IPv4.
>
> Concordo que a experiência do usuário é fundamental e ninguém deseja criar
> situações que gerem tickets, reclamações ou perda de funcionalidade.
>
> Por outro lado, me pergunto se estamos olhando para o problema na direção
> correta. Será que devemos investir tantos esforços para preservar
> indefinidamente a comunicação com dispositivos IPv4 legados dentro da LAN,
> quando a tendência natural do mercado é a renovação desses equipamentos ao
> longo do tempo?
>
> Uma impressora, uma câmera ou uma Smart TV acabam sendo substituídas
> eventualmente por modelos mais novos, e a expectativa é que cada vez mais
> esses dispositivos passem a oferecer suporte adequado ao IPv6.
>
> A percepção que tenho também é que o CLAT nos sistemas operacionais,
> origem desta discussão, possui um objetivo diferente. Ele não parece ter
> sido criado para resolver o problema dos dispositivos legados da LAN, mas
> sim para manter a compatibilidade das aplicações utilizadas pelos usuários
> finais. O foco está muito mais na origem das conexões do que no destino
> delas.
>
> Se observarmos a evolução da indústria, Android, iOS e agora Windows estão
> avançando na implementação de CLAT nos sistemas operacionais. Talvez isso
> seja um indicativo de que o mercado enxerga como prioridade garantir que as
> aplicações continuem funcionando em redes IPv6-only, enquanto a questão dos
> dispositivos IPv4 legados tende a ser resolvida gradualmente pelo ciclo
> natural de renovação dos equipamentos.
>
> Para organizar as ideias melhor:
>
> CLAT = mantém a compatibilidade das aplicações IPv4 executadas no host.
> PLAT = fornece conectividade para destinos IPv4 através da rede IPv6.
>
> Abraços !
> Henri
>
> Em ter., 16 de jun. de 2026 às 09:47, jordi.palet--- vía LACNOG <
> lacnog en lacnic.net> escreveu:
>
>> Creo que se puede contestar a eso sin necesidad de mediciones:
>>
>> ¿Tiene sentido que el trafico “local”, tenga que ir al ISP o a la nube,
>> si el CPE puede procesarlo?
>>
>> La experiencia del usuario es lo primero, según hemos dicho antes, y si
>> se puede poner en el CPE, no tiene sentido llevarlo fuera.
>>
>> Hay que tener en cuenta además, que llevar el tráfico local al ISP o a la
>> nube, no es tan sencillo. Implicaría algún sistema de PLAT “virtual” por
>> cada usuario, dado que los usuarios suelen tener el mismo prefijo IPv4 en
>> cada red residencial, quizás habría que configurar reglas en los CPEs, creo
>> que podría tener implicaciones adicionales de seguridad. Sinceramente,
>> cuanto mas lo pienso menos lo veo.
>>
>> Otro problema adicional. Si se cae el enlace, la red esta congestionada,
>> etc., etc., no puedes imprimir si el PLAT esta fuera de tu red. Tiene eso
>> alguna sentido para la calidad ofrecido al usuario?
>>
>> Siempre intentamos dejar el tráfico lo mas “local” posible. Esa es la
>> idea incluso de los IXPs, caches, CDNs, etc. No parece buena idea no hacer
>> eso porque algunos fabricantes no incorporen CLAT en los CPEs, o si ahora
>> les pedimos PLAT, no lo hagan tampoco ...
>>
>> Saludos,
>> Jordi
>>
>> @jordipalet
>>
>> El 16 jun 2026, a las 14:04, Henri Alves de Godoy <
>> henri.godoy en fca.unicamp.br> escribió:
>>
>> Talvez, uma das grandes discussões futuras será onde se deve localizar el
>> PLAT em cenários residenciais ? Na nuvem, no ISP ou CPE ?
>>
>> Para responder acredito que teremos que avançar nas medições, por isso a
>> contribuição da comunidade é muito importante.
>>
>> Abraços
>> Henri.
>>
>> Em ter., 16 de jun. de 2026 às 08:46, jordi.palet--- vía LACNOG <
>> lacnog en lacnic.net> escreveu:
>>
>>> Eso es, lo comente 3-4 emails atrás … Pero, aunque no hay mucha
>>> dificultad, es mas complejo implementar PLAT en un CPE que CLAT, no te
>>> parece? No le veo el sentido … En todo caso implementaría ambos: Ambos
>>> están con open source, el trabajo es una mera decisión (y obviamente
>>> pruebas para verificara que se ha integrado bien en el firmware del CPE).
>>>
>>> Como indique, es una cuestión de decisión de los fabricantes por
>>> “dólares”, presión del mercado, presión de los clientes, presión de la
>>> competencia …
>>>
>>> Saludos,
>>> Jordi
>>>
>>> @jordipalet
>>>
>>> El 16 jun 2026, a las 13:35, Henri Alves de Godoy <
>>> henri.godoy en fca.unicamp.br> escribió:
>>>
>>> Jordi, e se o PLAT estiver dentro de cada uma das residências, ao invés
>>> de utilizar o PLAT do ISP. ? Acredito que podemos resolver dessa forma,
>>> assim como aqui no meu cenário o PLAT fica local na vlan da rede wifi ou
>>> cabeada.
>>>
>>> Henri.
>>>
>>> Em ter., 16 de jun. de 2026 às 08:23, jordi.palet--- vía LACNOG <
>>> lacnog en lacnic.net> escreveu:
>>>
>>>> Hola Douglas,
>>>>
>>>> En ningún momento he negado que lo mas importante es la satisfacción
>>>> del cliente final. Lo que intento explicar *precisamente* es que con
>>>> IPv6-Mostly NO se cumple ese objetivo, más bien al contrario.
>>>>
>>>> IPv6-Mostly ha sido diseñado para redes gestionadas (enterprise
>>>> networks), donde un administrador decide en que segmentos se aplica y en
>>>> cuales no, o si por ejemplo no existen impresoras que sean solo IPv4, o si
>>>> las hay, implementa un regla en la red bien para que esas impresoras sean
>>>> accesibles, por ejemplo mediante un stateless NAT64 delante de ellas, o
>>>> bien realizando una traducción con WKP+RFC1819 (esta siendo estandarizado
>>>> en este momento) en el stateful NAT64 *de la red enterprise*. Lo que no
>>>> tiene sentido es que ese trafico *salga* de la red para llegar al stateful
>>>> NAT64 del ISP, y vuelva a entrar como IPv4 y viceversa en el camino
>>>> contrario, etc.
>>>>
>>>> Saludos,
>>>> Jordi
>>>>
>>>> @jordipalet
>>>>
>>>> El 16 jun 2026, a las 13:08, Douglas Fischer <fischerdouglas en gmail.com>
>>>> escribió:
>>>>
>>>> Reconhecer que a satisfação do usuário final é mais importante que o
>>>> ego de dizer que usa protocolo/metodologia A ou B é primordial.
>>>>
>>>> Em ter., 16 de jun. de 2026 às 07:41, jordi.palet--- vía LACNOG <
>>>> lacnog en lacnic.net> escreveu:
>>>>
>>>>> Hola Henri,
>>>>>
>>>>> Creo que no hace falta simularlo para comprender porque no funciona.
>>>>>
>>>>> Si en las LANs residenciales algunos dispositivos mediante opción 108
>>>>> dejan de usar IPv4, pero hay otros dispositivos que solo usan IPv4, esta
>>>>> claro que no hay comunicación entre ellos. No te parece?
>>>>>
>>>>> Ahora bien, si quires probarlo, tienes que asegurarte de tener, por
>>>>> ejemplo, una impresora que solo tenga IPv4. Y que el host con el que
>>>>> quieras acceder a ella, este en modo “IPv6-Mostly”. En lugar de una
>>>>> impresora, puede haber muchos otros dispositivos que comuniquen localmente,
>>>>> ejemplo cámaras RTSP, dispositivos de domótica, etc. Hay que asegurarse que
>>>>> no usen IPv6, o que no usen “cloud”. En cualquier caso, para hacer bien
>>>>> esta prueba, habría que desactivar IPv4 en la WAN del router, no se si
>>>>> tienes un entorno residencial que ya te ofrezca 464XLAT o cualquier otro
>>>>> mecanismo del RFC8585.
>>>>>
>>>>> También podría simular este entorno en un laboratorio virtual o en la
>>>>> red de la Universidad, donde si puedes provisionar una LAN con IPv6-only
>>>>> supongo.
>>>>>
>>>>> Pero como dije antes, creo que es evidente, que si el host solo habla
>>>>> IPv6 (IPv6-Mostly) y la impresora solo IPv4 …. “no se ven, no se pueden
>>>>> hablar”.
>>>>>
>>>>> En un teléfono celular (UE), cuando el teléfono usa 464XLAT, dicho UE
>>>>> solo se comunica con la red. Hay 2 casos:
>>>>> 1) iOS: NO usa CLAT, en su lugar HEv2 (RFC8305), usa algo equivalente
>>>>> a “bump in the host”, que hace la misma función y “self-synthesis” para
>>>>> general el AAAA.
>>>>> 2) Android: Usa CLAT.
>>>>>
>>>>> Ahora bien, si el teléfono activa el tethering para compartir datos
>>>>> con otros dispositivos, como el UE recibe un /64 de la red movil, por medio
>>>>> de RA, se usa “prefix sharing” (RFC7278), *CONVIRTIENDO* al UE en un *CPE*
>>>>> (ademas de mantenerse como “host”). Y de nuevo hay 2 casos:
>>>>> 1) iOS: Se activa CLAT (solo para los tethered devices, el UE como
>>>>> “host” sigue usando HEv2).
>>>>> 2) Android: Usa CLAT para ambos, tethered devices y el propio UE.
>>>>>
>>>>> El caso de un CPE que tenga enlace celular con 464XLAT es equivalente
>>>>> a un teléfono haciendo tethering, con la salvedad de que ahí el operador
>>>>> puede usar DHCPv6-PD para provisionar un /48 al CPE. Hay que recordar que
>>>>> aunque el uso de DHCPv6-PD esta estandarizado por 3GPP, no es común su
>>>>> implementación por parte de muchos fabricantes ni en UEs, ni en
>>>>> dispositivos de la red PS.
>>>>>
>>>>> Hay que tener en cuenta que para activar 464XLAT en iOS, y más aun
>>>>> CLAT, para el tethering, es necesario que el operador firme un contrato con
>>>>> Apple a través de su enlace, con pruebas previas de la calidad de la red
>>>>> IPv6, etc., etc. Apple es muy exigente y lenta en todo este proceso, porque
>>>>> quiere garantizar la calidad del servicio a sus clientes.
>>>>>
>>>>> Todo esto no es solo información teórica, sino experiencia en cientos
>>>>> de despliegues en los que he participado.
>>>>>
>>>>> Saludos,
>>>>> Jordi
>>>>>
>>>>> @jordipalet
>>>>>
>>>>> El 16 jun 2026, a las 12:10, Henri Alves de Godoy <
>>>>> henri.godoy en fca.unicamp.br> escribió:
>>>>>
>>>>> Hola Jordi,
>>>>>
>>>>> Vou tentar simular no meu ambiente ipv6-mostly esse cenário
>>>>> residencial, para poder te responder como seria essa compatibilidade de
>>>>> acesso e o caminho na prática.
>>>>>
>>>>> Com relação à operadora Vivo, vou tambem tentar capturar a sinalização
>>>>> que é enviada. Achei um tal de PCAPdroid que deve resolver a forma de
>>>>> captura.
>>>>>
>>>>> Mas como os aparelhos móveis com Android e iOS estão montando o CLAT
>>>>> automaticamente, é praticamente certo que a operadora está sinalizando um
>>>>> ambiente favorável para que a rede continue a operar em ipv6-only.
>>>>>
>>>>> Abraços.
>>>>>
>>>>> Em ter., 16 de jun. de 2026 às 04:59, jordi.palet--- vía LACNOG <
>>>>> lacnog en lacnic.net> escreveu:
>>>>>
>>>>>> Hola Douglas,
>>>>>>
>>>>>> He participado en cientos de despliegues con 464XLAT y en ninguno he
>>>>>> tenido esos problemas que mencionas, supongo que puede ser cuestión de
>>>>>> calidad del producto, y como siempre, experiencia y conocimiento.
>>>>>>
>>>>>> De todos modos la cuestión sigue siendo:
>>>>>> Si no usas CLAT en el CPE, y usas IPv6-Mostly (asumiendo que en el
>>>>>> CPE implementas opción 108, etc.), como resuelves la comunicación con IPv4
>>>>>> entre los nodos de la red residencial (por ejemplo impresoras, SmartTVs,
>>>>>> etc. con solo-IPv4) y nodos que usan IPv6-Mostly (y por tanto dejan de usar
>>>>>> IPv4)?
>>>>>>
>>>>>> Insisto que IPv6-Mostly esta pensado para entornos “managed”, es
>>>>>> decir, redes corporativas.
>>>>>>
>>>>>> Saludos,
>>>>>> Jordi
>>>>>>
>>>>>> @jordipalet
>>>>>>
>>>>>> El 15 jun 2026, a las 22:17, Douglas Fischer <
>>>>>> fischerdouglas en gmail.com> escribió:
>>>>>>
>>>>>> Eu já ouvi maravilhas e já ouvi xingamentos terríveis sobre o cenário
>>>>>> de 464XLAT.
>>>>>>
>>>>>> Dentro do MEU espectro de amostragem, 100% dos casos de reclamação
>>>>>> por parte de operadores de rede o cenário era CLAT feito na CPE.
>>>>>> E esses mesmos que reclamavam desse cenário disseram-me que nos casos
>>>>>> onde o CLAT era feito no endpoint não tinham reclamações.
>>>>>>
>>>>>> Em qui., 11 de jun. de 2026 às 13:09, jordi.palet--- vía LACNOG <
>>>>>> lacnog en lacnic.net> escreveu:
>>>>>>
>>>>>>> Essa transparência é que vejo como uma vantagem e também benefício,
>>>>>>>> mesmo em cenários residenciais. Concorda ?
>>>>>>>>
>>>>>>>
>>>>>>> Concordo em gênero, número, e grau!
>>>>>> O motivo dessa minha intensa concordância é que o cliente não quer (e
>>>>>> nem tem a obrigação) de saber se é o CLAT do CPE ou se é o CLAT do Android
>>>>>> ou do Windows. O que ele quer saber é se funciona ou não.
>>>>>> E mesmo para cenários residenciais, uma simples informação como "o
>>>>>> problema acontece no APP que roda no android, mas não acontece no APP que
>>>>>> roda no windows." "Ou na smarttv, ou no iphone, ou no MAC." faz toda a
>>>>>> diferença.
>>>>>>
>>>>>> Reconhecer que a satisfação do usuário final é mais importante que o
>>>>>> ego de dizer que usa protocolo/metodologia A ou B é primordial.
>>>>>>
>>>>>> O que acredito que vamos ver agora é redes que foram implantadas com
>>>>>> DualStack passarem implementar o IPv6 Mostly, e com isso a parcela de IPv4
>>>>>> nativo passante na rede ir diminuindo, sendo substituída por CLAT no
>>>>>> endpoint com PLAT.
>>>>>>
>>>>>> E com isso, naturalmente o número de portas públicas vai diminuir, e
>>>>>> eventualmente até a banda demanda também vai ir reduzindo.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Douglas Fernando Fischer
>>>>>> Engº de Controle e Automação
>>>>>> _______________________________________________
>>>>>> 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.
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.
>>>>>
>>>>> _______________________________________________
>>>>> LACNOG mailing list
>>>>> LACNOG en lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>>
>>>>
>>>>
>>>> --
>>>> Douglas Fernando Fischer
>>>> Engº de Controle e Automação
>>>>
>>>>
>>>>
>>>> **********************************************
>>>> 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.
>>>>
>>>> _______________________________________________
>>>> 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.
>>>
>>> _______________________________________________
>>> 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.
>>
>> _______________________________________________
>> 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.
>
> _______________________________________________
> 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/20260617/0901d7c2/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG