Кратко

  • RFC 2097 заставлял удалённую систему просить партнёра добавить конкретные имена NetBIOS. В одном согласовании часть имён могла пройти, а остальные — получить разные коды отказа.
  • NBFCP также делал видимыми класс партнёра, период и приоритет multicast и требование двенадцатиоктетного IEEE MAC-заголовка.
  • Opened и Added=0 оставались локальными свидетельствами. Они не доказывали глобальную уникальность, идентичность, полномочия, связь LAN с LAN, полную доставку, последующий успех сеанса или безопасность.

Линия удалённого доступа может быть физически активна, LCP завершён, а PPP уже находиться в фазе протоколов сетевого уровня, хотя у имени, нужного приложению, по-прежнему нет места на дальней сети. RFC 2097 сделал этот разрыв наблюдаемым.

Опубликованный в январе 1997 года PPP NetBIOS Frames Control Protocol закрепил 0x803f за управлением NBFCP, а 0x003f — за датаграммами NBF. Его топология была узкой: конечная система могла подключаться к партнёру или к LAN партнёра. Соединение двух LAN документ исключил из-за ограничений имён NetBIOS и механизмов их защиты.

Открыть переносчик и допустить имена — разные события

PPP разделял работу на фазы. LCP устанавливал, настраивал и проверял канал; затем могли выполняться аутентификация и оценка качества. NBFCP разрешался только в фазе сетевых протоколов, а NBF-датаграммы — лишь после состояния Opened.

Для конечных систем RFC 2097 дополнительно требовал Name-Projection. Инициатор перечислял шестнадцатиоктетные имена, которые удалённый партнёр должен был добавить в свою сеть, отмечая каждое как уникальное или групповое. Однооктетное поле Length ограничивало опцию четырнадцатью именами; больший набор приходилось делить.

Это было не общее заявление «NetBIOS включён». Машине могли требоваться разные имена для разных служб. Партнёр обязан был отдельно попытаться дать каждому локальное сетевое присутствие.

Частичный допуск возвращался полным списком

Если принять все имена не удавалось, получатель должен был выдать Configure-Nak со всем исходным списком. Успешные элементы получали Added=0, остальные — ненулевой код: дубликат в локальной таблице, переполненная таблица, имя занято на удалённом NetBIOS, обнаружен конфликт, имя определено другой средой или исчерпаны ресурсы.

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

Время тоже относилось к доказательствам. Добавление имён обычно занимало около трёх секунд — столько же мог составлять стандартный таймер перезапуска PPP. RFC рекомендовал десять секунд на период настройки. Ранний повтор мог свидетельствовать о нетерпеливом автомате, а не об отсутствии партнёра.

Поэтому Added=0 подтверждает лишь узкое утверждение: в данном обмене этот партнёр сообщил, что смог добавить это имя. Оно не доказывает согласованную картину у всех сегментов, серверов имён и мостов. RFC 1001 прямо допускал рассогласование информации после сбоев.

Самоописание партнёра не удостоверяло его личность

Peer-Information передавал класс реализации, старшую и младшую версии и необязательное имя. Начальные классы различали шлюз PPP NetBIOS, сервер только локального доступа, мост NBF и конечную систему.

Различие было операционно важно: мост давал иную поверхность пересылки, чем сервер, не пропускающий пакеты дальше. Но опция была рекомендуемой, не обязательной, а значения предоставлял сам партнёр. RFC 2097 не связывал их криптографически с проверенной машиной, организацией или оператором.

Политика multicast могла скрыть доступную службу

Одни приложения NetBIOS зависели от multicast, другие обходились без него. Multicast-Filtering согласовывал максимальный период пересылки и бит приоритета. Ноль означал пересылку всех пакетов. Обычное значение до шестидесяти секунд ограничивало частоту. 0xFFFF обозначал запрос значения либо его отсутствие в зависимости от Request или Nak. Приоритет выбирал между multicast и направленными пакетами.

Политика полосы превращалась в поведение приложения. Канал мог быть открыт, имена спроецированы, направленные пакеты идти, а программа, зависящая от частых объявлений, казаться неисправной. Согласованный период описывал обещанную обработку, но не прибытие каждого пакета.

Двенадцать октетов меняли допустимую оболочку

NBF использовался с заголовками 802.3 Ethernet, 802.5 Token Ring, DIX Ethernet и FDDI. Одним реализациям PPP для моста требовался полный заголовок, другим — только IEEE-адреса, а шлюзам порой не требовались MAC-поля.

IEEE-MAC-Address-Required выражал эту зависимость. По умолчанию MAC-заголовка не было. После успешного согласования каждая датаграмма начиналась двенадцатью октетами адресов назначения и источника. Поскольку решение принималось после LCP-согласования MRU, получатель должен был принимать NBF-пакеты на двенадцать октетов больше MRU.

Число нижнего уровня не исчерпывало контракт пакета. Наблюдение заголовка доказывало форму, но не пересылку мостом и не приём адресатом.

Opened было разрешением, а не сертификатом результата

Четыре опции разделяли факты, которые панель склонна сводить к зелёному индикатору: принятые имена, заявленная роль партнёра, обработка multicast и форма кадра. Opened разрешало NBF на этом канале при этих условиях.

Гарантии безопасности отсутствовали. Security Considerations сообщал, что безопасность не обсуждается. NBFCP не аутентифицировал человека или машину, не выдавал полномочий имени, не шифровал и не подтверждал целостность. Запрет режима LAN—LAN сохранял границу между локальной проекцией и общей маршрутизируемой сетью.

IANA по-прежнему перечисляет два значения протокола, четыре опции, коды результатов и классы партнёров. Это доказывает стабильность идентификаторов, но не современное развёртывание или соответствие продуктов. Отсутствие зарегистрированных errata также не измеряет совместимость.

Отличие от RFC 1088 существенно. RFC 1088 механически выводил имя NetBIOS из IPv4-адреса. RFC 2097 имя не создавал: он переносил выбранный партнёром набор к удалённой точке допуска и возвращал результат для каждого элемента.

В более поздней рамке Lu Heng о минимальной спецификации и первичности работающего кода NBFCP выглядит тонким общим слоем проверяемых обязательств. Это редакционная интерпретация, а не доказательство намерения автора RFC. Исторического факта достаточно: когда имя, роль, multicast и форма кадра получили отдельные квитанции, поднятый канал перестал означать готовый доступ.

Источники