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

Vie Oct 31 14:51:15 -03 2025

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> 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>
> 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> 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
>>
>
>
> **********************************************
> 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/343d6206/attachment-0001.htm>