Resumen

  • RFC 1997 exige que un receptor consciente de comunidades no anuncie una ruta NO_EXPORT fuera de la frontera de confederación; no autentica al emisor ni legitima el prefijo.
  • El valor vive en un atributo opcional transitivo que la política local puede modificar. RFC 8642 documentó que órdenes parecidas podían borrar o preservar las comunidades conocidas de forma distinta.
  • La confianza exige seguir la ruta enviada, recibida, transformada y anunciada en cada borde, además de conservar filtros independientes de prefijos y relaciones.

Una red anuncia un prefijo más específico por una interconexión privada para que su vecino lo use localmente. No quiere que el detalle llegue al resto de Internet. Añade NO_EXPORT. Ese gesto acredita la intención en el router emisor, no el resultado en el dominio receptor.

RFC 1997 creó COMMUNITIES para agrupar destinos con propiedades compartidas y simplificar la administración de políticas. El atributo es opcional, transitivo y contiene valores de cuatro octetos. Que el atributo sea transitivo no significa que una ruta NO_EXPORT pueda exportarse: son niveles semánticos distintos.

La regla indica que la ruta no debe salir de una frontera de confederación. Un AS independiente cuenta como su propia confederación. NO_ADVERTISE impide anunciarla a cualquier otro par BGP. NO_EXPORT_SUBCONFED también incluye a otros AS miembros de una confederación. IANA registra los números; el RFC da sentido operativo a cada uno.

La ventaja es una palabra común entre equipos que no comparten fabricante. La limitación es igual de importante: el vecino no recibe una orden remota. RFC 1997 permite añadir comunidades a rutas que llegaron sin ellas y modificar el conjunto según la política local.

RFC 8642 mostró el coste de esa libertad cuando la sintaxis no era uniforme. Una instrucción para “establecer” comunidades eliminaba todas las existentes en unos sistemas, preservaba algunas conocidas en otros y no reemplazaba nada en otro comportamiento documentado. La misma revisión humana podía aprobar resultados opuestos.

Por eso el archivo de configuración no es la prueba final. Una route-map puede añadir una etiqueta de cliente y retirar NO_EXPORT por accidente. IPv4 e IPv6 pueden atravesar cadenas distintas. La configuración guardada puede no corresponder al proceso en ejecución. Hay que mirar la ruta resultante.

RFC 8642 impide que nuevas implementaciones introduzcan más divergencia, pero no cambia retrospectivamente el parque instalado. Cada actualización debe probarse con prefijos acotados y comparaciones de atributos antes y después.

RFC 7454 propone una frontera de confianza más fina. Conviene limpiar las comunidades del espacio propio que un vecino no está autorizado a usar, conservar en general las demás y, en particular, no quitar NO_EXPORT sin motivo. Conservar todo permitiría invocar acciones internas; borrar todo destruiría señales legítimas.

NO_EXPORT tampoco contiene una firma. No demuestra quién lo añadió primero, si el origen del prefijo está autorizado o si el contrato comercial acepta esa solicitud. RPKI y las comunidades contestan preguntas distintas: origen permitido frente a alcance de propagación.

RFC 7908 describe una fuga como propagación más allá del alcance previsto, normalmente definido por políticas locales y relaciones entre proveedor, cliente y par. Muchas fugas no llevan ninguna comunidad de contención. Los filtros de prefijos, AS_PATH y clase de vecino siguen siendo necesarios.

RFC 9234 ofrece un contraste. Los vecinos pueden confirmar roles durante OPEN, y Only to Customer transporta estado de relación para prevenir o detectar ciertas fugas. Así se reduce la dependencia de una marca unilateral cuya coherencia con el vecino nadie comprobó.

La autoridad sigue distribuida. El modo estricto puede impedir la sesión si falta un rol compatible, pero también puede provocar una interrupción tras actualizar software. Un AS en el camino puede retirar OTC deliberadamente. La relación resulta más legible; no se convierte en una constitución central ni en prueba criptográfica.

La evidencia comienza en el Adj-RIB-Out del emisor: NLRI, familia, par y conjunto de atributos después de política. Continúa con la ruta cruda recibida y su forma posterior a la importación. Termina en cada salida que podría cruzar el límite.

Un colector público aislado no basta. Su ausencia solo describe la vista que ese colector recibe. Una prueba controlada anuncia un prefijo canario con y sin NO_EXPORT, observa pares conocidos, verifica que la ruta siga disponible dentro del ámbito permitido y confirma la retirada final.

La automatización debe comparar resultados de rutas. Puede bloquear una entrega si desaparece una comunidad protegida, detectar divergencia entre matriz de relaciones y anuncios reales, y exigir vencimiento para excepciones. En un incidente, el receptor necesita un mecanismo local para filtrar, retirar o limitar la ruta sin esperar al emisor original.

La especificación inicial mínima de Heng Lu encaja en este diseño. El protocolo comparte una instrucción pequeña; quienes soportan el riesgo deciden las excepciones y prueban el comportamiento. La primacía del código en ejecución determina el veredicto: RFC y commit describen intención, pero el UPDATE emitido es la realidad.

NO_EXPORT funciona cuando su modestia se conserva. Reduce el coste de expresar alcance sin transferir el mando del router. La palabra no contiene la ruta por sí sola. Cada red hace real la frontera al elegir, implementar y demostrar su política.

Sources