Кратко

  • DRAP заменил отдельного DLSw-соседа на каждой станции множеством лёгких клиентов, одним сервером и одной DLSw-связью с центральной площадкой.
  • Сервер назначал или кэшировал MAC-адреса, отвечал на проверки достижимости, согласовывал возможности, создавал идентификаторы и сохранял каналы при приостановленном TCP.
  • Эти сигналы не доказывали личность, полномочия, подлинное происхождение или сквозную доставку; RFC 2106 не определял аутентификацию и имел статус Informational, а не Internet Standard.

Масштабирование через перенос состояния

RFC 2106 начинался с практической проблемы. Если каждая удалённая станция выполняла полный DLSw, число TCP-сеансов с центральной площадкой росло вместе с числом станций. Протокол взаимодействия коммутаторов доходил до каждого пользовательского устройства.

DRAP перестроил иерархию. Станции становились клиентами ближайшего сервера, и только сервер поддерживал DLSw-соседство с центральным маршрутизатором. Много граничных подключений делили одну магистральную связь. Сложность не исчезла — она переместилась в шлюз, который помнил состояние клиентов и говорил от их имени.

Это отличает тему от соседних публикаций. RFC 1434 описывал две локальные LLC-связи поверх общего транспорта, RFC 2024 — строки каталога, кэша, транспорта и каналов DLSw в MIB, RFC 2043 — два независимых допуска SNA через PPP, RFC 2097 — допуск отдельных имён NetBIOS. RFC 2106 сделал сервер оперативной памятью и голосом множества рабочих станций.

Виртуальный MAC был адресом, а не удостоверением

У станции через PPP мог быть IP-адрес, но не LAN MAC. Сервер DRAP мог назначить виртуальный MAC. Если клиент предлагал ненулевой адрес, сервер проверял уникальность и сохранял его. Для сеансов по инициативе сервера клиент мог заранее зарегистрировать MAC и IP.

Адрес позволял найти конечную точку внутри протокола. Он не показывал, какой человек управлял устройством, имел ли он право пользоваться приложением и пришла ли регистрация из подлинного источника. Кэш содержал операционное утверждение, а не проверенную личность.

При нескольких настроенных серверах клиент мог разослать запросы и выбрать ответивший первым. Первый ответ доказывал доступность и задержку в конкретный момент, но не административную легитимность.

Сигнал состояния имел узкое значение

CAN_U_REACH задавал вопрос, I_CAN_REACH передавал утверждение сервера. START_DL запрашивал станцию канала, DL_STARTED сообщал о её создании. Идентификаторы отправителя и получателя различали каналы. Обмен возможностями согласовывал MAC, поддержку NetBIOS, SAP и режим ожидания нового TCP-подключения.

Положительный ответ означал, что сервер заявляет достижимость. Он не доказывал доставку приложению. Запущенный канал показывал локальный переход состояния, а не разрешение на использование. Идентификатор называл внутреннее состояние, не подтверждая независимо его происхождение.

RFC 2106 использовал одно двунаправленное TCP-соединение на пару клиент-сервер через порт 1973. TCP можно было приостановить, оставив каналы данных. При появлении новых данных клиент подключался вновь без повторного обмена возможностями. Необязательные keepalive проверяли ответ; после трёх неудач рекомендовалось закрыть TCP и каналы.

Поэтому «подключено» было многослойным утверждением. Сокета могло не быть, а логический канал продолжал жить. Ответ keepalive подтверждал отзывчивость, но не завершение транзакции у конечного приложения.

Informational — не знак консенсуса

RFC 2106 вышел в феврале 1997 года как Informational и прямо говорил, что не устанавливает стандарт Интернета. Он не описывал механизм аутентификации и не содержал раздела Security Considerations. Это была спецификация удалённого доступа и переходов состояния, а не архитектура идентичности.

RFC 2114 объявил его устаревшим в том же месяце, переименовал схему в DCAP и добавил обнаружение, сохранив модель клиент-сервер. Зарегистрированный порт, совместимая реализация или номер RFC делают систему удобнее для эксплуатации. По отдельности они не доказывают долговременного стандартизующего согласия.

Источники