Objetos de ruta IRR después de la migración de red

Resumen

Un objeto de ruta IRR establece que un prefijo puede ser originado por un AS designado dentro de una fuente de registro. Es una declaración utilizada para construir políticas, no una observación en vivo de BGP, un certificado de recursos o una declaración concluyente de titularidad legal.
La cadena operativa habitual expande un AS o AS-SET, recupera los objetos route y route6 coincidentes de fuentes IRR seleccionadas, compila los prefijos resultantes en un filtro y despliega ese filtro en sesiones de cliente o peering. Un objeto obsoleto importa cuando sobrevive a esa cadena de selección y compilación.
Mover una red puede significar cambiar de tránsito conservando el AS de origen, cambiar de origen conservando el titular del prefijo, transferir el prefijo, moverse entre regiones de servicio RIR o utilizar un proveedor de mitigación temporal. Cada evento requiere un juicio diferente sobre qué objetos de ruta deben continuar.
Las entradas obsoletas persisten porque la parte motivada para crear un reemplazo a menudo no es la que posee la antigua credencial de mantenedor. Los antiguos proveedores tienen poco incentivo comercial para limpiar, el personal y las cuentas desaparecen, y las bases de datos independientes no tienen una transacción común que retire todos los duplicados.
Ni una discrepancia con el BGP actual ni la antigüedad por sí solas demuestran que un objeto deba eliminarse. Las rutas de respaldo pueden estar inactivas, los anuncios previstos pueden prepararse antes de su uso, y una ruta observada puede ser en sí misma no autorizada. Deben combinarse RPKI, registros de asignación, autenticación del titular, notificaciones y observaciones BGP acotadas.
La eliminación puede interrumpir la alcanzabilidad cuando los operadores reconstruyen filtros automáticamente. Una migración segura sigue el principio de "crear antes de retirar": establecer la nueva declaración prevista en una fuente apropiada, probar cómo los consumidores designados resuelven conflictos, notificar a las partes afectadas, eliminar la autoridad sustituida, verificar las réplicas y luego verificar el despliegue del filtro.
Un titular de recursos necesita legitimación para impugnar un objeto de ruta que cubra su prefijo, incluso cuando otro mantenedor controle la entrada. El registro también debe al mantenedor listado una notificación, una razón, un registro de evidencia, una vía de revisión de emergencia y una etapa de suspensión reversible cuando el riesgo de eliminación errónea sea material.
Una Sociedad de Recursos Numéricos puede definir un recibo de migración portátil, pruebas de calidad de fuente y deberes recíprocos para titulares, registros y operadores. No debe erigirse en autoridad de enrutamiento universal ni afirmar que las observaciones en redes seleccionadas demuestran la convergencia global de filtros.

Una ruta puede irse mientras su declaración permanece

Considere una empresa que ha originado el mismo bloque de direcciones a través de un sistema autónomo durante años. Compra servicio a un operador diferente, cambia su diseño de enrutamiento y comienza a anunciar a través de otro AS. El nuevo proveedor le pide un objeto de ruta antes de abrir su filtro. La empresa crea uno en un registro aceptado por ese proveedor. El tráfico se mueve. El antiguo operador se desconecta. Sin embargo, un objeto de ruta que nombra el origen anterior permanece bajo una cuenta de mantenedor controlada por un ingeniero que se fue hace mucho tiempo, en una base de datos que la empresa ya no utiliza.

Nada en BGP elimina automáticamente esa declaración. BGP distribuye alcanzabilidad; no envía una instrucción de cancelación a cada registro de enrutamiento cuando finaliza una relación comercial. Tampoco un nuevo objeto de ruta reemplaza a todos los objetos más antiguos por una regla universal. Los pares prefijo-origen antiguos y nuevos pueden coexistir en bases de datos diferentes, o en la misma cuando sus claves difieren. Una réplica puede devolver ambos. Un constructor de filtros puede incluir uno, el otro o ambos según sus fuentes seleccionadas, orden de consulta, configuración de supresión y método de expansión.

El riesgo resultante a menudo se malinterpreta. Un objeto de ruta antiguo no hace que un enrutador origine una ruta. Sin embargo, puede hacer que un sistema de filtrado considere una combinación prefijo-origen antigua como elegible. Si el AS anterior anuncia el prefijo por error o maliciosamente, una red cuya política aún admite esa combinación tiene una barrera menos. En la dirección opuesta, eliminar un objeto que aún requiere un proveedor puede provocar que la siguiente actualización del filtro rechace el anuncio legítimo. La persistencia crea un permiso residual; la eliminación descuidada crea un peligro de alcanzabilidad.

Por eso el problema es institucional y no meramente administrativo. Diferentes partes controlan el registro del prefijo, el AS de origen, el objeto de ruta, la réplica, el generador de filtros y los enrutadores. El movimiento de red cambia algunas de esas relaciones, pero puede dejar intactas las credenciales y declaraciones antiguas. Una migración sólida debe transferir el reconocimiento operativo a lo largo de toda la cadena, preservando al mismo tiempo un medio para impugnar errores.

El objeto de ruta de 1995 separó la asignación de la intención de enrutamiento

El objeto de ruta llegó con un útil acto de higiene conceptual. RFC 1786, publicado en 1995, separó la información de asignación de espacio de direcciones de la información sobre un anuncio de enrutamiento. Un objeto de ruta identificaba un prefijo exacto y un AS de origen. Cuando una ruta podía ser originada por más de un AS, el registro podía contener múltiples objetos. El diseño reconocía un hecho que sigue siendo importante: la organización registrada como titular o receptora del espacio de direcciones y el AS que inyecta una ruta están relacionados, pero no son el mismo hecho.

RPSL estandarizó más tarde la representación. RFC 2622 convirtió el par prefijo-origen en la clave de clase. También describió mantenedores, conjuntos de rutas, conjuntos de AS y expresiones de política que podían ser procesadas por software. El objeto no fue concebido como prosa para un directorio pasivo. Se pretendía que se combinara con otros objetos para que los operadores pudieran verificar políticas y generar configuraciones. RFC 2650 mostró el puente práctico desde RPSL publicado hasta la configuración de enrutadores específicos del proveedor.

