RIPE NCC y la economía del poder de direccionamiento de los proveedores de nube

Resumen

• El poder de direccionamiento de los proveedores de nube se crea cuando la identidad IP pública se vuelve dependiente de la cuenta, gestionada por la plataforma y mediada por la contratación, en lugar de simplemente estar registrada.
• La región de servicio de RIPE NCC, su amplia base de LIR, el agotamiento del conjunto libre de IPv4 y sus servicios de registro hacen que sus registros sean una evidencia importante para la portabilidad, pero no un mandato para la intervención en el mercado de la nube.
• Los productos BYOIP y de prefijos anunciados pueden preservar la identidad pública propiedad del cliente, pero las verificaciones de admisión, las reglas de origen de ruta, la evidencia de autorización y la aprobación de la plataforma condicionan la portabilidad.
• El DNS inverso, RPKI/ROAs, la aceptación de rutas, el historial de reputación, las listas de permitidos y el acoplamiento de servicios de seguridad son ahora superficies de control comercial en la migración y salida de la nube.
• La contratación del sector público y de clientes regulados puede endurecer involuntariamente la dependencia de los conjuntos propiedad del proveedor cuando las licitaciones valoran la comodidad operativa pero no especifican suficientemente la evidencia de salida.
• RIPE NCC debería seguir siendo un libro de registro delgado y preciso, pero mejorar el valor de portabilidad de la evidencia registral para que la escasez no pueda convertirse demasiado fácilmente en dependencia del cliente.

La reunión de salida donde el poder de direccionamiento se hace visible

La reunión más reveladora sobre la nube a menudo no es aquella en la que una empresa decide por primera vez migrar sus cargas de trabajo. Es aquella en la que intenta marcharse. Los diagramas en la pared pueden mostrar clústeres de cómputo, bases de datos gestionadas, balanceadores de carga, cortafuegos y herramientas de observabilidad. La conversación sobre el presupuesto puede comenzar con las tarifas de suscripción, la capacidad reservada, los cargos de salida y la recapacitación del personal. Pero en poco tiempo la discusión suele girar hacia los detalles menos glamorosos de la identidad de direcciones públicas: qué rangos IPv4 están en uso, quién los controla, cuántos sistemas externos los reconocen, qué clientes los han incluido en listas de permitidos, qué sistemas de correo y fraude recuerdan su comportamiento, si el DNS inverso cambiará, si existe una autorización de origen de ruta y si el próximo proveedor aceptará el prefijo en absoluto.

Ahí es donde aparece el poder de direccionamiento de los proveedores de nube. No requiere que un proveedor posea todas las direcciones escasas. Tampoco depende solo del tamaño del inventario público de IPv4 de una plataforma. El poder se crea cuando la identidad de red pública se envuelve en la cuenta de nube del cliente y luego se hace operativamente conveniente dentro de esa cuenta. Una dirección propiedad del proveedor se emite por API, se adjunta a un servicio, se protege con un producto de seguridad, se describe en una arquitectura de cumplimiento, se escribe en listas de permitidos empresariales y es observada por sistemas de riesgo de terceros. Se convierte en parte de la cara externa del cliente. El cliente puede no pensar en ella como un activo. Puede pensar en ella como configuración. Ese es precisamente el punto.

La economía es simple pero fácil de pasar por alto. Los escasos recursos IPv4 se han vuelto costosos y administrativamente densos. Las empresas y los organismos públicos quieren servicios en la nube porque las plataformas simplifican las operaciones. Un proveedor que suministra direcciones públicas como parte del servicio gestionado puede convertir esa comodidad en una posición de negociación. El cliente recibe velocidad, automatización y soporte. También acepta que parte de su identidad pública está mediada por la plataforma. Si más adelante quiere mudarse, el costo no se limita a realojar las cargas de trabajo. Debe persuadir a clientes, reguladores, socios, sistemas antifraude, filtros de correo y equipos de seguridad para que confíen en una cara pública diferente. La dirección es solo un número, pero la evidencia que rodea al número es lo que la hace costosa.

RIPE NCC se sitúa cerca de la raíz de esa evidencia en su región. Su región de servicio abarca Europa, Oriente Medio y partes de Asia Central, y cubre más de 75 países. Su membresía incluye a más de 20.000 organizaciones de Registro Local de Internet. Su conjunto libre de IPv4 se agotó en noviembre de 2019. Sus servicios incluyen registros, la base de datos RIPE, RPKI, DNS inverso e información de enrutamiento y medición. Estos hechos no convierten a RIPE NCC en un regulador de la nube. Lo convierten en un libro de registro cuyos asientos son utilizados repetidamente por otras partes para decidir si una reclamación de dirección pública es creíble. En un mercado donde los proveedores de nube median cada vez más la experiencia de las direcciones públicas, la calidad y portabilidad de esa evidencia son importantes.

La pregunta para un registro regional de Internet es, por lo tanto, concreta pero importante. No debe intentar combatir directamente el poder de mercado de la nube. No debe convertirse en un terrateniente de la escasez ni en una oficina de licencias discrecionales para la arquitectura de nube. Su deber es más delgado y duradero: proteger la unicidad, la precisión y la continuidad, y hacer que los registros sean lo suficientemente útiles para que los titulares de direcciones puedan demostrar lo que controlan. Un libro de registro común reduce los costos de cambio cuando su evidencia viaja limpiamente entre plataformas. Un libro de registro débil o ambiguo permite que intermediarios poderosos conviertan la escasez de direcciones en dependencia.

Dos tipos de identidad de dirección pública

Los clientes de la nube ahora operan con dos formas superpuestas de identidad de dirección pública. La primera es la identidad propiedad del proveedor. Un cliente lanza un servicio y recibe direcciones del conjunto del proveedor. Esas direcciones pueden ser estáticas dentro de una cuenta, reservarse a través de un producto regional, estar vinculadas a un balanceador de carga o asociadas a un punto final gestionado. La Internet pública ve la dirección, pero el control comercial y operativo está dentro de la plataforma del proveedor. El cliente tiene acceso contractual, no control independiente. La plataforma puede automatizar la conexión, desconexión, reglas de cortafuegos, protección DDoS, manejo del DNS inverso en algunos casos, monitoreo y eventos del ciclo de vida. La dirección se siente nativa porque es nativa de la maquinaria del proveedor.

La segunda forma es la identidad portátil propiedad del cliente. El cliente trae un prefijo que ya controla, pide a un proveedor de nube que lo anuncie y utiliza ese rango público para cargas de trabajo en la plataforma. Los principales proveedores de nube han desarrollado variantes de este modelo, a menudo descritas como traiga-su-propia-IP, prefijo IP personalizado o servicios de prefijo público anunciado. El lenguaje del producto varía y los detalles cambian con el tiempo, pero el patrón general es común: el cliente debe demostrar control o autorización, cumplir con las condiciones de tamaño y registro, alinear la evidencia de origen de ruta, superar las verificaciones de la plataforma y aceptar las restricciones operativas del proveedor. La plataforma no se limita a enrutar un número. Está decidiendo si la evidencia registral del cliente es lo suficientemente buena para admitir ese número en el tejido de la nube.

