From tomas.lynch en gmail.com Sun Nov 2 12:19:32 2025 From: tomas.lynch en gmail.com (Tomas Lynch) Date: Sun, 2 Nov 2025 10:19:32 -0500 Subject: [lacnog] [dns-operations] Name Collision IPv6 Research Study - Public Comment In-Reply-To: References: <40DF56ED-37F9-4C5C-923F-D16DEE6160CD@consulintel.es>

<9736C449-E5E3-4580-8CF7-541CDB10F445@consulintel.es>

Message-ID: 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 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 > 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 >> 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 >>> 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 >>>> 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 >>>> *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" >>>> >>>> >>>> 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 > ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From nantoniello en gmail.com Sun Nov 2 14:04:04 2025 From: nantoniello en gmail.com (Nicolas Antoniello) Date: Sun, 2 Nov 2025 14:04:04 -0300 Subject: [lacnog] [dns-operations] Name Collision IPv6 Research Study - Public Comment In-Reply-To: References: <40DF56ED-37F9-4C5C-923F-D16DEE6160CD@consulintel.es>

<9736C449-E5E3-4580-8CF7-541CDB10F445@consulintel.es>

Message-ID: 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 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 >> 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 >>> 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 >>>> 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 >>>>> 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 >>>>> *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" >>>>> >>>>> >>>>> 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 > ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From lia.solis en gmail.com Mon Nov 3 03:15:42 2025 From: lia.solis en gmail.com (Lia Solis) Date: Mon, 3 Nov 2025 00:15:42 -0600 Subject: [lacnog] Directorio LACNOG Message-ID: Comunidad LACNOG, El pasado 9 de octubre, en el marco del evento LACNIC44-LACNOG2025, la comunidad LACNOG se reunió en su Asamblea Anual 2025, un espacio abierto que nos permite fortalecer lazos, compartir avances y seguir construyendo juntos el futuro de la operación de Internet en América Latina y el Caribe. Durante el encuentro, se compartió el informe financiero anual y se desarrolló el proceso de elección de dos cargos en el Directorio de LACNOG, en cuyo resultado se ratifica a Guillermo Cicileo, y deposita su confianza dando la bienvenida a Hernan Moguilevsky como miembros del Board. De igual manera, el Board de LACNOG en su reunión mensual llevada a cabo en fecha 30 de Octubre, ha designado democráticamente los roles de cada integrante, organizando sus cargos de la siguiente manera: - Presidente: Erika Vega - Vicepresidente: Ariel Weher - Tesorero: Hernan Franco - Secretario: Guillermo Cicileo - Segundo Secretario: Ricardo Patara - Segundo Tesorero: Edmundo Cazarez Queremos dar un inmenso agradecimiento a Nicolas Antoniello, Director Saliente, por su valiosa e invaluable participación, y constante aporte a la comunidad. Queremos expresar un sincero agradecimiento a las organizaciones que nos acogen, su apoyo constante hace posible que esta comunidad siga creciendo, aprendiendo y aportando al desarrollo de un Internet más fuerte, estable y resiliente en nuestra región. LACNOG ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: