ARIN y la economía de la fragilidad de la base de datos IRR

Resumen

• La fragilidad de la base de datos IRR en la región ARIN es un problema de fragmentación de fuentes: el mismo prefijo, ASN de origen, AS-SET o relación de enrutamiento puede representarse de manera diferente en ARIN, fuentes reflejadas, repositorios tipo RADb y bases de datos de enrutamiento privadas.
• La pregunta práctica del mercado no es solo si un único registro de ruta es válido, sino qué fuente elige creer primero un proveedor de tránsito, plataforma en la nube, servidor de rutas IXP o constructor de filtros.
• La frontera autoritativa de ARIN importa porque los datos originados en ARIN vinculados a recursos gestionados por ARIN tienen un peso probatorio diferente al de los datos no autoritativos o de terceros que aún pueden ser consumidos por filtros privados.
• El reflejo y las copias obsoletas crean vidas posteriores ocultas: un registro corregido en un lugar puede seguir afectando el filtrado en otro si otra fuente, espejo o ruta AS-SET aún apunta a la historia anterior.
• La expansión de AS-SET agrava el problema porque los conjuntos recursivos pueden extraer miembros y prefijos de varias fuentes, permitiendo que el orden de las fuentes funcione como una política económica no reconocida.
• Las transferencias IPv4, la incorporación a la nube y la participación en IXP ahora requieren diligencia en las fuentes IRR, especialmente para ISP pequeños y operadores del Caribe que no pueden absorber fácilmente excepciones manuales.
• RPKI mejora el entorno probatorio, pero no elimina la fragilidad del IRR porque los filtros privados aún utilizan datos IRR para políticas de enrutamiento, conos de clientes, membresía en AS-SET y admisión operativa.

La fragilidad son fuentes plurales, no una única entrada errónea

El primer error es buscar un único registro roto. En una sala de transferencias, un ticket de aprovisionamiento de IXP, una revisión de "traiga su propia IP" en la nube o un caso de incorporación de tránsito, el problema a menudo se presenta como un desacuerdo entre fuentes. Una base de datos dice que el prefijo pertenece con el nuevo ASN de origen del titular. Otra aún refleja un antiguo proveedor de tránsito. Una tercera fuente tiene un registro de ruta ingresado años antes por un ingeniero de red que ya se fue. Un espejo presenta datos que parecen actualizados porque la consulta funcionó hoy, aunque el registro subyacente se heredó de un acuerdo operativo anterior. Un AS-SET se expande a través de una cadena que incluye un miembro inesperado, y el constructor de filtros trata el resultado como una política de enrutamiento ordinaria.

Eso es la fragilidad de la base de datos IRR. No es la misma pregunta que quién puede publicar o eliminar un registro de prefijo-origen en particular. Esa pregunta más acotada importa, pero se sitúa dentro de una arquitectura de mercado más amplia. El problema mayor es que el entorno del Registro de Enrutamiento de Internet es plural. Está compuesto por fuentes operadas por RIR, repositorios comerciales y privados, espejos, preferencias locales de fuentes, conjuntos recursivos, registros copiados, entradas abandonadas y herramientas que traducen esta evidencia desigual en filtros privados. El efecto económico aparece cuando una red debe decidir en qué versión de la historia de enrutamiento creer.

ARIN es un caso de prueba útil porque su región combina un mercado de transferencias IPv4 altamente desarrollado con una densa dependencia operativa. Los operadores norteamericanos, las plataformas en la nube, las redes de contenido, los bancos, las universidades, los proveedores de alojamiento, las empresas de servicios gestionados, las agencias públicas y los operadores del Caribe utilizan direcciones cuyo valor depende de ser aceptadas por otros. La escasez de IPv4 no solo se registra. Se enruta, se filtra, se incorpora a plataformas en la nube, se financia, se arrienda, se examina reputacionalmente y se integra en planes de continuidad del cliente. En ese entorno, el costo de la evidencia IRR fragmentada no es académico. Es demora, descuento, trabajo de excepción manual y, a veces, alcanzabilidad parcial.

La cuestión también es institucional. Un registro es más legítimo cuando preserva un libro mayor confiable de recursos de numeración escasos y facilita la prueba operativa. Se vuelve peligroso cuando intenta convertir ese libro en un control discrecional sobre cada uso comercial de las direcciones. La fragmentación del IRR pone a prueba ese límite desde la otra dirección. Si ARIN hace muy poco para aclarar la semántica de las fuentes autoritativas para los recursos en su región, los repositorios privados y los viejos espejos llenan el vacío. Si intenta ordenar todas las decisiones de filtrado, se extralimita. La respuesta duradera se encuentra entre esos errores: autoridad de fuente clara, semántica de publicación limpia, evidencia responsable y límites explícitos sobre lo que el registro demuestra y lo que no.

Este es un ensayo sobre la selección de fuentes. El mismo registro de ruta puede tener un significado operativo diferente dependiendo de si proviene de ARIN, de una fuente adyacente a ARIN no autoritativa, de RADb, de un IRR privado de un proveedor anterior, de un espejo de otro repositorio o de un AS-SET expandido recursivamente. El mismo prefijo puede parecer limpio para un upstream y sospechoso para otro porque su orden de fuentes difiere. La misma transferencia puede estar operativamente completa en el libro mayor de ARIN y aún incompleta en el mundo de los filtros porque el comprador no ha encontrado todas las fuentes que consume un aceptante privado.

La frontera autoritativa de ARIN y la sombra de los datos no autoritativos

La distinción más importante en el entorno IRR de la región ARIN es la frontera entre los datos autoritativos y los datos que meramente parecen útiles. Para los recursos gestionados por ARIN, un registro de enrutamiento originado en ARIN vinculado al titular reconocido y gestionado a través del marco de control de recursos de ARIN tiene un carácter probatorio diferente al de un registro que reside en un repositorio de terceros. Eso no significa que los repositorios privados carezcan de valor. Significa que no deben confundirse con la declaración del propio registro sobre un recurso bajo su responsabilidad de coordinación.

La frontera de estilo ARIN-NONAUTH es útil precisamente porque nombra la ambigüedad. Una fuente no autoritativa puede contener datos operativamente relevantes. Puede describir un acuerdo real con un cliente, una migración histórica o una ruta que alguna vez funcionó. Pero no es lo mismo que una declaración autoritativa de fuente ARIN anclada en el libro mayor de recursos de ARIN. Si los filtros privados tratan esas categorías como iguales, convierten la conveniencia en autoridad oculta. Si los operadores ignoran por completo los datos no autoritativos, pueden perderse la evidencia que un upstream o servidor de rutas está utilizando realmente. El punto no es abolir una categoría. El punto es prevenir la confusión de categorías.

