Resumen

  • RFC 1887 presentó el multihoming como una elección sobre quién paga: el sitio mediante renumeración y complejidad, o la zona libre de rutas por medio de excepciones globales.
  • RFC 2073 incorporó Registry ID, Provider ID y Subscriber ID al formato; RFC 2374 sustituyó esa división por TLA/NLA/SLA y RFC 3587 hizo histórica también esa estructura fija.
  • La agregación siguió siendo necesaria, pero los nombres institucionales dejaron de formar parte permanente de la geometría de la dirección.

El recurso escaso era la memoria compartida

IPv6 ofrecía un espacio de direcciones vasto. Eso no daba a cada router memoria, energía ni tiempo de convergencia infinitos. La RFC 1887, de diciembre de 1995, quiso reducir la información de alcanzabilidad que debía circular entre dominios.

Si cien clientes tomaban bloques contiguos de un proveedor, el exterior podía ver un solo prefijo. La economía aparecía en redes que quizá no tenían contrato alguno con esos clientes. Era la continuación de la arquitectura CIDR de RFC 1518 y RFC 1519: el prefijo seguía la topología y el algoritmo escogía la coincidencia más larga.

Pero la asignación que hace posible el resumen también distribuye poder. RFC 1887 tituló una sección “eficiencia frente a control descentralizado”. No asumió que la frontera de una organización, la competencia de un registro y la forma física de Internet coincidieran. Un plan coherente debía elegir dónde tolerar la excepción.

El sitio estable convertía a los demás en memoria

La primera solución de multihoming entregaba al sitio un prefijo independiente. La organización mantenía una sola numeración y podía resumir todo su interior. A cambio, sus proveedores anunciaban una ruta específica que otros proveedores debían conservar. Funcionaba para unos pocos; no necesariamente para cientos de miles.

La segunda solución daba un prefijo por conexión. Cada proveedor resumía bien y el tráfico tendía a entrar cerca del destino. Sin embargo, una conexión cortada podía dejar inalcanzables las direcciones derivadas de ella. La conectividad exterior cambiaba y la numeración interior debía seguirla. Añadir rutas de respaldo recuperaba resiliencia a costa de perder parte de la ventaja de escala.

La tercera solución escogía un prefijo principal y limitaba la difusión de atajos. La cuarta agrupaba a clientes que compartían exactamente determinados proveedores. Eran formas distintas de colocar tablas, coordinación y dependencia; no eran una salida sin coste.

La conclusión de RFC 1887 utilizó una palabra decisiva: financiero. Cada alternativa imponía un coste real tanto a las organizaciones multihomed como a los dominios de tránsito, incluidos los no conectados con ellas. La política de aceptar o exportar prefijos ajenos expresaba ese reparto.

La cadena administrativa entró en 128 bits

La RFC 2073, publicada en enero de 1997, propuso un formato con prefijo de tipo, cinco bits de Registry ID, Provider ID, Subscriber ID y 64 bits internos. IANA ocupaba el nivel de registro principal y podía delegar; RIPE NCC, INTERNIC y APNIC recibían valores de registro junto con el espacio multirregional de IANA.

El formato hacía visible una cadena. El registro repartía espacio a proveedores; el proveedor organizaba a sus abonados; el abonado estructuraba su parte local. Aun así, los routers no debían comprender esa semántica: usaban longest-prefix match. El documento permitía otros formatos y contemplaba que un abonado recibiera espacio directamente del registro.

Por eso, el nombre de un campo nunca fue prueba suficiente de propiedad o control. Indicaba cómo se había formado un prefijo bajo una arquitectura concreta. No decía quién lo originaba hoy, qué contrato estaba vigente ni si un paquete llegaba.

Primero salió el registro; luego salieron TLA y NLA

En julio de 1998, RFC 2374 dejó obsoleta RFC 2073. Eliminó los bits de registro porque no hacían falta para agregar rutas. Propuso en su lugar Top-Level Aggregation, Next-Level Aggregation y Site-Level Aggregation, además del identificador de interfaz.

La topología pública podía agregarse por proveedores o puntos de intercambio. Un sitio conectado a un intercambio podría conservar independencia de los carriers de larga distancia y ser multihomed sin un prefijo por carrier. Sin embargo, la selección de proveedor y la portabilidad quedaban fuera del alcance. El dibujo reservaba una posibilidad, no ejecutaba la mudanza.

La RFC 3587, de agosto de 2003, convirtió RFC 2374 y TLA/NLA en históricos. Dijo que la estructura había sido sustituida por una política coordinada de los RIR, que podía no ser el mejor enfoque técnico en esa fase y que la política probablemente evolucionaría.

Sobrevivió un formato menos prescriptivo: prefijo global de enrutamiento, ID de subred e ID de interfaz. RIR e ISP podían seguir estructurando jerárquicamente el prefijo global y el administrador local su subred. No desapareció la agregación; desapareció la pretensión de que una jerarquía institucional particular debía quedar nombrada para siempre en el estándar.

Poder cambiar la dirección no elimina el ancla

La RFC 4192 describió una renumeración make-before-break: prefijos viejo y nuevo conviven mientras se cambian DNS, routers y configuración. El mecanismo permite continuidad, pero no descubre automáticamente cada dirección escrita en una ACL, un sistema de monitorización o una aplicación.

La RFC 4984 registró justamente ese límite. Para algunos sitios, las dependencias volvían la renumeración efectivamente imposible. El espacio PI evitaba el bloqueo del proveedor, pero hacía que el coste de una ruta adicional se distribuyera por el sistema global. El espacio PA agregaba, aunque el multihoming podía obligar a desagregarlo.

El informe llamó al problema “sobrecarga localizador/identificador”. La topología quiere que el localizador cambie; la organización quiere que el identificador permanezca. Una sola cadena de bits no puede maximizar simultáneamente ambas propiedades.

También cambió la frontera del sitio. RFC 3177 aconsejó /48 como caso general. RFC 6177 revocó en 2011 esa talla única y advirtió que unas pocas longitudes fijas podían convertirse en clases codificadas. Conservó espacio suficiente como principio y devolvió el tamaño exacto a la comunidad operativa.

Una dirección no absorbe todas las autoridades

La asignación prueba un acto registral bajo una política y fecha. Una observación BGP prueba un origen y camino visibles desde un punto. El contrato prueba una obligación comercial. Una traza o registro de servicio prueba otro resultado. Se pueden vincular mediante el prefijo; no se pueden sustituir.

La secuencia de RFC deja una disciplina útil para cualquier sistema de coordinación. Medir la economía de agregación. Conservar la procedencia de cada delegación. Registrar las excepciones globales y la carga interna de renumerar. Permitir que la política cambie sin presentar el estado nuevo como si siempre hubiese sido la semántica de la dirección.

La tabla de rutas necesita compresión. La historia y la responsabilidad necesitan exactamente lo contrario.

Fuentes