Resumen

  • RFC 3330 reunió bloques IPv4 dispersos y dejó claro que números parecidos podían obedecer reglas muy distintas para el host, el origen, el destino, el reenvío y las fugas.
  • Su tabla de 2002 era una instantánea, no un oráculo de seguridad. Los RFC posteriores y el registro actual de IANA separaron la clasificación en atributos versionados, donde los prefijos más específicos también importan.

La misma dirección no concede los mismos permisos

Una dirección IPv4 corriente puede identificar un host alcanzable mediante rutas públicas. Pero 127/8 debe volver al propio equipo; 10/8, 172.16/12 y 192.168/16 están destinados a redes privadas; 169.254/16 permite comunicarse dentro de un mismo enlace cuando falta la configuración habitual. Los prefijos documentales sirven para ejemplos y 198.18/15 se reservó para pruebas de rendimiento. La multidifusión y la difusión limitada siguen reglas diferentes.

Los 32 bits no explican esas diferencias. Las determinan una decisión de protocolo, una asignación o una política de encaminamiento. Un router que trate todos los valores como destinos públicos puede dejar escapar una dirección de bucle local. Un filtro que bloquee cualquier cosa llamada «especial» puede impedir un uso previsto. El nombre de una clase no equivale a la acción que corresponde.

Antes de RFC 3330, las descripciones de esos bloques estaban repartidas entre distintos RFC y registros de parámetros. El documento las reunió en un catálogo de IANA y señaló expresamente que no abarcaba el espacio IPv4 asignado a operadores y usuarios por los RIR. No sustituía la asignación ordinaria: hacía visibles un conjunto pequeño de excepciones y designaciones especiales.

«Especial» no es una sola propiedad

En 2002, las expectativas se explicaban mediante texto. Más tarde quedó claro que el indicador binario «especial» no bastaba para implementar filtros ni investigar incidentes. Una dirección puede ser válida como origen e inválida como destino; un router puede reenviarla entre interfaces externas sin que deba ser alcanzable globalmente; un protocolo puede exigir un tratamiento singular aunque otras propiedades sean falsas.

RFC 5735 sustituyó el catálogo histórico. RFC 6890 creó después registros mantenidos para direcciones IPv4 e IPv6 de propósito especial. Las entradas separan la validez como origen, la validez como destino, la posibilidad de reenvío, el alcance global y la reserva por el protocolo. Cada campo responde a una pregunta distinta; fusionarlos elimina justo la información de la que depende una regla de frontera.

RFC 8190 aclaró el significado de «alcance global». Es una propiedad operativa esperada dentro de un modelo administrativo, no una promesa empírica de que jamás se anunciará una ruta ni se filtrará un paquete. Si un observador público ve un prefijo que el registro marca como no global, puede haber una fuga, un filtro defectuoso, suplantación o un artefacto de medición. La observación por sí sola no cambia el registro.

También importa el prefijo más específico. Una entrada amplia puede contener una asignación más estrecha con atributos diferentes. Una regla que se detiene en el primer prefijo coincidente podría aceptar un origen no permitido o descartar tráfico válido. Para justificar una decisión hay que conservar la entrada exacta que ganó la coincidencia, los atributos consultados y la versión del registro.

La tabla tenía fecha porque la red cambiaba

RFC 3330 enumeró bloques cuyo carácter especial estaba terminando o que más adelante podían volver a asignarse normalmente. No era un error: era una instantánea de la red de entonces. El riesgo aparece cuando alguien incrusta esa fotografía de 2002 para siempre en software, informes de seguridad o reglas de cumplimiento.

Los sucesores continuaron la revisión. RFC 5737 reservó tres prefijos documentales distintos, en lugar de depender solo del TEST-NET mencionado en 2002. RFC 3927 desarrolló el comportamiento de IPv4 link-local. RFC 6890 cambió las listas estáticas por registros actualizables. Hoy el registro de direcciones IPv4 de propósito especial de IANA es la referencia operativa para esos campos; RFC 3330 sigue siendo evidencia histórica de cómo se construyó el catálogo.

La fecha importa en ambos sentidos. No se debe atribuir retrospectivamente a un operador de 2002 un atributo incorporado mucho después. Tampoco basta un RFC antiguo para clasificar un paquete observado hoy. Un análisis sólido anota la hora de observación, la versión o copia del registro, el prefijo exacto, la dirección del paquete, la interfaz y los atributos que sustentaron la decisión.

El documento también separaba las necesidades técnicas de una asignación especial de la política general de direcciones. Si un RFC necesitaba un bloque para el proceso de estándares, debía describir requisitos técnicos como el tamaño o la longitud del prefijo. IANA consultaría a los RIR y efectuaría la asignación cerca de la publicación. RFC 3330 describió una práctica; no concedió a cada experimento una reserva permanente ni creó nuevas normas de asignación.

La entrada de registro no filtra paquetes

El registro expresa una intención y ofrece datos a hosts, routers, firewalls, bibliotecas y herramientas de auditoría. No actualiza equipos ni impone filtros en los bordes. La brecha entre la propiedad registrada y la conducta observada es un problema operativo distinto.

Un paquete cuya fuente privada aparece en una interfaz externa puede deberse a suplantación, una configuración equivocada o una ruta encapsulada. Un programa puede usar loopback como convención local. Un ejemplo copiado puede dejar un prefijo documental en producción; una prueba de rendimiento puede contaminar métricas normales. En ninguno de esos casos la dirección, por sí sola, revela dónde se creó el paquete ni qué acción tomó la red.

Hay que registrar el sentido del paquete, las interfaces de entrada y salida, la encapsulación, el estado de traducción, la entrada de registro correspondiente al prefijo más largo y el resultado del filtro. Una captura demuestra que se observaron ciertos bits en un punto; no prueba por sí misma el lugar de origen. Del mismo modo, «sin alcance global» no significa «nunca visible para un colector público».

RFC 3330 marcó una transición importante: IPv4 ya no era solo una secuencia de direcciones asignadas, sino un espacio compartido con excepciones operativas documentadas. La lección duradera no consiste en memorizar algunos prefijos famosos. Consiste en separar el valor numérico, el tipo de asignación, la regla ejecutada y la observación. Si se mezclan esos cuatro recibos, el catálogo se convierte en una falsa prueba de origen o alcance.

Fuentes