Resumen

  • Las tres franjas de RFC 1918 pueden usarse sin coordinación registral y solo prometen unicidad dentro de una empresa o de un conjunto que coordina su plan.
  • El propio BCP reconoció que una fusión o una nueva interconexión podía convertir dos usos legítimos en direcciones duplicadas y obligar a renumerar.
  • Traducir, enrutar, resolver un nombre, autenticar un interlocutor y completar una operación son comprobaciones distintas. Una ruta disponible no devuelve por sí sola la identidad perdida.

Cuando un número adquiere dos biografías

La diligencia de una adquisición suele juntar documentos que nunca fueron redactados para convivir. Un inventario dice que 10.20.30.40 sostiene una aplicación financiera. El otro emplea el mismo valor para un servicio de fábrica. Cada equipo puede mostrar años de funcionamiento estable. No existe una asignación de IANA que permita ordenar las pretensiones, porque el espacio se creó precisamente para ser reutilizado.

Antes de la unión, «10.20.30.40 dentro de esta empresa» era una descripción suficiente. Después, la frase ha perdido su última mitad. La tabla combinada conserva el número y elimina el ámbito. Esa operación administrativa fabrica la ambigüedad antes de que viaje el primer paquete.

RFC 1918 se suele enseñar como memoria: 10/8, 172.16/12, 192.168/16. Vista históricamente, la decisión fue otra. El Internet aceptó que no todo host necesitaba una identidad numérica global y convirtió la frontera organizativa en parte de la arquitectura. La contraprestación era una deuda de integración.

La polémica precedió a la adopción

RFC 1597 formuló en marzo de 1994 la asignación para internets privados. Separó los hosts según su necesidad de comunicación externa. Cajeros, puestos internos, pantallas o interfaces de routers podían usar números inequívocos dentro de una empresa aunque el mismo número apareciera en otra.

RFC 1627 respondió en julio con un título deliberadamente combativo: Network 10 Considered Harmful. Defendía la unicidad global como condición de colaboración futura. Las organizaciones cambian de propósito, se conectan y se fusionan; las aplicaciones y licencias pueden aferrarse a los números. Su ejemplo de Apple describe miles de hosts renumerados, pero este paquete no aporta una fuente independiente que confirme cantidad, coste o resultado. Debe leerse como evidencia del debate, no como estadística universal.

En 1996, RFC 1918 sustituyó tanto la propuesta como su crítica y se publicó como BCP 5. Uno de sus autores, Eliot Lear, también había firmado RFC 1627. El nuevo texto no declaró falsa la advertencia. Conservó la libertad de uso privado e incorporó expresamente la posibilidad de renumerar cuando se unieran internets privados no coordinados.

La secuencia importa: primero se expuso el beneficio, después el desacuerdo y finalmente una práctica que reconocía ambos. La colisión de una fusión no fue una consecuencia imprevista que la comunidad técnica ocultara. Formaba parte del precio declarado.

La unicidad quedó limitada por diseño

Una empresa puede tomar direcciones de los tres bloques sin pedir autorización a IANA ni a un registro. RFC 1918 afirma que serán únicas solo dentro de esa empresa o dentro del conjunto de empresas que coopere sobre ese espacio. El registro especial actual de IANA mantiene las tres franjas como Private-Use y no globalmente alcanzables.

«Privada» no significa que la primera compañía adquiera propiedad exclusiva. Significa que el valor solo se interpreta dentro de una jurisdicción operativa limitada. Dos redes aisladas pueden usar el mismo /24 sin conflicto porque ninguna pretende que el Internet global distinga entre ambas.

Para que el acuerdo funcione, otras capas deben respetar el mismo contorno. Las rutas privadas no deben propagarse por enlaces entre empresas. Los paquetes con origen o destino privado no deben atravesarlos. Las referencias indirectas, como registros DNS internos, deben quedar contenidas. Si el número es local pero el anuncio o el nombre escapa, una capa promete una población distinta de la que la otra puede distinguir.

RFC 1918 tampoco llamó seguridad a esa condición. Dejó las cuestiones de seguridad fuera de su alcance. Una dirección privada puede estar detrás de filtros, pero no es una credencial. Su falta de alcance mundial no demuestra quién envió un paquete.

La fusión no decide quién debe ceder

