Resumen

  • DRAP sustituyó un par DLSw por estación por clientes ligeros, un servidor y una única relación DLSw hacia el centro.
  • El servidor asignaba o almacenaba MAC, contestaba sondeos de alcance, negociaba capacidades, creaba identificadores y podía mantener circuitos con TCP suspendido.
  • Esas señales no demostraban identidad, autorización, procedencia auténtica ni entrega de extremo a extremo; RFC 2106 no definió autenticación y fue Informational, no un estándar de Internet.

La escala cambió de lugar

RFC 2106 partía de una ineficiencia concreta. Si cada estación remota ejecutaba DLSw completo, el número de sesiones TCP hacia el centro crecía con el número de estaciones. Un protocolo entre conmutadores terminaba instalado en cada puesto de trabajo.

DRAP alteró la jerarquía. Las estaciones pasaron a ser clientes de un servidor cercano, y solo ese servidor mantuvo la relación DLSw con el router central. Muchas conexiones de borde compartían así un único vínculo lógico de troncal. No desapareció la complejidad: se trasladó al equipo que recordaba y hablaba en nombre de los clientes.

La diferencia respecto de artículos vecinos es exacta. RFC 1434 trató dos enlaces LLC locales sobre un transporte común; RFC 2024 expuso filas de directorio, caché, transporte y circuito de DLSw; RFC 2043 separó dos admisiones SNA sobre PPP; RFC 2097 proyectó nombres NetBIOS en la admisión. RFC 2106 convirtió al servidor de borde en memoria y autoridad operativa de estaciones remotas.

Una MAC útil, pero no una credencial

Una estación conectada por PPP podía tener IP y carecer de MAC de red local. El servidor DRAP podía asignarle una MAC virtual. Si el cliente presentaba una dirección no nula, el servidor comprobaba su unicidad y la guardaba. Para sesiones iniciadas desde el servidor, el cliente podía preregistrar MAC e IP.

La función era de direccionamiento. No establecía qué persona controlaba el equipo, si estaba autorizada a usar una aplicación o si el registro procedía de una fuente auténtica. La caché era un almacén de afirmaciones operativas, no una autoridad de identidad.

Con varios servidores configurados, el cliente podía enviar solicitudes y quedarse con el primero que respondiera. Ser primero probaba disponibilidad y tiempo de respuesta en ese momento, no legitimidad administrativa.

Las respuestas tenían un significado acotado

CAN_U_REACH preguntaba por un destino y I_CAN_REACH devolvía la afirmación del servidor. START_DL pedía una estación de enlace y DL_STARTED informaba de su creación. Identificadores de origen y destino distinguían circuitos. El intercambio de capacidades acordaba MAC, compatibilidad NetBIOS, listas SAP y escucha de nuevas conexiones TCP.

Una respuesta positiva indicaba que el servidor afirmaba disponer de alcance. No era comprobante de entrega en la aplicación. Un enlace iniciado acreditaba una transición local, no autorización. Un identificador daba nombre a un estado, no garantizaba por sí solo su procedencia.

RFC 2106 usó una conexión TCP bidireccional por pareja cliente-servidor en el puerto 1973. También permitía suspender TCP y conservar los circuitos de enlace. Al aparecer datos nuevos, el cliente reconectaba sin repetir el intercambio de capacidades. Los keepalive opcionales verificaban respuesta; después de tres fallos se recomendaba cerrar TCP y los circuitos.

Por eso «conectado» era una afirmación por capas. El socket podía faltar y el circuito lógico seguir vivo. Un keepalive demostraba que el par contestaba, no que una transacción hubiera llegado al destino final.

Un documento Informational que cambió pronto

RFC 2106 se publicó en febrero de 1997 como Informational y declaró expresamente que no era un estándar de Internet. No describió autenticación ni incluyó una sección Security Considerations. Fue una especificación de acceso remoto y estados, no una arquitectura de identidad.

RFC 2114 lo dejó obsoleto ese mismo mes, lo renombró DCAP y añadió descubrimiento, manteniendo el núcleo cliente-servidor. Un puerto registrado, una implementación interoperable o un número RFC pueden hacer operativo un sistema. Ninguno demuestra por sí solo consenso normativo duradero.

Fuentes