Ir al contenido principal

Guía IPv4

Riesgo de proveedores IPv4: autoridad, rutas, renovación y salida

Tu IPv4 parece estable, hasta que se rompa la cadena de proveedores

Resumen para decidir sobre continuidad IPv4

Una ruta activa no demuestra un control duradero

Mapee la cadena completa antes de producción: titular, contrato, autorización de origen, operador de ruta, responsables operativos, renovación y salida. Una cadena con varias partes puede funcionar, pero cada dependencia necesita autoridad verificable y un relevo probado.

  • Autoridad: vincule el CIDR exacto con el registro RIR, estado del recurso, partes contratantes, uso downstream permitido y personas capaces de cambiar el registro o aprobar el servicio.
  • Enrutamiento: nombre el ASN de origen y los responsables de LOA, ROA, objeto IRR, filtros, activación BGP, monitorización, retirada y rollback. Son controles relacionados, pero no intercambiables.
  • Operación: asigne rDNS, geofeed, reputación, respuesta a abusos, escalación, conservación de evidencia y aceptación de la aplicación a responsables localizables con expectativas medibles.
  • Continuidad: registre renovación, avisos, dependencias upstream, plazo de sustitución, renumeración, orden de retirada de ruta y autorizaciones, devolución y una salida ensayada.

Riesgo de la cadena de proveedores IPv4: respuesta breve

Que un prefijo funcione hoy no demuestra que su organización pueda seguir usándolo y anunciándolo mañana. El riesgo aparece cuando la autoridad registral, el permiso contractual, la autorización de origen, el tránsito, la gestión de abusos, la renovación y la salida dependen de partes distintas sin un relevo verificado.

Una cadena con varias partes no es insegura por definición. El problema es una responsabilidad sin dueño, una autoridad que no puede comprobarse o una dependencia que desaparece antes de disponer de capacidad de sustitución. Antes de usar el bloque en producción, identifique a todas las partes desde el titular registrado hasta la red que origina el prefijo y el operador que transporta el tráfico.

Mapee la cadena de control IPv4

Evidencia necesaria en cada capa de la cadena de proveedores IPv4
CapaPregunta que debe responderEvidencia que debe conservar
Registro¿Qué organización y cuenta del RIR controlan el prefijo exacto?Resultado fechado de RDAP o Whois, estado del recurso, identidad de la organización y contacto autorizado de la cuenta
Derecho de uso¿Qué contrato permite el uso, para qué carga y durante qué plazo?CIDR exacto, partes, uso permitido, derechos de terceros, fechas, tarifas, renovación, suspensión, terminación y sustitución
Origen de ruta¿Quién puede autorizar el ASN de origen previsto?ROA que cubra prefijo, ASN y longitud máxima, más validación RPKI externa
Filtros de ruta¿Quién puede crear o cambiar el objeto IRR y los filtros del proveedor?Autoridad del maintainer, objeto de ruta exacto, prefijo y ASN aceptados, ticket de cambio y confirmación de filtros
Tránsito¿Qué red anunciará y transportará la ruta?Diseño BGP, ASN, peers o upstreams, longitudes aceptadas, ventana de activación, escalación y ruta observada
Operación¿Quién gestiona abusos, rDNS, geofeed, reputación, monitorización e incidentes?Contactos nominales, niveles de servicio, autoridad de cambio, fuentes de evidencia y escalación probada
Salida¿Qué ocurre si termina una parte, una ruta o un acuerdo?Fechas de aviso, capacidad de reemplazo, renumeración, orden de retirada de ruta y ROA, exportación de datos, cuarentena y rollback

No deduzca el control de un logotipo, una factura, un panel o una ruta visible. Un revendedor puede tener una función comercial válida sin controlar la cuenta del RIR. La red que origina BGP puede no tener autoridad para crear el ROA. El titular registrado puede controlar el recurso, pero no su tránsito ni la migración de sus aplicaciones.

LOA, ROA, IRR y BGP son controles distintos

Qué demuestran y qué no demuestran los registros habituales de enrutamiento IPv4
ControlQué respaldaQué no demuestra por sí solo
LOADeclaración escrita de que un titular o proveedor autoriza una acción de red. El formato y su aceptación dependen del operador receptor.Registro en el RIR, autorización criptográfica del origen, ruta BGP activa o continuidad del contrato
ROA de RPKIObjeto firmado digitalmente que autoriza a un ASN a originar un prefijo y define la longitud máxima.Que BGP esté configurado, que todas las redes acepten la ruta o que el cliente tenga derecho comercial de uso
Objeto de ruta IRRDato de registro que los operadores pueden usar para construir filtros de prefijo y origen, sujeto al modelo de autorización de la base.Autorización criptográfica, ruta actual o filtros idénticos en todos los upstreams
Anuncio BGPRuta intercambiada entre sistemas autónomos en el momento observado.Titularidad, validez contractual, continuidad futura o corrección de los registros de abuso y registro

RFC 9582 define el ROA como la autorización del titular de un bloque para que un AS origine rutas. ARIN también indica que una organización downstream puede necesitar que el titular upstream cree el ROA en su nombre. Esa dependencia debe figurar en el acuerdo, tener una persona responsable y probarse antes de la activación.

Lista de diligencia para la cadena de proveedores IPv4

  1. Fije el objeto solicitado. Registre CIDR, longitudes necesarias, ASN de origen, RIR, uso, regiones, fecha de inicio, plazo y hora de la evidencia.
  2. Identifique a todas las partes. Enumere titular, arrendador o vendedor, revendedor, patrocinador de ruta, red de origen, tránsito, plataforma y entidad contratante. Marque qué relaciones son directas.
  3. Vincule autoridad y evidencia. Confirme quién puede actualizar el registro, firmar, emitir una LOA, crear o cambiar un ROA, mantener objetos IRR, abrir tickets de ruta y aprobar cambios urgentes.
  4. Lea el estado y la política aplicables. Una asignación, subasignación, transferencia o espacio dependiente de proveedor puede tener condiciones distintas de portabilidad y devolución. Consulte la fuente vigente del RIR para el recurso exacto.
  5. Convierta el contrato en operación. Nombre el prefijo, usos, dependencias, tiempos de respuesta, renovación, cambios de precio, suspensión, abusos, datos, terminación, reemplazo y límites de responsabilidad.
  6. Prepare el enrutamiento antes del tráfico. Configure ROA, IRR, filtros, LOA si se exige, BGP, rDNS, geofeed y contactos monitorizados. No use una longitud máxima de ROA más amplia que el plan de anuncios.
  7. Ejecute una aceptación por etapas. Anuncie en la ventana aprobada y verifique origen, path, estado RPKI, longitud, alcance desde redes representativas y rollback mediante observaciones independientes.
  8. Pruebe el ajuste a la aplicación. Use comprobaciones fechadas y pertinentes de reputación, geolocalización, correo o plataforma, DNS, latencia y abusos. Una sola puntuación no demuestra que todo el prefijo sea limpio o apto.
  9. Ensaye renovación y salida. Registre avisos en un calendario compartido, calcule el plazo de sustitución y documente migración, retirada de ruta, cambios ROA e IRR, rDNS y devolución.

Pruebe la continuidad antes de producción

Fallos de la cadena de proveedores y controles de aceptación
EscenarioControl que debe prepararEvidencia de aceptación
Termina la relación upstreamProveedor alternativo y plan de renumeración o cambio de origenResponsable, plazo, inventario de configuración, ventana de prueba y criterio de rollback
Cambia el ASN de origenSecuencia coordinada de ROA, IRR, filtros, BGP, monitorización y retiradaAmbos estados de autorización comprobados y nuevo origen observado antes de retirar el anterior
Se retira la rutaAlertas de ruta independientes y escalación 24/7La alerta llega al responsable y el proveedor puede identificar o restaurar el prefijo exacto
Cambia la autoridad del recursoAviso contractual y contacto vigente de la cuenta RIRComprobación registral fechada, confirmación autorizada y decisión documentada sobre el uso
Incidente de abuso o reputaciónControles de uso, conservación de evidencia, respuesta y criterios de sustituciónContacto probado, dueño del caso, remediación y plan de revalidación específico para la carga

BGP puede retirar una ruta anunciada o eliminar rutas cuando se cierra una sesión, según RFC 4271. RPKI e IRR ayudan a validar o filtrar anuncios, pero no mantienen viva una relación comercial o de tránsito que ha fallado. La continuidad necesita controles técnicos y una salida contractual.