La identidad propiedad del proveedor es eficiente al principio. El cliente evita los mercados de transferencia, el papeleo registral y la coordinación con los equipos de red. Puede construir a partir de plantillas. Puede destruir y recrear sistemas. Puede usar controles de seguridad nativos de la nube. Puede permitir que compras adquiera "conectividad pública" como parte de un servicio en lugar de adquirir y operar recursos de Internet. Para las startups, pequeñas empresas de software y equipos digitales del sector público, esto es a menudo racional. La alternativa puede ser lenta, costosa y desconocida. La escasez de IPv4 ha hecho que la tenencia independiente de direcciones sea más difícil de justificar cuando un proveedor puede suministrar una dirección por API.

La identidad portátil propiedad del cliente es costosa al principio pero valiosa al final. Permite a una empresa preservar la cara pública de un servicio cuando cambia de arreglos de alojamiento. Puede mantener estables las listas de permitidos de los socios. Puede preservar la reputación de correo y abuso cuando corresponda. Puede permitir que una empresa regulada muestre la continuidad de los puntos finales externos durante los ejercicios de resiliencia. También puede soportar diseños multinube o híbridos en los que la misma identidad pública no está anclada únicamente al conjunto de un proveedor. El cliente renuncia a cierta simplicidad pero conserva una porción de poder de negociación.

La distinción no es moral. Los conjuntos propiedad del proveedor no son inherentemente abusivos. BYOIP no es inherentemente liberador. Un cliente puede hacer un mal uso de un prefijo portátil, no mantener los datos registrales, crear riesgos de enrutamiento o tratar la portabilidad como una insignia mientras sigue dependiendo operativamente de otras maneras. Un proveedor puede suministrar direcciones honestamente y hacer la migración más fácil de lo que muchas redes privadas lograron jamás. Pero la pregunta institucional sigue siendo: ¿qué parte puede demostrar el control, qué parte puede cambiar la ruta, qué parte puede actualizar la delegación inversa, qué parte puede sobrevivir a una disputa y qué parte soporta el costo comercial de restablecer la confianza cuando la relación de cuenta termina?

En ese sentido, el poder de direccionamiento es un conjunto de fricciones. Vive en la brecha entre el control legal, la evidencia registral, la política de la plataforma y el reconocimiento operativo por parte de terceros. Un proveedor con un gran conjunto de direcciones y una automatización madura puede hacer que el camino más fácil sea el menos portátil. Un cliente con un prefijo limpio y bien documentado aún puede enfrentar verificaciones de admisión, demoras y límites de aceptación de rutas. El registro no elige al ganador comercial. Sin embargo, los registros del registro moldean la evidencia que ambas partes usan cuando negocian.

La escasez hace valioso el libro de registro, no soberano

El agotamiento de IPv4 a veces se describe como si automáticamente transfiriera autoridad a quien esté cerca del registro. Esa es la conclusión equivocada. La escasez hace que los registros precisos sean más valiosos. No convierte a un empleado en un terrateniente. El agotamiento del conjunto libre de IPv4 de RIPE NCC en noviembre de 2019 es un hecho de mercado y un hito administrativo, no una razón para que el registro asigne influencia en la nube según una política industrial. El papel útil no es racionar la competencia en la nube. Es asegurarse de que los registros que muestran quién posee, mantiene, delega y autoriza los recursos de numeración sigan siendo lo suficientemente coherentes para reducir la incertidumbre.

La región de RIPE NCC está inusualmente expuesta a este problema porque es amplia y comercialmente variada. Incluye densos mercados de nube de Europa occidental, centros financieros regulados, economías digitales emergentes, programas de nube del sector público, ecosistemas de puntos de intercambio de Internet, empresas de alojamiento, operadores de telecomunicaciones, redes de investigación y empresas que adquirieron direcciones mucho antes de que la migración a la nube se volviera normal. La región de servicio se extiende por Europa, Oriente Medio y partes de Asia Central. Más de 20.000 organizaciones LIR interactúan con el sistema de registro. Un solo patrón comercial no las describirá a todas. Algunas tienen equipos de red profesionales y una higiene registral madura. Otras tratan las direcciones como un detalle administrativo heredado.

Los proveedores de nube operan en esta diversidad con productos estandarizados. La estandarización es su fortaleza. Permite a una plataforma admitir un prefijo, verificar una señal criptográfica o registral, aplicar una política de enrutamiento, exponer una API y ejecutar el mismo proceso en muchas jurisdicciones. Eso es eficiente, pero también significa que la política de la plataforma puede convertirse en una capa de traducción privada entre el registro y el cliente. Si el registro es ambiguo, obsoleto o difícil de interpretar, el proveedor puede pedir más evidencia, retrasar la aprobación o rechazar el rango. Si el cliente carece de conocimiento interno, la respuesta del proveedor se convierte en la ley práctica de la portabilidad.

Por eso el libro de registro importa incluso cuando es delgado. Un libro de registro delgado no es pasivo. Es un dispositivo institucional para reducir las discusiones. Registra la unicidad, la administración y la autorización de manera que muchos sistemas posteriores puedan confiar sin pedir al registro que apruebe cada uso comercial. Cuando la evidencia es clara, el titular puede acercarse a múltiples proveedores, vendedores de seguridad y operadores de red con la misma prueba básica. Cuando la evidencia es débil, cada plataforma puede crear su propio ritual de admisión, y las plataformas más fuertes pueden hacer de ese ritual parte de la dependencia del cliente.

El peligro no es que RIPE NCC se vuelva irrelevante. Es que su evidencia siga siendo central pero se consuma a través de interfaces privadas que los clientes no pueden cuestionar fácilmente. Un proveedor puede decir que un prefijo no cumple con los requisitos del producto. Otro puede exigir un formato de autorización diferente. Un equipo de compras puede no entender la diferencia entre una dirección propiedad del proveedor y un prefijo portátil. Un equipo de seguridad puede aceptar los valores predeterminados de la plataforma porque reducen el riesgo inmediato. El registro sigue ahí, pero no está haciendo suficiente trabajo para la parte que más necesita la portabilidad.

La respuesta constructiva no es un registro más pesado. Es una mejor evidencia de portabilidad. El registro no debería decidir qué proveedor de nube debe aceptar a qué cliente. Debería ayudar a hacer legibles las reclamaciones de los titulares de recursos, el estado de la delegación inversa, la intención de origen de ruta y las señales de continuidad. Si un cliente ha mantenido registros precisos y puede mostrar una cadena limpia de autoridad, esa evidencia debería ser fácil de usar en todas las plataformas. La escasez se convierte entonces en una razón para mejorar las pruebas, no en un pretexto para un exceso de alcance del registro o la discreción de la plataforma.

BYOIP como mercado de admisión

Traiga-su-propia-IP suena como un producto de portabilidad. También es un mercado de admisión. Un cliente llega con un prefijo y pide a un proveedor de nube que lo porte. El proveedor debe proteger su sistema de enrutamiento, a sus otros clientes, su reputación con las redes ascendentes y su postura de seguridad. No puede simplemente aceptar cualquier rango declarado. Por lo tanto, pide al cliente que demuestre el control, cumpla con las condiciones de registro y de origen de ruta, cree señales de autorización y espere la revisión. Eso es sensato. También es donde una dirección pública queda sujeta al juicio de la plataforma.

AWS, Microsoft Azure, Google Cloud y otras plataformas importantes publican materiales de producto para los prefijos públicos suministrados por el cliente. Esos materiales son exhibiciones factuales útiles, no una teoría completa del mercado. Los documentos tienden a mostrar un patrón común: la plataforma requiere evidencia de que el cliente controla el rango o está autorizado para usarlo; el prefijo debe cumplir con las expectativas técnicas de tamaño y registro; la información de origen de ruta o la autorización deben ser compatibles con el anuncio del proveedor; el proveedor se reserva la discreción de aprobar, rechazar o restringir el uso; y el cliente debe integrar el prefijo admitido en el ciclo de vida propio de la plataforma. Los detalles difieren y las reglas de los productos evolucionan, pero la estructura de admisión es lo suficientemente estable como para importar.

