<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML con formato previo Car";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLconformatoprevioCar
{mso-style-name:"HTML con formato previo Car";
mso-style-priority:99;
mso-style-link:"HTML con formato previo";
font-family:"Consolas",serif;}
span.EstiloCorreo21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:70.85pt 85.05pt 70.85pt 85.05pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=ES-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='mso-fareast-language:EN-US'>Esto es más o menos equivalente a los que arman redes IPv4, le ponen como direccionamiento LAN las IP que les gusta (sin respetar la conocida RFC1918 y sus actualizaciones), y conectan sus redes a Internet. O también, proveedores que usan direccionamiento privado de la RFC1918 para brindar servicios públicos. Aun hay algunos casos por ahí…<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>Saludos,<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>Jorge<o:p></o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span lang=EN-US style='font-size:12.0pt;color:black'>De: </span></b><span lang=EN-US style='font-size:12.0pt;color:black'>LACNOG <lacnog-bounces@lacnic.net> en nombre de Carlos Martinez - Cagnazzo <carlos@cagnazzo.uy><br><b>Responder a: </b>Latin America and Caribbean Region Network Operators Group <lacnog@lacnic.net><br><b>Fecha: </b>martes, 4 de noviembre de 2025, 7:50 a.m.<br><b>Para: </b>Latin America and Caribbean Region Network Operators Group <lacnog@lacnic.net>, Hugo Salgado <hsalgado@vulcano.cl><br><b>Asunto: </b>Re: [lacnog] [dns-operations] Name Collision IPv6 Research Study - Public Comment<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><p>Me abrazo con los dos brazos de la recomendación de Hugo:<o:p></o:p></p><p>--> Si operan una red que tenga mas de un par de maquinas y usan DNS, inviertan en un dominio. Hay dominios muy baratos (no voy a hacer publicidad gratis aca, pero estan a un Google de distancia). <o:p></o:p></p><p>Nos lo van a agradecer :-)<o:p></o:p></p><div><p class=MsoNormal>On 4/11/25 12:34 AM, Hugo Salgado wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Hola Tomás.<o:p></o:p></pre><pre>Es muy difícil saber cuántos administradores de redes usan TLDs no<o:p></o:p></pre><pre>delegados. Principalmente porque, por diseño, esos nombres no salen a<o:p></o:p></pre><pre>la Internet pública! Así que solo podemos darnos cuenta de los que sí<o:p></o:p></pre><pre>"se filtran" (típicamente porque configuraron mal sus resolvers<o:p></o:p></pre><pre>internos, o porque un empleado en el café se le olvidó activar la<o:p></o:p></pre><pre>VPN) y hacer análisis de tráfico en los root servers.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Existen monitoreos continuos, como el ITIH de ICANN, que hace un ranking<o:p></o:p></pre><pre>de los que más aparecen:<o:p></o:p></pre><pre> HOME<o:p></o:p></pre><pre> LAN<o:p></o:p></pre><pre> CORP<o:p></o:p></pre><pre> SVC<o:p></o:p></pre><pre> DYNATRACE<o:p></o:p></pre><pre> GEOTAB<o:p></o:p></pre><pre> INTERNAL<o:p></o:p></pre><pre> OPENSTACKLOCAL<o:p></o:p></pre><pre> LOCALDOMAIN<o:p></o:p></pre><pre> ...<o:p></o:p></pre><pre>y así miles más. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Ahora la razón por qué lo usan... en un estudio hicieron una "etiología"<o:p></o:p></pre><pre>de las colisiones, analizando 1388 casos, y llegaron a:<o:p></o:p></pre><pre> Uso intencional dentro de una red (nombre/marca/acronismo) : 32%<o:p></o:p></pre><pre> Otro/desconocido : 30%<o:p></o:p></pre><pre> Sufijo puesto por el ISP : 16%<o:p></o:p></pre><pre> Uso intencional dentro de una red (concepto/no-marca) : 14%<o:p></o:p></pre><pre> Uso interno no-intencional (otro/desconocido) : 7%<o:p></o:p></pre><pre> Uso interno no-intencional (fuga de 2LD) : 1%<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>Cuando se lanzaron los primeros gTLDs, allá por el 2014, ICANN tenía<o:p></o:p></pre><pre>una página para reportar problemas. Tuvieron del orden de 120 casos<o:p></o:p></pre><pre>anuales los primeros 3 años, incluído 1 caso donde una "organización<o:p></o:p></pre><pre>grande" reportó problemas "graves" al día siguiente de activar uno de<o:p></o:p></pre><pre>los TLDs. El registro en ese caso suspendió la "interrupción controlada"<o:p></o:p></pre><pre>por unos días hasta que la empresa solucionó el problema. Pero después<o:p></o:p></pre><pre>de eso los reportes fueron casi cero. Igual estos casos son<o:p></o:p></pre><pre>anecdóticos, quizás cuántos más nunca se supo. O cuántos siguen<o:p></o:p></pre><pre>colisionando y nadie se ha dado cuenta!<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Por eso la recomendación es siempre usar un subdominio de un nombre<o:p></o:p></pre><pre>sobre el cual tengan control. Si tienen inscrito "empresa.com",<o:p></o:p></pre><pre>entonces usen "intranet.empresa.com", o algo así. Usando split-view<o:p></o:p></pre><pre>pueden bloquear la resolución hacia afuera, y responder solo a la<o:p></o:p></pre><pre>red interna.<o:p></o:p></pre><pre> <o:p></o:p></pre><pre>Saludos,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Hugo<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>On 14:04 02/11, Nicolas Antoniello wrote:<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Hola Tomás,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Sin perjuicio de lo que aportó Hugo y para sumar.<o:p></o:p></pre><pre>Una cosa que muchas veces sucede es que los administradores de redes crean<o:p></o:p></pre><pre>dominios para uso interno de la organización (dominios privados). Por<o:p></o:p></pre><pre>ejemplo me creo un dominio “administración” para la gente de administración<o:p></o:p></pre><pre>en un sistema interno privado (no se, por ejemplo un active directory)…<o:p></o:p></pre><pre>tiempo después, como consecuencia de la nueva ronda de creación de TLDs,<o:p></o:p></pre><pre>supongamos que se termina creando el TLD “administración” (que ahora sería<o:p></o:p></pre><pre>un gTLD).<o:p></o:p></pre><pre>Entonces ahora, ese “dominio” que para esa organización era privado va a<o:p></o:p></pre><pre>“colisionar” con todos los intentos por resolver cualquier subdominio del<o:p></o:p></pre><pre>nuevo gTLD… para detectar esas colisiones es que se desarrolló ese<o:p></o:p></pre><pre>mecanismo llamado interrupción controlada que es provisorio justamente para<o:p></o:p></pre><pre>que quienes tengan esos casos de dominio los detecten y resuelvan para que<o:p></o:p></pre><pre>no existan más esas colisiones.<o:p></o:p></pre><pre>La solución que plantea hugo, es siempre utilizar subdominios (aunque sean<o:p></o:p></pre><pre>para uso privado) pues al ser sub dominios de de uno público registrado, no<o:p></o:p></pre><pre>van a colisionar.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Las estadísticas no las tengo, tal vez hugo tiene más info sobre eso.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Saludos,<o:p></o:p></pre><pre>Nico<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>El El dom, nov 2, 2025 a la(s) 12:19, Tomas Lynch <a href="mailto:tomas.lynch@gmail.com"><tomas.lynch@gmail.com></a><o:p></o:p></pre><pre>escribió:<o:p></o:p></pre><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Nuevamente una conversación técnica muy interesante se fué por la tangente<o:p></o:p></pre><pre>gracias a una discusión intransigente sobre procedimientos de lo qué hace o<o:p></o:p></pre><pre>no hace el (IETF|ICANN|IANA|mi abuela).<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>La verdad es que no tengo opinión sobre el correo original de Hugo,<o:p></o:p></pre><pre>experto en el tema de DNS, donde se propone el uso de " ::ffff:7f00:3535<o:p></o:p></pre><pre>(que también se puede representar como ::ffff:127.0.53.53)". Pero sería<o:p></o:p></pre><pre>bueno que si alguien sigue leyendo este hilo de correos, separe la paja del<o:p></o:p></pre><pre>trigo (y hay mucha paja), y dé su opinión al respecto ya que son<o:p></o:p></pre><pre>temas TÉCNICOS muy interesantes.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Lo que me llama la atención es la postdata de Hugo que indica que "y a los<o:p></o:p></pre><pre>que estén armando sus redes privadas, por favor usen un subdominio de un<o:p></o:p></pre><pre>nombre que tengan inscrito." Mi pregunta Hugo es, ¿cuántos<o:p></o:p></pre><pre>administradores de redes han descubierto que están utilizando TLDs que<o:p></o:p></pre><pre>pasan a estar publicados? ¿cuál es el motivo por el que alguien llega a<o:p></o:p></pre><pre>utilizar un TLD que no sea los ya conocidos? Ojo, no dudo de que el sistema<o:p></o:p></pre><pre>de interrupción controlada sea efectivo y útil, mi pregunta va por el lado<o:p></o:p></pre><pre>de conocer cuántas personas asignan ".botarate" o ".pagafantas" a sus redes<o:p></o:p></pre><pre>en lugar de $mi_dominio.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Saludos,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Tomás Lynch<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>On Fri, Oct 31, 2025 at 3:57<span style='font-family:"Cambria Math",serif'> </span>PM jordi.palet--- vía LACNOG <a href="mailto:lacnog@lacnic.net"><<o:p></o:p></a></pre><pre><span class=MsoHyperlink><a href="mailto:lacnog@lacnic.net">lacnog@lacnic.net></a><span style='color:windowtext;text-decoration:none'> wrote:</span></span><o:p></o:p></pre><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Hola Nico,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Precisamente insistí doblemente en que tenia bien claro que no había sido<o:p></o:p></pre><pre>mala fe, pero eso no evita que piense que es un grave error (eso si que<o:p></o:p></pre><pre>obviamente es mi opinión personal) y que lo correcto es llevarlo por el<o:p></o:p></pre><pre>camino que indican los procedimientos que todos hemos aceptado y preparar<o:p></o:p></pre><pre>un I-D tanto para el prefijo IPv4 como para el IPv6, porque el IPv4 no esta<o:p></o:p></pre><pre>correctamente registrado, no es estándar y puede generar problemas de<o:p></o:p></pre><pre>interoperabilidad, puede no funcionar (no estar implementado tal y como se<o:p></o:p></pre><pre>necesite para esta función), etc.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Fíjate que no entré en ningún momento en el debate de si esos prefijos<o:p></o:p></pre><pre>son o no los mejores (aunque personalmente opino como otros en v6ops que no<o:p></o:p></pre><pre>lo son). Mi "mala idea” no era respecto a esos prefijos sino al hecho de<o:p></o:p></pre><pre>como se estaba procediendo con este tema. Creo que si se lee el primer<o:p></o:p></pre><pre>párrafo completo de ese primer correo mio, no hay duda, y esa parte no es<o:p></o:p></pre><pre>una opinion, es decir “el procedimiento es otro” (información, no opinión).<o:p></o:p></pre><pre>Por mas que releo el resto de ese correo, no veo mi opinion, sino<o:p></o:p></pre><pre>información de como debe hacerse.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Pero igualmente concurro, que por mucho que parezca que peleamos, estos<o:p></o:p></pre><pre>debates deben ser siempre considerados por la parte constructiva, igual<o:p></o:p></pre><pre>sean informaciones u opiniones (sin confundir unas con otras).<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Saludos,<o:p></o:p></pre><pre>Jordi<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>@jordipalet<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>El 31 oct 2025, a las 20:27, Nicolas Antoniello <a href="mailto:nantoniello@gmail.com"><nantoniello@gmail.com></a><o:p></o:p></pre><pre>escribió:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Jordi,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Claro, lo que yo creo (al igual que mencionas en tu correo) es que los<o:p></o:p></pre><pre>estándares y todo el intercambio que se produce en torno a ello es<o:p></o:p></pre><pre>justamente producto de esas discusiones, en el buen sentido.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Lo que también creo es que tal vez debemos ser un poco más abiertos en el<o:p></o:p></pre><pre>sentido de no pensar que se trata de alguna cosa mal intencionada o a<o:p></o:p></pre><pre>propósito. Yo creo que todos buscamos el resolver esos problemas que van<o:p></o:p></pre><pre>surgiendo, de la mejor manera y a veces algunos van o vamos a pensar que<o:p></o:p></pre><pre>las cosas se deberían hacer de otra manera. Y eso está bien.<o:p></o:p></pre><pre>También creo que justamente no aporta al debate el estar interpretando o<o:p></o:p></pre><pre>agravando la intención del otro cuando realmente lo que aporta es<o:p></o:p></pre><pre>justamente el argumentar por qué a mí me parece que tal o cual solución es<o:p></o:p></pre><pre>mejor.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Yo creo que lo que aporta más es justamente hacer las argumentaciones<o:p></o:p></pre><pre>técnicas de por qué es una mala o buena idea usar tal o cual prefijo (más<o:p></o:p></pre><pre>aún si hay algún error en algún texto) ya que eso va a ser considerado y<o:p></o:p></pre><pre>rectificado si así lo decide la comunidad, como creo que siempre ha sido.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Leyendo tu correo en respuesta al de Hugo, yo interpreto que si<o:p></o:p></pre><pre>comenzaste y continuaste dando tu opinión además de contar algunos hechos y<o:p></o:p></pre><pre>por eso di la mía.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Justamente creo que es bueno expresar tu visión técnica de por qué crees<o:p></o:p></pre><pre>que no es una buena opción y cuál sería para ti una buena opción, y el<o:p></o:p></pre><pre>procedimiento que entiendes se debe seguir para el proceso. Por otro lado<o:p></o:p></pre><pre>no creo que aporte el exponerlo en modo defensivo “recordando”<o:p></o:p></pre><pre>procedimientos o marcando supuestos errores cuando todo esto creo que busca<o:p></o:p></pre><pre>ser un debate constructivo.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Fraterno saludo,<o:p></o:p></pre><pre>Nico<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>El El vie, oct 31, 2025 a la(s) 15:57, jordi.palet--- vía LACNOG <a href="mailto:lacnog@lacnic.net"><<o:p></o:p></a></pre><pre><span class=MsoHyperlink><a href="mailto:lacnog@lacnic.net">lacnog@lacnic.net></a><span style='color:windowtext;text-decoration:none'> escribió:</span></span><o:p></o:p></pre><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Hola Nico,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Para que no haya dudas, no he dicho “yo" que se haya apropiado de esa<o:p></o:p></pre><pre>dirección, solo he reproducido lo antes han dicho otros (puse el enlace en<o:p></o:p></pre><pre>el correo anterior) porque no hay un RFC que lo indique, luego es<o:p></o:p></pre><pre>inapropiado, porque es un uso sin un estándar que lo indique. Si hay un RFC<o:p></o:p></pre><pre>entonces lo ha especificado IETF, sino es un uso inapropiado, fuera de<o:p></o:p></pre><pre>estándares, un I-D podría cambiarlo, establecerlo o eliminarlo, pero parece<o:p></o:p></pre><pre>que no lo hay. NO es mi opinión, es que no hay un RFC.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>De hecho, todos los números reflejados en paginas de IANA indican el RFC<o:p></o:p></pre><pre>que los asigna. No es una opinion, es lo que indican los procedimientos, es<o:p></o:p></pre><pre>como se hace siempre. Es la relación que hay entre IETF e ICANN/IANA.<o:p></o:p></pre><pre>Ejemplo:<o:p></o:p></pre><pre><a href="https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml">https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>Insisto en que hablo de “propiedad” dentro de los estándares, ese ese<o:p></o:p></pre><pre>*contexto*. Los estándares son propiedad del IETF y los números lo son *en<o:p></o:p></pre><pre>ese contexto*. Son estándares abiertos, pero con un propietario (el Trust<o:p></o:p></pre><pre>del IETF). IETF delega en IANA su gestión, pero no su definición. No es mi<o:p></o:p></pre><pre>opinión, es lo que esta establecido legalmente. Los estándares incluyen<o:p></o:p></pre><pre>números y en *ese contexto* la propiedad de todo ello es del IETF Trust, se<o:p></o:p></pre><pre>constituyó en el 2016 si no mal recuerdo, para tener formalidad en todo<o:p></o:p></pre><pre>ello. Es propietario, no solo de estándares sino incluso de los dominios<o:p></o:p></pre><pre>que usa IANA. Es información, no opinion mía. Insisto que no hablo de<o:p></o:p></pre><pre>propiedad de números (que no son de nadie) sino de protocolos y en ese<o:p></o:p></pre><pre>contexto los “números” que conllevan con de ese protocolo (asociados a su<o:p></o:p></pre><pre>uso).<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>La dirección que se esta proponiendo por parte de ICANN<o:p></o:p></pre><pre>es ::ffff:7f00:3535 (que es lo mismo que ::ffff:127.0.53.53), no es<o:p></o:p></pre><pre>link-local. Son direcciones IPv4-mapped (RFC4291), que se usan para<o:p></o:p></pre><pre>mecanismos de transición, y que no pueden aparecer en las comunicaciones<o:p></o:p></pre><pre>(“on the wire”). Es mala idea, muy mala. En la consulta publica esta mal<o:p></o:p></pre><pre>puesto (ffff::127.0.53.53), en los docs esta bien.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Menciono a cada organización o función, aun sabiendo que son las mismas,<o:p></o:p></pre><pre>para que no haya duda, pero lo tengo bien claro.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Quien ha hecho la consulta publica es ICANN/IANA, no se si el estudio<o:p></o:p></pre><pre>previo ha sido algo que ha encargado ICANN/IANA o no, pero es irrelevante,<o:p></o:p></pre><pre>la cuestión es hacer una consulta pública en lugar de discutirlo en IETF<o:p></o:p></pre><pre>con un I-D, ignorando los procedimientos. Es información, no opinión. Aun<o:p></o:p></pre><pre>así me extraña que este informe no haya sido promovido por ICANN/IANA,<o:p></o:p></pre><pre>seguramente seré fácil confirmarlo.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Si revisas mi primer email, era solo para informar de la realidad porque<o:p></o:p></pre><pre>no sabia si Hugo había visto solo la consulta pública o también la<o:p></o:p></pre><pre>discusión en v6ops, que insisto, es donde tiene que estar y una vez se<o:p></o:p></pre><pre>presente un I-D, no antes, no en una consulta publica de nadie mas. Te<o:p></o:p></pre><pre>conteste para aclarar tu correo, pero parece que ha sido peor, y que<o:p></o:p></pre><pre>consideras que estoy dando opiniones en lugar de información. Creo que no<o:p></o:p></pre><pre>tiene sentido seguir con ello. Quien participa en IETF y sigue el Trust,<o:p></o:p></pre><pre>LLC, y todos los temas no solo técnicos, sino tb administrativos, lo sabe<o:p></o:p></pre><pre>bien, y se ve bien claro en la discusión de v6ops, no por mi, sino por lo<o:p></o:p></pre><pre>que confirman los demás.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>Y para finalizar, si revisas los comentarios que se han hecho a la<o:p></o:p></pre><pre>consulta pública de ICANN veras información (no opiniones mias) como:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This proposal should be submitted as an Internet Draft, as that is the<o:p></o:p></pre><pre>way that the IETF deal with any and all proposals, including the assigning<o:p></o:p></pre><pre>IPv4 and IPv6 addresses with special purposes.<o:p></o:p></pre><pre><a href="https://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-prefix/04/">https://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-prefix/04/</a><o:p></o:p></pre><pre>is an example of such a proposal.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>The use of any loopback addresses, either IPv4, IPv6, or IPv4 loopback<o:p></o:p></pre><pre>addresses embedded in an IPv6 address is not appropriate for this purpose.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>The use of 127.0.53.53 for this purpose is unofficial, as there was<o:p></o:p></pre><pre>never any IETF review or assignment of that address for this purpose in the<o:p></o:p></pre><pre>IANA IPv4 Special-Purpose Address Space registry.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>The use of 127.0.0.0/8 prevents a useful reverse name that would<o:p></o:p></pre><pre>explain what is going on. Some PTR like possible-future-tld.icann.org<o:p></o:p></pre><pre>would help users of that "string" to understand what is going on.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>(copia y pega de lo mas relevante, todo seguido)<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>La conclusión de esta discusión es que, y no había pensado antes<o:p></o:p></pre><pre>hacerlo, hay que ser mas critico con este consulta y recordarle los<o:p></o:p></pre><pre>procedimientos y que no puede hacerlo unilateralmente como así lo ha hecho.<o:p></o:p></pre><pre>Así que ahora responderé yo también.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>Saludos,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Jordi<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>El 31 oct 2025, a las 18:51, Nicolas Antoniello <a href="mailto:nantoniello@gmail.com"><nantoniello@gmail.com></a><o:p></o:p></pre><pre>escribió:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Hola Jordi,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Creo que estás errado en muchas de tus afirmaciones en ese email… pero<o:p></o:p></pre><pre>bueno, no me voy a poner a debatirlo todo porque es mucho lo que escribiste:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Algunos de esos errores que creo que estás cometiendo:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>* IANA no se apropió de nada pues ni siquiera fue IANA que sugirió la<o:p></o:p></pre><pre>dirección.<o:p></o:p></pre><pre>* No, te vuelvo a repetir que la IETF no es dueña de las IPs ni de los<o:p></o:p></pre><pre>números de protocolos.<o:p></o:p></pre><pre>* Hasta donde sé, el fe80::/10 es Link Local Unicast para IPv6 no?<o:p></o:p></pre><pre>* Cuando decís “no IANA”, “no ICANN” pareciera que son 2 organizaciones<o:p></o:p></pre><pre>diferentes, IANA es una función y ICANN es quien la ejecuta… a los efectos<o:p></o:p></pre><pre>prácticos son lo mismo.<o:p></o:p></pre><pre>* Nuevamente estas “agravando” algo que no tiene nada de grave… te<o:p></o:p></pre><pre>repito una vez más que la sugerencia esa ni siquiera fue de alguien de IANA<o:p></o:p></pre><pre>(cómo vos decís), ni para IPv4 ni para IPv6.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>* Siempre haces afirmaciones unilaterales cómo si las cosas fueran cómo<o:p></o:p></pre><pre>tú quieres que sean Jordi, y las cosas son cómo son, producto de los<o:p></o:p></pre><pre>debates. Una vez más (por si no lo puse en claro hasta ahora) creo que<o:p></o:p></pre><pre>haces un montón de afirmaciones y explicaciones que están equivocadas y que<o:p></o:p></pre><pre>son TU punto de vista y que en consecuencia pueden confundir o llevar a<o:p></o:p></pre><pre>errores a algunos miembros de esta y otras listas. Una cosa es dar nuestra<o:p></o:p></pre><pre>opinión y otra muy diferente es afirmar todo cómo si tuviésemos la razón<o:p></o:p></pre><pre>cuando en numerosas ovaciones no la tenemos.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Fraterno saludo,<o:p></o:p></pre><pre>Nico<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>El El vie, oct 31, 2025 a la(s) 14:04, jordi.palet--- vía LACNOG <a href="mailto:lacnog@lacnic.net"><<o:p></o:p></a></pre><pre><span class=MsoHyperlink><a href="mailto:lacnog@lacnic.net">lacnog@lacnic.net></a><span style='color:windowtext;text-decoration:none'> escribió:</span></span><o:p></o:p></pre><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Hola Nico,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Efectivamente, IANA parece que se “apropio” indebidamente de esa<o:p></o:p></pre><pre>dirección en el caso de IPv4 (y seguramente no nos dimos cuenta en IETF en<o:p></o:p></pre><pre>ese momento o no se le dio la debida importancia, habría que ver si hubo<o:p></o:p></pre><pre>una consulta, pero por lo visto no<o:p></o:p></pre><pre><a href="https://mailarchive.ietf.org/arch/msg/v6ops/qgbtlp-pQo931maAD_Y_kdaaIlU/">https://mailarchive.ietf.org/arch/msg/v6ops/qgbtlp-pQo931maAD_Y_kdaaIlU/</a>).<o:p></o:p></pre><pre>Yo no recuerdo esa discusión, hablo por lo que han comentado otros, pero lo<o:p></o:p></pre><pre>prueba es que no hay un RFC que lo documente, y por tanto IANA no puede<o:p></o:p></pre><pre>hacer uso de ese prefijo.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Que se haya hecho contrariamente a las atribuciones de IANA<o:p></o:p></pre><pre>anteriormente, no cambia los procedimientos y evita que se sigan, no crees?<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Es como si ahora IANA decidiera hacer políticas para los RIRs por mucho<o:p></o:p></pre><pre>que haga una consulta a la comunidad, no tiene la atribución de hacer<o:p></o:p></pre><pre>políticas.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Por otro lado, no es un prefijo link local (mas bien seria una mapped<o:p></o:p></pre><pre>address “rara”) lo que esta sugiriendo a IANA, y desde luego no son<o:p></o:p></pre><pre>decisiones fundamentalistas si se usa uno u otro prefijo, hay muchas<o:p></o:p></pre><pre>implicaciones, tanto a nivel de soporte en implementaciones como a niveles<o:p></o:p></pre><pre>de mecanismos de transición, entre otros.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Creo que quien lo ha expresado mas claramente, ha sido Brian Carpenter<o:p></o:p></pre><pre>(ex-chair de IETF y creo que una voz que no es amiga de controversias),<o:p></o:p></pre><pre>pero que claramente ha dicho “lo siento señores de ICANN pero esto no es<o:p></o:p></pre><pre>algo a definir por ICANN sino por un proceso del IETF” (resumido y en<o:p></o:p></pre><pre>castellano):<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><a href="https://mailarchive.ietf.org/arch/msg/v6ops/B2GCyjHDYtSDPCI6UJOKcGc618s/">https://mailarchive.ietf.org/arch/msg/v6ops/B2GCyjHDYtSDPCI6UJOKcGc618s/</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre>(y ya lo habían comentado varios participantes reconocidos en emails<o:p></o:p></pre><pre>anteriores)<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Si se quiere seguir la discusión, no estando en la lista de v6ops (lo<o:p></o:p></pre><pre>ideal sería suscribirse y participar), los archivos son públicos en (casi<o:p></o:p></pre><pre>todos los correos desde el 29/10 hasta la fecha):<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><a href="https://mailarchive.ietf.org/arch/browse/v6ops/">https://mailarchive.ietf.org/arch/browse/v6ops/</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Mi afirmación es correcta en el contexto en el que estamos, habría que<o:p></o:p></pre><pre>remitirse a RFCs, pero te puedo garantizar que los protocolos incluyen la<o:p></o:p></pre><pre>definición de “números” (direcciones, puertos, registros, IDs, etc., etc.).<o:p></o:p></pre><pre>Los “números” no son propiedad de nadie (obviamente), pero si son propiedad<o:p></o:p></pre><pre>del IETF como parte de los estándares (en se contexto). El IETF siempre<o:p></o:p></pre><pre>define esos números de forma concreta solo y exclusivamente a través de un<o:p></o:p></pre><pre>Internet Draft, que puede llegar a ser un RFC si alcanza consenso, y en ese<o:p></o:p></pre><pre>documento se le dice a IANA que lo “refleje” formalmente en sus páginas<o:p></o:p></pre><pre>web, archivos, etc. Si el protocolo permite “libertad” para escoger ese<o:p></o:p></pre><pre>“número", a veces, se consulta o se deja a IANA seleccionarlo, pero se hace<o:p></o:p></pre><pre>de mutuo acuerdo con consultas previas. En ningún caso es IANA quien decide<o:p></o:p></pre><pre>y mucho menos con una consulta pública y sin I-D, ya que es el RFC el que<o:p></o:p></pre><pre>lo indica formalmente (es decir, todos esos “números” han de aparecer<o:p></o:p></pre><pre>especificados en el RFC que se publica).<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Y no, el IAB no es la entidad que se ocupa de esto, el IAB es solo<o:p></o:p></pre><pre>arquitectura, seguramente pensabas en el IESG. Aún así, ni siquiera es el<o:p></o:p></pre><pre>IESG quien define esos “números”, sino que es el autor o editor del<o:p></o:p></pre><pre>documento, consensuado a través del WG que corresponda. El IESG hace una<o:p></o:p></pre><pre>revisión y puede recomendar cambios al WG. El IESG puede incluso “exigir"<o:p></o:p></pre><pre>cambios en un documento para aprobarlo, pero generalmente salvo que haya<o:p></o:p></pre><pre>buenas razones que el WG no haya visto durante el debate del documento, se<o:p></o:p></pre><pre>publicará con los “números” definidos por el WG. Hay que tener en cuenta<o:p></o:p></pre><pre>que durante las discusiones de los documentos, los Area Director's (que<o:p></o:p></pre><pre>forman el IESG) participan en el trabajo del WG, así que generalmente<o:p></o:p></pre><pre>cuestiones graves ya han sido resueltas antes de llegar a consenso (y por<o:p></o:p></pre><pre>tanto al Last Call y al IESG) - aunque obviamente puede haber cosas que<o:p></o:p></pre><pre>salten en esa última revisión al ser mas transversal en lugar de solo un<o:p></o:p></pre><pre>área concreta el IETF.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Por ponerte un ejemplo mas claro, es el WG el que define que prefijos<o:p></o:p></pre><pre>en IPv6 son global unicast, link local, loopback, mapped addresses, etc.,<o:p></o:p></pre><pre>etc., no el IAB, no el IESG, no IANA, no ICANN, no los RIRs. Es decir,<o:p></o:p></pre><pre>todos esos números son “parte” y por tanto “propiedad” (en su definición,<o:p></o:p></pre><pre>para que se entienda bien mi afirmación) cuando hablamos de estándares, de<o:p></o:p></pre><pre>los propios estándares o protocolos.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Es el IETF quien delega la gestión “pública” de los “números” a IANA,<o:p></o:p></pre><pre>especialmente por el tema de ASN y direcciones (que requieren una<o:p></o:p></pre><pre>estructura formal para “volcarlos" a los RIRs - en sus orígenes el IETF no<o:p></o:p></pre><pre>tenía estructura administrativa - ahora se podría cambiar porque existe el<o:p></o:p></pre><pre>LLC y tiene empleados), porque lo demás, es mera “publicación” en los<o:p></o:p></pre><pre>registros de IANA de “resúmenes” de “números” que, insisto, definimos en<o:p></o:p></pre><pre>IETF a través de RFCs.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Estoy 100% seguro que ha sido un error por parte de IANA/ICANN y no mal<o:p></o:p></pre><pre>intencionado, no me cabe ninguna duda, pero es muy grave una metedura de<o:p></o:p></pre><pre>pata de este tipo de IANA, porque saltarse los procedimientos 100%<o:p></o:p></pre><pre>perfectamente definidos de cualquier organización, es muy grave (y a ojos<o:p></o:p></pre><pre>de terceros puede parecer malintencionado). De hecho, es curioso que hasta<o:p></o:p></pre><pre>que alguien del IETF el día 29 no ha mencionado la consulta pública de<o:p></o:p></pre><pre>IANA, y ha empezado la discusión en v6ops (aunque el tema de un I-D<o:p></o:p></pre><pre>corresponde a 6man, pero se ha copiado a ambos), ICANN no ha escrito a<o:p></o:p></pre><pre>v6ops (día 30) … eso ha sido 10 días después de la consulta pública<o:p></o:p></pre><pre>iniciada el día 20. Creo que en ICANN se dieron cuenta que en lugar de una<o:p></o:p></pre><pre>consulta pública en ICANN, correspondía verlo con 6man/v6ops (como digo 10<o:p></o:p></pre><pre>días después), por la propia discusión en v6ops y por eso enviaron el<o:p></o:p></pre><pre>email. De no haber sido por eso, quizás se hubiera acabado la consulta<o:p></o:p></pre><pre>pública y se hubiera registrado igual que paso con el IPv4 sin un RFC.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Ten en cuenta que si no hay un RFC, los fabricantes no lo implementan.<o:p></o:p></pre><pre>Puede que funcione de casualidad (creo que es el caso de IPv4), pero puede<o:p></o:p></pre><pre>generar problemas y falta de interoperabilidad.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>De hecho, y precisamente en coordinación con IANA (en este caso si han<o:p></o:p></pre><pre>seguido los procedimientos y han revisado mi version anterior del<o:p></o:p></pre><pre>documento), esta noche o mañana publicaré una nueva versión (v03, no puedo<o:p></o:p></pre><pre>hacerlo hasta el día 1 por el cut-off debido al meeting de la próxima<o:p></o:p></pre><pre>semana) de<o:p></o:p></pre><pre><a href="https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc6146-bis/">https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc6146-bis/</a> en el<o:p></o:p></pre><pre>que estoy trabajando para que el RFC6146 de NAT64 (y otros muchos<o:p></o:p></pre><pre>protocolos relacionados) pase a ser un STD, y he incorporado una sección<o:p></o:p></pre><pre>para IANA, concretamente:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>6. IANA Considerations<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> All references to [RFC6146] in the following registry groups should<o:p></o:p></pre><pre> be replaced with references to this document:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> * Service Function Chaining Service Function Types.<o:p></o:p></pre><pre> <a href="https://www.iana.org/assignments/service-function-chaining">https://www.iana.org/assignments/service-function-chaining</a>-<o:p></o:p></pre><pre> service-function-types/service-function-chaining-service-function-<o:p></o:p></pre><pre> types.xhtml.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> * IP Flow Information Export (IPFIX) Entities.<o:p></o:p></pre><pre> <a href="https://www.iana.org/assignments/ipfix/ipfix.xhtml">https://www.iana.org/assignments/ipfix/ipfix.xhtml</a>.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Como ves, como autor/editor, instruyo a IANA acerca de los cambios a<o:p></o:p></pre><pre>realizar en sus registros (si alcanza consenso en el WG, y pasa todo el<o:p></o:p></pre><pre>proceso, obviamente). Sin ese texto IANA no podría hacer esos cambios.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Saludos,<o:p></o:p></pre><pre>Jordi<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>@jordipalet<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>El 31 oct 2025, a las 16:36, Nicolas Antoniello <a href="mailto:nantoniello@gmail.com"><nantoniello@gmail.com></a><o:p></o:p></pre><pre>escribió:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Hola Jordi,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Según entiendo, en el caso del 127..53.53 no hay una formalización (ni<o:p></o:p></pre><pre>IANA ni IETF) hicieron nada al respecto pues ese prefijo se eligió (supongo<o:p></o:p></pre><pre>que por quienes propusieron el draft en su momento) dentro de un rango que<o:p></o:p></pre><pre>ya está reservado por quien ejecuta las funciones de la IANA para localhost.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>En este caso entiendo que lo mismo sucede con este nuevo prefijo pues<o:p></o:p></pre><pre>estaría dentro de un rango que ya está reservado para link local unicast en<o:p></o:p></pre><pre>IPv6 no? Entonces sería algo similar al anterior.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>La discusión de si es o no el prefijo más indicado queda por fuera de<o:p></o:p></pre><pre>eso y a esta altura creo que ya reviste cierto grado de fundamentalismo<o:p></o:p></pre><pre>innecesario… pero si para IPv4 se hizo de esa manera y no veo por qué<o:p></o:p></pre><pre>debería ser diferente ahora.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Y en lo que respecta a reserva formal de direcciones o cualquier valor<o:p></o:p></pre><pre>de protocolo, hasta donde se es IANA la que en general decide… lo que<o:p></o:p></pre><pre>sucede es que por lo general se acepta la propuesta del autor del draft, si<o:p></o:p></pre><pre>no hay objeciones técnicas claro está. Y creo que eso es lo que siempre ha<o:p></o:p></pre><pre>sucedido.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Sobre tu afirmación de que (y citó): “el IETF es el “propietario” de<o:p></o:p></pre><pre>las direcciones IP, protocolos, etc.” allí creo que te equivocas, la IETF<o:p></o:p></pre><pre>tiene atribuciones de estandarización que son supervisadas por el IAB<o:p></o:p></pre><pre>(aparte de que el IAB también asesora técnicamente al IETF). La<o:p></o:p></pre><pre>coordinación del espacio de direcciones y números de protocolo a nivel<o:p></o:p></pre><pre>global (igual que los ASN y la raíz del DNS) recae en quien ejecuta las<o:p></o:p></pre><pre>funciones de la IANA, que desde 1998 es ICANN. Y bueno, para las<o:p></o:p></pre><pre>direcciones IP (entre otros) la coordinación y gestión del espacio delgado<o:p></o:p></pre><pre>por ICANN a nivel regional recae en cada uno de los 5 registros regionales.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Fraterno saludos,<o:p></o:p></pre><pre>Nico<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>El El jue, oct 30, 2025 a la(s) 17:05, jordi.palet--- vía LACNOG <a href="mailto:lacnog@lacnic.net"><<o:p></o:p></a></pre><pre><span class=MsoHyperlink><a href="mailto:lacnog@lacnic.net">lacnog@lacnic.net></a><span style='color:windowtext;text-decoration:none'> escribió:</span></span><o:p></o:p></pre><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>Hola Hugo,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Mala idea … ya lo hemos discutido en la lista de v6ops de IETF,<o:p></o:p></pre><pre>ademas, por lo visto IANA se esta saltando sus atribuciones al pretender<o:p></o:p></pre><pre>hacerlo sin contar con el IETF, pero ademas no parece que sea el prefijo<o:p></o:p></pre><pre>mas adecuado.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>El procedimiento es presentar un I-D en v6ops, que v6ops lo apruebe<o:p></o:p></pre><pre>como WG item, pase el last call y lo apruebe el IESG.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Dicho de otro modo, IANA no puede definir esto sin contar con el IETF,<o:p></o:p></pre><pre>que es el “propietario” de las direcciones, protocolos, etc., IANA solo es<o:p></o:p></pre><pre>el gestor, pero no puede actuar por su cuenta.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>(que conste que no es que lo diga yo, es la discusión que hemos tenido<o:p></o:p></pre><pre>en IETF)<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Así que las opiniones al respecto deberán ir a v6ops, pero solo una<o:p></o:p></pre><pre>vez que se presente el I-D (lo puede presentar alguien de IANA, en eso no<o:p></o:p></pre><pre>hay ninguna dificultad y creo que seria lo lógico).<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>De hecho, ha entrado la duda de si esa asignación de IPv4 fue<o:p></o:p></pre><pre>correctamente realizada (y es la mas apropiada) o hay que retrocederla<o:p></o:p></pre><pre>también.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Saludos,<o:p></o:p></pre><pre>Jordi<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>@jordipalet<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>El 30 oct 2025, a las 20:43, Hugo Salgado <a href="mailto:hsalgado@vulcano.cl"><hsalgado@vulcano.cl></a><o:p></o:p></pre><pre>escribió:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Hola a todos.<o:p></o:p></pre><pre>Cuando aparece un nuevo TLD en la raíz del DNS, hay una etapa especial<o:p></o:p></pre><pre>para evitar que aquellos nombres que eventualmente pudieran haberse<o:p></o:p></pre><pre>estado usando en redes "privadas" tengan un aviso. Se le llama<o:p></o:p></pre><pre>"interrupción controlada", donde el nuevo TLD debe responder en modo<o:p></o:p></pre><pre>"wildcard" con una IP especial por algunos meses, para así dar una<o:p></o:p></pre><pre>oportunidad a los administradores de esas redes para que cambien de<o:p></o:p></pre><pre>nombres, antes que el TLD sea usado realmente con nombres de verdad.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Hasta el momento era solo IPv4, usando la IP 127.0.53.53, que está<o:p></o:p></pre><pre>dentro del rango asignado para redes loopback (127.0.0.0/8). No se<o:p></o:p></pre><pre>quiso usar directamente la 127.0.0.1, porque hay mayor riesgo que esa<o:p></o:p></pre><pre>también se use para servicios locales.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Ahora ICANN hizo un estudio para agregar registros AAAA. El problema<o:p></o:p></pre><pre>es que en IPv6 solo la ::1/128 es loopback, así que hay que decidir<o:p></o:p></pre><pre>cuál usar. Hasta el momento gana la ::ffff:7f00:3535 (que también se<o:p></o:p></pre><pre>puede representar como ::ffff:127.0.53.53). Han hecho pruebas en<o:p></o:p></pre><pre>distintos OS y redes, y parece comportarse como loopback.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>La idea es usar una IPv6 que no escape a la Internet pública, y que<o:p></o:p></pre><pre>un administrador pueda averiguar qué está pasando haciendo una<o:p></o:p></pre><pre>búsqueda por la IP en un buscador, y revisar logs para ver dónde se<o:p></o:p></pre><pre>originan.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Si les parece una mala idea, acá está el lugar en el sitio de ICANN<o:p></o:p></pre><pre>para dar su feedback:<o:p></o:p></pre><pre><<o:p> </o:p></pre><pre><a href="https://www.icann.org/en/public-comment/proceeding/name-collision-ipv6-research-study-20-10-2025">https://www.icann.org/en/public-comment/proceeding/name-collision-ipv6-research-study-20-10-2025</a><o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre><o:p> </o:p></pre></blockquote><pre>abierto hasta el 22 de diciembre.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Saludos,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Hugo<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>ps: y a los que estén armando sus redes privadas, por favor usen un<o:p></o:p></pre><pre>subdominio de un nombre que tengan inscrito. Es la mejor opción. La<o:p></o:p></pre><pre>segunda mejor opción es usar ".internal", que se va a reservar para<o:p></o:p></pre><pre>eso.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>*De: *Francisco Arias <a href="mailto:francisco.arias@icann.org"><francisco.arias@icann.org></a><o:p></o:p></pre><pre>*Asunto: **[dns-operations] Name Collision IPv6 Research Study -<o:p></o:p></pre><pre>Public Comment*<o:p></o:p></pre><pre>*Fecha: *30 de octubre de 2025, 18:13:42 CET<o:p></o:p></pre><pre>*Para: *<a href="mailto:dns-operations@dns-oarc.net">"dns-operations@dns-oarc.net"</a> <a href="mailto:dns-operations@dns-oarc.net"><dns-operations@dns-oarc.net></a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>Dear colleagues,<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>ICANN has opened a public comment period on a research study titled<o:p></o:p></pre><pre>"Controlled Interruption IPv6 Research Study". The study focuses on<o:p></o:p></pre><pre>extending ICANN's "controlled interruption" mechanism, previously<o:p></o:p></pre><pre>implemented using only the IPv4 address 127.0.53.53 into the IPv6 realm,<o:p></o:p></pre><pre>given the growing adoption of IPv6 (> 40 % of hosts). The public comment<o:p></o:p></pre><pre>period runs from 20 October 2025 to 22 December 2025:<o:p></o:p></pre><pre><a href="https://www.icann.org/en/public-comment/proceeding/name-collision-ipv6-research-study-20-10-2025">https://www.icann.org/en/public-comment/proceeding/name-collision-ipv6-research-study-20-10-2025</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Controlled interruption is a phase in the establishment of a new<o:p></o:p></pre><pre>generic top-level domain (gTLD) that is designed to reduce the risk of name<o:p></o:p></pre><pre>collision. During controlled interruption, certain DNS resource records,<o:p></o:p></pre><pre>designed to interrupt resolution processes, are temporarily published at<o:p></o:p></pre><pre>and below the gTLD name. The content of these DNS records is intended to<o:p></o:p></pre><pre>minimize any harm that arises from such interruption.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This study produces an initial list of candidate prefixes, followed by<o:p></o:p></pre><pre>technical tests of multiple applications on popular end-user operating<o:p></o:p></pre><pre>systems. The aim was to identify candidate addresses where DNS lookups<o:p></o:p></pre><pre>returning that address did not result in any unintended external network<o:p></o:p></pre><pre>traffic. A preferred candidate that met these criteria was identified:<o:p></o:p></pre><pre>ffff:127.0.53.53, which is the IPV6 mapping of the original IPv4 controlled<o:p></o:p></pre><pre>interruption address.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This mailing list is being alerted to request input on this topic.<o:p></o:p></pre><pre>While there will undoubtedly be valuable discussions on this list around<o:p></o:p></pre><pre>various aspects of this proposal, ICANN requests that specific feedback<o:p></o:p></pre><pre>(from individuals or the group as a whole) is ultimately provided directly<o:p></o:p></pre><pre>into the public comment website.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>--<o:p></o:p></pre><pre>Francisco.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>dns-operations mailing list<o:p></o:p></pre><pre><a href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a><o:p></o:p></pre><pre><a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>LACNOG mailing list<o:p></o:p></pre><pre><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><o:p></o:p></pre><pre><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><o:p></o:p></pre><pre>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>**********************************************<o:p></o:p></pre><pre>IPv4 is over<o:p></o:p></pre><pre>Are you ready for the new Internet ?<o:p></o:p></pre><pre><a href="http://www.theipv6company.com">http://www.theipv6company.com</a><o:p></o:p></pre><pre>The IPv6 Company<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This electronic message contains information which may be privileged<o:p></o:p></pre><pre>or confidential. The information is intended to be for the exclusive use of<o:p></o:p></pre><pre>the individual(s) named above and further non-explicilty authorized<o:p></o:p></pre><pre>disclosure, copying, distribution or use of the contents of this<o:p></o:p></pre><pre>information, even if partially, including attached files, is strictly<o:p></o:p></pre><pre>prohibited and will be considered a criminal offense. If you are not the<o:p></o:p></pre><pre>intended recipient be aware that any disclosure, copying, distribution or<o:p></o:p></pre><pre>use of the contents of this information, even if partially, including<o:p></o:p></pre><pre>attached files, is strictly prohibited, will be considered a criminal<o:p></o:p></pre><pre>offense, so you must reply to the original sender to inform about this<o:p></o:p></pre><pre>communication and delete it.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>LACNOG mailing list<o:p></o:p></pre><pre><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><o:p></o:p></pre><pre><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><o:p></o:p></pre><pre>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a><o:p></o:p></pre><pre><o:p> </o:p></pre></blockquote><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>**********************************************<o:p></o:p></pre><pre>IPv4 is over<o:p></o:p></pre><pre>Are you ready for the new Internet ?<o:p></o:p></pre><pre><a href="http://www.theipv6company.com">http://www.theipv6company.com</a><o:p></o:p></pre><pre>The IPv6 Company<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This electronic message contains information which may be privileged or<o:p></o:p></pre><pre>confidential. The information is intended to be for the exclusive use of<o:p></o:p></pre><pre>the individual(s) named above and further non-explicilty authorized<o:p></o:p></pre><pre>disclosure, copying, distribution or use of the contents of this<o:p></o:p></pre><pre>information, even if partially, including attached files, is strictly<o:p></o:p></pre><pre>prohibited and will be considered a criminal offense. If you are not the<o:p></o:p></pre><pre>intended recipient be aware that any disclosure, copying, distribution or<o:p></o:p></pre><pre>use of the contents of this information, even if partially, including<o:p></o:p></pre><pre>attached files, is strictly prohibited, will be considered a criminal<o:p></o:p></pre><pre>offense, so you must reply to the original sender to inform about this<o:p></o:p></pre><pre>communication and delete it.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>LACNOG mailing list<o:p></o:p></pre><pre><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><o:p></o:p></pre><pre><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><o:p></o:p></pre><pre>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a><o:p></o:p></pre><pre><o:p> </o:p></pre></blockquote><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>**********************************************<o:p></o:p></pre><pre>IPv4 is over<o:p></o:p></pre><pre>Are you ready for the new Internet ?<o:p></o:p></pre><pre><a href="http://www.theipv6company.com">http://www.theipv6company.com</a><o:p></o:p></pre><pre>The IPv6 Company<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This electronic message contains information which may be privileged or<o:p></o:p></pre><pre>confidential. The information is intended to be for the exclusive use of<o:p></o:p></pre><pre>the individual(s) named above and further non-explicilty authorized<o:p></o:p></pre><pre>disclosure, copying, distribution or use of the contents of this<o:p></o:p></pre><pre>information, even if partially, including attached files, is strictly<o:p></o:p></pre><pre>prohibited and will be considered a criminal offense. If you are not the<o:p></o:p></pre><pre>intended recipient be aware that any disclosure, copying, distribution or<o:p></o:p></pre><pre>use of the contents of this information, even if partially, including<o:p></o:p></pre><pre>attached files, is strictly prohibited, will be considered a criminal<o:p></o:p></pre><pre>offense, so you must reply to the original sender to inform about this<o:p></o:p></pre><pre>communication and delete it.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>LACNOG mailing list<o:p></o:p></pre><pre><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><o:p></o:p></pre><pre><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><o:p></o:p></pre><pre>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a><o:p></o:p></pre><pre><o:p> </o:p></pre></blockquote><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>**********************************************<o:p></o:p></pre><pre>IPv4 is over<o:p></o:p></pre><pre>Are you ready for the new Internet ?<o:p></o:p></pre><pre><a href="http://www.theipv6company.com">http://www.theipv6company.com</a><o:p></o:p></pre><pre>The IPv6 Company<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This electronic message contains information which may be privileged or<o:p></o:p></pre><pre>confidential. The information is intended to be for the exclusive use of<o:p></o:p></pre><pre>the individual(s) named above and further non-explicilty authorized<o:p></o:p></pre><pre>disclosure, copying, distribution or use of the contents of this<o:p></o:p></pre><pre>information, even if partially, including attached files, is strictly<o:p></o:p></pre><pre>prohibited and will be considered a criminal offense. If you are not the<o:p></o:p></pre><pre>intended recipient be aware that any disclosure, copying, distribution or<o:p></o:p></pre><pre>use of the contents of this information, even if partially, including<o:p></o:p></pre><pre>attached files, is strictly prohibited, will be considered a criminal<o:p></o:p></pre><pre>offense, so you must reply to the original sender to inform about this<o:p></o:p></pre><pre>communication and delete it.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>LACNOG mailing list<o:p></o:p></pre><pre><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><o:p></o:p></pre><pre><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><o:p></o:p></pre><pre>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a><o:p></o:p></pre><pre><o:p> </o:p></pre></blockquote><pre>_______________________________________________<o:p></o:p></pre><pre>LACNOG mailing list<o:p></o:p></pre><pre><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><o:p></o:p></pre><pre><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><o:p></o:p></pre><pre>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a><o:p></o:p></pre><pre><o:p> </o:p></pre></blockquote></blockquote><pre><o:p> </o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>_______________________________________________<o:p></o:p></pre><pre>LACNOG mailing list<o:p></o:p></pre><pre><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><o:p></o:p></pre><pre><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><o:p></o:p></pre><pre>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a><o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>LACNOG mailing list<o:p></o:p></pre><pre><a href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a><o:p></o:p></pre><pre><a href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a><o:p></o:p></pre><pre>Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a><o:p></o:p></pre></blockquote><p class=MsoNormal>_______________________________________________ LACNOG mailing list LACNOG@lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog <o:p></o:p></p></div></body></html>