¿Necesita un ASN para anunciar IPv4 arrendado? Comparativa de cuatro vías de enrutamiento

No. No siempre.

Necesita un ASN en algún punto de la cadena de enrutamiento, porque así es como BGP identifica quién está autorizado a originar su prefijo. Pero no tiene por qué ser suyo. Existen cuatro vías de anuncio, y tres de ellas funcionan sin que usted tenga que presentar nunca una solicitud a un registro regional de Internet.

Cuál le conviene depende de cuántos proveedores de tránsito tenga, de dónde se ejecute la carga de trabajo y de cuánto control necesite sobre el tráfico entrante. Esta es toda la decisión en una sola pantalla.

El resto de esta guía recorre cada vía, la documentación que cambia con ella y la única regla técnica que determina si su subred se enruta o no. Si se encuentra en una fase anterior del proceso y prefiere ver primero el panorama completo, empiece por el flujo completo de arrendamiento.

Primero, la contradicción que nadie en este mercado menciona en voz alta

Lea en paralelo la documentación de dos proveedores de arrendamiento y obtendrá respuestas opuestas a la misma pregunta.

Algunos arrendadores tratan el ASN como un requisito imprescindible. RapidSeedbox no completa un arrendamiento sin él e indica a los clientes que no lo tienen que lo obtengan de su proveedor de VPS o de hosting. Voldeta afirma sin rodeos que, para alquilar una subred IPv4 y anunciarla, es necesario disponer de un ASN, propio o de un tercero, y añade que el ASN debe tener una reputación limpia y no figurar en Spamhaus.

Otros proveedores se niegan a que use el suyo. Leaseweb anuncia los prefijos de sus clientes exclusivamente desde números de AS de Leaseweb; anunciar un prefijo con el ASN propio del cliente no es una opción. En su lugar, solicitan mnt-routes delegados en los bloques de RIPE o una Letter of Authorization del titular registrado.

Ninguno de los dos bandos se equivoca. Describen dos vías distintas, y cada uno ha dado por hecho, sin decirlo, que la suya es la única. De esa suposición procede la mayor parte de la confusión en torno al IPv4 arrendado.

Qué hace realmente un ASN en este contexto

Sáltese esta sección si ya trabaja con BGP.

Un Autonomous System Number identifica un conjunto de prefijos IP que funcionan bajo una única política de enrutamiento. Cuando dos redes intercambian rutas, se identifican mediante su ASN y anuncian qué prefijos pueden alcanzar. El RFC 1930 describe el ASN como la unidad de política de enrutamiento en el enrutamiento exterior, y sigue siendo la definición breve más precisa disponible.

Se utilizan dos formatos. El espacio original de 16 bits ofrecía 65.536 números y está prácticamente agotado a nivel de los RIR; las nuevas asignaciones proceden del espacio de 32 bits definido en el RFC 6793, que sustituyó al RFC 4893. De vez en cuando vuelven a circular números de 16 bits devueltos o recuperados, pero lo previsible es que reciba un ASN de 32 bits.

Para una subred arrendada, solo importa una propiedad del ASN: es la identidad asociada a la ruta. Quien origina su prefijo en BGP le asigna su número de AS. Ese número tiene que coincidir después con lo que dice la documentación. Todo lo que sigue se deriva de esa única restricción.

Vía 1: su propio ASN y su propia sesión BGP

Solicita un número de AS a su RIR, establece sesiones BGP con sus proveedores de tránsito y origina usted mismo la subred arrendada.

Qué cambia en la documentación. El titular de las IP, o la plataforma de arrendamiento en su nombre, emite una LOA a nombre de su ASN, crea o actualiza el objeto route del IRR que vincula el bloque a su ASN y crea el ROA que autoriza a su ASN a originar el prefijo. Los tres apuntan a usted. La mecánica de esa autorización, y por qué los titulares conservan el control en todo momento, se explica en nuestra guía sobre quién emite la LOA y por qué los titulares mantienen el control.

