Resumen

  • RFC 2050 organizó la distribución IPv4 alrededor de tres objetivos que podían chocar: conservación, enrutabilidad y registro.
  • La inscripción identificaba una asignación, un usuario y contactos; no era un anuncio BGP, una aceptación mundial ni una prueba de entrega, y sus procedimientos ya no son política vigente.

El texto de RFC 2050 pedía algo incómodo: juzgar cada solicitud sin fingir que existía una respuesta óptima para todos. Conservar una reserva finita favorecía bloques ajustados al uso. Hacer escalable el enrutamiento favorecía bloques jerárquicos que un proveedor pudiera agregar. Registrar exigía publicar quién recibió qué y a quién llamar. Mejorar una columna podía encarecer otra.

Por eso el documento subrayó que una asignación o adjudicación IPv4 no garantizaba la enrutabilidad «de ninguna manera». La frase no degradaba el registro. Definía su competencia. El registro evitaba duplicaciones y dejaba una pista de responsabilidad; cada red autónoma seguía decidiendo qué anuncio aceptar.

La distinción entre allocation y assignment era funcional. Un registro regional entregaba un bloque a un proveedor para que este hiciera asignaciones a sus clientes. La empresa final recibía autoridad de uso interno, no una facultad automática de subdividir y volver a delegar. Ninguno de esos actos configuraba un router vecino.

La información de reasignación debía llegar pronto al registro. Servía para identificar al usuario y al contacto operativo o de seguridad, comprobar que el proveedor había agotado la mayor parte de su bloque antes de pedir otro y apoyar estudios. Aproximadamente el 80 % de esa información debía estar presentada antes de otra asignación CIDR. Era una cadena de rendición de cuentas, no telemetría de tráfico.

El expediente podía incluir subredes, máscaras, conteos de hosts, topología, protocolos, limitaciones, asignaciones anteriores, calendario de despliegue y crecimiento. RFC 2050 citaba 25 % de utilización inmediata y 50 % al año, más un inicio gradual para proveedores. Esos números describen el criterio de 1996. No prueban que un solicitante desplegara lo prometido ni autorizan aplicar hoy la misma regla.

El RFC 1518 había situado la agregación en la arquitectura CIDR. RFC 2050 aconsejó pedir direcciones al proveedor ascendente, mantener intactos los bloques y devolverlos al terminar la conectividad, con tiempo para renumerar. La tabla global podía crecer menos, pero el cliente adquiría un coste de cambio visible.

Para redes multihomed o conectadas a un gran intercambio, el acceso directo al registro podía tener sentido. El propio RFC advertía que esas direcciones independientes del proveedor eran las menos susceptibles de ser enrutables. Incluso una carta de un proveedor dispuesto a inyectar un prefijo largo sólo documentaba la decisión de ese proveedor.

Los grandes tránsitos podían limitar longitudes o filtrar rutas no agregadas. Así se separaban cuatro hechos: el registro había emitido el bloque; el proveedor había intentado anunciarlo; ciertos vecinos lo habían aceptado; y un paquete había llegado desde un origen concreto. Saltar de uno a otro convertía evidencia parcial en ficción.

La visibilidad BGP tampoco cerraba el caso. Un colector ve a través de sus pares y en un instante. No demuestra propagación universal, uso interno, legitimidad jurídica, autorización del origen, respuesta de un servicio o permanencia de los criterios. Una ausencia tampoco prueba abandono.

RFC 2050 hablaba de préstamos durante la conectividad, auditoría, validez mientras persistiera la necesidad, posible invalidación, aprobación de transferencias y recursos de apelación hasta IANA. Deben leerse como prácticas documentadas en 1996. La ficha del RFC Editor, el Datatracker y la búsqueda de erratas conservan su estado histórico.

El RFC 7020 sustituyó al 2050 en 2013. Explicó que el sistema había cambiado de forma sustancial y omitió procedimientos reemplazados por políticas de ICANN y los RIR. Mantuvo tres objetivos equivalentes y dijo con mayor claridad que anunciar una dirección y decidir cómo se publica son cuestiones operativas ajenas al registro.

La nota IESG del documento original limita también el valor de la etiqueta BCP 12. Aprobarlo significaba creer que representaba correctamente la práctica vigente. No significaba respaldarla ni recomendarla. La nota prometió una reevaluación en diciembre de 1997; las fuentes congeladas no ofrecen un resultado separado que pueda afirmarse.

El RFC 1466 fue el antecedente reemplazado. El RFC 2008 examinó después préstamo, portabilidad y filtrado de rutas más específicas. El RFC 7249 ofrece contexto institucional posterior. Son piezas contiguas, no permisos para mezclar épocas.

El registro IPv4 actual de IANA prueba su propia fotografía de asignaciones. No reconstruye un expediente de 1996 ni acredita por sí solo un anuncio actual.

La metáfora de la libreta de direcciones de Heng Lu separa bien el registro de las calles. Sus ensayos sobre capas de realidad, primacía del código en ejecución y especificación mínima son lentes editoriales modernas, no fuentes sobre la intención de los autores.

La lección no es que el registro careciera de poder. Podía proteger unicidad, exigir documentación y diseñar incentivos de agregación. La lección es que ese poder terminaba antes de la decisión de cada proveedor. RFC 2050 dejó escrita la frontera que su propio sistema no podía cruzar.

Fuentes