Esa historia explica tanto la permanencia como la incomodidad del sistema. Los objetos de texto eran portátiles, públicos y automatizables en un momento en que la coordinación entre dominios necesitaba un lenguaje común. La distribución entre registros coincidía con el carácter distribuido de la administración de redes. Sin embargo, el objeto de ruta no llevaba una conciencia automática de una terminación posterior de contrato, fusión, transferencia o cambio en la tabla de enrutamiento en vivo. Su durabilidad era una característica para una política estable y una carga para la sucesión.

El modelo temprano incluso incluía un atributowithdrawnen la especificación predecesora. Marcar una ruta antigua como retirada podía preservar la información histórica de enrutamiento sin presentarla como actual. La práctica operativa moderna se ha centrado generalmente en objetos route y route6 actuales, eliminación, selección de fuentes e historia externa. La cuestión de gobernanza subyacente no desapareció: ¿quién puede declarar que una intención de enrutamiento anterior ha terminado, y cómo llega esa decisión a cada consumidor que convirtió la declaración en política?

La respuesta no puede ser simplemente "quien todavía pueda iniciar sesión". Las credenciales son necesarias para el mantenimiento ordinario, pero un acuerdo de credenciales abandonado no debería congelar un permiso obsoleto para siempre. Tampoco puede ser la respuesta "quien actualmente anuncia el prefijo". El BGP observado es evidencia de uso, no una autoridad autenticada por sí misma. La separación introducida en 1995 debe mantenerse durante la migración, no colapsarse por conveniencia.

Un objeto de ruta no es ni la ruta ni el recurso

Tres registros se confunden fácilmente. Un registro de números registra la organización a la que se le asigna, delega o de otro modo registra un bloque de direcciones según sus reglas. Un objeto de ruta IRR registra un prefijo y un AS de origen previsto en una fuente de registro de enrutamiento nombrada. Los colectores BGP observan anuncios que aparecieron en puntos de observación particulares. Cada uno responde a una pregunta diferente.

El registro de asignación puede respaldar una afirmación sobre quién puede gestionar el recurso dentro del sistema administrativo de un RIR. No muestra que el titular esté enrutando actualmente el prefijo o qué proveedor ha autorizado. El objeto de ruta expresa la intención de enrutamiento, pero la solidez de esa expresión depende de los controles de admisión y actualización de la base de datos. La observación BGP muestra que un origen fue visible, pero no si el titular del recurso consintió en ello. Tratar cualquiera de ellos como evidencia completa hace que la migración sea insegura o imposible.

RPKI añade una declaración más fuerte y más limitada. Una Autorización de Origen de Ruta válida puede vincular criptográficamente la autoridad certificada de direcciones con un AS de origen y longitudes de prefijo permitidas. Eso la hace muy relevante al decidir si un objeto de ruta IRR entra en conflicto con la intención actual del titular. Sigue sin reproducir toda la política RPSL, probar una relación comercial o mostrar que una ruta está activa. Un titular puede preparar un ROA antes del anuncio; una ruta puede ser NotFound porque no existe un ROA que la cubra; y un titular equivocado puede autorizar el origen incorrecto.

Por lo tanto, la cuestión del objeto obsoleto debe formularse con precisión. No es "¿difiere este objeto del BGP actual?", sino "¿sigue expresando este objeto una posibilidad de enrutamiento actual y autorizada, y deberían los consumidores designados seguir convirtiéndola en permiso?" Una ruta de respaldo puede estar ausente de la tabla global y, sin embargo, ser válida. Un proveedor de limpieza temporal puede aparecer solo durante un ataque. Un origen de tránsito antiguo puede seguir siendo visible en un colector porque la retirada no ha llegado a todas las rutas. Una ruta recién secuestrada puede parecer actual.

La evidencia debe compararse por función. El registro de asignación establece la legitimación administrativa. La autenticación del titular establece quién está preguntando. RPKI puede establecer la intención de origen certificada donde esté desplegada. Los registros de contrato o cambio establecen el movimiento planificado. Las observaciones BGP muestran el estado operativo. La respuesta del antiguo mantenedor puede explicar un registro por delegación o un servicio continuo. Ningún registro responsable debería usar una señal conveniente como oráculo universal de eliminación.

Los filtros convierten un texto histórico en permiso actual

La fuerza práctica del objeto de ruta aparece en el procedimiento de construcción de filtros de un operador. Una red de tránsito puede pedir a un cliente un nombre de AS-SET. El software expande recursivamente ese conjunto en números de AS, busca objetos route y route6 cuyos orígenes coincidan con esos AS, obtiene los prefijos relevantes y emite una lista de prefijos o un fragmento de política. El operador revisa o despliega automáticamente el resultado en la sesión eBGP del cliente. Las redes de peering y los servidores de rutas pueden usar variaciones del mismo método.

La utilidadbgpq4hace explícita esta conversión: genera listas de prefijos, filtros de ruta y listas de AS-path a partir de datos IRR, y permite a quien la llama especificar las fuentes IRR a utilizar. El servicio de consulta de RADb también permite a un cliente seleccionar fuentes y, de lo contrario, devuelve información recopilada de múltiples registros. IRRd puede ordenar fuentes predeterminadas, aplicar supresión RPKI, aplicar filtros de alcance y suprimir objetos de ruta superpuestos de menor preferencia. Por lo tanto, la respuesta de la base de datos es una entrada moldeada por la política local, no un conjunto canónico global.

Un objeto antiguo tiene varios efectos posibles. Si se construye un filtro para el AS de origen anterior, el prefijo antiguo puede permanecer en la lista permitida de ese AS. Si el AS-SET de un cliente todavía contiene el origen anterior o un descendiente obsoleto, la expansión recursiva puede llevar el prefijo a una política más amplia. Si la instancia IRR consumidora incluye todas las fuentes replicadas sin preferencia, un duplicado en una base de datos independiente puede sobrevivir después de que se elimine una copia autorizada.

Si el operador nunca actualiza su configuración generada, incluso una eliminación correcta puede no eliminar el permiso antiguo del enrutador.

Lo contrario también importa. Un nuevo objeto de ruta puede estar perfectamente autorizado en su base de datos de origen y aun así no llegar a un operador cuya réplica esté retrasada, cuya lista de fuentes seleccionadas excluya esa base de datos o cuyo trabajo de configuración no se haya ejecutado. La migración no se completa con la aceptación por parte del registro. La aceptación inicia una secuencia de distribución, selección, compilación, revisión y despliegue.