En un entorno de bajo valor, la confusión de categorías podría ser tolerable. Una pequeña inconsistencia se resolvería con un ticket, una llamada telefónica o una excepción manual. En el mercado actual, la inconsistencia puede afectar el precio de transferencia, los plazos de liquidación, la migración a la nube, la admisión a un IXP y la continuidad del cliente. Un comprador de espacio IPv4 puede recibir el estado de transferencia reconocido por ARIN y aún encontrar que una entrada de tipo RADb, una fuente de un proveedor anterior o un registro no autoritativo es lo primero que ve una herramienta de filtrado. El comprador no ha perdido el recurso. Ha heredado una carga probatoria.

La frontera autoritativa también importa para los vendedores. Un vendedor que tiene registros ARIN limpios pero deja en su lugar datos de ruta antiguos de terceros no ha entregado una historia operativa limpia. El vendedor puede decir, con precisión, que ARIN reconoce la transferencia. El comprador puede responder, también con precisión, que los filtros privados no consultan solo ARIN. La disputa no es sobre la propiedad metafísica. Es sobre qué evidencia pueden leer las redes cuya aceptación hace que el bloque sea útil.

El papel de ARIN debe ser disciplinado. No debe pretender ser el tribunal global de todas las fuentes IRR. No puede ni debe ordenar a cada red privada que prefiera los datos de ARIN en cada filtro. Pero puede hacer que la frontera de la fuente ARIN sea más difícil de malinterpretar. Puede publicar semánticas de fuente que separen los datos autoritativos de recursos gestionados por ARIN del material no autoritativo o de terceros. Puede dejar claro que una transferencia de reconocimiento registral no es una garantía de que todas las fuentes IRR externas hayan sido limpiadas. Puede ayudar a los titulares a identificar la diferencia entre el estado mantenido por ARIN y los datos que sobreviven fuera del control de ARIN.

Esa frontera también protege a ARIN de extralimitarse. El registro no debe convertirse en un regulador general de rutas solo porque los filtros privados son desordenados. Su función central es más acotada: unicidad, reconocimiento actual de recursos, contactos responsables, continuidad del servicio y evidencia adyacente al enrutamiento que las redes puedan evaluar. Si la fuente es autoritativa, diga por qué. Si la fuente no es autoritativa, dígalo claramente. Si un registro ha sido reflejado, preserve el origen de la reclamación. Los mercados pueden tolerar la incertidumbre cuando la incertidumbre está etiquetada. Se vuelven frágiles cuando las etiquetas desaparecen.

El reflejo hace que los datos antiguos parezcan vivos

El reflejo es útil porque hace que los datos estén disponibles. Es peligroso porque puede hacer que los datos antiguos parezcan vivos. Un operador que consulta un servidor IRR puede no notar si la respuesta provino de la fuente original, de una copia reflejada, de un espejo obsoleto de una fuente anteriormente válida o de un repositorio que mantiene datos históricos más tiempo del que sobrevive la relación operativa. La consulta tiene éxito, la respuesta está estructurada y el prefijo aparece en un formato que las herramientas pueden consumir. Eso es suficiente para que muchos filtros procedan.

Esta es la vida posterior silenciosa de los datos de enrutamiento. Un registro puede ser corregido en un lugar pero aún visible a través de otra ruta. Un proveedor anterior puede actualizar su propia fuente, mientras que un programa de actualización del espejo se retrasa. Un repositorio comercial puede conservar una ruta registrada por proxy por conveniencia. Un IRR privado puede ser reflejado por un par que no ha notado que la fuente cambió. Un AS-SET puede apuntar a una fuente cuyos miembros incluyen datos más antiguos. Un servidor de rutas puede reconstruirse diariamente, pero a partir de una lista de entrada que da más peso a un espejo obsoleto que a una fuente autoritativa corregida.

El problema económico es que la parte que intenta enrutar paga por la historia. Un comprador de una transferencia no puede simplemente decir: "ARIN ahora me reconoce". Debe preguntar qué fuentes de datos consume cada contraparte importante. Un equipo de la nube puede preguntar por qué el origen antiguo todavía aparece. Un proveedor de tránsito puede rechazar hasta que se resuelva el conflicto. Un servidor de rutas de intercambio puede no explicar qué fuente causó la denegación. Un prestamista o asesor puede marcar el bloque como operativamente desordenado. Los datos antiguos se convierten en un pequeño impuesto para el titular actual.

El reflejo también oscurece la responsabilidad. Si un registro obsoleto se consulta desde un espejo, ¿quién debería arreglarlo? El titular puede no controlar la fuente original. La fuente original puede decir que los datos ya cambiaron. El operador del espejo puede tratar el problema como un problema de actualización en lugar de un problema de autoridad. La red que consumió el espejo puede no revelar su lista de fuentes. El resultado es un ejercicio probatorio de cuatro esquinas alrededor de un registro que puede haber comenzado como una conveniencia de enrutamiento ordinaria.

Es por eso que la procedencia de la fuente importa tanto como el contenido. Una respuesta útil del IRR no solo debe reportar datos de prefijo, origen y mantenedor. Debe preservar suficiente información de la fuente para que el lector sepa de dónde provino la reclamación y si los datos son autoritativos para el recurso en cuestión. Si un espejo está involucrado, el lector debe entender que es un espejo. Si una fuente no es autoritativa, no se debe permitir que el lector infiera autoridad a partir del formato. Si un registro es antiguo, la información de última modificación y actualidad debe ser fácil de encontrar y fácil de retener para las herramientas.

Para ARIN, la lección no es que el reflejo sea malo. El ecosistema de políticas de enrutamiento de Internet depende de la replicación, la alcanzabilidad y la conveniencia de las consultas. La lección es que la evidencia replicada necesita una identidad clara. Una función de libro mayor que es confiable en la fuente aún puede perder fuerza si los espejos difuminan la autoridad. El registro puede publicar datos actuales, pero el mercado consume copias. Si las copias no llevan semántica de fuente, el mercado ve un mundo plano: una respuesta entre muchas, todas con forma de RPSL, todas aparentemente capaces de influir en los filtros.

