Resumen

  • La estimación de redes no anunciadas de RFC 1917 no era un inventario de direcciones abandonadas: una red interna podía estar activa sin publicar una ruta global.
  • El llamamiento dependía de la cooperación del asignatario, del proveedor y del registro. Decidir, autorizar, renumerar, retirar, actualizar y reasignar eran actos distintos.
  • Los registros actuales muestran delegación y recuperación bajo políticas concretas, pero no prueban por sí solos el uso anterior, la retirada operacional ni la causa histórica de cada devolución.

La diferencia entre dos cifras no era una bolsa de direcciones libres

En febrero de 1996, BCP 4 reunió dos preocupaciones que el crecimiento de Internet había vuelto urgentes. La primera era la utilización de un espacio IPv4 finito. La segunda era la capacidad de los routers centrales para sostener un número creciente de rutas. RFC 1917 proponía devolver asignaciones y mejorar la agregación, pero no confundía por completo ambos remedios.

Su cifra del 30–40 % debe leerse con fecha y atribución. No era una medición actual ni una observación de cada máquina. Algunos titulares tenían redes registradas que funcionaban de manera privada y podían conectarse más tarde. Otros usaban pasarelas de aplicación o NAT y nunca anunciaban sus direcciones internas. La ausencia de una ruta podía ser indicio de abandono, pero también de aislamiento, filtrado o agregación.

Para decidir que un bloque era realmente prescindible hacían falta datos que el sistema global no podía ver: inventario de activos, planes de crecimiento, aplicaciones, enlaces con terceros y la autoridad empresarial para renunciar a la asignación. El observador de rutas controlaba una ventana; el titular controlaba otra.

El exceso procedía de historias diferentes

RFC 1917 no culpaba a una sola práctica. En los primeros años, una organización podía obtener redes según su solicitud, cuando el espacio parecía abundante. Más tarde podía acumular varias clases C y recibir una clase B al crecer inesperadamente. Algunos proveedores asignaban espacio según el servicio contratado y no según necesidad comprobada. Las fusiones superponían planes. Los manuales de fabricantes enseñaban a pedir direcciones públicas para máquinas que sólo hablarían dentro de una empresa.

El documento señaló que cuatro redes de clase A habían sido devueltas a IANA en mayo de 1995. No dio sus nombres en ese pasaje ni reconstruyó el retiro técnico. La afirmación demuestra que RFC 1917 registraba un precedente; no autoriza a completar el relato con titulares o resultados no documentados.

Frente a esos excedentes, el RFC formuló un llamamiento. Animó a devolver redes sin uso, a liberar porciones poco utilizadas cuando fuera razonablemente fácil y a planificar la renumeración. Para redes destinadas a permanecer aisladas recomendó considerar el espacio privado de RFC 1597. RFC 1918 lo sustituyó y dejó claro el coste: las direcciones privadas carecen de significado global y una futura conexión puede exigir renumerar.

Devolver requería más que una decisión técnica

El formulario histórico pedía enviar el prefijo y cambiar sus contactos por una reserva. Era una instrucción administrativa concreta, no un protocolo de descubrimiento. Antes del mensaje, alguien debía establecer que la organización ya no necesitaba el espacio y que quien escribía podía representarla. Después, el registro debía aceptar el cambio. Los operadores debían retirar rutas y referencias. Sólo tras un intervalo justificado podía evaluarse una nueva asignación.

El verbo devolver oculta así una secuencia: intención, autorización, transacción registral, retirada operativa, observación y eventual redistribución. Una respuesta positiva del registro no afirmaba que los paquetes hubieran dejado de llegar. Una tabla BGP vacía no afirmaba que ningún host interno conservara el número. Una nueva asignación no probaba que la anterior se hubiese cerrado correctamente.

La agregación daba al proveedor una responsabilidad distinta

RFC 1917 propuso que ciertos clientes que ocupaban la parte baja de un bloque contiguo permitieran al proveedor usar porciones altas para otros clientes sin añadir rutas globales. También pidió a los proveedores devolver redes ajenas a sus bloques normales, impulsar la renumeración de nuevos clientes que traían direcciones antiguas y comprobar las rutas anunciadas a sus proveedores superiores.

El proveedor podía demostrar qué configuración controlaba y qué anuncio originaba. No podía convertir esa visibilidad en prueba de que el cliente no tenía dependencias internas o de que una persona concreta estaba facultada para ceder el registro. La cooperación entre proveedor y cliente resolvía una frontera; no eliminaba las demás.

Una norma posterior no fue el poder secreto del llamamiento

RFC 2050 afirmó después que las direcciones seguían siendo válidas mientras continuaran cumpliéndose los criterios de asignación, y describió la posibilidad de invalidarlas cuando desapareciera la necesidad. Esa autoridad y el esfuerzo de notificación del registro pertenecen a un marco posterior. RFC 1917 seguía siendo una solicitud de retorno voluntario.

RFC 7020 separó con más precisión la gestión del fondo, la distribución jerárquica y la exactitud registral de la decisión operacional de anunciar una dirección. El registro impide la asignación simultánea y conserva información; no controla automáticamente los routers.

Hoy, una actualización de una antigua clase A pasa por el RIR de la región del solicitante, y el retorno de un /8 completo llega a IANA después de ese trámite. La página de IANA que describe el procedimiento es de 2010, revisada en 2016; no debe proyectarse sobre el formulario de 1996.

El registro de espacio IPv4 recuperado muestra rangos, RIR de retorno, fechas y asignaciones bajo el mecanismo mundial posterior al agotamiento ratificado en 2012. Es una fuente fuerte para esas filas. No es una lista exhaustiva de devoluciones históricas, de usuarios finales anteriores ni de motivos, y no atribuye cada retorno a RFC 1917.

Fuentes