La unidad de gobernanza relevante es, por tanto, el filtro efectivo, no meramente el objeto almacenado. Los registros deben publicar suficiente información de estado para mostrar cuándo una actualización ingresó en su estado autoritativo y en sus servicios de distribución. Los operadores deben registrar qué instantánea, fuentes, opciones de consulta y expansión de conjuntos produjeron un filtro desplegado. Los titulares deben poder preguntar si un proveedor designado ha consumido un cambio.

Sin estos recibos, cada parte puede decir con verdad que su propio paso tuvo éxito mientras la ruta permanece bloqueada o el permiso obsoleto permanece activo.

Los incentivos favorecen la creación y descuidan la retirada

RFC 7682 describió la asimetría con claridad en 2015. Los clientes tienen una fuerte razón para registrar nueva información de enrutamiento cuando un proveedor no actualizará una lista de prefijos sin ella. El incentivo para eliminar la información antigua disminuye drásticamente después de un cambio de tránsito, especialmente cuando el nuevo proveedor no impone la misma disciplina IRR. El nuevo circuito depende de la creación; pocas facturas dependen de la eliminación.

El control también está dividido. Un proveedor puede haber creado objetos de ruta en nombre de un cliente bajo su propio mantenedor. Ese registro por delegación fue conveniente durante el servicio. Al finalizar, el cliente puede controlar el prefijo pero no la credencial del objeto. El equipo de red del antiguo proveedor puede considerar la limpieza como trabajo para un antiguo cliente. El gestor de cuenta puede no entender la consecuencia de enrutamiento. El ingeniero original puede haberse ido.

Un mantenedor puede sobrevivir como identidad técnicamente válida después de que la organización humana capaz de actuar a través de él se haya vuelto inalcanzable.

Los eventos corporativos agravan el problema. Una empresa cambia de nombre, se fusiona, vende una división de red o externaliza operaciones. El registro del prefijo puede actualizarse mientras las credenciales IRR permanecen con el predecesor o un contratista. Una transferencia de direcciones puede otorgar al receptor legitimación en el registro de números sin darle la contraseña o clave referenciada por elmnt-byde un objeto de ruta antiguo. Un movimiento entre regiones de servicio RIR puede cambiar qué IRR integrada está mejor posicionada para autenticar al titular de la dirección, mientras que los objetos de terceros independientes permanecen en otro lugar.

No hay una penalización de mercado natural para cada registro obsoleto. Si el origen antiguo nunca anuncia la ruta, la mayor parte del tráfico fluye normalmente. Una entrada obsoleta puede ser ignorada por la generación de filtros para el nuevo origen y permanecer invisible para el titular hasta que una revisión de seguridad, otra migración o un intento de creación la encuentre. La propia característica de objetos obsoletos de RADb refleja esta ambigüedad: puede marcar un objeto utilizando BGP, mantenedor, RIR y otras señales, pero la marca en sí misma no cambia el comportamiento de las consultas.

La información sin un deber asignado puede convertirse en una advertencia que todos ven y nadie cierra.

Un mejor diseño de incentivos vincula la retirada al evento que crea el cambio. La terminación del tránsito debe incluir un inventario IRR y una obligación de eliminación. La transferencia de recursos debe exponer todos los objetos de ruta descubiertos antes de su finalización. Los contratos de registro y proveedor deben otorgar al titular actual una vía de impugnación documentada. Los operadores que consumen datos IRR deben publicar sus prácticas de actualización y excepción. La limpieza debe convertirse en parte de la finalización de la autoridad, no en una tarea de limpieza voluntaria después de que la relación comercial ha desaparecido.

"La red se movió" describe varios eventos diferentes

Migración es una palabra demasiado amplia para una sola regla de eliminación. El caso más simple es un cambio de tránsito sin cambio de origen. El titular conserva su ASN y anuncia los mismos prefijos a través de un nuevo proveedor ascendente. El objeto de ruta puede permanecer completamente correcto porque vincula el prefijo con el origen inalterado del titular, no con el antiguo proveedor de tránsito. Lo que necesita ser eliminado puede ser una membresía obsoleta de AS-SET o una copia delegada gestionada por el proveedor, no la declaración prefijo-origen en sí.

Un segundo caso cambia el origen manteniendo el mismo titular. Una empresa puede pasar de un servicio originado por el proveedor a su propio ASN, cambiar de redes gestionadas o poner el control de origen en una empresa del grupo diferente. Aquí, el antiguo objeto de ruta puede representar un permiso que debería expirar. Un solapamiento planificado puede ser legítimo mientras ambos orígenes anuncian durante la transición. La eliminación antes de que el nuevo proveedor haya reconstruido los filtros puede interrumpir el servicio; la coexistencia indefinida deja una autoridad residual.

Un tercer caso transfiere el recurso de direcciones. El nuevo titular registrado puede conservar el origen antiguo temporalmente, usar uno nuevo inmediatamente o designar una red de terceros. El registro de transferencia respalda la legitimación del receptor para gestionar la intención de enrutamiento actual, pero no revela la ruta prevista por sí mismo. Los objetos antiguos necesitan revisión en lugar de una eliminación mecánica. El mismo par prefijo-origen puede seguir siendo válido bajo un nuevo titular, pero su mantenedor y cadena de contacto pueden necesitar migración.

Un cuarto caso cruza regiones de registro. El registro de números autoritativo y la IRR integrada preferida pueden moverse, mientras que los objetos de ruta en una fuente anterior, RADb u otro registro independiente continúan. El tratamiento de la RIPE NCC de los objetos fuera de región ilustra la importancia de este límite. Los objetos existentes fueron reetiquetados comoRIPE-NONAUTH, se detuvo la creación de nuevos objetos fuera de región y, más tarde, la política utilizó evidencia RPKI conflictiva, notificación y un período de espera para la eliminación. El estado de la fuente cambió porque cambió la capacidad de la institución para autenticar el prefijo.

Los cambios operativos temporales forman un quinto caso. La mitigación de DDoS, los lanzamientos anycast, la recuperación ante desastres y las fusiones pueden producir un segundo origen destinado a existir solo bajo condiciones establecidas. Una instantánea tomada durante la activación puede hacer que el objeto temporal parezca actual; una instantánea tomada durante la inactividad puede hacer que parezca obsoleto. Dichos objetos necesitan un propósito explícito, un propietario y condiciones de revisión. El tiempo por sí solo es un mal sustituto del alcance declarado.

