[lacnog] [dns-operations] Name Collision IPv6 Research Study - Public Comment
Carlos Martinez - Cagnazzo
carlos en cagnazzo.uy
Mar Nov 4 09:50:27 -03 2025
Me abrazo con los dos brazos de la recomendación de Hugo:
--> 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).
Nos lo van a agradecer :-)
On 4/11/25 12:34 AM, Hugo Salgado wrote:
> Hola Tomás.
> Es muy difícil saber cuántos administradores de redes usan TLDs no
> delegados. Principalmente porque, por diseño, esos nombres no salen a
> la Internet pública! Así que solo podemos darnos cuenta de los que sí
> "se filtran" (típicamente porque configuraron mal sus resolvers
> internos, o porque un empleado en el café se le olvidó activar la
> VPN) y hacer análisis de tráfico en los root servers.
>
> Existen monitoreos continuos, como el ITIH de ICANN, que hace un ranking
> de los que más aparecen:
> HOME
> LAN
> CORP
> SVC
> DYNATRACE
> GEOTAB
> INTERNAL
> OPENSTACKLOCAL
> LOCALDOMAIN
> ...
> y así miles más.
>
> Ahora la razón por qué lo usan... en un estudio hicieron una "etiología"
> de las colisiones, analizando 1388 casos, y llegaron a:
> Uso intencional dentro de una red (nombre/marca/acronismo) : 32%
> Otro/desconocido : 30%
> Sufijo puesto por el ISP : 16%
> Uso intencional dentro de una red (concepto/no-marca) : 14%
> Uso interno no-intencional (otro/desconocido) : 7%
> Uso interno no-intencional (fuga de 2LD) : 1%
>
>
> Cuando se lanzaron los primeros gTLDs, allá por el 2014, ICANN tenía
> una página para reportar problemas. Tuvieron del orden de 120 casos
> anuales los primeros 3 años, incluído 1 caso donde una "organización
> grande" reportó problemas "graves" al día siguiente de activar uno de
> los TLDs. El registro en ese caso suspendió la "interrupción controlada"
> por unos días hasta que la empresa solucionó el problema. Pero después
> de eso los reportes fueron casi cero. Igual estos casos son
> anecdóticos, quizás cuántos más nunca se supo. O cuántos siguen
> colisionando y nadie se ha dado cuenta!
>
> Por eso la recomendación es siempre usar un subdominio de un nombre
> sobre el cual tengan control. Si tienen inscrito "empresa.com",
> entonces usen "intranet.empresa.com", o algo así. Usando split-view
> pueden bloquear la resolución hacia afuera, y responder solo a la
> red interna.
>
> Saludos,
>
> Hugo
>
>
> On 14:04 02/11, Nicolas Antoniello wrote:
>> Hola Tomás,
>>
>> Sin perjuicio de lo que aportó Hugo y para sumar.
>> Una cosa que muchas veces sucede es que los administradores de redes crean
>> dominios para uso interno de la organización (dominios privados). Por
>> ejemplo me creo un dominio “administración” para la gente de administración
>> en un sistema interno privado (no se, por ejemplo un active directory)…
>> tiempo después, como consecuencia de la nueva ronda de creación de TLDs,
>> supongamos que se termina creando el TLD “administración” (que ahora sería
>> un gTLD).
>> Entonces ahora, ese “dominio” que para esa organización era privado va a
>> “colisionar” con todos los intentos por resolver cualquier subdominio del
>> nuevo gTLD… para detectar esas colisiones es que se desarrolló ese
>> mecanismo llamado interrupción controlada que es provisorio justamente para
>> que quienes tengan esos casos de dominio los detecten y resuelvan para que
>> no existan más esas colisiones.
>> La solución que plantea hugo, es siempre utilizar subdominios (aunque sean
>> para uso privado) pues al ser sub dominios de de uno público registrado, no
>> van a colisionar.
>>
>> Las estadísticas no las tengo, tal vez hugo tiene más info sobre eso.
>>
>> Saludos,
>> Nico
>>
>>
>> El El dom, nov 2, 2025 a la(s) 12:19, Tomas Lynch<tomas.lynch en gmail.com>
>> escribió:
>>
>>> Nuevamente una conversación técnica muy interesante se fué por la tangente
>>> gracias a una discusión intransigente sobre procedimientos de lo qué hace o
>>> no hace el (IETF|ICANN|IANA|mi abuela).
>>>
>>> La verdad es que no tengo opinión sobre el correo original de Hugo,
>>> experto en el tema de DNS, donde se propone el uso de " ::ffff:7f00:3535
>>> (que también se puede representar como ::ffff:127.0.53.53)". Pero sería
>>> bueno que si alguien sigue leyendo este hilo de correos, separe la paja del
>>> trigo (y hay mucha paja), y dé su opinión al respecto ya que son
>>> temas TÉCNICOS muy interesantes.
>>>
>>> Lo que me llama la atención es la postdata de Hugo que indica que "y a los
>>> que estén armando sus redes privadas, por favor usen un subdominio de un
>>> nombre que tengan inscrito." Mi pregunta Hugo es, ¿cuántos
>>> administradores de redes han descubierto que están utilizando TLDs que
>>> pasan a estar publicados? ¿cuál es el motivo por el que alguien llega a
>>> utilizar un TLD que no sea los ya conocidos? Ojo, no dudo de que el sistema
>>> de interrupción controlada sea efectivo y útil, mi pregunta va por el lado
>>> de conocer cuántas personas asignan ".botarate" o ".pagafantas" a sus redes
>>> en lugar de $mi_dominio.
>>>
>>> Saludos,
>>>
>>> Tomás Lynch
>>>
>>>
>>> On Fri, Oct 31, 2025 at 3:57 PM jordi.palet--- vía LACNOG< lacnog en lacnic.net> wrote:
>>>
>>>> Hola Nico,
>>>>
>>>> Precisamente insistí doblemente en que tenia bien claro que no había sido
>>>> mala fe, pero eso no evita que piense que es un grave error (eso si que
>>>> obviamente es mi opinión personal) y que lo correcto es llevarlo por el
>>>> camino que indican los procedimientos que todos hemos aceptado y preparar
>>>> un I-D tanto para el prefijo IPv4 como para el IPv6, porque el IPv4 no esta
>>>> correctamente registrado, no es estándar y puede generar problemas de
>>>> interoperabilidad, puede no funcionar (no estar implementado tal y como se
>>>> necesite para esta función), etc.
>>>>
>>>> Fíjate que no entré en ningún momento en el debate de si esos prefijos
>>>> son o no los mejores (aunque personalmente opino como otros en v6ops que no
>>>> lo son). Mi "mala idea” no era respecto a esos prefijos sino al hecho de
>>>> como se estaba procediendo con este tema. Creo que si se lee el primer
>>>> párrafo completo de ese primer correo mio, no hay duda, y esa parte no es
>>>> una opinion, es decir “el procedimiento es otro” (información, no opinión).
>>>> Por mas que releo el resto de ese correo, no veo mi opinion, sino
>>>> información de como debe hacerse.
>>>>
>>>> Pero igualmente concurro, que por mucho que parezca que peleamos, estos
>>>> debates deben ser siempre considerados por la parte constructiva, igual
>>>> sean informaciones u opiniones (sin confundir unas con otras).
>>>>
>>>> Saludos,
>>>> Jordi
>>>>
>>>> @jordipalet
>>>>
>>>>
>>>> El 31 oct 2025, a las 20:27, Nicolas Antoniello<nantoniello en gmail.com>
>>>> escribió:
>>>>
>>>> Jordi,
>>>>
>>>> Claro, lo que yo creo (al igual que mencionas en tu correo) es que los
>>>> estándares y todo el intercambio que se produce en torno a ello es
>>>> justamente producto de esas discusiones, en el buen sentido.
>>>>
>>>> Lo que también creo es que tal vez debemos ser un poco más abiertos en el
>>>> sentido de no pensar que se trata de alguna cosa mal intencionada o a
>>>> propósito. Yo creo que todos buscamos el resolver esos problemas que van
>>>> surgiendo, de la mejor manera y a veces algunos van o vamos a pensar que
>>>> las cosas se deberían hacer de otra manera. Y eso está bien.
>>>> También creo que justamente no aporta al debate el estar interpretando o
>>>> agravando la intención del otro cuando realmente lo que aporta es
>>>> justamente el argumentar por qué a mí me parece que tal o cual solución es
>>>> mejor.
>>>>
>>>> Yo creo que lo que aporta más es justamente hacer las argumentaciones
>>>> técnicas de por qué es una mala o buena idea usar tal o cual prefijo (más
>>>> aún si hay algún error en algún texto) ya que eso va a ser considerado y
>>>> rectificado si así lo decide la comunidad, como creo que siempre ha sido.
>>>>
>>>> Leyendo tu correo en respuesta al de Hugo, yo interpreto que si
>>>> comenzaste y continuaste dando tu opinión además de contar algunos hechos y
>>>> por eso di la mía.
>>>>
>>>> Justamente creo que es bueno expresar tu visión técnica de por qué crees
>>>> que no es una buena opción y cuál sería para ti una buena opción, y el
>>>> procedimiento que entiendes se debe seguir para el proceso. Por otro lado
>>>> no creo que aporte el exponerlo en modo defensivo “recordando”
>>>> procedimientos o marcando supuestos errores cuando todo esto creo que busca
>>>> ser un debate constructivo.
>>>>
>>>> Fraterno saludo,
>>>> Nico
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> El El vie, oct 31, 2025 a la(s) 15:57, jordi.palet--- vía LACNOG< lacnog en lacnic.net> escribió:
>>>>
>>>>> 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> 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
>>>>>>
>>>>>
>>>>> **********************************************
>>>>> 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
>>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion:https://mail.lacnic.net/mailman/options/lacnog
>>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion:https://mail.lacnic.net/mailman/options/lacnog
> _______________________________________________
> 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/20251104/2fb70921/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG