
Arrendar un /24 de principio a fin: el ciclo de vida operativo para titular y cliente
Un recorrido paso a paso por toda la vida de un /24 arrendado: el trabajo de registro, RPKI y gestión de abusos que decide si el arrendamiento funciona, tanto para el operador que arrienda espacio como para el que lo recibe.
Artem Kohanevich
Cofundador y CEO de IPbnb
Última actualización
Índice
elemento
La mayoría de lo que se escribe sobre el mercado secundario de IPv4 se queda en la economía. Pero lo que realmente determina si un arrendamiento funciona, o si se convierte en un problema de soporte y reputación para ambas partes, ocurre en el registro, en RPKI y en el buzón de abusos. Así que, en lugar de hablar del mercado en abstracto, sigamos a un único /24 a lo largo de toda su vida: desde una asignación inactiva en un registro de RIPE, pasando por el acuerdo, su puesta en servicio y un año de operación, hasta su devolución al final del plazo.
Aquí hay dos operadores, y probablemente usted sea uno de ellos. Uno tiene un /24 que no ha cursado tráfico desde un rediseño de red basado en IPv6 y CGNAT: limpio, registrado, pagado y sin generar nada. El otro está sumando abonados este trimestre, se ha quedado sin espacio y se enfrenta a una lista de espera de RIPE que ofrece un único /24 tras una espera de 12 a 24 meses. El arrendamiento los conecta.
Fase 1: preparación
Lado del titular: ¿está el bloque realmente listo para arrendarse? Una subred inactiva rara vez está tan limpia como cree su titular. Antes de generar ingresos necesita una auditoría, el mismo trabajo independientemente de con quién se arriende:
Reputación e historial en listas negras. Compruebe el prefijo en Spamhaus DROP y SBL, en las DNSBL habituales y cualquier abuso histórico asociado al rango. Un bloque sin actividad desde 2021 puede seguir arrastrando inclusiones en listas por lo que funcionara en él antes. Consulte nuestras notas sobre herramientas de reputación de IP.
Higiene del registro. Confirme que el
inetnum, elstatus:, los objetos de maintainer y elabuse-cestán actualizados, y que no quedan objetosroute:obsoletos que apunten a un AS de origen que ya no anuncia el espacio.Estado de RPKI. Compruebe si ya existe un ROA y para qué origen: un ROA residual del anuncio anterior al rediseño invalidará el futuro anuncio del cliente si no se actualiza.
Residuos de geolocalización. Los datos antiguos de geofeed o las bases de datos de geolocalización de terceros pueden seguir situando el bloque donde ya no está, algo que el cliente nota de inmediato en forma de usuarios mal geolocalizados.
Nada de esto es un obstáculo: es preparación. Pero supone tiempo real de ingeniería, y saltárselo es la forma de empezar un arrendamiento con un cliente que no puede enviar correo el primer día.
Lado del cliente: por qué está aquí. La lista de espera no es una vía de suministro para una red que crece ahora: un /24, solo para LIR, una cola larga y sin garantía de plazos. La alternativa realista es CGNAT, que tiene un coste medible y visible para el cliente final, no gratuito:
Agotamiento de bloques de puertos en picos de concurrencia, y mapeo EIM/EIF que rompe las conexiones entrantes y las aplicaciones peer-to-peer.
Atribución de abusos que ahora obliga a correlacionar puerto de origen y marca de tiempo con los registros de NAT para cada denuncia: un coste que crece con el número de abonados.
Reputación y geolocalización compartidas, de modo que un solo abonado degrada la dirección para todos los que están detrás de ella.
El espacio arrendado evita todo esto: en la red se comporta exactamente igual que el espacio propio; usted anuncia el prefijo y el enrutamiento no lo trata de forma diferente. La diferencia está en la documentación y en el modelo de confianza.
Fase 2: el acuerdo y el modelo de confianza
Un arrendamiento es una autorización, no una transferencia. El titular conserva el recurso en el registro de RIPE; el cliente obtiene el derecho a anunciarlo. Dos documentos lo recogen:
La Letter of Authorization (LOA): la declaración firmada del titular de que la organización del cliente y su AS de origen pueden anunciar el prefijo. Los proveedores de tránsito, los IXP y los peers la solicitan para justificar sus filtros, y muchos siguen basándose en ella incluso donde se ha desplegado RPKI.
El contrato de arrendamiento: plazo, precio, uso permitido, obligaciones en materia de abusos y qué ocurre en caso de incumplimiento o rescisión anticipada.
La confianza es mutua. El titular confía en que el cliente no hará que el bloque acabe en listas negras ni originará nada que atraiga denuncias de abuso contra el nombre y el AS del titular. El cliente confía en que el titular no retirará el ROA ni la LOA a mitad del plazo, no arrendará dos veces el mismo espacio y controla realmente lo que dice controlar. Por eso la auditoría de preparación también es importante para el cliente: antes de anunciar, verifique de forma independiente el historial de enrutamiento del prefijo en RIPEstat y bgp.tools en lugar de fiarse ciegamente de la LOA. Nuestra guía de seguridad del arrendamiento para titulares de bloques cubre la parte del titular.
Fase 3: puesta en servicio del prefijo
Aquí es donde el arrendamiento se hace realidad, y donde se producen la mayoría de los fallos técnicos.
Creación del ROA. El titular, como titular registrado, crea un ROA que autoriza el ASN de origen del cliente, en el LIR Portal de RIPE NCC, dentro de Resource Certification. La trampa es
maxLength: si se fija igual a la longitud del prefijo (un ROA de /24 con maxLength /24), el cliente no puede desagregar; si se deja demasiado holgado, se autorizan prefijos más específicos que abren la puerta a un secuestro mediante prefijos más específicos. Para un único /24 destinado a un solo cliente, maxLength debe coincidir con el prefijo, salvo que el cliente tenga un motivo declarado para anunciar prefijos más específicos.Objeto route del IRR. Un objeto
route:en el IRR de RIPE que coincida con el prefijo y el AS de origen del cliente, para que los proveedores de tránsito que generan filtros a partir de datos del IRR acepten el anuncio.El anuncio. El cliente configura el prefijo y lo origina desde el AS autorizado. Con un ROA válido, es válido según RPKI; sin el objeto del IRR y la LOA, los proveedores de tránsito estrictos lo seguirán descartando.
Validación. Ambas partes confirman la propagación y la validez RPKI: bgp.tools y RIPEstat para la visibilidad, y una comprobación con Routinator o Cloudflare para el estado de validación. El titular vigila que no aparezca ningún origen inesperado mientras el espacio se sigue anunciando.
Para el paso a paso en el registro, la guía de nuestro Centro de ayuda sobre la configuración de una subred arrendada y su ROA explica el procedimiento.
Fase 4: convivir con el arrendamiento
Un /24 arrendado no es algo que se configure y se olvide para ninguna de las partes, y el reparto de responsabilidades debe constar de forma explícita en el contrato.
Abusos y reputación. Las denuncias llegan al
abuse-cregistrado, que normalmente apunta al titular aunque sea el cliente quien controla el tráfico. Ambas partes necesitan un procedimiento definido: quién recibe las denuncias, quién investiga, con qué rapidez debe actuar el cliente y qué provoca una suspensión. Un cliente que deja que el bloque acabe en listas negras ha dañado un activo que no es suyo; un titular sin procedimiento de escalado acaba gestionando la correspondencia con Spamhaus.Geolocalización. Los nuevos usuarios se geolocalizan allí donde las principales bases de datos creen que está el bloque. Publique datos de geofeed precisos (una referencia
geofeed:en elinetnum, conforme a los RFC de geofeed) y envíe correcciones a los grandes proveedores de geolocalización: es un punto de coordinación continuo, no una tarea puntual.Supervisión. Comprobaciones continuas de desviaciones en la validez RPKI, orígenes inesperados y nuevas entradas en listas negras. Un ROA caducado o un cambio en el filtro de un proveedor de tránsito puede dejar el prefijo parcialmente inaccesible sin una causa evidente.
La carga operativa de esta fase (incorporación, ciclo de vida del ROA, abusos, reputación, renovaciones) es la esencia de cualquier arrendamiento, y hay más de una forma de asumirla. Un titular puede gestionarla internamente, manteniendo toda la visibilidad y la rentabilidad pero montando el IPAM, el servicio de gestión de abusos y el trabajo de registro como una pequeña operación propia; delegarla en un bróker, lo que elimina la carga diaria pero suele costar visibilidad, control de la relación y rentabilidad; o apoyarse en una plataforma gestionada que mantiene la relación y los ingresos en manos del titular mientras asume las herramientas y el cumplimiento normativo.
El cliente tiene una elección paralela: gestionar el espacio arrendado junto con su propia gestión de direcciones o integrarlo en lo que ya gestiona su enrutamiento y sus abusos. Ninguna opción es automáticamente la correcta: las tareas son las mismas en todos los casos; la cuestión es dónde recae la carga.
Fase 5: final del plazo: renovación, devolución y recuperación
Los arrendamientos terminan, y el cierre tiene su propia ingeniería. En una renovación, haga coincidir la caducidad del ROA con las fechas del contrato para que el prefijo no quede inválido según RPKI en el intervalo. En una devolución, el cliente retira el anuncio, el titular revoca o reescribe el ROA y elimina el objeto route: del cliente, y se revoca la LOA, en ese orden; de lo contrario, se crea una ventana con un estado válido pero no anunciado o inválido pero anunciado. Y la parte que los titulares subestiman: las secuelas en la reputación. Un bloque vuelve con la reputación que le haya dejado el cliente. Si se ha usado bien, vuelve limpio; si no, el titular hereda la limpieza antes de volver a arrendarlo. Ese es el argumento más sólido para que las cláusulas de abusos y suspensión de la fase 4 sean reales y se apliquen, y no simple texto estándar.
La tercera posición: gestionarlo usted mismo
Si se sigue el ciclo de vida hasta el final, surge una pregunta para cualquier operador que ya tiene espacio y presta servicio a clientes: ¿por qué ser una parte más en la plataforma de otro cuando podría gestionar la relación de arrendamiento con su propia marca? Puede hacerlo, y el ciclo de vida descrito es la especificación de lo que se necesita: IPAM, un ciclo de vida de LOA y ROA gestionado a escala, un servicio de gestión de abusos que cumpla los plazos de tramitación de denuncias, procesos de exclusión de listas negras y de reputación, facturación, renovaciones y el cumplimiento normativo que lo respalde. Nada de ello es exótico; todo es continuo, y es la parte que no se refleja en el precio de arrendamiento. Esa es la verdadera decisión entre desarrollarlo internamente o asociarse, y los centros de datos y proveedores de hosting, que ya actúan como proveedores de conectividad para sus clientes y a menudo tienen espacio propio, son los candidatos más claros.
Lo que enseña el ciclo de vida
El mercado secundario de IPv4 es más viable de lo que sugiere su reputación, pero el trabajo es real, y es trabajo de registro y enrutamiento, no de negociación. Tanto si monetiza un bloque sin uso como si arrienda lo que necesita este trimestre o gestiona su propia operación de arrendamiento, la ingeniería es la misma: registros limpios, RPKI válido, una LOA defendible, una gestión de abusos rigurosa y un cierre limpio.
Si lo hace bien, un /24 arrendado se comporta como cualquier otro prefijo de su tabla. Si lo hace mal, tendrá un problema de reputación con el nombre de otro. En cuanto a la economía, fije el precio con datos de mercado actualizados y no con una cifra aislada: es el ciclo de vida descrito, y no la tarifa, lo que decide si un acuerdo merece la pena.