El registro de migración debe identificar qué evento ocurrió. De lo contrario, un registro puede eliminar un objeto duradero del mismo origen porque un operador cambió, preservar un origen obsoleto porque el titular no cambió o tratar una autorización de emergencia temporal como permanente. La precisión sobre el evento es la primera salvaguarda tanto contra los residuos como contra la limpieza errónea.

La protección del mantenedor preserva el control y puede preservar el abandono

Los mantenedores RPSL resolvieron un problema esencial: las declaraciones de enrutamiento públicas no deberían ser editables por cualquiera que las desapruebe. RFC 2725 distinguió la autenticación de la autorización y describió cómomnt-by,mnt-routes,mnt-lower, reglas de recuperación y controles relacionados podían regir las adiciones y los cambios. En la operación ordinaria, el propio mantenedor del objeto de ruta autoriza la modificación o eliminación. Eso protege a los operadores de interferencias arbitrarias.

Se suponía que la jerarquía añadiría un recurso. Los mantenedores del espacio de direcciones y del AS podían autorizar la creación de rutas; los conceptos de recuperación podían permitir a una autoridad de recursos superior recuperar objetos subordinados;auth-overridedescribía una recuperación diferida cuando un mantenedor se había vuelto inactivo. Sin embargo, la implementación varió y el diseño de repositorio distribuido nunca se convirtió en una cadena de autoridad global uniforme. RFC 7682 observó que la información obsoleta podía permanecer porque terceros no podían eliminarla de forma segura y porque la semántica de anulación corría el riesgo de actuar antes de que el titular listado recibiera una notificación efectiva.

Los controles actuales de la base de datos de RIPE muestran una respuesta práctica dentro de una región autoritativa. Un titular de recursos actual puede forzar la eliminación de ciertos objetos de ruta bloqueantes a través del mantenedor en un objeto de espacio de direcciones que lo cubra, incluso sin la credencial propia del objeto de ruta. La autoridad está limitada por la jerarquía de recursos mantenida por RIPE NCC. Permite la eliminación, no la reasignación silenciosa, y no crea una legitimación equivalente en cada IRR independiente.

Esa limitación es apropiada. Un registro que sirve a un titular de recursos no debería reclamar control sobre cada base de datos de terceros simplemente porque la dirección está registrada en su región. Sin embargo, el titular no debería tener que suplicar informalmente a un mantenedor delegado abandonado para siempre. Cada IRR necesita una regla publicada que explique qué evidencia otorga legitimación a un titular actual, cuándo se acepta el registro de otro registro, qué notificación se envía, cómo se puede impugnar una suspensión y quién aprueba la eliminación irreversible.

La protección del mantenedor es legítima solo cuando se combina con la sucesión. Una credencial identifica quién puede operar un objeto bajo las reglas actuales; no prueba que el permiso subyacente siga siendo sustancialmente válido para siempre. La institución gana confianza al preservar el control autorizado durante el servicio y al permitir la recuperación basada en evidencia después de que el control ha cambiado legítimamente.

La replicación distribuye la disponibilidad y también distribuye el retraso

El IRR es una federación de bases de datos, no una sola tabla. Los operadores a menudo consultan una instancia de IRRd que contiene una fuente local autoritativa y copias replicadas de varias otras. RADb anuncia una vista de consulta combinada extraída de registros de todo el IRR. El modelo mejora la disponibilidad y permite que un constructor de filtros use un solo punto final en lugar de contactar a cada registro por separado.

La replicación también separa el momento de la eliminación del momento de la desaparición. Una fuente autoritativa acepta un cambio. Un diario o instantánea lo pone a disposición. Una réplica sondea, valida la secuencia y aplica la actualización. Una réplica descendente puede repetir el proceso. El servicio de filtrado del operador consulta entonces su vista local según un calendario. El enrutador recibe un cambio de configuración posterior. Cada etapa tiene su propio reloj y modos de fallo.

RFC 7682 documentó prácticas más antiguas de NRTM y archivos planos, incluyendo replicación insegura e intervalos de actualización sustanciales. Las implementaciones han mejorado. El IRRd actual puede usar importaciones, flujos NRTM, diarios, seriales y configuraciones específicas de fuente; el diseño más reciente de NRTM de RIPE proporciona instantáneas versionadas y deltas con hashes e identidad de fuente. Una mejor integridad de transporte y un sondeo más rápido reducen la incertidumbre. No hacen que un operador seleccione la fuente correcta o elimine un duplicado mantenido independientemente.

Un objeto eliminado en la fuente A puede continuar como un objeto distinto en la fuente B. Esto no es necesariamente un retraso de replicación. Puede haber sido enviado por separado, copiado bajo otro mantenedor o conservado como un registro no autoritativo. A la inversa, un objeto visible en un punto final de consulta combinada puede ser una réplica fiel cuyo origen autoritativo aún no ha procesado una impugnación. Los investigadores deben distinguir la procedencia del transporte.

Por lo tanto, la sincronización entre bases de datos tiene dos significados. La sincronización técnica pregunta si las réplicas han aplicado el serial o la instantánea actual de una fuente. La sincronización institucional pregunta si cada fuente que afirma independientemente el permiso sustituido ha revisado la misma evidencia de migración y ha alcanzado un estado justificado. La primera puede ser automatizada por protocolos de replicación. La segunda requiere referencias comunes, notificaciones recíprocas y decisiones responsables.

Un recibo de migración debe registrar ambos. Nombra el objeto en cada fuente, la hora de actualización autoritativa, las observaciones de las réplicas y el estado de los duplicados independientes. "Eliminado de RADb" o "actualizado en el RIR" no es suficiente cuando otra fuente seleccionada todavía devuelve el par antiguo. Tampoco debe un equipo seguir eliminando ciegamente hasta que una consulta combinada se vea limpia; debe saber qué institución hizo cada afirmación y bajo qué autoridad.

La prueba de la fuente debe viajar con la solicitud

La parte que solicita la retirada debe presentar algo más que una captura de pantalla de la tabla de enrutamiento actual. Una solicitud creíble comienza con la legitimación sobre el recurso: un titular actual autenticado en el RIR correspondiente, o un delegado autorizado cuyo alcance esté claro. Identifica el prefijo exacto, el origen antiguo, el origen nuevo o continuo, cada fuente y mantenedor conocido, el evento de migración y el estado efectivo solicitado.