Qué gana. Multihoming real. Puede mover la subred entre proveedores de tránsito sin cambiar la numeración, gestionar el tráfico entrante con controles de longitud de prefijo y de AS-path, y resistir la caída de un proveedor de tránsito sin perder sus direcciones. Para un ISP o un operador de telecomunicaciones, esto no es una preferencia: es la razón de ser de su tabla de enrutamiento.

Qué cuesta. Según el RIPE NCC Charging Scheme 2026 (ripe-848), una cuenta de LIR cuesta €1,800 al año, con una cuota de alta de €1,000, más €50 por cada asignación de ASN. En mayo de 2026, los miembros votaron adoptar la opción A para 2027: €1,894 por cuenta de LIR, con el primer ASN incluido en la cuota anual y €50 por cada ASN adicional. Si no quiere convertirse en LIR, puede solicitar un ASN a través de un LIR patrocinador, que cobra su propia tarifa, o presentar la solicitud directamente a RIPE NCC: ripe-679 permite ambas vías. Disponemos de un desglose completo de los costes de ser miembro de RIPE NCC si está valorando la membresía como LIR frente a un acuerdo de patrocinio.

Cuándo no es la decisión correcta. Si tiene un único proveedor de tránsito y un solo /24, un ASN solo le aporta carga administrativa. Seguirá dependiendo de un único proveedor para la alcanzabilidad, asumirá obligaciones con el registro y cuotas recurrentes, y su política de enrutamiento será idéntica a la de su proveedor. La mayoría de los clientes de IP no necesitan un ASN propio, y quien obtiene ingresos de su respuesta no es la persona adecuada a la que preguntar.

Nos encargamos del registro y patrocinio de ASN para los clientes que sí lo necesitan, y a los demás les decimos que no lo necesitan. Cuando la respuesta es sí, el proceso es más rápido si la subred también procede de nosotros: asignamos el bloque desde el principio en la forma que requiere el registro, de modo que ambos pasos encajan en lugar de bloquearse mutuamente. Los clientes que arriendan con nosotros también disfrutan de tarifas reducidas en todos los servicios de LIR relacionados. Los pasos en la plataforma se describen en Configurar su subred: añadir un ASN y configurar el ROA.

Vía 2: su proveedor de tránsito o de hosting anuncia la subred por usted

Es el modelo más habitual, y el que la mayoría de las guías sobre arrendamiento pasan por alto por completo.

Su proveedor de hosting, su centro de colocation o su proveedor de tránsito origina el prefijo desde su AS. Usted no gestiona BGP. No toca ningún router. La subred aparece en sus servidores y el tráfico llega.

Qué cambia en la documentación. La LOA se emite a nombre de su proveedor, no de usted. El objeto route y el ROA indican como origen el ASN del proveedor, no el suyo. Este es el detalle en el que muchos tropiezan: a veces los clientes piden a su titular de IP que cree un ROA para un ASN desde el que en realidad no anuncian, y luego no entienden por qué no se enruta nada.

Limitaciones prácticas que debe comprobar antes de firmar. La mayoría de los proveedores fijan un tamaño mínimo anunciable de /24 en IPv4: cualquier prefijo más largo se filtra a nivel global, independientemente de quién lo origine. Muchos agregan los anuncios y no los desagregan a petición. Algunos limitan el número de prefijos externos que transportan por cliente o cobran una tarifa de configuración por bloque.

A qué renuncia. A la portabilidad y al control. Como el anuncio depende de su proveedor, cambiar de proveedor implica una nueva LOA, un nuevo objeto route, un nuevo ROA y un nuevo anuncio. Usted sigue teniendo las direcciones arrendadas, pero el enrutamiento no le acompaña automáticamente.

Vía 3: BYOIP en la nube

Los programas Bring Your Own IP le permiten importar un bloque arrendado a una nube pública y usarlo en recursos de la nube. Lo que sigue se centra en la cuestión del ASN; para el proceso completo de incorporación en cada plataforma, consulte nuestra guía de BYOIP por proveedor.