El reflejo convierte la publicación en una cadena de suministro. Una cadena de suministro defectuosa no se repara simplemente arreglando la fábrica si los distribuidores continúan enviando existencias antiguas. En términos de IRR, la fuente autoritativa puede ser la fábrica, pero el servidor de rutas, el proveedor de tránsito y la mesa de ayuda de la nube a menudo reciben los productos a través de intermediarios. La fragilidad vive en esa distancia.

RADb y los IRR privados son parte del mercado, no están fuera de él

RADb y otras fuentes IRR no RIR o privadas a menudo se tratan como una molestia en las discusiones de políticas, pero son parte del mercado real. Existen porque los operadores necesitaban un lugar para publicar políticas de enrutamiento, datos de rutas de clientes e información de AS-SET cuando las bases de datos de los RIR estaban incompletas, eran difíciles de usar, lentas para adaptarse o no eran autoritativas para el recurso que se describía. También existen porque las redes privadas toman decisiones de enrutamiento privadas. Un gran operador, proveedor de servicios gestionados o centro de datos puede mantener registros para los clientes porque reduce la fricción de aprovisionamiento.

El resultado es una economía probatoria mixta. Algunos registros de terceros están obsoletos. Algunos son descuidados. Algunos son registros proxy que deberían haberse retirado. Algunos son la única evidencia legible por máquina que un pequeño cliente puede dar a un upstream. Algunos describen relaciones legítimas cliente-proveedor que ARIN mismo no debería tratar de adjudicar. Algunos son conveniencias comerciales. Algunos se convierten en pasivos operativos años después. Tratar todos los datos de terceros como basura es incorrecto. Tratarlos todos como equivalentes a los datos registrales autoritativos también es incorrecto.

Las fuentes de estilo RADb tienen una importancia particular en la región ARIN porque la región tiene muchos titulares heredados, clientes de la nube, acuerdos de direcciones arrendadas, clientes de centros de datos, redes gestionadas y compradores de transferencias cuyas relaciones de enrutamiento no encajan en una simple historia de titular-origen. Una empresa puede poseer un bloque pero enrutar a través de un proveedor. Una universidad puede usar un rango heredado a través de la red de un consorcio. Un cliente de la nube puede necesitar un ASN de plataforma durante una migración. Un proveedor caribeño puede depender de un upstream que mantiene registros en su nombre. Los datos IRR privados pueden reflejar estas relaciones mejor que una simple línea de titular. Pero esa utilidad operativa no responde a la pregunta de autoridad.

La pregunta de autoridad es: ¿qué prueba la fuente? Un registro de un tercero puede probar que alguien publicó una reclamación de enrutamiento en ese repositorio. Puede ser evidencia de que un upstream esperaba una ruta. Puede ser una entrada útil para un filtro. Puede respaldar una relación de servicio. No prueba, por sí mismo, el control actual del recurso reconocido por ARIN. Cuando los filtros privados no mantienen esa distinción, una fuente privada puede ganar poder práctico sobre un recurso escaso sin asumir la responsabilidad a nivel de registro.

Aquí es donde la economía institucional ayuda. Un repositorio privado reduce los costos de transacción para los participantes que entienden sus límites. Aumenta los costos sistémicos cuando extraños confían en él sin entender esos límites. El mismo registro de estilo RADb puede ser útil entre un proveedor y su cliente, pero perjudicial si un futuro comprador, plataforma en la nube o servidor de rutas lo confunde con la autoridad actual del titular. El valor del registro depende del contexto. La fragilidad aparece cuando el contexto es despojado por el reflejo y la generación automatizada de filtros.

La respuesta constructiva no es exigir un mundo puro con solo datos de RIR. La política de enrutamiento es demasiado diversa para eso. La respuesta es hacer explícita la calidad de la fuente y alinear la preferencia de fuente con la cadena de autoridad del recurso. Para el espacio de direcciones gestionado por ARIN, los datos actuales de fuente ARIN normalmente deberían tener un peso especial como señal adyacente al libro mayor. Los datos de terceros deben tratarse como evidencia de relación, no como prueba final de autoridad sobre el recurso. Cuando los datos de terceros entran en conflicto con los datos autoritativos de ARIN, el conflicto debe desencadenar una explicación en lugar de la aceptación ciega de cualquier fuente que aparezca primero en una herramienta local.

Esta distinción mejoraría el mercado. Los vendedores sabrían qué registros externos deben divulgarse. Los compradores sabrían lo que están heredando. Los upstreams podrían usar fuentes privadas sin pretender que son pruebas de título. Los IXP podrían construir políticas de fuentes que sean lo suficientemente claras para que los miembros corrijan errores. ARIN podría preservar la disciplina de su mandato aclarando su propia fuente en lugar de reclamar dominio sobre todas las demás.

La recursión de AS-SET es donde la fragilidad se agrava

Los AS-SET son donde la fragilidad del IRR deja de ser una lista de registros aislados y se convierte en una red de suposiciones heredadas. Un registro de ruta dice que se espera que un prefijo se origine desde un ASN. Un AS-SET dice qué ASN, o qué otros AS-SET, pertenecen al cono de enrutamiento o grupo de políticas de un cliente. Los constructores de filtros a menudo comienzan con un nombre de AS-SET, lo expanden recursivamente, recopilan prefijos relacionados y generan listas de prefijos o políticas de ruta. Si la cadena de AS-SET cruza fuentes, los datos obsoletos pueden multiplicarse silenciosamente.

La recursión importa porque la primera pregunta puede ser inocente: "¿Cuál es su AS-SET?" Un cliente proporciona un nombre. La herramienta del proveedor lo busca en una lista de fuentes. Si el mismo nombre existe en más de una fuente, el orden de las fuentes puede decidir qué conjunto se utiliza. Si un conjunto incluye otro conjunto, la herramienta sigue la cadena. Si un conjunto miembro apunta a una fuente antigua, el filtro puede extraer ASN antiguos. Si los registros de ruta para esos ASN se extraen de varias fuentes, la lista final de prefijos puede incluir rutas que nadie ha revisado recientemente. Para cuando se implementa el filtro, la entrada parece autoritativa porque se ha convertido en configuración.

Esto no es una debilidad teórica. Es un dispositivo de escalado cotidiano. Las redes grandes no pueden aprobar manualmente cada prefijo downstream. Los IXP no pueden construir a mano el cono de clientes de cada miembro. Las operaciones de nube y tránsito no pueden depender de correos electrónicos personalizados para cada ruta. La expansión de AS-SET convierte las declaraciones de enrutamiento dispersas en políticas legibles por máquina. Eso es valioso. El peligro es que la recursión oculta el camino por el cual una fuente antigua o débil entró en la decisión final.