La evidencia puede luego estratificarse. Un registro de asignación actual respalda el control del prefijo bajo las reglas del RIR. Un ROA puede respaldar la intención de origen actual cuando su cobertura y longitud máxima coinciden realmente con la ruta en cuestión. Una declaración firmada o autenticada del titular explica si un origen antiguo está revocado, retenido para respaldo o autorizado hasta una fecha de transición. Los registros de terminación o transferencia del proveedor pueden corroborar el evento sin requerir que los términos comerciales se hagan públicos.

Las observaciones BGP muestran si los orígenes antiguos y nuevos son visibles en momentos y puntos de observación determinados.

El antiguo mantenedor también debe ser escuchado cuando sea factible. Puede mostrar que el objeto cubre una ruta de cliente activa bajo un nombre corporativo diferente, que un acuerdo de mitigación sigue en vigor o que el cambio de registro del solicitante está en disputa. El silencio después de una entrega verificada y un período de respuesta definido es evidencia de falta de respuesta, no prueba de cada hecho subyacente. El tomador de decisiones debe decir qué peso asignó al silencio.

El estándar de prueba debería aumentar con la consecuencia. Suprimir un objeto claramente inválido según RPKI en una vista de consulta no autoritativa es diferente de borrar la única declaración en la que se basa un proveedor crítico. Una impugnación de emergencia que involucre un aparente secuestro puede justificar una supresión temporal y una revisión rápida. La eliminación permanente en una transferencia ambigua puede requerir una autenticación más fuerte del titular, la aprobación de dos personas y evidencia de que una ruta de reemplazo está lista.

Toda decisión debe preservar un registro de auditoría no público: reclamaciones presentadas, resultados de validación, notificaciones, respuestas, conflictos, identidad del revisor, momento y razón. La salida pública puede ser más limitada, exponiendo el estado del objeto y una clase de razón sin datos personales o contratos sensibles. El objetivo no es la divulgación máxima. Es la capacidad de demostrar más tarde que la autoridad de enrutamiento residual fue eliminada por una regla y no por influencia o accidente.

BGP es un testigo, no un juez

Los datos de enrutamiento en vivo son indispensables porque un IRR existe para describir la política operativa. La evaluación de objetos obsoletos de RADb compara pares prefijo-origen con BGP y complementa las coincidencias directas con señales de mantenedor, enlace AS, RIR y reputación. El trabajo de medición reciente presentado a través de RIPE Labs compara de manera similar los objetos de ruta con IRR autoritativos, RPKI y la zona libre por defecto para identificar conflictos, redundancia e inactividad. Dichos métodos revelan patrones que la inspección estática de registros no puede.

Sin embargo, la visibilidad BGP tiene límites agudos. Los colectores ven pares seleccionados, no cada interconexión privada. Un anuncio de respaldo puede estar intencionalmente ausente. Un más específico puede aparecer solo durante la ingeniería de tráfico o la mitigación de ataques. La agregación puede hacer que un objeto de ruta legítimo parezca no utilizado. Una ruta puede ser visible porque un origen no autorizado tuvo éxito. La ausencia de observación no es prueba de abandono, y la presencia no es prueba de consentimiento.

Las ventanas de tiempo ayudan pero no curan el problema. Un objeto que no ha coincidido con el BGP observado durante años merece revisión, especialmente cuando los contactos están muertos y un titular actual lo disputa. Aún puede describir un respaldo frío o un prefijo anunciado solo dentro de un dominio de enrutamiento limitado. Un objeto joven puede ser incorrecto el día en que se crea. El tiempo de última modificación mide la interacción con la base de datos, no la verdad.

El papel útil de BGP es probatorio y acotado. Un equipo de migración puede nombrar colectores, looking glasses ascendentes o su propia telemetría de sesión; registrar el origen observado antes, durante y después de la transición; y conservar resultados contradictorios. Si el origen antiguo desaparece en todos los lugares observados mientras el nuevo origen y el filtro de reemplazo funcionan, la confianza en la retirada aumenta. Si el origen antiguo persiste, el equipo investiga si se trata de propagación, fuga, solapamiento intencional o uso indebido.

Las mediciones nunca deben ser convertidas en un denominador global sin respaldo. Un estudio de IRR y colectores de enrutamiento seleccionados puede describir su conjunto de datos, fechas y método de clasificación. No puede mostrar cómo cada operador privado construyó filtros, cuántos objetos inactivos eran legítimos o cuántas migraciones causaron daño al cliente. Las decisiones institucionales deben usar las mediciones como evidencia disciplinada, no como certeza decorativa.

RPKI puede establecer precedencia sin convertirse en una máquina de eliminación

RPKI ofrece algo que los objetos IRR convencionales generalmente no pueden: una declaración verificable criptográficamente enraizada en la autoridad certificada de recursos numéricos. Cuando un ROA actual cubre un prefijo y autoriza un origen mientras un objeto IRR nombra un origen conflictivo, el conflicto es una evidencia poderosa. La política RIPE 2018-06 utilizó esa propiedad para limpiar objetos de ruta conflictivos deRIPE-NONAUTH, con notificación y un período de conflicto sostenido antes de la eliminación.

IRRd también puede suprimir objetos de ruta que son inválidos según RPKI y puede exponer pseudo-objetos IRR derivados de ROA a las herramientas de filtrado existentes. ARIN ha ido más lejos en otra dirección al vincular la creación de objetos de ruta IRR autenticados a ROA a través de su Auto-Manager de IRR. Estos mecanismos reducen la divergencia y dan a los operadores una señal de origen más fuerte sin requerir que todos los sistemas de filtrado sean reemplazados de inmediato.

Pero importan tres precauciones. Primero, NotFound no es inválido. Si no existe un ROA que cubra, RPKI no proporciona autoridad conflictiva. Eliminar cada objeto IRR NotFound castigaría a los titulares que no han desplegado RPKI y podría eliminar datos de enrutamiento legítimos. Segundo, un ROA válido puede coexistir con un objeto de ruta para el mismo origen mientras otra política RPSL sigue siendo incorrecta u obsoleta. Tercero, un ROA puede contener un error operativo cometido por el titular legítimo. La autoridad criptográfica no es omnisciencia.

La precedencia también necesita precisión a nivel de objeto. La comparación debe usar correctamente la cobertura del prefijo, el origen y la longitud permitida. Un ROA para un agregado con una longitud máxima restrictiva puede hacer que un objeto de ruta más específico sea inválido incluso cuando el titular pretendía ese más específico para un evento futuro. La solución puede ser corregir el ROA, no eliminar el objeto IRR. La notificación permite al titular distinguir un conflicto de seguridad de un error de configuración.

