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

[Nicolas Antoniello]

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> 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> 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). 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>
> *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" <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
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>
> _______________________________________________
> 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/20251031/fddb5f07/attachment-0001.htm>