Alquilar, subarrendar o comprar: compare dependencias

Una transferencia directa aceptada por el RIR aplicable puede eliminar intermediarios comerciales, pero no elimina el trabajo de enrutamiento, RPKI, IRR, abusos, reputación o migración. Un alquiler puede encajar con demanda variable o temporal si la autoridad del titular y cada responsabilidad operativa son comprobables.

El subarrendamiento añade al menos una relación. Confirme que el uso downstream está permitido y quién responde ante el titular y el RIR. En la región del RIPE NCC, la política vigente distingue asignaciones y subasignaciones provider-aggregatable y explica que ciertos espacios dependientes del proveedor deben devolverse cuando termina el servicio. Otras regiones y estados difieren: compruebe la política actual en vez de extrapolar una regla.

Preguntas que todo proveedor IPv4 debe responder

  • ¿Cuál es el prefijo exacto, RIR, estado del recurso y organización registrada?
  • ¿Es el titular, un proveedor autorizado, un revendedor o el operador de ruta?
  • ¿Permite el titular este uso downstream y cualquier subdelegación prevista?
  • ¿Quién crea el ROA y qué ASN de origen y longitud máxima autorizará?
  • ¿Quién crea el objeto IRR y confirma los filtros de todos los upstreams necesarios?
  • ¿Quién emite una LOA si se exige y cómo se verifica la autoridad del emisor?
  • ¿Quién gestiona incidentes BGP, rDNS, geofeed, reputación y abusos?
  • ¿Cuáles son la renovación, el aviso, el precio, la suspensión y la terminación?
  • ¿Qué ocurre si sale de la cadena un upstream, revendedor, titular u operador?
  • ¿Cómo funcionan sustitución, renumeración, exportación de evidencia, retirada y devolución?

Dónde encaja i.lease

i.lease puede convertir una solicitud IPv4 en un requisito operativo definido: tamaño, región, uso, ASN, modelo de ruta, evidencia, plazo, renovación y salida. Revise el alquiler IPv4 gestionado, consulte los anuncios actuales del marketplace o aplique la lista de evaluación de riesgo IPv4 antes de comparar oferta.

Ningún proveedor puede garantizar aceptación global permanente de una ruta, cambios instantáneos de reputación de terceros o ausencia total de incidentes. Una promesa útil define el alcance, demuestra la autoridad, asigna la operación, prueba la escalación y prepara la salida antes de depender del prefijo.

Preguntas frecuentes sobre el riesgo de proveedores IPv4

¿Qué es el riesgo de la cadena de proveedores IPv4?

Es el riesgo de continuidad creado cuando usar, registrar, autorizar, enrutar, soportar, renovar o devolver un prefijo depende de varias partes. Importa menos el número que la claridad y verificabilidad de cada dependencia y relevo.

¿Una ruta BGP activa demuestra que el proveedor controla el prefijo?

No. Demuestra que se observó una ruta desde un origen y path en ese momento. Compruebe por separado registro RIR, contrato, ROA, IRR, filtros y relación operativa.

¿Una LOA es igual que un ROA de RPKI?

No. La LOA es un documento aceptado según el proceso de un operador. El ROA es un objeto RPKI firmado que autoriza un ASN para un prefijo y longitud máxima. Ninguno crea por sí solo la ruta BGP ni el contrato.

¿Comprar IPv4 elimina el riesgo de proveedores?

Puede eliminar dependencias de alquiler o reventa tras una transferencia válida, pero las cuentas del registro, RPKI, IRR, tránsito, reputación, abusos y migración siguen necesitando responsables y evidencia.

¿Cuál es la comprobación de renovación más importante?

Confirme quién puede renovar, fechas exactas de aviso y decisión, condiciones de precio o elegibilidad, dependencias upstream y plazo necesario para reemplazar y renumerar.

¿Cómo se prueba un fallo de la cadena?

Ejecute un ejercicio controlado: alerte ante un cambio de ruta, contacte a la escalación, valide cambios ROA e IRR, ensaye migración o retirada y registre criterios objetivos de éxito, rollback y responsabilidad.

Fuentes primarias para verificar

Volver al blog