La regla correcta es que una declaración criptográfica válida, actual y controlada por el titular merece un peso probatorio mayor que una afirmación no autenticada de un tercero. No elimina la necesidad de identificar el evento, advertir a los operadores afectados, proteger la continuidad y registrar el remedio. Una prueba sólida debería hacer que el debido proceso sea más rápido y exacto, no innecesario.

La eliminación debe ser escalonada porque los filtros tienen memoria

La secuencia segura comienza con un inventario. Buscar en los IRR autoritativos de los RIR, registros independientes, servicios de consulta combinada y los conjuntos de fuentes utilizados por los proveedores conocidos. Registrar las claves exactas prefijo-origen, mantenedores, contactos, horas de creación y modificación, etiquetas de fuente, estado RPKI y BGP observado. Expandir los AS-SET relevantes porque una relación obsoleta puede sobrevivir allí incluso después de que un objeto de ruta se corrija.

A continuación, definir el estado terminal previsto. ¿Qué orígenes deben permanecer autorizados? ¿Qué prefijos y longitudes se anunciarán realmente? ¿Hay un solapamiento planificado, un rol de respaldo o mitigación? ¿Qué fuente es apropiada para el titular actual? ¿Quién controla cada objeto de reemplazo? Esta declaración evita que la limpieza se convierta en una competencia para minimizar el número de registros sin importar el propósito operativo.

Luego, crear antes de retirar. Crear o corregir los objetos de ruta previstos a través de fuentes que puedan autenticar al titular actual. Crear ROA consistentes cuando sea apropiado. Pedir a los operadores de tránsito y peering designados que ejecuten una vista previa de sus filtros generados. Confirmar que el nuevo origen sería aceptado y que la recursión a través de AS-SET produce los prefijos esperados. Un correo de aceptación del registro no puede sustituir esta prueba del lado del consumidor.

Solo entonces deben emitirse los avisos de retirada. El antiguo mantenedor, el titular actual del recurso, el contacto del AS de origen cuando esté disponible y los proveedores consumidores conocidos reciben el objeto exacto, la clase de evidencia, la acción propuesta, el plazo de respuesta y el contacto de emergencia. Un objeto disputado puede ser suspendido de las vistas de consulta ordinarias mientras permanece recuperable para los revisores, si las reglas del registro admiten ese remedio y el riesgo lo justifica. La suspensión no debe convertirse silenciosamente en una eliminación permanente.

Después de la decisión, cada fuente autoritativa o independiente registra su acción bajo una referencia de migración común. Las réplicas se verifican con los seriales o instantáneas de la fuente. Las consultas combinadas se repiten con una selección explícita de fuentes. Los operadores reconstruyen los filtros, revisan el delta y aplican un refresco de ruta o su actualización de política segura equivalente. Las observaciones confirman que la ruta prevista sigue siendo aceptada y que el origen sustituido ya no está permitido en las sesiones designadas.

El cierre llega al final. El recibo enumera las fuentes no resueltas, los operadores inalcanzables y cualquier excepción continua. Si un registro de terceros rechaza la eliminación, el titular y los proveedores pueden excluir o reducir la preferencia de esa fuente para el prefijo afectado, pero la excepción permanece visible. Un estado verde debe significar una finalización acotada, no que se omitió evidencia inconveniente.

La coordinación entre bases de datos necesita un evento común, no una base de datos central

Es tentador resolver la inconsistencia proponiendo un IRR global único. Eso simplificaría algunas consultas mientras concentraría la capacidad de admitir, suprimir y eliminar declaraciones de enrutamiento. La historia de los registros de enrutamiento de Internet refleja diferencias legítimas regionales, de proveedores y operativas. La resiliencia puede beneficiarse de múltiples servicios de publicación y consulta. El elemento faltante no es necesariamente un solo propietario; es un evento de cambio interoperable.

Un identificador de evento de migración puede vincular notificaciones y recibos entre registros sin exigirles que renuncien a su autoridad de decisión. El registro incluye los recursos exactos, los orígenes antiguos y previstos, el método de autenticación del titular, el estado RPKI de apoyo, el tipo de evento, el intervalo efectivo y los contactos. Cada registro añade su propia decisión, razón, tiempo y vía de apelación. Las réplicas transportan los datos de origen como antes. Los operadores pueden consumir las decisiones según la preferencia declarada.

Este arreglo expone el desacuerdo en lugar de ocultarlo. Un IRR integrado en un RIR puede aceptar la solicitud del titular actual. RADb puede necesitar verificar un objeto mantenido por separado. Otro registro puede conservar un objeto porque documenta una relación de respaldo activa. El recibo muestra tres resultados y su evidencia. Un operador puede entonces distinguir la coexistencia justificada de una copia abandonada.

La acción específica de la fuente también evita la eliminación accidental por colisión de nombres. Los objetos de ruta se identifican por prefijo, origen y fuente, no solo por prefijo. Un objeto en una fuente puede ser una réplica de otro o una afirmación independiente. Un evento común debe preservar esa procedencia. Nunca debe instruir a cada base de datos para que borre todo el texto coincidente sin preguntar quién lo aceptó originalmente y qué usuarios dependen de él.

La coordinación debe incluir acuses de recibo negativos. Un registro que no tiene un objeto relevante lo dice. Una réplica informa del serial autoritativo que ha aplicado. Un proveedor declara que no utiliza la fuente afectada. Estas declaraciones acotadas son más valiosas que el silencio porque reducen la superficie desconocida. También hacen posible una revisión posterior al incidente cuando un filtro difiere más tarde del estado esperado.

El modelo es de responsabilidad federada: semántica común de evidencia y estado, autoridad local, recibos portátiles y excepciones visibles. Se alinea con el carácter distribuido del IRR mientras corrige la suposición de que las bases de datos independientes inferirán de alguna manera la misma migración a partir de BGP.

La notificación es un control operativo, no una cortesía administrativa

La notificación a veces se trata como un retraso añadido por los abogados. En la limpieza de registros de enrutamiento, es parte de la validación técnica. El mantenedor listado puede saber por qué permanece un objeto aparentemente obsoleto. El titular actual puede descubrir un ROA conflictivo. El AS de origen puede enterarse de que una relación de cliente nunca se cerró. Un proveedor puede identificar una dependencia de filtro que necesita un reemplazo antes de la eliminación.

