<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Me abrazo con los dos brazos de la recomendación de Hugo:</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). </p>
<p>Nos lo van a agradecer :-)</p>
<div class="moz-cite-prefix">On 4/11/25 12:34 AM, Hugo Salgado
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:aQl0VzI_AG8FyrMb@pepino.intra.nic.cl">
<pre wrap="" class="moz-quote-pre">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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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 <a class="moz-txt-link-rfc2396E" href="mailto:tomas.lynch@gmail.com"><tomas.lynch@gmail.com></a>
escribió:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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 <a class="moz-txt-link-rfc2396E" href="mailto:lacnog@lacnic.net"><
lacnog@lacnic.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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 <a class="moz-txt-link-rfc2396E" href="mailto:nantoniello@gmail.com"><nantoniello@gmail.com></a>
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 <a class="moz-txt-link-rfc2396E" href="mailto:lacnog@lacnic.net"><
lacnog@lacnic.net></a> escribió:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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:
<a class="moz-txt-link-freetext" 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>
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.
<a class="moz-txt-link-freetext" 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>
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 <a class="moz-txt-link-rfc2396E" href="mailto:nantoniello@gmail.com"><nantoniello@gmail.com></a>
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 <a class="moz-txt-link-rfc2396E" href="mailto:lacnog@lacnic.net"><
lacnog@lacnic.net></a> escribió:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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
<a class="moz-txt-link-freetext" href="https://mailarchive.ietf.org/arch/msg/v6ops/qgbtlp-pQo931maAD_Y_kdaaIlU/">https://mailarchive.ietf.org/arch/msg/v6ops/qgbtlp-pQo931maAD_Y_kdaaIlU/</a>).
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):
<a class="moz-txt-link-freetext" href="https://mailarchive.ietf.org/arch/msg/v6ops/B2GCyjHDYtSDPCI6UJOKcGc618s/">https://mailarchive.ietf.org/arch/msg/v6ops/B2GCyjHDYtSDPCI6UJOKcGc618s/</a>
(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):
<a class="moz-txt-link-freetext" href="https://mailarchive.ietf.org/arch/browse/v6ops/">https://mailarchive.ietf.org/arch/browse/v6ops/</a>
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
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc6146-bis/">https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc6146-bis/</a> 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.
<a class="moz-txt-link-freetext" href="https://www.iana.org/assignments/service-function-chaining">https://www.iana.org/assignments/service-function-chaining</a>-
service-function-types/service-function-chaining-service-function-
types.xhtml.
* IP Flow Information Export (IPFIX) Entities.
<a class="moz-txt-link-freetext" href="https://www.iana.org/assignments/ipfix/ipfix.xhtml">https://www.iana.org/assignments/ipfix/ipfix.xhtml</a>.
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 <a class="moz-txt-link-rfc2396E" href="mailto:nantoniello@gmail.com"><nantoniello@gmail.com></a>
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 <a class="moz-txt-link-rfc2396E" href="mailto:lacnog@lacnic.net"><
lacnog@lacnic.net></a> escribió:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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 <a class="moz-txt-link-rfc2396E" href="mailto:hsalgado@vulcano.cl"><hsalgado@vulcano.cl></a>
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:
<
<a class="moz-txt-link-freetext" 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>
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">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 <a class="moz-txt-link-rfc2396E" href="mailto:francisco.arias@icann.org"><francisco.arias@icann.org></a>
*Asunto: **[dns-operations] Name Collision IPv6 Research Study -
Public Comment*
*Fecha: *30 de octubre de 2025, 18:13:42 CET
*Para: *<a class="moz-txt-link-rfc2396E" href="mailto:dns-operations@dns-oarc.net">"dns-operations@dns-oarc.net"</a> <a class="moz-txt-link-rfc2396E" href="mailto:dns-operations@dns-oarc.net"><dns-operations@dns-oarc.net></a>
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:
<a class="moz-txt-link-freetext" 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>
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
<a class="moz-txt-link-abbreviated" href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a>
<a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a>
_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
**********************************************
IPv4 is over
Are you ready for the new Internet ?
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com">http://www.theipv6company.com</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
**********************************************
IPv4 is over
Are you ready for the new Internet ?
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com">http://www.theipv6company.com</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
**********************************************
IPv4 is over
Are you ready for the new Internet ?
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com">http://www.theipv6company.com</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
**********************************************
IPv4 is over
Are you ready for the new Internet ?
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com">http://www.theipv6company.com</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="" class="moz-quote-pre">
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</body>
</html>