El mercado de admisión crea asimetría. Una gran empresa con un equipo de red, asesoría jurídica interna, contactos registrales establecidos y múltiples proveedores puede preparar la evidencia. Puede crear o ajustar ROAs, actualizar los datos de contacto, coordinar el DNS inverso y presionar a los equipos de cuenta. Una empresa más pequeña puede saber solo que tiene un prefijo en viejos documentos o que un socio de alojamiento organizó una vez la conectividad. Un organismo público puede depender de un integrador de sistemas que trata el direccionamiento público como un detalle de implementación. El proveedor de nube se convierte entonces en el intérprete experto de la identidad propia del cliente. Eso es un apoyo útil, pero también es influencia.

La influencia se ve aumentada por el tiempo. Una admisión BYOIP fallida rara vez es una disputa política abstracta. Puede retrasar una ventana de migración, una prueba de recuperación ante desastres, un compromiso de licitación o el lanzamiento de un producto. Si la alternativa propiedad del proveedor está disponible de inmediato, la presión del proyecto favorece el conjunto de la plataforma. El cliente puede tener la intención de volver más tarde y arreglar la portabilidad. Más tarde a menudo significa nunca. Una vez que el servicio se ha lanzado con direcciones propiedad del proveedor, los terceros comienzan a recordar esas direcciones. La decisión barata se incrusta en las listas de permitidos, los registros de seguridad, las integraciones de clientes y la evidencia de auditoría.

Por lo tanto, BYOIP no es meramente una característica para contar. La pregunta más profunda es si funciona como infraestructura práctica de salida. Un proveedor puede anunciar una opción de portabilidad mientras mantiene una elegibilidad restringida, revisiones lentas, requisitos de evidencia complejos o restricciones operativas que hacen que muchos clientes elijan los conjuntos nativos. Eso puede reflejar un control de riesgos legítimo. También puede preservar la posición comercial del proveedor. Los externos no pueden evaluar el equilibrio a menos que la evidencia de portabilidad sea más clara y esté más estandarizada.

El papel de RIPE NCC es indirecto. No debería decirle a una plataforma cómo diseñar su red. No debería obligar a un proveedor a portar una ruta que cree un riesgo de seguridad u operativo. Pero puede hacer que el lado del cliente del proceso de admisión sea menos opaco. Los registros, los contactos mantenidos, los datos de origen de ruta, la delegación inversa y la evidencia relacionada deben ser lo suficientemente coherentes para que un titular pueda acercarse a un proveedor sin tener que reconstruir su propia historia a partir de archivos. Cuantos menos misterios haya en el libro de registro público, menos margen hay para que la admisión en la nube se convierta en un veto privado sobre la portabilidad.

Límites de cuenta y automatización por API

Las plataformas de nube hacen que el direccionamiento público se sienta moderno al convertirlo en un recurso de cuenta. Eso es conveniente porque los usuarios empresariales quieren infraestructura programable. Una dirección pública puede ser reservada, etiquetada, adjuntada a un balanceador de carga, movida entre instancias, monitoreada, protegida, registrada y facturada. Puede aparecer en plantillas de infraestructura como código. Puede estar sujeta a reglas de identidad y acceso. Puede ser creada por un equipo de plataforma en lugar de por un ingeniero de red. Esta es la genialidad operativa de la nube. También es el mecanismo por el cual la identidad de dirección pública se vuelve dependiente de la cuenta.

Los límites de cuenta importan porque definen quién puede actuar. Si una dirección proviene de un conjunto del proveedor, el cliente normalmente no puede llevársela fuera del proveedor. Puede ser capaz de reservarla dentro de una región, conservarla a través de reinicios de servicio o moverla entre productos dentro de la misma plataforma. Pero la cuenta es la valla. El cliente puede automatizar dentro de esa valla y se vuelve dependiente de la valla para la continuidad de la identidad. Una reorganización corporativa, una disputa de cuenta, una factura impagada, un bloqueo de cumplimiento o una migración fallida pueden entonces afectar no solo el acceso a la computación, sino la cara pública del servicio.

BYOIP cambia el límite pero no lo elimina. Una vez que un prefijo propiedad del cliente es admitido en una plataforma de nube, normalmente se sigue operando a través de las API y el modelo de cuenta de la plataforma. El cliente puede conservar el control registral, pero su uso diario está mediado por la capa de enrutamiento y servicios del proveedor. Desaprovisionar el prefijo, moverlo a otra cuenta, ajustar el anuncio, cambiar el uso regional o combinarlo con servicios de seguridad puede requerir pasos específicos de la plataforma. En este sentido, la portabilidad no es una propiedad binaria. Es una cadena de actos operativos que deben ser posibles bajo presión.

La comodidad de la automatización puede ocultar la pérdida de la práctica independiente. Los equipos de red que antes manejaban sesiones BGP, delegaciones inversas y coordinación con proveedores pueden ser reemplazados por equipos de plataforma cuya experiencia es la política de nube. Eso puede ser eficiente e incluso más seguro para muchas cargas de trabajo. Sin embargo, significa que menos personas dentro del cliente pueden distinguir entre una dirección que la empresa puede llevar a otra parte y una dirección que la plataforma simplemente alquila como parte de la prestación del servicio. Compras puede ver ambas como "IP estática". Los desarrolladores pueden ver ambas como configuración de punto final. Los auditores pueden preguntar si el servicio es resiliente sin preguntar si la identidad pública es portátil.

Esta confusión semántica es comercialmente útil para el proveedor. Cuanto más experimenta el cliente el direccionamiento público como una característica de la plataforma, menos probable es que calcule el costo de salida al principio. Para cuando se contempla la salida, la dirección está enredada con roles IAM de cuenta, registros, políticas DDoS, grupos de cortafuegos, certificados de balanceadores de carga, automatización de DNS, monitoreo de terceros y documentación del cliente. El camino de salida no es imposible. Es tedioso, arriesgado y políticamente poco atractivo. El tedio es una forma de bloqueo.

Un registro delgado solo puede contrarrestar esto haciendo la diferencia legible. La evidencia registral debería ayudar a los clientes, auditores y equipos de compras a hacer mejores preguntas. ¿Esta identidad pública es propiedad del proveedor o está controlada por el cliente? Si está controlada por el cliente, ¿dónde se registra el control? ¿Las autorizaciones de origen de ruta están alineadas con el origen de nube previsto? ¿Quién controla el DNS inverso? ¿Qué debe cambiarse si la relación de cuenta termina? Estas no son preguntas para un caso de competencia en la nube. Son preguntas de continuidad. Los registros del registro deberían hacerlas respondibles antes de una crisis, no después.

DNS inverso, RPKI y aceptación de rutas como evidencia de portabilidad

La identidad de dirección pública no la porta solo la dirección. La porta la evidencia de respaldo. El DNS inverso dice a otros sistemas cómo se nombra a sí misma una dirección. RPKI y los ROAs ayudan a los sistemas de validación de origen de ruta a determinar si un sistema autónomo está autorizado para originar un prefijo. La aceptación de rutas por parte de redes y plataformas determina si el tráfico llegará a la nueva ubicación. Los datos de contacto y de recursos del registro ayudan a establecer quién es responsable del recurso de numeración. Cada capa es técnica. Cada una también tiene un significado comercial en una migración a la nube.

