[lacnog] [dns-operations] Name Collision IPv6 Research Study - Public Comment

Vie Oct 31 15:56:25 -03 2025

Hola Nico,

Para que no haya dudas, no he dicho “yo" que se haya apropiado de esa dirección, solo he reproducido lo antes han dicho otros (puse el enlace en el correo anterior) porque no hay un RFC que lo indique, luego es inapropiado, porque es un uso sin un estándar que lo indique. Si hay un RFC entonces lo ha especificado IETF, sino es un uso inapropiado, fuera de estándares, un I-D podría cambiarlo, establecerlo o eliminarlo, pero parece que no lo hay. NO es mi opinión, es que no hay un RFC.

De hecho, todos los números reflejados en paginas de IANA indican el RFC que los asigna. No es una opinion, es lo que indican los procedimientos, es como se hace siempre. Es la relación que hay entre IETF e ICANN/IANA. Ejemplo: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

Insisto en que hablo de “propiedad” dentro de los estándares, ese ese *contexto*. Los estándares son propiedad del IETF y los números lo son *en ese contexto*. Son estándares abiertos, pero con un propietario (el Trust del IETF). IETF delega en IANA su gestión, pero no su definición. No es mi opinión, es lo que esta establecido legalmente. Los estándares incluyen números y en *ese contexto* la propiedad de todo ello es del IETF Trust, se constituyó en el 2016 si no mal recuerdo, para tener formalidad en todo ello. Es propietario, no solo de estándares sino incluso de los dominios que usa IANA. Es información, no opinion mía. Insisto que no hablo de propiedad de números (que no son de nadie) sino de protocolos y en ese contexto los “números” que conllevan con de ese protocolo (asociados a su uso).

La dirección que se esta proponiendo por parte de ICANN es ::ffff:7f00:3535 (que es lo mismo que ::ffff:127.0.53.53), no es link-local. Son direcciones IPv4-mapped (RFC4291), que se usan para mecanismos de transición, y que no pueden aparecer en las comunicaciones (“on the wire”). Es mala idea, muy mala. En la consulta publica esta mal puesto (ffff::127.0.53.53), en los docs esta bien.

Menciono a cada organización o función, aun sabiendo que son las mismas, para que no haya duda, pero lo tengo bien claro.

Quien ha hecho la consulta publica es ICANN/IANA, no se si el estudio previo ha sido algo que ha encargado ICANN/IANA o no, pero es irrelevante, la cuestión es hacer una consulta pública en lugar de discutirlo en IETF con un I-D, ignorando los procedimientos. Es información, no opinión. Aun así me extraña que este informe no haya sido promovido por ICANN/IANA, seguramente seré fácil confirmarlo.

Si revisas mi primer email, era solo para informar de la realidad porque no sabia si Hugo había visto solo la consulta pública o también la discusión en v6ops, que insisto, es donde tiene que estar y una vez se presente un I-D, no antes, no en una consulta publica de nadie mas. Te conteste para aclarar tu correo, pero parece que ha sido peor, y que consideras que estoy dando opiniones en lugar de información. Creo que no tiene sentido seguir con ello. Quien participa en IETF y sigue el Trust, LLC, y todos los temas no solo técnicos, sino tb administrativos, lo sabe bien, y se ve bien claro en la discusión de v6ops, no por mi, sino por lo que confirman los demás.

Y para finalizar, si revisas los comentarios que se han hecho a la consulta pública de ICANN veras información (no opiniones mias) como:

This proposal should be submitted as an Internet Draft, as that is the way that the IETF deal with any and all proposals, including the assigning IPv4 and IPv6 addresses with special purposes. https://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-prefix/04/ is an example of such a proposal.

The use of any loopback addresses, either IPv4, IPv6, or IPv4 loopback addresses embedded in an IPv6 address is not appropriate for this purpose.

The use of 127.0.53.53 for this purpose is unofficial, as there was never any IETF review or assignment of that address for this purpose in the IANA IPv4 Special-Purpose Address Space registry.

The use of 127.0.0.0/8 prevents a useful reverse name that would explain what is going on. Some PTR like possible-future-tld.icann.org would help users of that "string" to understand what is going on.

(copia y pega de lo mas relevante, todo seguido)

La conclusión de esta discusión es que, y no había pensado antes hacerlo, hay que ser mas critico con este consulta y recordarle los procedimientos y que no puede hacerlo unilateralmente como así lo ha hecho. Así que ahora responderé yo también.

Saludos,

Jordi