El BCP explica que al combinar internets privados algunos números pueden dejar de ser únicos y los hosts afectados necesitar renumeración. También advierte del riesgo cuando dos organizaciones desean comunicarse más tarde. Elegir subbloques al azar puede disminuir la probabilidad de coincidencia; no crea un coordinador ni una prioridad.

El problema de gobierno queda, por tanto, fuera del número. ¿Se renumera la red con menos dependencias? ¿Se conserva la que alberga el servicio más difícil de mover? ¿Se mantienen dominios separados? ¿Se traduce durante una transición? ¿Quién verifica que DNS, reglas de acceso y operaciones de negocio siguen apuntando al destino correcto?

No hay una respuesta moral en la antigüedad del uso. Ambas organizaciones utilizaron un recurso reutilizable. La decisión debe apoyarse en impacto y evidencia: superficie de cambio, control efectivo, capacidad de prueba, continuidad exigida y coste que cada actor puede soportar.

El concepto de realm revela la coordenada ausente

RFC 2663 definió después un address realm como el dominio donde las direcciones son asignadas de forma única y las rutas pueden localizar sus entidades. En otras palabras, la dirección privada estaba incompleta sin su realm. La pared entre empresas transportaba silenciosamente esa segunda coordenada.

La NAT tradicional conecta dominios mediante una traducción y presupone que el espacio interior no se solapa con el exterior. Cuando un mismo valor ya nombra hosts en ambos lados, RFC 2663 presenta twice NAT: cambian origen y destino al cruzar el límite. La solución añade una representación válida para cada lado, pero no convierte el número original en universal.

RFC 3022 muestra el coste operativo de esa capa. Basic NAT asigna direcciones entre conjuntos; NAPT incorpora puertos. Las dos direcciones de una sesión deben atravesar estado coherente, y un desvío a otro traductor puede romper el flujo. El método oculta ciertos cambios a los hosts, pero reduce el significado de extremo a extremo de la dirección y concentra memoria en la red.

Así nace otra deuda. Cada excepción necesita un mapa, capacidad, simetría, observación y un responsable. Si el mapa no está unido a un momento y a un realm, los registros posteriores pueden contener cifras correctas que ya no identifican un acontecimiento.

El peligro no siempre parece una caída

RFC 5684 es una Independent Submission de 2010, no una especificación del IETF Standards Track. Examina redes privadas superpuestas detrás de NAT encadenadas y conexiones VPN remotas. En una de sus escenas, la dirección anunciada para un resolvedor aguas arriba coincide con la de un host local; el tráfico se entrega localmente. En otra, un servicio de la red remota puede confundirse con el servicio corporativo esperado.

El documento llama a este resultado mistaken end host identity. La conexión puede responder y, precisamente por eso, engañar. Para sus escenarios recomienda direcciones no superpuestas o globales en ciertos servidores críticos y autenticación de extremo a extremo en vez de confiar solo en la IP de origen.

La lección no es que toda superposición produzca una suplantación. RFC 5684 no mide prevalencia y sus recomendaciones son específicas de despliegue. La lección probatoria es más limitada: éxito de transporte y corrección de identidad no son sinónimos.

Una auditoría debe pedir recibos distintos. La configuración acredita la dirección local. La ruta acredita el camino elegido. La tabla de traducción acredita la correspondencia. Una credencial acredita al interlocutor. La aplicación acredita su resultado. Mezclarlos permite que «contestó algo» se convierta sin fundamento en «contestó el sistema debido».

Un cuarto ámbito no es un cuarto bloque de RFC 1918

RFC 6598 reservó en 2012 100.64.0.0/10 como Shared Address Space para el entorno de los proveedores y sus CGN. Lo distingue expresamente del espacio privado empresarial. IANA registra ambos como usos especiales no globalmente alcanzables, pero su perímetro y sus operadores no coinciden.

La diferencia evita otra pérdida de contexto. Hogar, empresa y proveedor no forman un interior uniforme. Una dirección adquiere sentido dentro de la población donde se garantiza su unicidad. Cuando un proyecto cruza esas fronteras, debe llevar consigo el nombre del ámbito, traducir la representación o cambiar el número.

RFC 1918 no debilitó la importancia de la unicidad; la distribuyó. Permitió que cada administrador resolviera un problema local sin pedir una identidad global. A cambio, dejó escrito que el futuro podía reunir esos mundos. El día de la fusión, las dos redes siguen teniendo razón sobre su pasado. La nueva arquitectura tiene que construir una sola verdad para su futuro.

Fuentes