Resumen

  • RFC 3721 distinguió el nombre de protocolo permanente de un nodo iSCSI, su dirección de red modificable y un alias humano no único: valores que responden a preguntas diferentes.
  • La detección podía hallar nombres y rutas de destinos, pero no descubría unidades lógicas SCSI ni demostraba inicio de sesión, autorización o una operación de E/S exitosa.

«Disco local» es una etiqueta tranquilizadora en una consola de almacenamiento. También es una identidad de protocolo deficiente. Puede ayudar a una persona a elegir una fila, pero no indica a un sistema remoto qué destino debe contactar, no demuestra quién se conecta y tampoco decide qué puede usar esa conexión. En abril de 2004, RFC 3721 hizo explícitas estas diferencias para los nombres y la detección de destinos de Internet Small Computer Systems Interface (iSCSI).

La decisión de diseño central fue separar el nombre de un nodo de su dirección. Un nodo iSCSI lógico recibe un nombre permanente e independiente de su ubicación durante toda su vida. La dirección combina ese nombre con una ubicación TCP, por ejemplo un host y un puerto. Un nodo puede tener varias direcciones y sus coordenadas de red pueden cambiar. El traslado de un adaptador entre máquinas era una razón para no convertir la tarjeta en identidad: el nodo lógico podía conservar su estado SCSI y su configuración de autorización aunque cambiara la ruta.

El nombre cualificado iqn. incorpora una fecha, un dominio invertido que identifica a la autoridad de nombres y un sufijo local opcional. Esa sintaxis estructura un espacio de nombres; no demuestra que la autoridad conserve hoy el dominio ni codifica dónde es accesible el destino. RFC 3721 también describe el formato eui., basado en un identificador IEEE EUI-64. En ambos casos, el nombre identifica el nodo, no funciona como ruta de red.

El alias pertenece a otra capa. Es una cadena opcional de presentación UTF-8 y no tiene que ser única. El ejemplo de RFC 3721 muestra «Local Disk» junto al nombre real del destino. El alias sirve para que una persona reconozca una fila; el protocolo no debe usarlo para identificar, direccionar ni autenticar a un iniciador o destino. Dos sistemas pueden mostrar el mismo texto sin ser el mismo destino. El nombre puede seguir estable aunque cambie la dirección. Una ruta puede llevar a un destino sin determinar si un usuario tiene permiso para entrar.

La separación resulta especialmente útil cuando cambia la ubicación del almacenamiento. Si el nombre estuviera atado a una interfaz o dirección concreta, una reconfiguración de red podría parecer la creación de una nueva identidad. El nombre estable permite que la configuración se refiera al nodo lógico; las direcciones describen dónde se puede intentar una sesión. Es un mecanismo de continuidad, no una garantía automática de migración: el RFC especifica nombres y detección, pero no prueba que cada implementación conserve correctamente el estado durante un traslado.

La detección también tiene límites. Su objetivo es que un iniciador encuentre los destinos a los que tiene acceso y obtenga una o más direcciones. La configuración estática puede suministrar esos datos de antemano. SendTargets permite consultar una entidad de red conocida para obtener información de destinos. Los marcos de descubrimiento sin configuración, como SLP e iSNS, ofrecen opciones más amplias. Que una especificación los describa no demuestra que se hayan desplegado en todas las redes de almacenamiento.

Lo más importante: encontrar un destino no equivale a encontrar sus discos. RFC 3721 distingue la detección de unidades lógicas SCSI (LUN), que corresponde a la capa SCSI, de la detección de destinos iSCSI. Un nombre y una dirección devueltos no prueban que se haya establecido una sesión, que la autenticación haya funcionado, que exista autorización, que un LUN sea visible o que los datos de una aplicación hayan circulado. Cada etapa tiene su propia decisión y evidencia.

La sección de seguridad refuerza esta idea. En un entorno no confiable, no basta con confiar en el nombre de nodo que declara el iniciador. El destino autentica un identificador de seguridad —los ejemplos del RFC incluyen CHAP, SRP y Kerberos— y después autoriza el acceso, normalmente mediante una lista de control de acceso. Ese identificador autenticado puede ser diferente del nombre iSCSI declarado; la política debe vincularlos explícitamente. La autenticación responde quién demostró una credencial. La autorización responde qué puede hacer esa identidad. Un alias o una respuesta de detección no responde ninguna de las dos.

Los estándares posteriores aportan un epílogo útil, aunque acotado. RFC 4171 hizo que iSNS fuera opcional para iSCSI y obligatorio para iFCP. RFC 7143, que consolidó el protocolo iSCSI en 2014, indicó que los equipos que necesitaran detección más allá de SendTargets deberían implementar iSNS para gestión extendida e interoperabilidad. También señaló que SLP no se había implementado ni desplegado ampliamente para iSCSI y que las implementaciones no debían depender de su interoperabilidad.

Es una observación limitada sobre iSCSI en un RFC posterior, no un censo de todos los productos de almacenamiento ni de todos los mecanismos de descubrimiento de servicios.

RFC 3721 es informativo y complementa, pero no reemplaza, la especificación de protocolo RFC 3720. Su aporte histórico es un vocabulario de registros no intercambiables: nombre estable del nodo, dirección actual, alias opcional, identidad de seguridad autenticada, regla de autorización y destino detectado. Una consola útil puede mostrarlos juntos. Una operación fiable empieza por no tratarlos como lo mismo.

Fuentes