Para un comprador de transferencia, esto puede ser costoso. El comprador puede limpiar los registros de ruta para el bloque comprado y aún descubrir que un viejo AS-SET controlado por un proveedor anterior vuelve a incluir el prefijo en una ruta de política obsoleta. Un pequeño ISP puede actualizar su propio conjunto pero dejar un miembro cliente en una fuente privada que se expande de manera diferente en diferentes upstreams. Un centro de datos puede pedir a un cliente que use un AS-SET mantenido por el proveedor porque se ajusta a las herramientas del proveedor, mientras que otro par insiste en un conjunto calificado por fuente en otro lugar. Un servidor de rutas puede rechazar porque el AS-SET declarado del miembro no incluye la combinación exacta de origen-fuente que el servidor espera.

La recursión de AS-SET también crea problemas de nomenclatura. Los nombres que no están calificados por fuente pueden colisionar. Un conjunto en un repositorio puede no ser el conjunto que una herramienta elige. Un cliente puede asumir que el proveedor está expandiendo un conjunto actual, mientras que la lista de fuentes del proveedor encuentra primero un conjunto más antiguo. Un gran operador puede resolver esto mediante coordinación directa. Un pequeño operador puede solo recibir un rechazo que dice que su AS-SET es incorrecto. La diferencia no es solo conocimiento técnico. Es poder de negociación.

Por lo tanto, una buena higiene de IRR requiere visibilidad de la cadena. Un constructor de filtros debe poder decirle a un cliente no solo que un prefijo fue rechazado, sino qué ruta de AS-SET y fuente produjo el rechazo. Un titular debe poder auditar qué conjuntos nombran su ASN o prefijos. Un archivo de diligencia de transferencia debe incluir no solo los registros de ruta del bloque, sino también las referencias de AS-SET que pueden hacer que la vieja historia de enrutamiento persista. Un servidor de rutas debe fomentar el uso de AS-SET calificados por fuente donde la ambigüedad sea probable. Estas prácticas no eliminan la recursión. Hacen que la recursión sea inspeccionable.

RPKI no resuelve este problema particular porque RPKI no modela los conos de clientes. Un ROA puede decir que un AS puede originar un prefijo. No dice qué ASN pertenecen al AS-SET de un cliente, si un proveedor debe aceptar una ruta downstream, o si un servidor de rutas debe incluir a los clientes de un miembro en los filtros generados. Los datos IRR siguen siendo el lenguaje de las relaciones de política de enrutamiento. Es por eso que la fragilidad de AS-SET sigue siendo económicamente importante incluso en un mercado más consciente de RPKI.

El orden de las fuentes es una política económica oculta

El orden de las fuentes suena como una preferencia de ingeniería. En la práctica, puede comportarse como una política económica. Un constructor de filtros puede consultar primero ARIN, luego RADb, luego RIPE, luego un repositorio privado. Otro puede poner RADb primero porque sus clientes históricamente lo usaron. Otro puede preferir RPKI para la validación de origen, pero aún usar múltiples fuentes IRR para la generación de listas de prefijos. Un servidor de rutas IXP puede publicar una lista de fuentes predeterminada. Un operador puede mantener su lista privada. El resultado es que dos redes pueden evaluar la misma reclamación de ruta de manera diferente sin que ninguna de las dos sea irracional.

Cuando el orden de las fuentes difiere, los resultados comerciales difieren. Un prefijo aceptado por un upstream puede ser rechazado por otro. Una solicitud de incorporación a la nube puede pasar después de que un revisor humano dé prioridad a la evidencia actual de ARIN, mientras que un filtro de tránsito rechaza porque un registro de terceros más antiguo aparece primero. Un comprador puede creer que la limpieza está completa porque su consultor consultó un orden de fuentes, mientras que el proveedor preferido del comprador usa otro. Un pequeño ISP puede perder una semana descubriendo que "falta de coincidencia IRR" realmente significa "nuestra herramienta prefirió una fuente no autoritativa que usted no sabía que consumíamos".

Esta política oculta tiene efectos distributivos. Las redes grandes pueden solicitar excepciones, persuadir a pares y mantener contactos directos con los equipos de filtrado. Las redes más pequeñas a menudo no pueden. Un gran cliente de la nube puede recibir una explicación cuidadosa; una pequeña empresa de alojamiento puede recibir una respuesta de plantilla. Un operador nacional puede ejecutar su propia política de fuentes; un proveedor de acceso del Caribe puede estar limitado por las opciones de dos proveedores de tránsito disponibles. Por lo tanto, el orden de las fuentes asigna costos fijos. Decide quién debe limpiar qué base de datos antes de que los ingresos puedan continuar.

La naturaleza oculta del orden de las fuentes también distorsiona los precios. Un comprador de transferencia puede exigir un descuento si el bloque parece desordenado bajo las listas de fuentes comunes. Un vendedor puede resistirse, diciendo que el estado autoritativo de ARIN está limpio. Ambos pueden tener razón. La brecha de valor proviene de la probabilidad de que contrapartes importantes prefieran datos obsoletos o no autoritativos antes de ver el estado limpio. Esa probabilidad es difícil de valorar si el orden de las fuentes es opaco. Se convierte en una prima de riesgo.

La mejor disciplina es la transparencia, no la uniformidad. No sería realista exigir que cada red use las mismas fuentes IRR en el mismo orden. Las redes tienen diferentes historias, clientes, posturas de seguridad y apetitos de riesgo. Pero las redes que rechazan rutas debido a datos IRR deben divulgar lo suficiente para que el titular pueda solucionar el problema. Si el rechazo provino de un conflicto de fuente específico, diga qué fuente. Si el problema provino de una ruta de AS-SET, muestre la ruta. Si la red prefiere datos de fuente ARIN para recursos ARIN, dígalo. Si prefiere una fuente comercial amplia por razones operativas, haga visible el riesgo.

El orden de las fuentes es donde el código en ejecución revela la realidad institucional. Las reuniones pueden describir una base de datos como autoritativa, pero la lista de fuentes del constructor de filtros decide si esa autoridad se lee primero, después o en absoluto. Un mercado de direcciones construido sobre IPv4 escaso no puede ignorar ese hecho. Si el orden de las fuentes está oculto, los participantes del mercado están comerciando activos cuyas reglas de aceptación no pueden ver completamente. Si el orden de las fuentes es visible, el mismo mercado puede valorar la limpieza, asignar responsabilidades y reducir las sorpresas.