AWS. BYOIP en las regiones comerciales autoriza anuncios desde los ASN de Amazon 16509 y 14618; la región AWS GovCloud (US) utiliza el ASN 8987. En IPv4, el ROA debe crearse con una longitud máxima de /24. La autorización tiene dos partes: el ROA demuestra que las direcciones pueden anunciarse, y un certificado X.509 autofirmado publicado en los comentarios (remarks) de RDAP del bloque demuestra que la cuenta de AWS que las incorpora es la suya. AWS documenta la validación del resultado mediante la llamada de datos de validación RPKI de RIPEstat, que funciona con independencia del RIR que administre el espacio.

AWS también permite traer su propio ASN. Mediante IPAM puede asociar un ASN del que sea titular a un CIDR de BYOIP y hacer que AWS anuncie el prefijo con su AS en lugar del de Amazon. Es el único caso en el que el despliegue en la nube y un ASN propio no son excluyentes, y conviene saberlo antes de concluir que BYOIP implica renunciar a su identidad de enrutamiento.

Azure. Compatible mediante Custom IP Prefix. El ROA debe autorizar el AS de origen 8075 para la nube pública, o 8070 para US Gov, y debe firmarse con el RPKI de su RIR. Un prefijo IPv4 unificado o principal debe estar entre /21 y /24. Una vez puesto en servicio, Microsoft anuncia el rango a nivel global desde el AS 8075; anunciar el mismo rango desde cualquier otro lugar al mismo tiempo puede provocar inestabilidad en el enrutamiento, por lo que las migraciones requieren una ventana de mantenimiento. Otras dos limitaciones determinan si Azure es viable: no se permite SMTP desde espacio BYOIP de Azure, por lo que esta vía no es adecuada para cargas de trabajo de correo; y el rango debe retirarse del servicio antes de modificar o eliminar el ROA, ya que de lo contrario Microsoft seguirá anunciando un prefijo para el que ya no tiene autorización.

GCP. Compatible, con sus propios requisitos de incorporación.

Qué vigilar en las tres. Cada nube impone su propio tamaño mínimo de prefijo, sus restricciones regionales y su calendario de validación. Como el control del registro lo tiene su titular de IP, usted no puede completar solo los pasos de ROA y RDAP: deben coordinarse con el titular o con la plataforma de arrendamiento. Y si el motivo del arrendamiento es mantener un conjunto estable de direcciones detrás de las listas de permitidos de sus socios, las limitaciones de esta sección pesan más de lo habitual; consulte cómo mantener las direcciones arrendadas en las listas de permitidos de los socios.

Vía 4: anunciar desde el ASN de un tercero

Es habitual en proxy, recopilación de datos y proyectos de corta duración. Un socio que ya opera un AS anuncia la subred en su nombre en virtud de un acuerdo comercial.

Qué cambia en la documentación. Lo mismo que en la vía 2: la LOA, el objeto route y el ROA indican el ASN del socio. La diferencia es que su relación con quien anuncia es puramente contractual y, a menudo, más corta que el propio arrendamiento.

La cuestión de la reputación. El requisito de Voldeta se aplica a cualquier acuerdo de este tipo: el ASN que anuncia necesita un historial limpio. Una subred con un historial impecable anunciada desde un AS con mala reputación heredará problemas: primero en la entrega de correo y después en el filtrado. Compruebe el ASN, no solo el bloque.

El riesgo de salida. Si la colaboración termina antes que el arrendamiento, necesitará un nuevo anunciante, una nueva LOA, un nuevo objeto route y un nuevo ROA, y si falta cualquiera de ellos la subred deja de enrutarse. Incluya el traspaso en el acuerdo antes de necesitarlo.

La regla que determina si todo esto funciona

El ASN del ROA debe coincidir con el AS que realmente origina la ruta.

Eso es todo. Cada uno de los fallos que se describen a continuación es una variante de esta regla.

