Resumen

  • Una dirección IPv6 de alcance limitado no codifica a qué instancia de ese alcance pertenece. Un nodo conectado a varias zonas añade un índice local separado de los 128 bits y lo utiliza para escoger interfaz sin enviarlo en el paquete.
  • RFC 6874 intentó en 2013 representar el ZoneID dentro de los URI mediante %25. RFC 9844 anuló esa solución en 2025 y exigió, en su lugar, que las interfaces de usuario recojan, validen y traduzcan la zona dentro del equipo.

Una dirección, dos salidas

Imaginemos un equipo de mantenimiento conectado a una red de servicio por cable y a otra mediante un adaptador aislado. En ambas hay un dispositivo con la dirección link-local fe80::1. La aplicación puede tener una dirección bien formada y aun carecer de la decisión necesaria para usarla.

La RFC 4291 limita las direcciones link-local a un enlace y prohíbe que los routers reenvíen a otro enlace paquetes con origen o destino link-local. Reutilizar la misma cifra en dos enlaces no crea por sí solo una colisión global, porque ninguno de los dos nombres pretende escapar de su enlace.

La RFC 4007 dio precisión a esta geometría en marzo de 2005. Scope es el tamaño de una región topológica; zone es una instancia concreta de una región de ese scope. Dos enlaces son dos zonas diferentes del mismo alcance link-local.

Los 128 bits indican el valor de la dirección, no la zona concreta. Cuando un nodo está unido a más de una, asigna índices locales para distinguirlas. Esos índices no son números coordinados entre equipos. Pueden diferir incluso entre los dos extremos del mismo enlace.

La puerta, por tanto, pertenece al remitente. El receptor no necesita conocer cómo llamó el remitente a su tarjeta de red, y no podría confiar en que ese nombre tuviera el mismo significado en su propio sistema.

Lo que se consume antes de cruzar el límite

La arquitectura asigna una decisión pequeña a cada actor. La persona o automatización expresa la zona; la UI valida; el sistema operativo resuelve; el socket transporta el número dentro del host; la capa IP aplica el alcance. Antes de que el paquete cruce el enlace, el identificador ya ha cumplido su función.

Retenerlo fuera del paquete evita exportar la topología y los nombres internos de cada nodo. También impide que el receptor confunda una pista del emisor con una identidad propia. El precio es que copiar una cadena no siempre reproduce la operación; la ventaja es que el fallo de reproducción señala la falta real de contexto.

La dirección dependía de una puerta local, pero nunca afirmó que esa puerta perteneciera a la dirección. Esa modestia permite reutilizar valores en zonas separadas sin construir una coordinación global innecesaria. El sistema fiable no borra la dependencia: la hace explícita justo donde puede comprobarla.

La separación escrita en la API

La RFC 3493, publicada en febrero de 2003, ya expresaba la división en la interfaz básica de sockets. sockaddr_in6 reserva sin6_addr para la dirección y sin6_scope_id para un selector de 32 bits. El índice acompaña a la llamada local; no amplía la dirección IPv6.

El documento también define la correspondencia entre nombres e índices de interfaz. if_nametoindex() consulta el sistema donde se ejecuta el programa. Si el nombre no existe allí, la operación falla. No hay una consulta a un registro mundial de eth0, ni un mecanismo para pedir al destino cómo denomina su enlace.

RFC 4007 recomienda una forma cómoda para personas y configuraciones: <address>%<zone_id>. Una implementación debería admitir identificadores decimales no negativos y puede aceptar nombres locales. Como la dirección ya expresa el scope, el sufijo solo tiene que desambiguar entre zonas de ese scope.

La recomendación trae sus propios límites. Añadir zona a una dirección global carece de sentido; tampoco debe aplicarse a loopback. La cadena completa es para uso dentro del nodo y no debe circular por la red salvo que todos los intérpretes hayan pactado sus semánticas.

Esa prohibición conserva una propiedad útil: cada campo llega hasta el actor que puede interpretarlo. La red comparte la dirección; el host consume la pista sobre su puerta.

Validar antes de entregar al núcleo

RFC 4007 no fijó repertorio de caracteres ni longitud para identificadores de zona, y dejó el sentido de cadenas no numéricas a cada implementación. Esa libertad exige controles en cada UI. RFC 9844 recomienda una longitud apropiada y rechazar entradas peligrosas como NUL. El erratum held 8553 de RFC 4007 vincula precisamente esa ausencia con la guía de seguridad nueva.