Una notificación efectiva debe llegar a más que la dirección incrustada en un objeto de veinte años. El registro debe usar los contactosnotifyy del mantenedor del objeto, los canales de contacto actuales del RIR, la cuenta del titular registrado y, cuando sea apropiado, el contacto operativo del AS de origen. Los resultados de la entrega deben registrarse. No es necesario exponer públicamente cada dirección; la prueba de que la institución intentó los canales relevantes es suficiente para la revisión.

El mensaje necesita consecuencia y remedio. Indica si la acción propuesta es una advertencia, reducción de preferencia, supresión o eliminación; cuándo ocurrirá; qué evidencia la desencadenó; cómo impugnarla; y cómo obtener una revisión urgente si la alcanzabilidad se ve afectada. Las solicitudes vagas de "actualizar sus registros" no crean un plazo responsable. La eliminación inmediata sin una vía para detener un error puede convertir la higiene de datos en una denegación de servicio.

Los períodos de respuesta deben basarse en el riesgo, no ser ceremoniales. Un objeto claramente conflictivo y no autoritativo durante un evento de abuso activo puede justificar una supresión temporal rápida. Un objeto de respaldo inactivo pero no contradicho puede justificar una revisión más larga. La institución debe publicar los factores, no inventar un período diferente para cada solicitante influyente. Cualquier acción de emergencia recibe una revisión independiente inmediata.

La notificación también llega a las redes consumidoras. Un proveedor de tránsito no necesita evidencia confidencial, pero necesita saber que una entrada de prefijo-origen que utiliza cambiará y que se ha preparado un reemplazo. Los operadores pueden escalonar los deltas de filtro, inspeccionar las eliminaciones inesperadas y evitar reconstruir en el peor momento. El costo de unas pocas notificaciones precisas es pequeño en comparación con la depuración de una ruta rechazada por varias capas de política obsoleta.

Los derechos y remedios determinan si la limpieza es legítima

El titular actual del recurso necesita el derecho a descubrir objetos de ruta que cubran sus prefijos, incluyendo la fuente, el mantenedor, el estado y la vía de impugnación. El descubrimiento no debería depender de conocer el nombre de cada base de datos. Los servicios de búsqueda combinada pueden ayudar, pero su cobertura debe ser declarada. Un resultado faltante de un punto final no es prueba de que no existe un objeto en otro lugar.

El titular también necesita legitimación para solicitar la corrección o retirada. Ese derecho no garantiza la eliminación inmediata; garantiza que el registro autenticará la solicitud, examinará la evidencia, notificará a las partes afectadas y emitirá una decisión razonada. Cuando el mantenedor del objeto de ruta es un antiguo proveedor, no se debe decir al titular que solo el antiguo proveedor puede hablar. La disputa misma trata sobre si esa autoridad operativa delegada terminó.

El mantenedor listado tiene derechos recíprocos. Puede ver la reclamación, presentar evidencia de autorización continua y apelar una decisión adversa. Si las credenciales fueron comprometidas, puede solicitar una suspensión de emergencia. Si el titular actual está equivocado sobre un acuerdo de respaldo o de cliente, el registro puede ser retenido o modificado. El debido proceso protege la información de enrutamiento precisa tanto como elimina los residuos.

Los consumidores necesitan un remedio diferente: una excepción con una expiración. Si una decisión de registro se retrasa mientras un objeto obsoleto crea un riesgo demostrable, un operador puede excluir el objeto o la fuente para el prefijo afectado bajo una política documentada. Si la eliminación bloquea inesperadamente el servicio, puede restaurar temporalmente una excepción revisada mientras el titular y el registro reparan la declaración autoritativa. Las excepciones deben ser limitadas, registradas y reconsideradas automáticamente.

La revisión independiente completa la estructura. Un revisor verifica la cadena de autoridad, la evidencia, la notificación, el efecto técnico y la consistencia con las reglas publicadas. Debería ser posible revertir una supresión errónea y crear un nuevo objeto actual sin falsificar la historia. Las versiones antiguas pueden permanecer en el historial protegido incluso cuando desaparecen de las consultas de política normales.

La legitimidad es visible en el remedio. Una base de datos que puede aceptar objetos pero no ofrece una vía práctica de corrección pide a los operadores que confíen en la permanencia sin responsabilidad. Una base de datos que elimina a petición privada sin notificación les pide que confíen en la discreción. El punto medio creíble es la evidencia, la legitimación, la acción acotada y la revisión.

Las métricas útiles miden el cierre, no el tamaño de la base de datos

Contar objetos de ruta es fácil y a menudo engañoso. Una base de datos puede reducir su total eliminando políticas inactivas legítimas. Puede presumir de alta frescura tocando marcas de tiempo sin confirmar la autoridad. Puede informar pocos conflictos porque su regla de selección de fuentes oculta objetos de menor preferencia. Las métricas de gobernanza deben seguir el evento de migración y retener el denominador.

Para cada migración participante, medir el intervalo desde la solicitud autenticada hasta el inventario completo; la proporción de objetos descubiertos para los cuales se pudo contactar a un mantenedor responsable; el intervalo hasta la aceptación del reemplazo; el tiempo hasta cada decisión de fuente independiente; el retraso de la réplica; el tiempo hasta la actualización del filtro del operador designado; y el número de excepciones no resueltas al cierre.

Separar los cambios de tránsito con el mismo origen, los cambios de origen, las transferencias de recursos, los movimientos interregionales y los servicios temporales porque sus estados esperados difieren.

Las medidas de calidad también deben registrar las acciones falsas. ¿Cuántas clasificaciones de obsoleto propuestas fueron retiradas después de que un mantenedor demostrara el uso actual? ¿Cuántas eliminaciones requirieron restauración de emergencia? ¿Cuántos reemplazos fueron aceptados sintácticamente pero omitidos de las fuentes seleccionadas de un proveedor? ¿Cuántos permisos antiguos permanecieron después de la fecha objetivo? Publicar tanto la sobreremoción como la subremoción desalienta a un registro de optimizar solo un lado.

Las estadísticas a nivel de fuente necesitan contexto. Las etiquetas de obsoleto de RADb son señales de revisión útiles, pero su documentación dice que la etiqueta no altera los resultados de las consultas. Un despliegue de IRRd que suprime objetos inválidos según RPKI o de menor preferencia está midiendo la visibilidad efectiva, no la eliminación física. Un IRR de RIR puede tener un vínculo más fuerte con el titular del recurso que un registro independiente, pero una cobertura regional más limitada. Las comparaciones deben indicar estas diferencias de diseño.