El DNS inverso es un buen ejemplo porque a menudo se trata como una tarea doméstica menor hasta que se convierte en un bloqueador. Los sistemas de correo, los departamentos de abuso, las herramientas de seguridad empresarial y las verificaciones de cumplimiento pueden inspeccionar los nombres inversos. Un traslado de direcciones propiedad del proveedor al conjunto de otro proveedor puede cambiar la identidad inversa de maneras que afectan a la confianza. Un traslado usando un prefijo propiedad del cliente puede preservar o controlar esa identidad si la delegación y las operaciones se organizan adecuadamente. Si el cliente nunca entendió quién controlaba el DNS inverso, descubre la dependencia en el peor momento. El costo no es el registro DNS. Es la pérdida de continuidad que el registro representaba.

RPKI y los ROAs son igualmente importantes, aunque de manera diferente. En los entornos BYOIP de nube, la compatibilidad del origen de ruta puede decidir si un proveedor anunciará un prefijo de cliente y si otras redes aceptarán la ruta. Un cliente puede necesitar un ROA que autorice al sistema autónomo del proveedor a originar el prefijo, o puede necesitar eliminar o ajustar las autorizaciones conflictivas. El requisito preciso depende del proveedor y del modelo de despliegue, y los detalles del producto cambian. El punto económico es estable: la evidencia de origen de ruta se ha convertido en una credencial de admisión. Una plataforma que ayuda a los clientes a navegarla proporciona valor. Una plataforma que controla el proceso también gana influencia en los tiempos.

La aceptación de rutas añade otra capa de poder de mercado. Incluso si un registro es preciso y un ROA es técnicamente válido, la ruta debe ser aceptada por redes que filtran prefijos, imponen tamaños mínimos o aplican sus propias políticas. Los proveedores de nube tienen la escala y las relaciones operativas para gestionar esto a gran volumen. Los proveedores más pequeños pueden estar más expuestos a disputas de filtrado, problemas de reputación o propagación lenta. Los clientes observan esto como fiabilidad. Pueden concluir que una plataforma importante es el único lugar práctico para portar ciertas identidades públicas, incluso cuando el registro no lo dice. La escala de la plataforma convierte entonces la capacidad de coordinación técnica en ventaja comercial.

La lección política no es que todas las rutas deban ser aceptadas o que todas las delegaciones inversas deban ser sin fricciones. Los datos incorrectos y el mal enrutamiento pueden dañar la Internet en general. La lección es que la portabilidad depende de la evidencia que pueda transportarse entre entornos. Si el control del DNS inverso, los contactos registrales, la autorización de origen de ruta y la intención de enrutamiento están dispersos o no están claros, el cliente no puede comparar fácilmente a los proveedores. Debe pedir a cada plataforma que interprete la evidencia por él. La plataforma con el mejor equipo de producto se convierte en el juez práctico del futuro de direcciones del cliente.

RIPE NCC ya opera partes clave de este entorno probatorio a través de los registros, la base de datos RIPE, RPKI, DNS inverso e información de enrutamiento o medición. La dirección útil es hacer que estas señales sean más fáciles de auditar para la portabilidad sin convertirlas en permisos para cada movimiento comercial. Un cliente debería poder producir un paquete claro de evidencia: este es el titular, este es el mantenedor autorizado, este es el estado inverso, esta es la intención actual de origen de ruta, este es el historial de rutas relevante, y estos son los contactos responsables del cambio. Si ese paquete es portátil, la admisión en la nube sigue siendo un proceso de producto en lugar de una trampa de dependencia.

Memoria de reputación y listas de permitidos empresariales

La escasez de IPv4 da precio a las direcciones. La reputación les da memoria. La Internet pública recuerda qué direcciones han enviado correo, alojado servicios, atraído quejas de abuso, aparecido en sistemas de fraude, pasado pruebas de penetración, servido API o estado integradas en sistemas de socios. Parte de esa memoria es formal. Parte es informal. Parte reside en productos comerciales de inteligencia de amenazas. Parte reside en las propias listas de permitidos de un cliente o en los documentos de control de cambios de sus socios. Un proveedor de nube que suministra la dirección también suministra parte del historial del cliente.

La memoria de reputación importa porque la salida obliga al cliente a elegir entre llevar su identidad pública existente y empezar de nuevo. Si el cliente usaba direcciones propiedad del proveedor, es posible que no pueda llevar esa identidad a otro proveedor. Debe pedir a los socios que actualicen las listas de permitidos, convencer a los sistemas de seguridad para que acepten nuevos rangos, monitorear los falsos positivos, explicar los cambios a los reguladores, volver a ejecutar pruebas y manejar incidentes de soporte. Para un sitio web de consumo esto puede ser manejable. Para el procesamiento de pagos, la administración pública, las integraciones sanitarias, los sistemas industriales, los portales de la cadena de suministro o los informes regulados, el cambio puede ser lento y políticamente costoso.

Las empresas a menudo subestiman esto porque las listas de permitidos están descentralizadas. Un equipo central de arquitectura puede conocer los puntos finales públicos. Puede no conocer a cada socio que ha fijado una dirección, cada sistema heredado que carece de flexibilidad DNS, cada regla de cortafuegos escrita por una filial, o cada plataforma del sector público que requiere un ticket para actualizar el acceso. La dirección del proveedor de nube se reproduce silenciosamente fuera del proveedor. El cliente no solo usa el conjunto del proveedor. Entrena a su ecosistema para que reconozca el conjunto del proveedor como su propia cara.

Esta es una forma poderosa de influencia negociadora. El proveedor no necesita amenazar al cliente. Solo necesita ser la fuente predeterminada de una identidad pública en la que los externos han aprendido a confiar. Las negociaciones de renovación tienen lugar entonces bajo la sombra de la interrupción operativa. El costo del cambio no es solo la factura de migración del proveedor. Incluye el restablecimiento de la reputación del cliente con cientos de contrapartes. Cuanto más grande y más regulado sea el cliente, más costoso se vuelve ese restablecimiento.

Los prefijos portátiles pueden reducir este problema, pero solo si se preparan con anticipación. Si el cliente trae su propio rango de direcciones a la nube desde el principio, puede preservar la identidad externa a través de los cambios de alojamiento. Los socios pueden necesitar ajustar rutas, certificados, DNS o expectativas de seguridad, pero la dirección básica puede permanecer. Eso hace que el cliente dependa menos del conjunto de un proveedor. También le da al cliente una posición más fuerte en las negociaciones de precio y servicio. La capacidad creíble de irse es a menudo más importante que el acto de irse.

RIPE NCC no puede gestionar la memoria de reputación. No debería decidir si una dirección es de confianza para un banco, un proveedor de correo o una pasarela del sector público. Pero puede ayudar a que las reclamaciones de continuidad sean más creíbles. Un registro preciso, registros de contacto limpios, una delegación inversa estable y una información coherente sobre el origen de ruta pueden respaldar la afirmación del cliente de que una identidad pública está genuinamente bajo su control y puede trasladarse de manera responsable. En un mercado escaso, esa prueba es parte de la resiliencia económica del cliente.

Acoplamiento de seguridad y el precio del tráfico limpio

