Resumen

  • RFC 1930 definió un sistema autónomo por su política de rutas única y claramente establecida, no por el nombre de la empresa ni por la cantidad de routers.
  • El formulario de RIPE de 1994 ya separaba los datos administrativos de los técnicos; la BCP de 1996 precisó cuándo un ASN propio aportaba información de enrutamiento.

Análisis

Una organización puede tener routers y prefijos, contratar acceso a un proveedor y, aun así, no necesitar un número de sistema autónomo propio. Esa es la sorpresa útil de RFC 1930. En marzo de 1996, la buena práctica del IETF no trató el ASN como una credencial para cada organización conectada. Definió el sistema autónomo como un grupo de prefijos IP gestionado bajo una política de rutas única y claramente definida. El número tenía sentido cuando otras redes debían distinguir esa política.

En un cliente conectado a un solo proveedor, la diferencia era práctica. Si sus rutas seguían la política del proveedor, RFC 1930 decía que normalmente no hacía falta un AS separado: sus prefijos podían quedar dentro del AS del proveedor. Un sitio con varias conexiones era distinto si necesitaba expresar preferencias propias frente a sus proveedores. La cuestión no era simplemente tener dos cables, dos routers o dos contratos. Era si sus anuncios debían representar una política distinta de la de sus pares.

El papeleo ya hacía visible esa diferencia. RIPE-109, fechado el 1 de marzo de 1994, dividía la solicitud de un AS en dos partes: administrativa y técnica. La primera era obligatoria; la segunda podía quedar incompleta al presentar la solicitud, aunque RIPE pedía enviar luego los detalles. El formulario incluía un objeto AS con expresiones as-in y as-out para describir qué rutas aceptaba un operador de sus pares y cuáles les anunciaba. RFC 1930 dice expresamente que su guía de alcance más amplio se basó en ese documento regional.

El texto corregía un error de categoría además de explicar un identificador de protocolo. La definición anterior vinculaba un AS con una sola administración técnica y un protocolo interno común. RFC 1930 señaló que una red podía usar varios protocolos internos y métricas y, sin embargo, presentar un plan coherente hacia el exterior. A la inversa, una sola empresa podía reunir políticas de rutas diferentes. El límite relevante era la política visible para otras redes, no el organigrama ni el número de máquinas.

La distinción también importaba porque el espacio de números era finito. RFC 1930 lo describió como un campo de 16 bits y registró unos 5.100 AS asignados y menos de 600 anunciados activamente en el Internet global, según los autores en 1996. Esas cifras son históricas, no actuales. El documento desaconsejó crear un AS por rutina administrativa y reservó del 64512 al 65535 para uso privado. En 2007, RFC 4893 definió una transición gradual de BGP a números de cuatro octetos con mecanismos de compatibilidad; RFC 6793 la sustituyó después.

La historia no es solo una crisis de escasez. Trata de qué debía representar el número. Un ASN puede identificar una frontera de política en un registro público o en una ruta BGP; por sí solo no prueba quién opera cada router, si una ruta fue aceptada ni dónde se presta un servicio. El formulario, el protocolo y la observación de la red son registros distintos. Confundirlos convierte un identificador útil en una afirmación que no puede sostener.

Fuentes