El objetivo no es hacer que cada filtro privado obedezca a ARIN. El objetivo es hacer que el filtrado privado sea lo suficientemente inteligible para que la autoridad actual del recurso no sea derrotada por accidente, inercia o una preferencia no examinada por datos antiguos.

Manejo de conflictos: silencio, preferencia y carga

Los conflictos no son excepciones raras. Son subproductos normales de un mundo plural de registros de enrutamiento. El mismo prefijo puede aparecer en múltiples fuentes. Un origen antiguo puede coexistir con un nuevo origen. Un AS-SET puede incluir un miembro que ya no pertenece. Un repositorio privado puede describir una relación con un cliente que ARIN no puede ver. Un espejo puede retrasarse. Un servidor de rutas puede leer una respuesta mientras que una plataforma en la nube lee otra. El manejo de conflictos determina si esta pluralidad sigue siendo manejable o se convierte en una penalización del mercado.

Hay tres formas básicas de manejar los conflictos: silencio, preferencia y desplazamiento de la carga. Silencio significa que la red que rechaza da poca explicación. El titular solo se entera de que su ruta no pasó. Preferencia significa que la red tiene una jerarquía de fuentes o regla de decisión, ya sea pública o privada. Desplazamiento de la carga significa que el titular actual debe probar por qué la fuente obsoleta o conflictiva debe ser ignorada. La mayoría de los sistemas reales combinan las tres. La pregunta económica es quién paga cuando colisionan.

El silencio es el más caro para los actores pequeños. Una red grande puede diagnosticar ejecutando sus propias herramientas y llamando a sus pares. Un pequeño ISP puede no saber si el problema es un registro RADb obsoleto, un residuo de estilo ARIN-NONAUTH, un retraso del espejo, una colisión de AS-SET, un calificador de fuente faltante o una falta de coincidencia RPKI. Cuanto más largo sea el diagnóstico, más paga el operador en tiempo perdido. En un mercado caribeño con opciones de tránsito limitadas, el retraso puede significar un mayor costo mayorista, peor rendimiento para el cliente o incumplimiento de plazos de servicio.

La preferencia puede ser eficiente si es clara. Un servidor de rutas que dice que prefiere datos autoritativos del RIR para recursos en la región relevante, luego usa fuentes de terceros seleccionadas para datos de relación, da a los miembros un camino predecible. Un proveedor de tránsito que dice que consulta fuentes especificadas en un orden especificado permite a los clientes probar antes del encendido. Un proveedor de nube que explica cómo reconcilia los datos de ARIN, los ROA y los registros IRR reduce el riesgo de incorporación. La preferencia se vuelve problemática cuando está oculta pero se trata como verdad objetiva.

El desplazamiento de la carga es inevitable, pero debe ser disciplinado. Si un titular actual quiere que otros ignoren un viejo registro de terceros, debe proporcionar evidencia. Si un origen delegado quiere mantener una ruta aceptada, debe mostrar la autoridad actual. Si un proveedor mantiene un AS-SET proxy, debe mantenerlo actualizado. Pero la carga no debe ser infinita. Una vez que la autoridad actual de fuente ARIN, la postura actual de ROA cuando sea relevante y la evidencia operativa actual se alinean, no se debe permitir que los datos obsoletos no autoritativos mantengan al mercado como rehén indefinidamente.

El estándar de manejo de conflictos debe preguntar qué es competente para probar cada fuente. Los datos de fuente ARIN son más fuertes en la autoridad de recursos ARIN. Los datos de estilo RADb o privados pueden ser más fuertes en una relación de enrutamiento cliente-proveedor. Un espejo es tan fuerte como su fuente y actualidad. Un AS-SET es evidencia de intención de política, no de propiedad. Un ROA es autorización de origen de ruta, no un mapa del cono de clientes. Si cada señal se mantiene dentro de su competencia, los conflictos pueden resolverse sin pretender que un artefacto responde a todas las preguntas.

La ganancia económica de un manejo disciplinado de conflictos es la liquidez. Un bloque con restos de IRR antiguos no carece de valor; es un bloque con riesgo de limpieza. Un bloque con datos autoritativos claros y residuos externos aislados es más fácil de valorar. Una red con razones de rechazo transparentes es más fácil de trabajar. Un registro que etiqueta la autoridad de la fuente reduce las disputas sin convertirse en un organismo de aplicación. El conflicto no desaparecerá. Pero no se debe permitir que la ambigüedad decida el resultado por defecto.

Diligencia de transferencia en un mundo IRR fragmentado

Las transferencias IPv4 exponen la fragilidad del IRR porque una transferencia cambia la historia del titular más rápido de lo que el entorno del registro de enrutamiento puede cambiar. ARIN puede reconocer al destinatario. Las partes pueden cerrar. Los abogados pueden actualizar los documentos. El comprador puede preparar un nuevo plan de origen. Sin embargo, el mundo de los filtros aún puede contener registros más antiguos, copias reflejadas, AS-SET proxy, entradas no autoritativas y datos mantenidos por proveedores que apuntan al pasado operativo del vendedor. El activo se ha movido. La cadena de suministro de evidencia no se ha movido completamente con él.

Un archivo serio de diligencia de transferencia debe, por lo tanto, incluir un inventario de fuentes IRR. Debe enumerar los registros de fuente ARIN, registros adyacentes a ARIN no autoritativos cuando sean visibles, registros de estilo RADb, registros mantenidos por proveedores, referencias IRR privadas conocidas por las partes, copias reflejadas, referencias de AS-SET y resultados comunes de los constructores de filtros. Debe distinguir los registros que el vendedor puede cambiar, los registros que el comprador puede cambiar después del cierre, los registros controlados por proveedores y los registros que pueden requerir cooperación de terceros. También debe identificar qué contrapartes importantes dependen de qué fuentes.

Esto no es un adorno legal. Es economía de entrega. Un comprador que necesita el bloque para migración a la nube, corte de clientes, mitigación de DDoS, contratación pública, expansión de alojamiento o servicio regional de banda ancha no puede tratar la limpieza IRR como una tarea casual posterior al cierre. Si el upstream preferido del comprador no aceptará la ruta hasta que se corrija una fuente obsoleta, el comprador no está recibiendo capacidad productiva inmediata. Está recibiendo un proyecto de remediación. El precio debe reflejar eso.