Los proveedores de nube rara vez venden el direccionamiento público solo. Lo venden junto con cortafuegos, protección DDoS, filtrado de aplicaciones web, gestión de abusos, registro, controles de identidad, informes de cumplimiento y productos de red gestionados. Este paquete puede mejorar la seguridad. Las grandes plataformas ven los ataques temprano, operan a escala y pueden absorber tráfico que abrumaría a redes más pequeñas. Para muchos clientes, las direcciones públicas propiedad del proveedor vienen con una postura de seguridad que no podrían reproducir por sí solos. El paquete es valioso, y su valor es una de las razones por las que los clientes aceptan el control de la plataforma.

El acoplamiento de seguridad se convierte en una fuente de poder de direccionamiento cuando la identidad pública limpia de un servicio depende de permanecer dentro del sistema protector del proveedor. Un cliente que se muda no solo debe mover una dirección o cambiar una dirección. Debe recrear la capacidad de mitigación, la evidencia de registro, los procedimientos de incidentes, los contactos de abuso, las atestaciones de cumplimiento y las garantías al cliente. Si la dirección antigua pertenece al proveedor, el cliente puede perder tanto el número como el historial de seguridad adjunto. Si la dirección es portátil pero el servicio de seguridad no lo es, el cliente debe coordinar un traspaso cuidadoso. De cualquier manera, el camino de salida es más complejo que un cambio de enrutamiento.

La protección DDoS ilustra la lógica económica. Un proveedor puede ofrecer una mitigación siempre activa profundamente integrada con su perímetro público. Un cliente puede no saber cuánto de su disponibilidad depende de esa integración hasta que prueba otra opción. Si la identidad de dirección del cliente es propiedad del proveedor, un proveedor rival no puede simplemente heredar el punto final de confianza. Si el cliente usa BYOIP, el rival aún tiene que admitir el prefijo, alinear la evidencia de origen de ruta y proporcionar una mitigación comparable. La dirección, la ruta y el envoltorio de seguridad se convierten en un solo paquete comercial.

Este paquete puede ser procompetitivo cuando reduce los costos de entrada para los clientes. Una pequeña empresa puede desplegarse globalmente con una fuerte protección sin negociar tránsito, centros de limpieza y detalles registrales. Un servicio público puede lanzarse rápidamente. Un proveedor de software puede estandarizar sus operaciones. Sin embargo, el mismo paquete puede volverse anti-portátil cuando compras lo trata como un servicio de nube indivisible. Si la licitación pide tiempo de actividad y protección DDoS pero no evidencia de salida, el proveedor ganador puede suministrar un servicio técnicamente excelente que deje al comprador dependiendo de la identidad pública propiedad del proveedor.

El remedio es una mejor separación en la evidencia, no una separación artificial en la ingeniería. Sería absurdo decir a las plataformas que no pueden integrar direcciones y seguridad. La integración es parte del valor que proporcionan. Pero los clientes deberían poder ver qué partes del paquete son portátiles, cuáles están vinculadas a la cuenta y cuáles requieren nuevas pruebas en la salida. Una evaluación de resiliencia debería distinguir entre "el servicio puede reconstruirse" y "la identidad pública puede trasladarse con un riesgo aceptable". Son afirmaciones diferentes.

Para RIPE NCC, la cuestión relevante es de nuevo la integridad de la capa de evidencia pública. Si un prefijo propiedad del cliente se utiliza detrás de un producto de seguridad en la nube, los datos del registro y de RPKI deben hacer claro el control del cliente. Si el DNS inverso o el historial de enrutamiento se van a utilizar para respaldar las reclamaciones de continuidad, esa evidencia debería ser fácil de recuperar y entender. El registro no certifica el producto de seguridad. Preserva la evidencia de recursos que permite al cliente evitar confundir la comodidad de la seguridad con la cautividad permanente.

Contratación pública y clientes regulados

La contratación del sector público y de clientes regulados puede amplificar el poder de direccionamiento de los proveedores de nube porque estos compradores a menudo formalizan las decisiones operativas en contratos largos. Un ministerio, sistema hospitalario, universidad, banco, aseguradora o empresa de servicios públicos puede adquirir servicios en la nube a través de un marco que valora la seguridad, la resiliencia, la auditabilidad y la capacidad del proveedor. Esas son preocupaciones legítimas. Los grandes proveedores a menudo obtienen buenos resultados. Pero si el lenguaje de contratación trata el direccionamiento público como un servicio empaquetado sin exigir evidencia de portabilidad, el contrato puede endurecer la dependencia antes de que nadie se dé cuenta.

El problema no es la negligencia. Los equipos de compras suelen intentar reducir el riesgo. Las direcciones propiedad del proveedor pueden parecer más seguras que los recursos propiedad del cliente porque el proveedor asume la responsabilidad del aprovisionamiento, el enrutamiento y el soporte operativo. BYOIP puede parecer una excepción especializada que ralentiza la entrega. En un calendario de licitaciones, la comodidad tiene valor político. Un proyecto que se lanza a tiempo con conjuntos del proveedor puede ser celebrado. El problema de salida aparece años después, cuando el contrato está a punto de renovarse, un regulador pide un análisis de riesgo de concentración o un ejercicio de resiliencia requiere el movimiento de cargas de trabajo.

Las empresas reguladas enfrentan un problema similar. Los supervisores financieros, las autoridades de protección de datos, los organismos públicos de auditoría y los reguladores sectoriales piden cada vez más a las empresas que gestionen la concentración de externalizaciones, la resiliencia y la salida. Esas discusiones a menudo se centran en la ubicación de los datos, los derechos contractuales, la recuperación operativa y los servicios críticos. La identidad de dirección pública es menos visible. Sin embargo, para muchos servicios es parte de la resiliencia. Si una API de pagos, un portal público de reclamaciones o un panel operativo solo es accesible a través de direcciones propiedad del proveedor que cientos de contrapartes reconocen, la capacidad de reconstruir la computación en otro lugar puede no ser igual a la capacidad de restaurar el servicio en la práctica.

La contratación de nube pública también puede influir en el mercado privado. Cuando los grandes compradores gubernamentales aceptan como normal la identidad propiedad del proveedor, los integradores, consultores y proveedores reproducen esa norma. Las plantillas se difunden. Los documentos de seguridad describen los rangos de direcciones del proveedor como aceptables. Los procedimientos de listas de permitidos asumen el conjunto de la plataforma. Las empresas más pequeñas que sirven a clientes gubernamentales siguen entonces el patrón para reducir la fricción. Una decisión de compra se convierte en una convención de mercado, y la convención aumenta el poder de negociación de la plataforma.

Nada de esto significa que las licitaciones deban exigir que todas las cargas de trabajo usen prefijos propiedad del cliente. Eso sería un desperdicio y a veces imposible. La mejor pregunta es la proporcionalidad. Los servicios de alta dependencia deberían identificar si su identidad pública es portátil, qué evidencia lo demuestra, quién controla el DNS inverso, qué cambios de origen de ruta son necesarios, qué contrapartes tienen listas de permitidos y cuánto tiempo llevaría un cambio de dirección. Los servicios de menor riesgo pueden usar conjuntos propiedad del proveedor con una aceptación consciente del costo de salida. La cuestión no es que todas las direcciones deban ser portátiles. Es que los servicios importantes no deberían descubrir la no portabilidad solo cuando intentan irse.

RIPE NCC puede apoyar esto mediante una evidencia pública más clara y la educación, sin convertirse en un regulador de compras. Puede ayudar a los compradores a entender que los registros no son decorativos. Son infraestructura de continuidad. El hecho de que la región de RIPE NCC incluya más de 75 países hace que esto sea especialmente importante. La madurez del sector público varía ampliamente. Una evidencia común y comprensible del control de los recursos ayudaría a compradores y auditores a hacer las preguntas correctas incluso cuando carecen de equipos de red profundos.