La cadena puede atravesar formularios, shells, ficheros, analizadores de URI, registros y funciones de sistema. Un doble decodificado, un truncamiento o una normalización distinta puede hacer que la puerta mostrada no sea la puerta usada.

Por eso, una herramienta no debería registrar solo «conexión correcta». Debe poder demostrar qué dato recibió, cómo lo separó, a qué índice lo convirtió y qué interfaz existía en ese instante. La validación de caracteres protege al parser; la trazabilidad protege el significado operativo.

Incluso con trazabilidad, el éxito prueba poco más. Que %eth0 funcionara demuestra una resolución local y una operación por ese camino. No autentica al dispositivo remoto, no demuestra propiedad, no ofrece alcance global y no hace portable el nombre.

El conflicto con una sintaxis global

La RFC 3986, de enero de 2005, organiza los URI como identificadores de alcance global, aunque reconoce que ciertas acciones pueden depender del contexto del usuario. También reserva % para la codificación porcentual: un signo por ciento literal usado como dato se representa con %25.

La RFC 6874 trató de encajar el ZoneID en esa gramática en 2013. Para un URI HTTP propuso un literal entre corchetes como [fe80::a%25en1], donde %25 expresa el separador literal y en1 identifica la zona local.

El objetivo era práctico: permitir que un navegador u otra herramienta de URI abriera un dispositivo link-local. Sin embargo, el propio texto decía que el ZoneID solo tenía significado en el nodo originario y debía eliminarse antes de incluirlo en una solicitud HTTP saliente.

Así, la misma pieza parecía formar parte del URI en la barra de direcciones, pero dejaba de serlo antes de viajar. Había que decidir si intervenía en el origin, el historial, los marcadores, las políticas, los proxies o la comparación de URLs. Cada capa podía decodificar %25 en un momento distinto.

No bastaba con escoger otro delimitador. El desacuerdo era de jurisdicción: una selección efímera de interfaz local había entrado en una identidad pensada para almacenarse, compartirse y comparar entre contextos.

Deshacer la extensión para aclarar la obligación

La RFC 9844, publicada en agosto de 2025, declaró completamente obsoleta RFC 6874 porque los implementadores de navegadores consideraron impracticable el método. También revirtió la actualización de RFC 3986. El erratum verificado 8552 de RFC 6874 deja constancia de ese cambio.

La nueva regla se dirige a la interfaz, no al URI. Una UI que acepte una dirección distinta de global unicast debe permitir al usuario escribir o seleccionar un identificador de zona. Se prefiere la forma completa con %, pero se permiten campos separados, listas, delimitadores alternativos o parámetros independientes.

La interfaz mantiene separados dirección e identificador y traduce este último a un índice local. Un identificador malo debería producir un error visible. POSIX inet_pton() no puede convertir por sí solo fe80::1%eth0; la aplicación necesita getaddrinfo() o separar la cadena y combinar inet_pton() con if_nametoindex().

RFC 9844 excluye la semántica de obtención de URI por navegadores. No promete que una URL link-local se convierta en un origin portable. Exige que las herramientas que necesitan una zona no oculten la decisión y que el resultado siga siendo contexto local no transmitido.

El cambio preservó la función mientras redujo la afirmación. El usuario puede indicar una puerta; el estándar ya no finge que esa puerta es parte de una referencia global.

El espejismo de una forma canónica

La escritura de IPv6 admite varias representaciones equivalentes. La RFC 5952 redujo en 2010 esa variedad con reglas sobre ceros, mayúsculas y corchetes al combinar una dirección literal con un puerto. Una forma común mejora comparaciones, registros y configuración.

Pero RFC 5952 no canoniza la extensión de zona de RFC 4007. RFC 9844 lo señala expresamente. El bloque de dirección puede quedar normalizado mientras %eth0 sigue dependiendo de los nombres y del estado de una sola máquina.

Tampoco existe un default portátil. RFC 4007 recomienda zonas predeterminadas y suele representar la elección por defecto con cero. RFC 9844 documenta que algunos sistemas operativos no ofrecen una zona por defecto utilizable y menciona Linux. Omitir el dato con éxito significa que el entorno aportó contexto, no que la dirección lo contuviera.

Un sistema de observabilidad que almacena solo la cadena canónica pierde la puerta elegida. Uno que conserva solo un número de interfaz pierde la intención humana y puede interpretar ese número de otra manera después de una reconstrucción. La evidencia requiere dirección, entrada original, índice resuelto, host y momento.

Fuentes