Кратко

  • RFC 1088, опубликованная как STD 48, инкапсулирует IP-дейтаграммы в дейтаграммы NetBIOS и детерминированно выводит имя получателя IP.XX.XX.XX.XX из IP-адреса.
  • Тем самым для данного соответствия не нужен запрос физического адреса. Это не доказывает маршрут, владение, личность, достижимость, принятие приложением и не реализует IP multicast.

Короткая формула легко создаёт избыток смысла. RFC 1088 не объявляет имя NetBIOS описанием всей машины. Она задаёт стандартный способ передавать IP-дейтаграммы в сети NetBIOS, пользуясь только службой дейтаграмм. IP-дейтаграмма становится данными NetBIOS-дейтаграммы, а имя назначения заранее получается из IP-адреса.

Имя NetBIOS может состоять из шестнадцати байтов. Для IP-приложений RFC использует IP. и четыре байта интернет-адреса, записанные ASCII-шестнадцатерично. Поэтому, говорит документ, не нужен механизм запроса физического адреса вроде ARP: имя NetBIOS уже является отображением IP-адреса. Это полезное устранение конкретного шага. Оно не означает, что исчезли вопросы о физическом интерфейсе, топологии, следующем переходе или доступности.

RFC 791 сохраняет необходимое различие: имя говорит, что ищут; адрес — где это находится; маршрут — как туда попасть. RFC 1088 делает только локальное отображение адреса в имя службы дейтаграмм. Из удобочитаемого имени нельзя вывести путь. Нельзя вывести и то, кто контролирует хост, кто вправе пользоваться адресом или получил ли его пакет приложение.

Две регистрации и постоянно возобновляемый приём

Процедура реализации подчёркивает локальный характер механизма. Для каждого поддерживаемого IP-адреса хост добавляет IP.XX.XX.XX.XX в таблицу имён NetBIOS, а также добавляет групповое имя IP.FF.FF.FF.FF. Для обоих имён выставляются запросы приёма дейтаграмм. Получив дейтаграмму по любому из них, стек её обрабатывает и выставляет новый запрос. При прекращении поддержки IP незавершённые приёмы отменяются, а оба имени удаляются.

Это состояние одного хоста: зарегистрировать, слушать, переустановить запрос, убрать. Это не способ обнаружить скрытую топологию нескольких LAN. RFC 950 показывает иной случай прозрачных подсетей: мостам может понадобиться узнать, на какой LAN находится хост, рассылать запросы и вести кэши. RFC 1088 не выдаёт имя за такую разведку. Она заранее определяет имя, по которому работает её носитель.

По той же причине это не «замена ARP». RFC 826 описывает в Ethernet-контексте разрешение адреса протокола в адрес Ethernet. RFC 1088 говорит только, что в выбранной конвенции NetBIOS IP-адрес уже даёт имя, нужное службе дейтаграмм. Одного запроса нет; но не исчезают топология, маршрутизация, ответственность и неопределённость ответа.

Имя broadcast и честно указанное отсутствие multicast

Для широковещательных IP-адресов применяется групповое имя NetBIOS IP.FF.FF.FF.FF. Сразу после этого RFC говорит, что не предпринимает попытки поддерживать IP multicast через групповые имена NetBIOS. Наличие одного имени broadcast нельзя переписать задним числом как общую семантику групп.

Есть и жёсткий предел носителя: максимум данных в NetBIOS-дейтаграмме равен 512 байтам, следовательно, таков MTU IP-over-NetBIOS. Соседние хосты могут быть вынуждены собирать фрагментированные дейтаграммы. Производное имя, отправленная дейтаграмма, её фрагменты и собранная IP-дейтаграмма — разные наблюдения. Система наблюдения, которая называет их одним фактом «цель подтверждена», теряет место, где мог произойти сбой.

Упоминание маршрутизатора также условно. Маршрутизатор, умеющий инкапсулировать IP и в обычные канальные протоколы, и в дейтаграммы NetBIOS, позволил бы этим хостам общаться с более широким Интернетом. Это описание следствия при наличии способности. Оно не подтверждает развёртывание конкретного маршрутизатора, маршрут к конкретному адресу, право на адрес или реальную достижимость.

Именно сдержанность делает механизм исторически ясным. RFC 1088 удешевила локальную координацию, сделав имя вычислимым из адреса. Вычислимость не стала властью над маршрутом или доказательством контроля.

Источники и границы

Источники подтверждают спецификацию 1989 года, правило имени, состояние приёма, границы broadcast/multicast и MTU, а также различия с IP, подсетями и ARP. Они не подтверждают нынешнее развёртывание, конфигурацию конкретного хоста, владение, личность, разрешение, наблюдаемый маршрут, доставку или успешный результат приложения.