Para transferencias de alta dependencia, las condiciones de liquidación pueden necesitar incluir hitos IRR. El vendedor puede acordar divulgar los registros de ruta y AS-SET conocidos. Las partes pueden acordar qué registros permanecen temporalmente durante la migración. Los proveedores pueden ser notificados. El comprador puede crear registros de fuente ARIN de reemplazo cuando la autoridad lo permita. Se puede contactar a los repositorios externos. Un cronograma de depósito en garantía puede distinguir el reconocimiento del registro de la aceptación operativa para las contrapartes más importantes. No todas las transferencias necesitan tanto detalle. Pero cuanto más dependa el caso de negocio de la alcanzabilidad rápida, más importa el archivo de fuentes IRR.

La contribución de ARIN es ser explícito sobre lo que puede y no puede entregar. Puede registrar la transferencia, mantener el libro mayor de recursos autoritativo, respaldar los datos de enrutamiento de fuente ARIN y ayudar a los titulares a comprender el estado del lado ARIN. No puede garantizar que RADb, un IRR privado, una fuente de un proveedor anterior, un servidor de rutas IXP o una plataforma en la nube haya actualizado su propia vista. Esa limitación debe ser parte del entendimiento estándar del mercado, no una sorpresa descubierta después del cierre.

La diligencia de transferencia es donde el principio del registro como libro mayor se vuelve práctico. El libro mayor debe ser limpio, acotado y confiable. A su alrededor se encuentra un mercado de aceptación más amplio que debe ser inspeccionado. Un comprador de IPv4 escaso no está comprando simplemente un rango de números. Está comprando una ruta para ser creído por muchos sistemas independientes. Los datos IRR fragmentados son uno de los lugares donde esa ruta puede romperse.

Los pequeños operadores, las nubes y los IXP sienten el costo primero

La fragilidad del IRR no se distribuye de manera uniforme. Las redes grandes a menudo pueden sortearla. Mantienen equipos de ingeniería, contactos privados, herramientas de políticas de ruta, rutas de escalamiento y soporte legal. Pueden ejecutar sus propias comparaciones de fuentes. Pueden negociar excepciones. Pueden persuadir a un proveedor de nube, socio de tránsito o par para que revise de nuevo. Un pequeño ISP, una empresa regional de alojamiento, un departamento universitario, un proveedor de servicios gestionados o un operador caribeño puede tener la misma reclamación legítima de recursos pero menos formas de hacerla legible.

Para los pequeños operadores, el costo es fijo. Aprender las reglas de fuentes IRR, mantener AS-SET, auditar espejos, limpiar viejos registros de estilo RADb, coordinar ROAs y responder a rechazos de filtros opacos lleva tiempo, independientemente del tamaño del bloque. Un /24 utilizado por un pequeño proveedor de acceso puede requerir casi el mismo trabajo de prueba que una cartera más grande en manos de una plataforma sofisticada. Ese costo fijo es regresivo. Penaliza a los operadores cuyos ingresos por ejercicio de prueba son bajos.

Las redes del Caribe ilustran el punto de manera aguda. La región de servicio de ARIN incluye operadores de islas y mercados pequeños cuya conectividad puede depender de un conjunto limitado de cables submarinos, opciones de upstream, opciones de intercambio y regiones de nube fuera de su mercado doméstico. Si un conflicto IRR retrasa un servidor de rutas o el encendido del tránsito, el operador puede no tener cinco sustitutos. Puede pagar más, aceptar peores rutas o decepcionar a clientes a quienes no les importa que el problema provenga de una fuente obsoleta. La evidencia frágil se convierte en un costo de conectividad local.

Las plataformas en la nube crean otra forma de presión. Los programas de "traiga su propia IP" a menudo requieren prueba de que el cliente controla el prefijo y puede autorizar el origen de la plataforma. RPKI puede ser parte de esa prueba. Los datos IRR también pueden examinarse, especialmente cuando la plataforma quiere entender orígenes antiguos o la política de ruta actual. Si una fuente de terceros obsoleta dice una cosa y la evidencia actual de ARIN dice otra, la plataforma puede pausar. La pausa es racional desde la perspectiva de la plataforma. Es costosa para el cliente.

Los IXP y los servidores de rutas ponen la lógica en código. Un servidor de rutas debe proteger a los miembros de malas rutas y malas configuraciones. Puede usar datos IRR y RPKI juntos. Puede generar filtros a partir de los AS-SET de los miembros. Si los datos IRR del miembro faltan, son conflictivos o están ocultos detrás del orden incorrecto de fuentes, la ruta puede no propagarse. Para una gran red de contenido, ese es un camino entre muchos. Para un operador regional, la aceptación del servidor de rutas puede afectar el rendimiento y el costo del tránsito materialmente.

El costo social no es meramente una molestia. Si solo las grandes plataformas pueden costear evidencia limpia, el mercado de direcciones se vuelve menos competitivo. Los pequeños titulares pueden vender con descuento porque no pueden probar la limpieza de manera eficiente. Los pequeños compradores pueden evitar bloques con historias complicadas. Las redes regionales pueden permanecer dependientes de upstreams que mantienen la maquinaria IRR para ellos. El mercado entonces recompensa la capacidad administrativa tanto como la necesidad operativa.

ARIN puede reducir esta carga de costo fijo sin convertirse en un programa de subsidios o una policía de rutas. Puede proporcionar una guía más clara sobre los límites de las fuentes, una visibilidad más fácil para el titular de los datos de enrutamiento de fuente ARIN, listas de verificación prácticas para transferencias, ejemplos de calificación de fuente AS-SET y explicaciones de cómo interactúan RPKI y la evidencia IRR. Las redes privadas pueden ayudar dando razones de rechazo procesables. Los IXP pueden publicar políticas de fuentes. Las nubes pueden explicar qué evidencia requieren y por qué. El objetivo compartido es la legitimidad de baja fricción: un pequeño operador legítimo no debería necesitar una campaña institucional a medida para probar una ruta de rutina.

Por qué RPKI ayuda pero no retira al IRR

RPKI es la respuesta más fuerte a parte del problema. Un ROA permite al titular de un recurso autorizar un ASN de origen en un sistema basado en certificados. La validación de origen de ruta permite a las redes clasificar los anuncios contra esa autorización. En comparación con un registro IRR suelto de terceros, un ROA válido vinculado al titular actual del recurso es una señal mucho más limpia para la autorización de origen. Una implementación más amplia de RPKI reduce el espacio para que algunas afirmaciones de origen de ruta falsas u obsoletas sean creídas.