Proveedores pequeños y la asimetría de la prueba

El poder de direccionamiento de los proveedores de nube no es solo una contienda entre grandes plataformas y grandes clientes. También afecta a las pequeñas empresas de alojamiento, a los proveedores regionales de nube, a las empresas de servicios gestionados y a los proveedores de infraestructura especializada. Estas empresas pueden atender a clientes que necesitan soporte local, comodidad en la soberanía de datos, conocimiento sectorial o flexibilidad de precios. Pueden ser técnicamente competentes y cercanas al cliente. Sin embargo, a menudo carecen del alcance global de rutas, la profundidad de producto BYOIP automatizado, la escala de seguridad y el reconocimiento en compras de las plataformas más grandes. La evidencia de portabilidad de direcciones puede ayudarles a competir o dejarlos atrapados detrás de sistemas privados de admisión.

Un cliente que posee un prefijo limpio y puede demostrar el control puede considerar un proveedor más pequeño con menos temor. Puede pedir al proveedor que anuncie el rango, mantenga el DNS inverso, alinee RPKI, soporte los arreglos DDoS y documente el camino de salida. El proveedor aún debe ser capaz, pero la identidad pública del cliente no está bloqueada en la plataforma incumbente. Por el contrario, un cliente que se ha construido sobre el conjunto de direcciones de un proveedor a hiperescala puede descubrir que mudarse a un proveedor regional significa un doloroso restablecimiento de la identidad pública. El proveedor regional compite entonces no solo en calidad de servicio, sino contra la memoria de las direcciones del incumbente en el ecosistema del cliente.

La asimetría de la prueba también afecta a las negociaciones. Los grandes proveedores tienen equipos que pueden interpretar los registros, validar el control del prefijo y guiar a los clientes a través de los cambios de origen de ruta. Los proveedores pequeños pueden depender de procesos manuales. Los clientes pueden confiar más en la decisión de admisión de la gran plataforma que en sus propios registros. Si la plataforma dice que un prefijo no está listo, el cliente puede asumir que el problema es el prefijo en lugar de las condiciones del producto de la plataforma. Si un proveedor más pequeño dice que la misma evidencia es utilizable, el cliente puede preocuparse por el riesgo. El estándar de admisión privado de la plataforma más grande se convierte en un punto de referencia del mercado, incluso cuando refleja el diseño del producto en lugar de la verdad universal del enrutamiento.

Esto no es un argumento para rebajar los estándares de enrutamiento. Un mercado en el que cualquiera puede afirmar el prefijo de cualquier otro sería inseguro. El punto es que la prueba no debería ser innecesariamente específica de la plataforma. Si un titular de recursos tiene datos registrales precisos, contactos mantenidos, información de origen de ruta válida y una autorización clara, esa evidencia debería ser inteligible para muchos proveedores. Un proveedor más pequeño no debería tener que hacer ingeniería inversa de la lista de verificación privada de una plataforma a hiperescala para convencer a un cliente de que su propio prefijo es utilizable.

La escasez de direcciones intensifica esta asimetría porque los clientes que aún no poseen espacio IPv4 pueden no tener un camino realista hacia una identidad pública independiente, excepto mediante transferencias o acuerdos de arrendamiento. El costo de obtener un rango portátil puede ser alto. La carga administrativa puede ser desconocida. Los conjuntos propiedad del proveedor aparecen entonces como la opción racional. Para muchos servicios de bajo riesgo lo son. Pero cuando el punto final público del cliente es estratégico, la ausencia de identidad portátil da al proveedor incumbente un derecho sobre el excedente de negociación futuro. El precio de la comodidad de la dirección se paga más tarde mediante opciones reducidas.

Un entorno probatorio saludable de RIPE NCC no garantizaría el éxito de los pequeños proveedores. Simplemente haría la portabilidad menos misteriosa. El registro no debería inclinar el mercado hacia ninguna clase de proveedor. Pero debería hacer que el control de los recursos sea lo suficientemente claro para que los clientes puedan comparar ofertas por los méritos del servicio y no por el temor de que su identidad pública no pueda sobrevivir al movimiento. En términos institucionales, el libro de registro debería reducir la prima por ser la plataforma que ya aloja la dirección del cliente.

Por qué el poder de direccionamiento en la nube no es lo mismo que el acaparamiento de direcciones

Es tentador medir el poder de direccionamiento en la nube contando quién posee recursos IPv4. El inventario importa. Los grandes conjuntos permiten a las plataformas suministrar direcciones a los clientes al instante, absorber el crecimiento y mantener productos regionales. Los precios de IPv4 hacen que esos conjuntos sean activos valiosos en el balance, incluso cuando no se informan de manera que aísle la economía de las direcciones. Pero el inventario es solo una parte del poder. El poder más duradero proviene de convertir el uso de direcciones en una relación gestionada.

Un proveedor con menos direcciones pero una fuerte integración de cuenta aún puede crear dependencia. Si los clientes adjuntan las direcciones del proveedor a servicios críticos, las escriben en las listas de permitidos de los socios, confían en las prácticas de DNS inverso del proveedor, usan su perímetro de seguridad y construyen automatización alrededor de sus API, el proveedor gana influencia incluso sin dominar todo el mercado de direcciones. Por el contrario, un gran poseedor de direcciones que no media en la identidad del cliente puede tener menos efecto de bloqueo. La pregunta comercial no es solo "¿quién tiene los números?" Es "¿quién controla la evidencia, los tiempos y los rituales operativos que hacen que esos números sean utilizables?"

Por eso BYOIP puede coexistir con el bloqueo. Un proveedor puede permitir a los clientes traer prefijos y aun así preservar la influencia a través de las condiciones de la cuenta, las limitaciones regionales, los plazos de revisión, los requisitos de origen de ruta, el acoplamiento de seguridad y los procedimientos de salida. Algunas de esas restricciones están justificadas. Las redes en la nube son complejas, y la admisión descuidada de prefijos puede crear riesgo de secuestro, inestabilidad o abuso. Pero la existencia de un producto de portabilidad no debería poner fin al análisis. La verdadera prueba es si el cliente puede usar la misma evidencia para obtener un servicio creíble de más de un proveedor en un tiempo comercialmente relevante.

El acaparamiento de direcciones también implica un villano simple. El poder de direccionamiento en la nube es más difuso. Los clientes eligen la comodidad. Los integradores favorecen los diseños repetibles. Los equipos de seguridad prefieren plataformas conocidas. Compras recompensa la entrega. Los reguladores a veces piden resiliencia pero dejan la identidad pública vaga. Los registros mantienen la evidencia pero puede que no la empaqueten para la portabilidad. Cada actor se comporta sensatamente dentro de su propio dominio. El resultado combinado puede seguir siendo una reducción de las opciones del cliente.

La economía se asemeja a otros mercados donde un recurso común se incrusta en un envoltorio de servicio. Un número de teléfono, un nombre de dominio, una credencial de pago o un certificado de identidad pueden ser portátiles en principio, pero el cambio depende de registros, pruebas, contratos, propagación y reconocimiento de terceros. Al titular no le importa que exista un derecho en teoría si ejercerlo crea semanas de interrupción. El proveedor de nube que hace que la configuración inicial sea perfecta y la salida posterior intrincada ha ganado poder a través del proceso más que de la propiedad por sí sola.