> El 31 oct 2025, a las 18:51, Nicolas Antoniello <nantoniello en gmail.com> escribió:
> 
> Hola Jordi,
> 
> Creo que estás errado en muchas de tus afirmaciones en ese email… pero bueno, no me voy a poner a debatirlo todo porque es mucho lo que escribiste:
> 
> Algunos de esos errores que creo que estás cometiendo:
> 
> * IANA no se apropió de nada pues ni siquiera fue IANA que sugirió la dirección.
> * No, te vuelvo a repetir que la IETF no es dueña de las IPs ni de los números de protocolos.
> * Hasta donde sé, el fe80::/10 es Link Local Unicast para IPv6 no?
> * Cuando decís “no IANA”, “no ICANN” pareciera que son 2 organizaciones diferentes, IANA es una función y ICANN es quien la ejecuta… a los efectos prácticos son lo mismo.
> * Nuevamente estas “agravando” algo que no tiene nada de grave… te repito una vez más que la sugerencia esa ni siquiera fue de alguien de IANA (cómo vos decís), ni para IPv4 ni para IPv6.
> 
> * Siempre haces afirmaciones unilaterales cómo si las cosas fueran cómo tú quieres que sean Jordi, y las cosas son cómo son, producto de los debates. Una vez más (por si no lo puse en claro hasta ahora) creo que haces un montón de afirmaciones y explicaciones que están equivocadas y que son TU punto de vista y que en consecuencia pueden confundir o llevar a errores a algunos miembros de esta y otras listas. Una cosa es dar nuestra opinión y otra muy diferente es afirmar todo cómo si tuviésemos la razón cuando en numerosas ovaciones no la tenemos.
> 
> Fraterno saludo,
> Nico
> 
> 
> 
> El El vie, oct 31, 2025 a la(s) 14:04, jordi.palet--- vía LACNOG <lacnog en lacnic.net <mailto:lacnog en lacnic.net>> escribió:
>> Hola Nico,
>> 
>> Efectivamente, IANA parece que se “apropio” indebidamente de esa dirección en el caso de IPv4 (y seguramente no nos dimos cuenta en IETF en ese momento o no se le dio la debida importancia, habría que ver si hubo una consulta, pero por lo visto no https://mailarchive.ietf.org/arch/msg/v6ops/qgbtlp-pQo931maAD_Y_kdaaIlU/). Yo no recuerdo esa discusión, hablo por lo que han comentado otros, pero lo prueba es que no hay un RFC que lo documente, y por tanto IANA no puede hacer uso de ese prefijo.
>> 
>> Que se haya hecho contrariamente a las atribuciones de IANA anteriormente, no cambia los procedimientos y evita que se sigan, no crees?
>> 
>> Es como si ahora IANA decidiera hacer políticas para los RIRs por mucho que haga una consulta a la comunidad, no tiene la atribución de hacer políticas.
>> 
>> Por otro lado, no es un prefijo link local (mas bien seria una mapped address “rara”) lo que esta sugiriendo a IANA, y desde luego no son decisiones fundamentalistas si se usa uno u otro prefijo, hay muchas implicaciones, tanto a nivel de soporte en implementaciones como a niveles de mecanismos de transición, entre otros.
>> 
>> Creo que quien lo ha expresado mas claramente, ha sido Brian Carpenter (ex-chair de IETF y creo que una voz que no es amiga de controversias), pero que claramente ha dicho “lo siento señores de ICANN pero esto no es algo a definir por ICANN sino por un proceso del IETF” (resumido y en castellano):
>> 
>> https://mailarchive.ietf.org/arch/msg/v6ops/B2GCyjHDYtSDPCI6UJOKcGc618s/
>> 
>> (y ya lo habían comentado varios participantes reconocidos en emails anteriores)
>> 
>> Si se quiere seguir la discusión, no estando en la lista de v6ops (lo ideal sería suscribirse y participar), los archivos son públicos en (casi todos los correos desde el 29/10 hasta la fecha):
>> 
>> https://mailarchive.ietf.org/arch/browse/v6ops/
>> 
>> Mi afirmación es correcta en el contexto en el que estamos, habría que remitirse a RFCs, pero te puedo garantizar que los protocolos incluyen la definición de “números” (direcciones, puertos, registros, IDs, etc., etc.). Los “números” no son propiedad de nadie (obviamente), pero si son propiedad del IETF como parte de los estándares (en se contexto). El IETF siempre define esos números de forma concreta solo y exclusivamente a través de un Internet Draft, que puede llegar a ser un RFC si alcanza consenso, y en ese documento se le dice a IANA que lo “refleje” formalmente en sus páginas web, archivos, etc. Si el protocolo permite “libertad” para escoger ese “número", a veces, se consulta o se deja a IANA seleccionarlo, pero se hace de mutuo acuerdo con consultas previas. En ningún caso es IANA quien decide y mucho menos con una consulta pública y sin I-D, ya que es el RFC el que lo indica formalmente (es decir, todos esos “números” han de aparecer especificados en el RFC que se publica).
>> 
>> Y no, el IAB no es la entidad que se ocupa de esto, el IAB es solo arquitectura, seguramente pensabas en el IESG. Aún así, ni siquiera es el IESG quien define esos “números”, sino que es el autor o editor del documento, consensuado a través del WG que corresponda. El IESG hace una revisión y puede recomendar cambios al WG. El IESG puede incluso “exigir" cambios en un documento para aprobarlo, pero generalmente salvo que haya buenas razones que el WG no haya visto durante el debate del documento, se publicará con los “números” definidos por el WG. Hay que tener en cuenta que durante las discusiones de los documentos, los Area Director's (que forman el IESG) participan en el trabajo del WG, así que generalmente cuestiones graves ya han sido resueltas antes de llegar a consenso (y por tanto al Last Call y al IESG) - aunque obviamente puede haber cosas que salten en esa última revisión al ser mas transversal en lugar de solo un área concreta el IETF.
>> 
>> Por ponerte un ejemplo mas claro, es el WG el que define que prefijos en IPv6 son global unicast, link local, loopback, mapped addresses, etc., etc., no el IAB, no el IESG, no IANA, no ICANN, no los RIRs. Es decir, todos esos números son “parte” y por tanto “propiedad” (en su definición, para que se entienda bien mi afirmación) cuando hablamos de estándares, de los propios estándares o protocolos.
>> 
>> Es el IETF quien delega la gestión “pública” de los “números” a IANA, especialmente por el tema de ASN y direcciones (que requieren una estructura formal para “volcarlos" a los RIRs - en sus orígenes el IETF no tenía estructura administrativa - ahora se podría cambiar porque existe el LLC y tiene empleados), porque lo demás, es mera “publicación” en los registros de IANA de “resúmenes” de “números” que, insisto, definimos en IETF a través de RFCs.
>> 
>> Estoy 100% seguro que ha sido un error por parte de IANA/ICANN y no mal intencionado, no me cabe ninguna duda, pero es muy grave una metedura de pata de este tipo de IANA, porque saltarse los procedimientos 100% perfectamente definidos de cualquier organización, es muy grave (y a ojos de terceros puede parecer malintencionado). De hecho, es curioso que hasta que alguien del IETF el día 29 no ha mencionado la consulta pública de IANA, y ha empezado la discusión en v6ops (aunque el tema de un I-D corresponde a 6man, pero se ha copiado a ambos), ICANN no ha escrito a v6ops (día 30) … eso ha sido 10 días después de la consulta pública iniciada el día 20. Creo que en ICANN se dieron cuenta que en lugar de una consulta pública en ICANN, correspondía verlo con 6man/v6ops (como digo 10 días después), por la propia discusión en v6ops y por eso enviaron el email. De no haber sido por eso, quizás se hubiera acabado la consulta pública y se hubiera registrado igual que paso con el IPv4 sin un RFC.
>> 
>> Ten en cuenta que si no hay un RFC, los fabricantes no lo implementan. Puede que funcione de casualidad (creo que es el caso de IPv4), pero puede generar problemas y falta de interoperabilidad.
>> 
>> De hecho, y precisamente en coordinación con IANA (en este caso si han seguido los procedimientos y han revisado mi version anterior del documento), esta noche o mañana publicaré una nueva versión (v03, no puedo hacerlo hasta el día 1 por el cut-off debido al meeting de la próxima semana) de https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc6146-bis/ en el que estoy trabajando para que el RFC6146 de NAT64 (y otros muchos protocolos relacionados) pase a ser un STD, y he incorporado una sección para IANA, concretamente:
>> 
>> 6.  IANA Considerations
>> 
>>    All references to [RFC6146] in the following registry groups should
>>    be replaced with references to this document:
>> 
>>    *  Service Function Chaining Service Function Types.
>>       https://www.iana.org/assignments/service-function-chaining-
>>       service-function-types/service-function-chaining-service-function-
>>       types.xhtml.
>> 
>>    *  IP Flow Information Export (IPFIX) Entities.
>>       https://www.iana.org/assignments/ipfix/ipfix.xhtml.
>> 
>> Como ves, como autor/editor, instruyo a IANA acerca de los cambios a realizar en sus registros (si alcanza consenso en el WG, y pasa todo el proceso, obviamente). Sin ese texto IANA no podría hacer esos cambios.
>> 
>> Saludos,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>>> El 31 oct 2025, a las 16:36, Nicolas Antoniello <nantoniello en gmail.com <mailto:nantoniello en gmail.com>> escribió:
>>> 
>>> Hola Jordi,
>>> 
>>> Según entiendo, en el caso del 127..53.53 no hay una formalización (ni IANA ni IETF) hicieron nada al respecto pues ese prefijo se eligió (supongo que por quienes propusieron el draft en su momento) dentro de un rango que ya está reservado por quien ejecuta las funciones de la IANA para localhost.
>>> 
>>> En este caso entiendo que lo mismo sucede con este nuevo prefijo pues estaría dentro de un rango que ya está reservado para link local unicast en IPv6 no? Entonces sería algo similar al anterior.
>>> 
>>> La discusión de si es o no el prefijo más indicado queda por fuera de eso y a esta altura creo que ya reviste cierto grado de fundamentalismo innecesario… pero si para IPv4 se hizo de esa manera y no veo por qué debería ser diferente ahora.
>>> 
>>> Y en lo que respecta a reserva formal de direcciones o cualquier valor de protocolo, hasta donde se es IANA la que en general decide… lo que sucede es que por lo general se acepta la propuesta del autor del draft, si no hay objeciones técnicas claro está. Y creo que eso es lo que siempre ha sucedido.
>>> 
>>> Sobre tu afirmación de que (y citó): “el IETF es el “propietario” de las direcciones IP, protocolos, etc.” allí creo que te equivocas, la IETF tiene atribuciones de estandarización que son supervisadas por el IAB (aparte de que el IAB también asesora técnicamente al IETF). La coordinación del espacio de direcciones y números de protocolo a nivel global (igual que los ASN y la raíz del DNS) recae en quien ejecuta las funciones de la IANA, que desde 1998 es ICANN. Y bueno, para las direcciones IP (entre otros) la coordinación y gestión del espacio delgado por ICANN a nivel regional recae en cada uno de los 5 registros regionales.
>>> 
>>> Fraterno saludos,
>>> Nico
>>> 
>>> 
>>> 
>>> El El jue, oct 30, 2025 a la(s) 17:05, jordi.palet--- vía LACNOG <lacnog en lacnic.net <mailto:lacnog en lacnic.net>> escribió:
>>>> Hola Hugo,
>>>> 
>>>> Mala idea … ya lo hemos discutido en la lista de v6ops de IETF, ademas, por lo visto IANA se esta saltando sus atribuciones al pretender hacerlo sin contar con el IETF, pero ademas no parece que sea el prefijo mas adecuado.
>>>> 
>>>> El procedimiento es presentar un I-D en v6ops, que v6ops lo apruebe como WG item, pase el last call y lo apruebe el IESG.
>>>> 
>>>> Dicho de otro modo, IANA no puede definir esto sin contar con el IETF, que es el “propietario” de las direcciones, protocolos, etc., IANA solo es el gestor, pero no puede actuar por su cuenta.
>>>> 
>>>> (que conste que no es que lo diga yo, es la discusión que hemos tenido en IETF)
>>>> 
>>>> Así que las opiniones al respecto deberán ir a v6ops, pero solo una vez que se presente el I-D (lo puede presentar alguien de IANA, en eso no hay ninguna dificultad y creo que seria lo lógico).
>>>> 
>>>> De hecho, ha entrado la duda de si esa asignación de IPv4 fue correctamente realizada (y es la mas apropiada) o hay que retrocederla también.
>>>> 
>>>> Saludos,
>>>> Jordi
>>>> 
>>>> @jordipalet
>>>> 
>>>> 
>>>> 
>>>>> El 30 oct 2025, a las 20:43, Hugo Salgado <hsalgado en vulcano.cl <mailto:hsalgado en vulcano.cl>> escribió:
>>>>> 
>>>> 
>>>> 
>>>>> Hola a todos.
>>>>> Cuando aparece un nuevo TLD en la raíz del DNS, hay una etapa especial
>>>>> para evitar que aquellos nombres que eventualmente pudieran haberse
>>>>> estado usando en redes "privadas" tengan un aviso. Se le llama
>>>>> "interrupción controlada", donde el nuevo TLD debe responder en modo
>>>>> "wildcard" con una IP especial por algunos meses, para así dar una
>>>>> oportunidad a los administradores de esas redes para que cambien de
>>>>> nombres, antes que el TLD sea usado realmente con nombres de verdad.
>>>>> 
>>>>> Hasta el momento era solo IPv4, usando la IP 127.0.53.53, que está
>>>>> dentro del rango asignado para redes loopback (127.0.0.0/8 <http://127.0.0.0/8>). No se
>>>>> quiso usar directamente la 127.0.0.1, porque hay mayor riesgo que esa
>>>>> también se use para servicios locales.
>>>>> 
>>>>> Ahora ICANN hizo un estudio para agregar registros AAAA. El problema
>>>>> es que en IPv6 solo la ::1/128 es loopback, así que hay que decidir
>>>>> cuál usar. Hasta el momento gana la ::ffff:7f00:3535 (que también se
>>>>> puede representar como ::ffff:127.0.53.53). Han hecho pruebas en
>>>>> distintos OS y redes, y parece comportarse como loopback.
>>>>> 
>>>>> La idea es usar una IPv6 que no escape a la Internet pública, y que
>>>>> un administrador pueda averiguar qué está pasando haciendo una
>>>>> búsqueda por la IP en un buscador, y revisar logs para ver dónde se
>>>>> originan.
>>>>> 
>>>>> Si les parece una mala idea, acá está el lugar en el sitio de ICANN
>>>>> para dar su feedback:
>>>>> <https://www.icann.org/en/public-comment/proceeding/name-collision-ipv6-research-study-20-10-2025>
>>>>> abierto hasta el 22 de diciembre.
>>>>> 
>>>>> Saludos,
>>>>> 
>>>>> Hugo
>>>>> 
>>>>> 
>>>>> ps: y a los que estén armando sus redes privadas, por favor usen un
>>>>> subdominio de un nombre que tengan inscrito. Es la mejor opción. La
>>>>> segunda mejor opción es usar ".internal", que se va a reservar para
>>>>> eso.
>>>>> 
>>>>> 
>>>> 
>>>>> De: Francisco Arias <francisco.arias en icann.org <mailto:francisco.arias en icann.org>>
>>>>> Asunto: [dns-operations] Name Collision IPv6 Research Study - Public Comment
>>>>> Fecha: 30 de octubre de 2025, 18:13:42 CET
>>>>> Para: "dns-operations en dns-oarc.net <mailto:dns-operations en dns-oarc.net>" <dns-operations en dns-oarc.net <mailto:dns-operations en dns-oarc.net>>
>>>>> 
>>>>> 
>>>>> Dear colleagues,
>>>>>  
>>>>> ICANN has opened a public comment period on a research study titled "Controlled Interruption IPv6 Research Study". The study focuses on extending ICANN's "controlled interruption" mechanism, previously implemented using only the IPv4 address 127.0.53.53 into the IPv6 realm, given the growing adoption of IPv6 (> 40 % of hosts). The public comment period runs from 20 October 2025 to 22 December 2025: https://www.icann.org/en/public-comment/proceeding/name-collision-ipv6-research-study-20-10-2025
>>>>>  
>>>>> Controlled interruption is a phase in the establishment of a new generic top-level domain (gTLD) that is designed to reduce the risk of name collision. During controlled interruption, certain DNS resource records, designed to interrupt resolution processes, are temporarily published at and below the gTLD name. The content of these DNS records is intended to minimize any harm that arises from such interruption.
>>>>>  
>>>>> This study produces an initial list of candidate prefixes, followed by technical tests of multiple applications on popular end-user operating systems. The aim was to identify candidate addresses where DNS lookups returning that address did not result in any unintended external network traffic. A preferred candidate that met these criteria was identified: ffff:127.0.53.53, which is the IPV6 mapping of the original IPv4 controlled interruption address.
>>>>>  
>>>>> This mailing list is being alerted to request input on this topic. While there will undoubtedly be valuable discussions on this list around various aspects of this proposal, ICANN requests that specific feedback (from individuals or the group as a whole) is ultimately provided directly into the public comment website.
>>>>>  
>>>>> -- 
>>>>> Francisco.
>>>>>  
>>>>> _______________________________________________
>>>>> dns-operations mailing list
>>>>> dns-operations en lists.dns-oarc.net <mailto:dns-operations en lists.dns-oarc.net>
>>>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> LACNOG mailing list
>>>>> LACNOG en lacnic.net <mailto: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 <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 <mailto: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 <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 <mailto: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.

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20251031/d75deebd/attachment-0001.htm>