Pero RPKI no retira al IRR porque responde a una pregunta diferente. RPKI dice si un AS está autorizado a originar un prefijo, dentro de límites de longitud de prefijo especificados. No describe un AS-SET, un cono de clientes, una política de peering, una relación de tránsito, una membresía de servidor de rutas, una delegación de servicio gestionado o la fuente de filtro preferida de un proveedor. Los datos IRR siguen siendo el lenguaje de trabajo para muchas de esas relaciones de política. Las redes que construyen filtros de clientes aún necesitan una forma de saber qué ASN y prefijos pertenecen detrás de un cliente. RPKI solo no cuenta esa historia.

También hay una brecha de implementación. Algunas redes aplican la validación de origen de ruta estrictamente. Otras la usan como advertencia. Algunas rutas están cubiertas por ROAs. Otras permanecen NotFound. Algunos errores son temporales y operativos en lugar de maliciosos. Algunas redes combinan RPKI con filtros IRR, aceptando una ruta solo si tanto la autorización de origen como la política IRR parecen plausibles. En ese mundo mixto, un conflicto IRR aún puede retrasar una ruta incluso cuando RPKI es correcto, y la falta de un ROA aún puede dejar al IRR como la principal evidencia legible por máquina.

RPKI también puede agudizar los tiempos de transferencia. Una transferencia puede requerir cambios de ROA, cambios de origen y limpieza IRR en una secuencia coordinada. Si el ROA se actualiza pero los datos IRR antiguos permanecen, algunos filtros aún pueden cuestionar la ruta. Si los datos IRR se actualizan pero el ROA es incorrecto, la validación de origen de ruta puede clasificar el anuncio como inválido. Si los estados antiguo y nuevo se superponen durante la migración, ambos sistemas deben entenderse. El valor de RPKI es alto precisamente porque agrega una mejor señal; la necesidad de disciplina IRR permanece porque la aceptación privada aún lee múltiples señales.

Los sistemas también fallan de manera diferente. RPKI depende de la continuidad del certificado y del repositorio, la actualidad de la publicación, el comportamiento del validador y las elecciones correctas de maxLength. El IRR depende de la calidad de la fuente, los mantenedores, el reflejo, la recursión de AS-SET y la preferencia de fuente local. Un operador maduro vigila ambos. Un archivo de transferencia maduro explica ambos. Un proceso de incorporación a la nube maduro reconcilia ambos. Tratar a cualquiera de los dos como un sustituto total del otro crea puntos ciegos.

Para ARIN, RPKI es una oportunidad para mejorar la jerarquía de evidencia. Donde la autoridad actual de recursos ARIN, la postura actual de ROA y los datos IRR actuales de fuente ARIN se alinean, los filtros privados deberían tener una fuerte razón para confiar en la historia de origen de ruta. Donde entran en conflicto, el conflicto debe ser visible y explicable. Donde los datos de terceros entran en conflicto con ambos, los datos de terceros deben tratarse como una afirmación que requiere contexto, no como un voto igual. RPKI fortalece la evidencia autoritativa. No borra la necesidad de etiquetar la evidencia no autoritativa.

Por lo tanto, el mercado debería dejar de preguntar si gana RPKI o IRR. La pregunta relevante es cómo se ordenan las dos señales en un archivo de aceptación práctico. Un bloque limpio de la región ARIN debe tener reconocimiento registral actual, contactos precisos, ROAs apropiados, registros de ruta de fuente ARIN actuales cuando sea necesario, estado conocido de limpieza IRR externa, AS-SET calificados por fuente y una explicación clara de cualquier residuo de terceros restante. RPKI es central en ese archivo. No es todo el archivo.

Lo que ARIN puede hacer sin convertirse en un regulador de rutas

El camino constructivo para ARIN es estrecho pero significativo. No debe decirle a cada red qué enrutar. No debe supervisar los términos comerciales de los arrendamientos IPv4, las migraciones a la nube o las relaciones de tránsito. No debe convertir la preferencia de fuente en una ley de enrutamiento regional obligatoria. Su legitimidad es más fuerte cuando actúa como un libro mayor confiable y una institución de coherencia probatoria. La fragilidad del IRR necesita exactamente ese tipo de disciplina.

Primero, ARIN puede hacer más clara la semántica de las fuentes. Los operadores deben poder distinguir los datos autoritativos de fuente ARIN para recursos gestionados por ARIN de los datos no autoritativos, reflejados o de terceros. La distinción debe ser visible para los humanos y fácil de preservar para las herramientas. Si un registro no es autoritativo para el recurso, la etiqueta debe sobrevivir a la consulta, el espejo y la exportación a contextos de construcción de filtros cuando sea factible. Una etiqueta limpia es una forma barata de infraestructura de mercado.

Segundo, ARIN puede mejorar la visibilidad del titular. Los titulares deben poder comprender los registros de enrutamiento del lado ARIN asociados con sus recursos y las implicaciones básicas de las categorías de fuentes. Esto no requiere que ARIN descubra cada entrada de RADb o IRR privado. Sí requiere que ARIN haga su propio estado lo suficientemente legible como para que un titular pueda separar la evidencia gobernada por ARIN de las tareas de limpieza externas. Un pequeño operador no debería necesitar un especialista solo para saber qué está diciendo ARIN sobre su prefijo.

Tercero, ARIN puede publicar guías de IRR orientadas a transferencias. Los participantes en transferencias necesitan saber que el reconocimiento registral y la limpieza IRR están relacionados pero no son idénticos. Una lista de verificación práctica debe preguntar: qué registros de fuente ARIN existen, qué registros externos se conocen, qué AS-SET hacen referencia a los ASN relevantes, qué espejos o listas de fuentes utilizan las contrapartes importantes, qué ROAs deben cambiar, qué orígenes antiguos permanecen temporalmente válidos y qué registros requieren cooperación de terceros. Una guía de este tipo apoya a los mercados sin dictar los términos de las transacciones.

Cuarto, ARIN puede resistir la tentación de usar la fragilidad del IRR como expansión de su mandato. Las fuentes fragmentadas son un problema real, pero no todo problema real pertenece al registro como soberano. Las redes privadas tienen derecho a gestionar el riesgo. Los clientes son responsables de sus relaciones de enrutamiento. Los repositorios de terceros pueden ser útiles. Los tribunales y los contratos deciden muchas disputas comerciales. El trabajo de ARIN es mantener confiable el registro central, no convertirse en el juez final de toda aceptación de rutas.