Una Route Origin Authorization es una declaración firmada por el titular del recurso que indica qué ASN puede originar un prefijo determinado y hasta qué longitud de prefijo. En la región de RIPE, los ROA los crea el titular registrado en el RIPE NCC RPKI Dashboard: el titular de las IP, no el cliente. Junto a él está el objeto route del IRR, que vincula el inetnum a un ASN concreto y, con ello, autoriza a ese ASN a anunciar el bloque.

El RFC 6811 define tres estados de validación:

• NotFound: ningún ROA cubre el prefijo. La mayoría de las redes siguen aceptando estas rutas, pero la proporción que lo hace disminuye a medida que crece la adopción de RPKI. Tenga en cuenta que RIPEstat muestra este estado como «unknown» en la salida de su API, lo que suele generar confusión.

• Valid: hay un ROA y coinciden tanto el ASN de origen como la longitud de prefijo. Este es el objetivo.

• Invalid: hay un ROA, pero el ASN de origen es incorrecto o el prefijo anunciado es más largo que la longitud máxima del ROA. Todas las redes que aplican Route Origin Validation descartan la ruta. El fallo parece una misteriosa caída parcial más que un error de configuración.

Si RPKI le resulta un terreno desconocido, nuestra guía para principiantes sobre cómo funcionan realmente RPKI y los ROA explica la creación de ROA, los errores de longitud máxima y lo que le cuesta un ROA incorrecto.

De ello se derivan directamente dos consecuencias:

1. Decida su vía antes de crear el ROA. Si su proveedor de hosting anuncia por usted, el ROA indica el ASN del proveedor. Si utiliza Azure Custom IP Prefix, indica el 8075. Crear un ROA para su propio ASN y después pedir a un proveedor que anuncie el bloque es el error de enrutamiento autoinfligido más frecuente en el espacio arrendado.

2. Si su ASN cambia durante el arrendamiento, el ROA y el objeto route deben cambiar con él. No es automático. Es una solicitud a su titular de IP o a su plataforma de arrendamiento, y debe hacerse antes del cambio, no después.

¿Puede anunciarse un /24 desde su ASN mientras el agregado que lo cubre sigue anunciándose desde el del titular? Sí. Los operadores lo hacen desde hace años. El prefijo más específico prevalece por la coincidencia de prefijo más largo, de modo que el tráfico llega a usted. Lo que hace que funcione son unos objetos route correctos y un ROA coincidente para el más específico; lo que hace que falle es anunciar sin ellos y que la ruta se trate como un secuestro. Si depende únicamente del más específico, tenga en cuenta que no podrá hacer multihoming de forma fiable fuera del proveedor de tránsito del titular a menos que la documentación cubra todas las rutas.

¿Cumplo los requisitos para tener mi propio ASN?

El multihoming es el criterio de la política, y es más estricto de lo que sugieren la mayoría de los artículos. La sección 2.0 de ripe-679 establece expresamente que una red debe tener multihoming para optar a un AS Number, y que un nuevo ASN solo debe usarse cuando se requiera una nueva política de enrutamiento externa. Al presentar la solicitud, usted aporta esa política de enrutamiento en RPSL, y RIPE NCC puede ponerse en contacto con sus proveedores de tránsito para verificarla.

Conviene explicarlo con precisión, porque la situación ha cambiado muy recientemente. La propuesta de política 2025-01, «ASN assignment criteria revisited», habría eliminado todos los requisitos de justificación para el primer ASN de una organización. Sus autores argumentaban que los ASN de 32 bits ya no son escasos (los RIR han asignado unos 88.400, en torno al 0,002% del espacio disponible) y que la regla del multihoming es inaplicable en la práctica, ya que aproximadamente la mitad de los ASN asignados por RIPE NCC no la cumplen. La propuesta llegó a la versión 2.0, se debatió hasta RIPE 92 en Edimburgo en mayo de 2026 y fue retirada el 6 de julio de 2026. Los criterios vigentes de ripe-679 siguen en vigor. Si ha leído en otro sitio que RIPE va a conceder primeros ASN a simple petición, esa información ya no es exacta.