Para RIPE NCC, esta distinción es vital. Si el problema fuera meramente el acaparamiento, la respuesta podría ser la redistribución o el racionamiento. Ese no es el camino correcto para un registro regional de Internet cuya fortaleza reside en la coordinación neutral. Si el problema es la portabilidad de la evidencia, la respuesta son mejores registros, señales más claras y herramientas de continuidad más fiables. El libro de registro no debería convertirse en un planificador de mercado. Debería hacer más difícil que la escasez y la confusión se monetaricen como cautividad.

La economía institucional de un libro de registro delgado

Un libro de registro delgado puede ser una institución fuerte cuando hace bien su trabajo específico. El registro de RIPE NCC no necesita decidir la equidad económica de cada contrato de nube para influir en los resultados del mercado. Al mantener registros precisos y sistemas de evidencia relacionados, da forma al costo de verificación. El costo de verificación es un impuesto oculto sobre el cambio. Cuando es bajo, los clientes pueden probar ofertas, mover servicios y disciplinar a los proveedores. Cuando es alto, los clientes permanecen con los incumbentes porque demostrar el derecho a moverse es demasiado lento, demasiado técnico o demasiado incierto.

Este es un problema clásico de economía institucional. Los mercados funcionan mejor cuando las reclamaciones de tipo propiedad, las responsabilidades y las autorizaciones pueden verificarse a bajo costo. Las direcciones IPv4 no son propiedad ordinaria, y el registro debe evitar un lenguaje que sugiera una propiedad absoluta. Sin embargo, los clientes y los proveedores aún necesitan expectativas estables. ¿Quién es responsable del recurso? ¿Quién puede autorizar una ruta? ¿Quién controla la delegación inversa? ¿Quién debería recibir los contactos de abuso? ¿Qué registro es el actual? Si las respuestas requieren una interpretación a medida, la parte con el departamento legal y técnico más grande gana.

Las plataformas de nube prosperan al reducir muchos costos de transacción. Reducen la necesidad de negociar hardware, coubicación, tránsito, mitigación DDoS y operaciones rutinarias. Pero pueden aumentar otro costo de transacción: el costo de irse con la identidad pública intacta. Un libro de registro público delgado contrarresta esto al hacer que las reclamaciones independientes del cliente sean más fáciles de establecer. No suprime los contratos de plataforma. Da al cliente una opción externa creíble.

La distinción entre libro de registro y guardián no es, por tanto, un eslogan. Un guardián concede permiso según su discreción. Un libro de registro registra hechos y autorizaciones de manera que permite que muchas partes se coordinen. Si RIPE NCC intentara dictar la admisión en la nube, debilitaría su neutralidad y crearía nuevas disputas. Si descuidara el valor de portabilidad de sus registros, dejaría a los clientes dependientes de guardianes privados. El camino intermedio es disciplinado: mantener el registro delgado, pero hacer que la evidencia sea limpia, actual y fácil de transportar.

Esto también protege la continuidad de la red en funcionamiento. Internet no mejora con un formalismo abrupto que trata cada defecto administrativo como una razón para interrumpir el servicio. Los clientes, los proveedores y las redes necesitan continuidad mientras se mejoran los registros. Pero la continuidad no debe convertirse en una excusa para datos obsoletos que atrapan a los titulares en viejos acuerdos. La tarea del registro es apoyar el movimiento responsable: suficiente estabilidad para que los servicios no fallen, suficiente claridad para que la dependencia pueda ser cuestionada y suficiente neutralidad para que no tome partido comercial.

En la región de RIPE NCC, este enfoque es particularmente relevante porque la adopción de la nube se cruza con sistemas legales variados, culturas de contratación pública e historiales de direcciones heredadas. Una sola regla pesada fallaría. Una mejor capa de evidencia viajaría a través de estas diferencias. Permitiría a un hospital en un país, una fintech en otro, una nube regional en un tercero y un ministerio público en otro lugar utilizar la misma prueba básica al discutir la portabilidad de direcciones. Ese es el poder silencioso de un buen libro de registro.

Lo que debería contener un estándar de evidencia de portabilidad

Un estándar útil de evidencia de portabilidad no exigiría que RIPE NCC certifique que un proveedor de nube debe aceptar un prefijo. Describiría la evidencia que un titular de recursos debería poder reunir antes, durante y después de un despliegue en la nube. Sería práctico, no grandioso. Ayudaría a los equipos de compras, auditores, proveedores y clientes a distinguir entre la identidad propiedad del proveedor y la identidad controlada por el cliente. Daría a los compradores más pequeños una lista de verificación que no dependa de un equipo de cuenta de una hiperescala.

El primer elemento es la claridad del titular del recurso. El cliente debería poder mostrar el registro actual, los contactos mantenidos, la organización responsable y la cadena de autoridad para los cambios. Si el recurso se posee a través de un LIR patrocinador o una entidad relacionada, el cliente debería entender lo que eso significa para la admisión y salida de la nube. Los acuerdos comerciales ambiguos deben aclararse antes de que un servicio crítico dependa del rango. Un nombre en una base de datos no es suficiente si nadie sabe quién puede autorizar el cambio.

El segundo elemento es la preparación del origen de ruta. El titular debería saber qué sistema autónomo está autorizado para originar el prefijo, cómo se mantienen los ROAs, qué longitud máxima se permite y cómo encaja el origen del proveedor de nube previsto en el registro. Esto no significa que cada cliente deba convertirse en un experto en enrutamiento. Significa que la evidencia debería ser lo suficientemente accesible para que una verificación de admisión en la nube no sea la primera vez que el cliente descubre un conflicto. La validación del origen de ruta se ha vuelto demasiado importante como para dejarla para después.

El tercer elemento es el control del DNS inverso. Los clientes deberían saber quién controla la delegación inversa, qué convenciones de nomenclatura se utilizan, cómo se realizan los cambios y cómo afectan esos cambios al correo, las herramientas de seguridad y las verificaciones de los socios. El DNS inverso no es un ejercicio de marca. Es parte de la pila de identidad pública. Si una dirección propiedad del proveedor tiene un nombramiento inverso controlado por el proveedor, el cliente debería reconocerlo como una compensación de portabilidad. Si un prefijo propiedad del cliente tiene un nombramiento inverso controlado por el cliente, debería documentarse como un activo de continuidad.

El cuarto elemento es el historial de rutas y reputación. Un cliente que se prepara para mudarse debería poder revisar dónde se ha visto su prefijo, cómo se ha originado y si algún problema de reputación podría afectar la admisión o aceptación. La información de enrutamiento y medición de RIPE NCC puede apoyar este análisis sin pretender juzgar la calidad comercial de un proveedor. El objetivo es reducir las sorpresas. Una sorpresa sobre el historial de rutas durante una ventana de migración es un costo evitable.

El quinto elemento es el procedimiento de salida de la cuenta. Si el prefijo se utiliza en una plataforma de nube, el cliente debería documentar cómo retirarlo, moverlo a otra cuenta, cambiar la autorización de origen, actualizar los productos de seguridad, preservar los registros y manejar el intervalo entre proveedores. Esto está en parte fuera del registro. Pero la evidencia registral debería ser referenciada en el procedimiento. El cliente debería saber qué registros públicos deben cambiar y cuáles deben permanecer estables.

Un estándar así sería modesto pero útil. No resolvería la concentración de la nube. No haría que IPv4 fuera abundante. No eliminaría las revisiones de seguridad legítimas que realizan los proveedores. Sin embargo, reduciría el misterio privado en torno a la portabilidad de las direcciones. En un mercado escaso, reducir el misterio es un acto competitivo incluso cuando la institución permanece neutral.