Ninguna evidencia seleccionada proporciona un denominador global completo de migraciones de objetos de ruta, filtros generados a partir de entradas obsoletas, ataques exitosos habilitados por permisos residuales o cortes causados por eliminaciones. Las configuraciones privadas de los proveedores y las disputas de los clientes no son generalmente observables. Los informes deben describir los registros, fechas, clases de objetos, puntos de observación BGP y operadores participantes realmente estudiados.

Los límites honestos no debilitan el argumento a favor de la acción. Hacen que las afirmaciones de rendimiento sean útiles. A un titular le importa si su propio movimiento se cerró en las fuentes y proveedores designados. A un operador le importa si su filtro provino de entradas actuales y autorizadas. A una comunidad de registros le importa si sus remedios funcionan y los errores se reparan. Esas preguntas pueden medirse sin pretender ver cada enrutador.

Una Sociedad de Recursos Numéricos puede estandarizar el recibo de traspaso

La Sociedad de Recursos Numéricos aboga por un registro de números preciso, derechos más claros para los operadores de red y límites a la discreción administrativa concentrada. Aplicados con cuidado, esos principios respaldan un papel práctico en la migración de IRR. La NRS puede reunir a titulares, registros, redes de tránsito y operadores de software para definir un recibo portátil y un vocabulario de evidencia.

El recibo no sería un objeto de ruta y no autorizaría BGP. Registraría el evento en torno a las declaraciones autoritativas: prefijo, orígenes antiguos y previstos, tipo de evento, RIR relevante, fuentes IRR, estado del mantenedor, autenticación del titular, comparación RPKI, notificaciones, decisiones de fuente, observaciones de réplicas, pruebas de filtros, excepciones y revisor. Las firmas o atestaciones autenticadas identifican quién hizo cada declaración sin pretender que una sola institución las hizo todas.

La NRS también puede publicar pruebas de conformidad. Un registro demuestra descubrimiento, impugnación del titular actual, notificación al antiguo mantenedor, suspensión reversible, registro de eliminación y estado de réplica. Un proveedor demuestra selección explícita de fuentes, expansión reproducible de AS-SET, actualización escalonada de filtros y expiración de excepciones. Un proveedor de transferencia o red gestionada demuestra que la terminación incluye un inventario IRR. Los resultados de las pruebas expiran e identifican la versión examinada.

Esto avanzaría la descentralización al hacer que la calidad del servicio sea portátil. Los titulares podrían comparar si un IRR ofrece una recuperación creíble. Los operadores podrían preferir fuentes cuyos controles de autoridad y frescura estén medidos. Los registros podrían coordinarse sin crear un nuevo firmante central. Los investigadores podrían analizar eventos completados con consentimiento y límites adecuados.

La NRS debe permanecer consciente de la evidencia. Sus materiales públicos declaran posiciones de defensa; no prueban el despliegue de un servicio de migración IRR o un consenso universal de los miembros sobre detalles técnicos. La acreditación no puede obligar a un RIR a eliminar un objeto, garantizar que un proveedor actualice los filtros o establecer un título legal sobre el espacio de direcciones. El valor de la Sociedad residiría en estándares, transparencia y apoyo a los miembros, no en reclamar una autoridad raíz que no posee.

El papel positivo más fuerte es hacer que los derechos sean ejecutables. Un titular que se ha movido debe saber dónde permanecen las declaraciones antiguas, cómo impugnarlas, qué prueba se requiere y cuándo cambió cada consumidor. Eso es más concreto que un eslogan sobre el control y más compatible con una Internet distribuida que reemplazar a un guardián no responsable por otro.

La migración termina cuando el permiso antiguo ya no llega a la política

Un resultado ordenado de búsqueda IRR no es el objetivo final. La red prevista debe permanecer alcanzable a través de orígenes autorizados, y el permiso anterior debe dejar de influir en los filtros que importan. Ese estado puede describirse sin reclamar un conocimiento universal.

El titular actual está autenticado. Las declaraciones de prefijo-origen previstas existen en fuentes apropiadas y, cuando se utilizan, se alinean con ROA válidos. Las copias de seguridad planificadas y los orígenes temporales tienen un alcance explícito. Los objetos sustituidos han sido eliminados o suprimidos según reglas publicadas tras notificación y revisión. Los duplicados independientes se resuelven o se nombran como excepciones. Las réplicas han aplicado los cambios autoritativos relevantes. Las redes de tránsito y peering designadas han reconstruido y desplegado filtros.

Las observaciones BGP en los puntos de observación declarados coinciden con el estado previsto.

Cada cláusula importa. Sin la autenticación del titular, la limpieza puede convertirse en un secuestro por administración. Sin un reemplazo, la eliminación puede bloquear el servicio. Sin notificación, una ruta inactiva legítima puede ser borrada. Sin acción fuente por fuente, los duplicados sobreviven. Sin evidencia de réplica y filtro, un cambio de registro puede no llegar nunca a los enrutadores. Sin observaciones acotadas, una afirmación de finalización va más allá de lo que nadie midió.

El antiguo objeto de ruta no es peligroso meramente porque sea antiguo. Se vuelve peligroso cuando una afirmación obsoleta retiene fuerza operativa sin un principal responsable actual. Tampoco la eliminación es intrínsecamente virtuosa. Solo es segura cuando la institución puede explicar por qué terminó la autoridad, cómo se protegió la continuidad y qué remedio existe si el juicio fue erróneo.

Los fundadores del IRR diseñaron un medio distribuido para convertir la política de enrutamiento declarada en coordinación. Tres décadas después, esa misma fortaleza hace que la sucesión sea trascendente. Un texto escrito para un arreglo comercial y técnico puede ser copiado, replicado y compilado mucho después de que el arreglo cambie. Las redes se mueven más rápido que la memoria institucional a menos que la migración se convierta en un evento por derecho propio.

La regla rectora es, por tanto, simple pero exigente: demostrar la fuente actual de autoridad, hacer utilizable la política prevista, notificar a quienes pueden contradecir la evidencia, retirar las afirmaciones antiguas en cada fuente independiente, verificar la distribución y cerrar solo después de que los consumidores designados hayan cambiado. Una red no se ha movido completamente mientras su permiso anterior siga vivo en los filtros de las redes de las que depende.