Кратко

  • RFC 1234 определил в 1991 году IPX-over-UDP. Он позволяет считать IP-интернет одной IPX-сетью; у известного IPX-хоста последние четыре октета номера хоста содержат IP-адрес узла, поэтому unicast-сопоставление получается прямым.
  • Broadcast не получает такого же охвата. Каждый сервер и маршрутизатор хранит вручную созданный список IP-peers, а запрос на broadcast превращается в отдельный unicast каждому из них. RFC говорит: если эти пакеты не достигают всей server peer group, ресурс может быть виден конечной системе, но недостижим для неё.

Одна сеть была именно взглядом на пересылку

RFC 1234 решал конкретную задачу: как провести IPX через интернет, несущий только IP. UDP-инкапсуляция создаёт этот путь. Соглашение о номере IPX-хоста делает понятной и доставку известному узлу: первые два октета равны нулю, последние четыре содержат IP-адрес node.

Это не превращает IP-интернет в единый физический LAN, одну администрацию, общий домен доверия или автоматически полный домен обнаружения. RFC разрешает реализации видеть одну IPX-сеть. Он не утверждает, что это название само отвечает, кто должен услышать поиск маршрута или сервиса, и что ответ уже доставлен всем.

IPX нуждался в broadcast-средствах, чтобы NetWare-серверы и IPX-маршрутизаторы, разделяющие сеть, находили друг друга. Отправить пакет на известный адрес и разослать вопрос всем существенным участникам — разные действия. Во втором надо определить состав получателей и действительно доставить вопрос каждому.

Broadcast стал поддерживаемым списком рассылки

Internet-wide IP broadcast, по RFC 1234, не является ни подходящим, ни доступным. Вместо него каждый сервер и маршрутизатор должен вести вручную составленный список IP-peers. Когда уровень IPX запрашивает broadcast, реализация имитирует его, посылая отдельную unicast-копию каждому peer из списка.

Значит, охват больше не следует молча из общей среды. Он зависит от списка, от того, кто его поддерживает, и от доставки каждой копии. RFC прямо замечает, что несколько peer groups могут делить один IP-интернет и не знать друг о друге, поскольку списки строятся вручную. Внутри одной группы каждый список должен содержать всех её peers.

Наличие IP-пути между двумя площадками поэтому не доказывает их участия в одном и том же обнаружении. И возможность описать их как одну логическую IPX-сеть не доказывает, что запрос достиг каждого нужного сервера или маршрутизатора. Общий underlay и полнота распространения вопроса — разные факты.

Клиенту тоже требовалось спросить весь правильный круг

Обязанность не ограничивалась серверами. Клиент в IPX-сети посылает broadcasts, чтобы обнаружить маршрутизатор к нужному назначению. RFC предусматривает у клиента настроенный список IP-адресов всех серверов и маршрутизаторов peer group; клиент посылает копию пакета на каждый адрес.

Итог зависит от полноты с обеих сторон: от списков серверов и маршрутизаторов и от того, обращается ли клиент ко всем относящимся к делу server peer groups. Туннель, безошибочно несущий известный unicast, сам не добавит пропущенный peer, не исправит устаревший адрес и не доставит повторно копию, которая постоянно не доходит до части группы.

Предупреждение RFC условно, а не является описанием конкретной аварии. Если такие пакеты не имеют тенденции достигать всей server peer group, ресурсы IPX-интернета могут быть видимы конечной системе, но недостижимы ею. Документ не называет ресурс, виновного оператора, причину сбоя или реальную топологию. Он задаёт условие, при котором видимость и получение пригодного маршрута расходятся.

Адрес известного хоста не решал вопрос о коллективном составе

В схеме есть асимметрия. Местонахождение известного хоста читается из его IPX-представления. Broadcast спрашивает: кто должен услышать? Ответ находится не в дейтаграмме, а в изменяемом списке и в операционном решении, которое его поддерживает. RFC 1234 не делает IP-топологию автоматическим ответом на вопрос членства.

RFC допускает, что позднее можно применить IP multicast, но отмечает, что тогда multicast не был широко доступен, не имел well-known адреса и не использовался реализациями. Это не только историческая деталь. Замена списка multicast-ом, реестром или другим групповым механизмом не отменяет необходимости определить членов, показать пропуск доставки и различать группы, делящие один транспорт.

Текст фиксирует и условия переноса: default IPX MTU — 576 bytes, общий размер IP после инкапсуляции — 604 bytes; UDP checksum необязателен, но настоятельно рекомендуется, потому что IPX обычно не применял собственную контрольную сумму. Эти правила помогают туннелю работать, но не доказывают полноту списка peers.

Источник и границы доказательств

Закрытый источник статьи — RFC 1234, Tunneling IPX Traffic through IP Networks. Он подтверждает дату, UDP-инкапсуляцию, соглашение о номере хоста, peer lists, клиентское обнаружение, условное «видимо, но недостижимо», MTU, checksum и замечания о безопасности. Он не подтверждает конкретное развёртывание, реальный инцидент, топологию организации, нынешнее использование или текущий статус UDP-порта 213.