Una agenda constructiva para RIPE NCC

Una agenda constructiva para RIPE NCC comenzaría con la visibilidad de la portabilidad. El registro podría facilitar a los miembros y titulares de recursos ver, en un solo lugar, la evidencia que probablemente importará en un proceso de admisión o salida de la nube: información del titular, contactos mantenidos, estado del DNS inverso, estado RPKI/ROA, orígenes de ruta observados y advertencias operativas relevantes. Esto no sería una certificación. Sería una vista de preparación. Su valor residiría en reducir el costo de hacer las preguntas correctas.

El siguiente paso sería una guía escrita para compradores, no solo para especialistas en redes. Muchas decisiones sobre la nube las toman los equipos de compras, riesgos, legales y de entrega digital. Necesitan un lenguaje que distinga las direcciones propiedad del proveedor de los prefijos controlados por el cliente sin necesidad de convertirse en ingenieros de enrutamiento. Una breve guía pública podría explicar por qué "IP estática" no es lo mismo que identidad portátil, por qué importan el DNS inverso y los ROAs, y cómo las decisiones sobre direcciones afectan la salida. Dicha guía sería especialmente útil para los compradores del sector público y regulados.

RIPE NCC también podría fomentar paquetes de evidencia estandarizados para la planificación de BYOIP y de salida. Los proveedores seguirían siendo libres de establecer las reglas de sus productos, pero un paquete de evidencia común ayudaría a los clientes a comparar los requisitos. Podría incluir los datos registrales actuales, los contactos de autorización, el estado RPKI, los ASN de origen previstos, el control del DNS inverso y los procedimientos de cambio. Si los principales proveedores siguen pidiendo verificaciones adicionales, es su derecho. Pero el cliente partiría de una base de prueba común en lugar de la incertidumbre.

La medición también puede ayudar. La información de enrutamiento y medición de RIPE NCC puede iluminar cómo se originan los prefijos, dónde ocurren los cambios y cuán visibles son las rutas durante la migración. El objetivo no debería ser calificar políticamente a los proveedores. Debería ser ayudar a los titulares a entender la historia operativa y el riesgo. Un cliente que puede ver su historial de rutas está mejor preparado para discutir la admisión con una plataforma de nube o un proveedor regional. Un cliente que no puede verlo debe confiar en quien ofrezca la interpretación más segura.

Por último, RIPE NCC puede convocar sin imponer. Puede reunir a proveedores de nube, redes regionales, empresas, compradores del sector público y equipos de seguridad en una discusión práctica sobre la evidencia de portabilidad. La agenda debería ser concreta: reducir la ambigüedad evitable, mejorar la continuidad y mantener la prueba registral utilizable en todas las plataformas. Dicha convocatoria sería coherente con un papel de coordinación. No exigiría que el registro juzgara directamente el poder de mercado.

La objeción probable es que esta agenda es demasiado modesta para la escala de la concentración de la nube. Pero la modestia es una virtud aquí. El registro no puede hacer que IPv4 sea abundante, y no debería convertirse en una autoridad de competencia. Lo que puede hacer es asegurarse de que la capa de evidencia compartida funcione para la parte más débil en una disputa de portabilidad. Eso no lo es todo. Sigue siendo significativo. Muchas formas de poder de mercado sobreviven porque el costo de demostrar una alternativa es demasiado alto. Reducir ese costo es una contribución legítima del registro.

El libro de registro delgado y la cuenta de nube

La cuenta de nube es una invención comercial notable. Convierte la infraestructura en un conjunto de servicios programables. Permite a los clientes consumir redes globales sin construirlas. Envuelve la complejidad en API y contratos de soporte. Ha permitido a muchas organizaciones en la región de RIPE NCC desplegar servicios que antes habrían requerido mucho más capital y experiencia. La crítica del poder de direccionamiento de los proveedores de nube no debería oscurecer ese logro.

Pero la cuenta no es lo mismo que el libro de registro público de Internet. La cuenta es una relación con un proveedor. El libro de registro es una herramienta de coordinación utilizada por muchas partes. Cuando la identidad de dirección pública se absorbe demasiado completamente en la cuenta, el cliente puede ganar comodidad mientras pierde su posición independiente. Puede actuar rápidamente dentro de la plataforma, pero le cuesta demostrar su identidad fuera de ella. Esa es la disyuntiva económica central.

La escasez de IPv4 agudiza la disyuntiva. Si las direcciones públicas fueran abundantes, un cliente podría empezar de nuevo más fácilmente. La escasez hace que la identidad antigua sea valiosa. Hace que los historiales de direcciones sean pegajosos. Hace que los conjuntos de los proveedores sean atractivos y que los rangos portátiles sean costosos. Hace que cada verificación de admisión sea más trascendental. La escasez no decide quién debería ganar el mercado de la nube, pero aumenta el valor de toda institución que pueda reducir los costos de cambio. RIPE NCC es una de esas instituciones porque sus registros son parte de la cadena de pruebas.

La conclusión correcta no es ni el fatalismo de plataforma ni el activismo registral. Los proveedores de nube seguirán suministrando direcciones públicas, productos BYOIP y paquetes de seguridad. Los clientes seguirán eligiendo la comodidad. Algunas cargas de trabajo no justificarán la identidad portátil. Las autoridades de competencia, los organismos de contratación y los reguladores abordarán las cuestiones más amplias de concentración a través de sus propias herramientas. La responsabilidad de RIPE NCC es más concreta: mantener la evidencia de recursos precisa, continua y lo suficientemente utilizable para que los clientes puedan demostrar su identidad pública cuando sea necesario.

Si el libro de registro es fuerte, un cliente puede pedir servicio a un proveedor de nube sin renunciar a su futuro. Puede traer un prefijo, mostrar el control, alinear la evidencia de origen de ruta, gestionar el DNS inverso y preservar la reputación a través del movimiento. Puede decidir conscientemente cuándo los conjuntos propiedad del proveedor valen el costo de salida. Puede hacer que compras compare no solo el tiempo de actividad de hoy, sino la posición negociadora de mañana. El resultado no es una libertad perfecta. Es un mercado más honesto.

Si el libro de registro es débil, los proveedores de nube no necesitan apoderarse de nada. Pueden dejar que la escasez, la incertidumbre y la inercia del cliente hagan el trabajo. Los conjuntos propiedad del proveedor se convierten en la cara pública predeterminada. BYOIP sigue siendo una ruta especializada para aquellos con suficiente experiencia. Las listas de permitidos y la memoria de reputación se acumulan. Los paquetes de seguridad profundizan la dependencia. Los marcos del sector público normalizan el patrón. En la renovación, el proveedor no solo vende computación y seguridad, sino también el alivio de la interrupción que causaría la salida.

Esa es la economía del poder de direccionamiento de los proveedores de nube en la región de RIPE NCC. No es solo el volumen de direcciones. Es la conversión de la identidad pública escasa en un servicio vinculado a la cuenta, una admisión privada y un hábito de contratación. La respuesta no es convertir a RIPE NCC en un policía de la nube. Es hacer que el libro de registro común haga su trabajo silencioso lo suficientemente bien como para que la portabilidad sea real antes de que se necesite con urgencia. En un mundo de IPv4 escaso, ese trabajo silencioso es uno de los pocos controles prácticos sobre la dependencia de las direcciones.