Una política de enrutamiento única parece más difícil de lo que es. No significa que deba usar proveedores de tránsito distintos de los de todos los demás. Dos organizaciones que usan los mismos dos proveedores de tránsito tienen igualmente políticas de enrutamiento distintas, porque cada una controla su propio espacio de direcciones y sus propios anuncios.

Si no está seguro de que su configuración cumpla el criterio de multihoming, consúltelo antes de presentar la solicitud. Preparamos la política de enrutamiento en RPSL, gestionamos la solicitud a través de un LIR patrocinador o directamente ante RIPE NCC, y hacemos el seguimiento hasta la asignación. El ASN se registra a su nombre y sigue siendo suyo.

Lista de comprobación previa al anuncio

Revísela antes de dirigir cualquier tráfico a la subred, sea cual sea la vía. Si va a trasladar servicios en producción en lugar de poner en marcha algo nuevo, la secuencia completa de migración sin interrupciones añade a estos pasos la preparación del TTL de DNS y el funcionamiento en paralelo.

• [ ] LOA emitida a nombre del ASN que anuncia, válida durante el plazo de arrendamiento

• [ ] Objeto route del IRR creado para el prefijo con el ASN de origen correcto

• [ ] ROA creado, con el ASN correcto y una longitud máxima de prefijo que coincida con lo que se va a anunciar

• [ ] El prefijo se valida como Valid: compruébelo mediante la llamada de datos de validación RPKI de RIPEstat, una instancia de Routinator u otra implementación de relying party mantenida, como rpki-client o FORT. No utilice el RIPE NCC RPKI Validator: no se mantiene desde el 1 de julio de 2021, y el servicio público de rpki-validator.ripe.net se migró a Routinator en septiembre de 2021.

• [ ] Prefijo visible desde varios puntos de observación: RIPE RIS, BGPView o el toolkit de Hurricane Electric

• [ ] El ASN de origen observado en Internet coincide con el ASN del ROA

• [ ] DNS inverso delegado

• [ ] Reputación del bloque comprobada en las principales listas negras, y también la reputación del ASN que anuncia

Una vez activa la subred, la configuración del enrutamiento se convierte en una cuestión de inventario: las fechas de vencimiento de los arrendamientos, las comprobaciones de reputación y las asignaciones de subredes requieren seguimiento durante todo el plazo de arrendamiento.

Preguntas frecuentes

¿Puedo arrendar IPv4 sin un ASN?

Sí. Tres de las cuatro vías anteriores no requieren un ASN propio. Lo que no puede es enrutar la subred sin que algún ASN la origine.

¿Pueden dos ASN distintos anunciar partes del mismo bloque?

Sí. Una subred más específica puede anunciarse desde un ASN mientras el agregado que la cubre se anuncia desde otro. Ambos necesitan objetos route correctos, y el más específico necesita un ROA cuya longitud máxima de prefijo lo permita.

¿Importa la reputación del ASN que anuncia?

Sí, y se comprueba poco. Los operadores de listas negras y los receptores de correo examinan el AS de origen además del historial de las direcciones. Algunos arrendadores se niegan a autorizar un anuncio desde un ASN con mal historial.

¿Qué ocurre si mi ASN cambia durante el arrendamiento?

El titular de las IP debe actualizar el ROA y el objeto route del IRR antes de que usted anuncie desde el nuevo AS. Planifique una ventana; no haga el cambio confiando en que todo salga bien.

¿Puedo anunciar un /24 arrendado que forma parte de la asignación mayor de otra organización?

Sí, con una LOA y los objetos de registro correctos. Es una práctica habitual, no una excepción.

¿Va a eliminar RIPE el requisito de multihoming?

No. La propuesta que lo habría hecho, la 2025-01, se retiró el 6 de julio de 2026. ripe-679 se mantiene sin cambios.

¿Puedo usar IPv4 arrendado en Azure para enviar correo electrónico?

No. Azure no permite SMTP desde espacio de direcciones BYOIP. Si el caso de uso es el correo, elija otra vía de despliegue.