La prueba es si ARIN reduce el costo de prueba sin aumentar los puntos de control discrecionales. Un titular debería encontrar más fácil probar la autoridad actual del recurso. Un comprador debería encontrar más fácil identificar los residuos IRR externos. Un servidor de rutas debería encontrar más fácil preferir evidencia limpia. Un pequeño ISP debería encontrar más fácil solucionar un rechazo. Una plataforma en la nube debería encontrar más fácil entender la historia de origen de ruta. Ninguno de estos resultados requiere que ARIN ordene el enrutamiento. Requieren que ARIN mantenga el libro mayor y su evidencia adyacente aptos para un mercado en el que IPv4 es capital.

Fuentes y método

Este artículo trata las mecánicas del registro público y la seguridad del enrutamiento como exhibiciones factuales, no como encuadre institucional. El marco analítico es la economía institucional en torno a los recursos de numeración escasos: la distinción entre un libro mayor y un guardián, el peligro del riesgo a nivel de registro una vez que IPv4 se convierte en capital, la disciplina de que las redes en funcionamiento, no la retórica, deciden la realidad operativa, y la necesidad de proteger la continuidad de los recursos de numeración sin convertir al registro en un ejecutor general.

El límite operativo importa porque el mismo bloque de direcciones puede moverse a través de varios canales de evidencia a la vez. Los contactos del registro y los ROA pueden respaldar la historia del titular actual. Los objetos de ruta, AS-SET, copias reflejadas y registros mantenidos por proveedores aún pueden describir acuerdos operativos más antiguos. Los filtros de nube, tránsito e intercambio pueden preferir diferentes listas de fuentes. Este artículo se ocupa de esa fragmentación: cómo múltiples fuentes IRR, espejos, recursión de AS-SET y orden de fuentes hacen que la misma afirmación de enrutamiento signifique cosas diferentes para diferentes filtros.

Las mecánicas oficiales del registro son útiles aquí solo para identificar lo que hacen los sistemas: datos del registro de enrutamiento de fuente ARIN, RPKI, ROAs, registros públicos de recursos, etiquetas de fuente y servicios relacionados con el enrutamiento. No proporcionan la conclusión. La conclusión proviene del entorno del mercado: escasez de IPv4, práctica de transferencias en América del Norte, incorporación a la nube y centros de datos, filtrado de IXP, limitaciones de capacidad de los pequeños operadores y el hecho de que las redes privadas convierten datos de enrutamiento públicos y semipúblicos en decisiones privadas de aceptación.

El artículo evita deliberadamente una simple obra de moralidad. Las fuentes IRR privadas y de estilo RADb no se tratan como villanos. Los datos de fuente ARIN no se tratan como magia. RPKI no se trata como un reemplazo universal. Cada fuente de evidencia se juzga por lo que es competente para probar y por el costo impuesto cuando se malinterpretan sus límites. Ese es el método requerido para un mercado cuyos activos son intangibles, escasos y operativamente integrados.

Conclusión: la fragilidad es un costo de ser creído

Es fácil subestimar la fragilidad de la base de datos IRR porque parece un problema de datos técnicos. En realidad, es un problema de costo de confianza. Un bloque IPv4 escaso se vuelve útil solo cuando suficientes sistemas independientes creen en la historia de enrutamiento actual. Esos sistemas no todos leen la misma evidencia. Algunos leen ARIN. Algunos leen RADb. Algunos leen espejos. Algunos expanden AS-SET recursivamente. Algunos combinan IRR y RPKI. Algunos usan listas de fuentes antiguas. Algunos ocultan su orden de fuentes detrás de una cola de soporte. El titular experimenta esta pluralidad como fricción.

Para ARIN, la postura institucional correcta no es ni pasividad ni extralimitación. La pasividad permite que los datos obsoletos no autoritativos y los hábitos de fuentes privadas asignen poder práctico sobre los recursos de la región ARIN. La extralimitación convertiría al registro en un regulador de rutas y repetiría el viejo error de convertir la contabilidad en control discrecional. La mejor postura es la disciplina del libro mayor: hacer claro el estado autoritativo, preservar la identidad de la fuente, apoyar la evidencia actual adyacente al enrutamiento, etiquetar los límites y ayudar a los operadores a entender lo que permanece fuera de ARIN.

Para el mercado, la lección práctica es que la diligencia de fuentes IRR ahora es parte de la diligencia de activos IPv4. Un archivo de transferencia que ignora las fuentes de enrutamiento externas está incompleto. Una migración a la nube que ignora las viejas rutas de AS-SET está expuesta. Una política de IXP que no da a los miembros una razón de rechazo procesable aumenta los costos fijos. Un comprador que asume que el reconocimiento de ARIN limpia automáticamente los registros de estilo RADb está comprando sorpresas. Un vendedor que deja datos obsoletos de terceros atrás está entregando un activo menos líquido de lo que el precio puede implicar.

RPKI mejora este mundo, pero no lo suprime. El futuro no es un sistema de prueba único que haga desaparecer todas las demás fuentes. El futuro es una jerarquía de evidencia en la que cada fuente lleva el peso apropiado a su autoridad. Los datos de fuente ARIN deben ser autoritativos para los recursos gestionados por ARIN. RPKI debe tener un fuerte valor de autorización de origen. Las fuentes privadas y de estilo RADb deben describir relaciones con límites claros. Los espejos deben preservar la procedencia. Los AS-SET deben estar calificados por fuente donde la ambigüedad importa. Los constructores de filtros deben explicar sus elecciones cuando esas elecciones bloquean rutas legítimas.

La economía es modesta pero consecuente. La semántica de fuente limpia reduce los costos de transacción. Los conflictos visibles hacen que el riesgo sea valorable. Una mejor higiene de AS-SET reduce las barreras accidentales del mercado. Las razones de rechazo claras ayudan a las pequeñas redes a competir. La diligencia de transferencia que incluye fuentes IRR protege a compradores y vendedores. ARIN no necesita volverse más poderoso para producir estas ganancias. Necesita hacer que su evidencia existente sea más legible y más difícil de confundir con evidencia más débil.

Es por eso que la fragilidad del IRR pertenece a la discusión sobre la escasez de IPv4. La escasez da precio a las direcciones, pero la aceptación les da valor productivo. En un mundo IRR fragmentado, la aceptación depende no solo de tener razón, sino de tener razón en la fuente en la que un filtro privado cree primero. La economía de la fragilidad de la base de datos IRR de ARIN es la economía de esa primera creencia.