Кратко

  • RFC 1504 давал экспортируемой AppleTalk-сети уникальную туннельную идентичность из DI и исходного диапазона, а принимающему домену позволял назначить ей свободный локальный номер.
  • Локальный номер был представлением. Вернувшись по резервному пути без DI/UI, он выглядел реальной новой сетью; создавший его роутер мог отобразить его снова и получить shadow network.
  • RI-Ack, строка таблицы и успешный маршрут подтверждали отдельные шаги. Для идентичности и результата требовались эпоха отображения, порт, connection ID, sequence, граница snapshot/update и наблюдение payload.

Последнее событие не рассказывало всей истории

RFC 1504 был опубликован в августе 1993 года как информационный документ Alan Oppenheimer из Apple Computer. Его задача — подробно описать протокол Apple, который мог работать поверх Internet. Это не Internet Standard и не отчёт о развёртывании.

AURP распространял информацию о маршрутах по однонаправленным соединениям. У соединения был connection ID, у пакета — sequence number. Отправитель ждал RI-Ack на каждый ответ и повторял пакет, если подтверждение терялось.

Надёжность доставки пакета не давала атомарного состояния. Новый peer мог начать initial exchange, пока изменения ещё находились в pending state. Его RI-Rsp описывал одну картину, а следующий RI-Upd мог сообщить, что неизвестная сеть изменила distance или что уже известная сеть была добавлена.

RFC 1504 задавал правила согласования. Distance Change для неизвестной сети обрабатывался как Network Added. Network Added для известной — как Distance Change. Некоторые Network Down или Route Change для неизвестного объекта игнорировались.

Эти преобразования помогали построить рабочую локальную таблицу. Они не доказывали, что все peers видели один и тот же мир в одну секунду.

При overflow приёмник мог потерять часть информации. Поскольку отправитель не обязан бесконечно повторять routing information, после появления памяти следовало запросить полную таблицу через RI-Req. Если в цепочке событий есть дыра, свежий delta не восстанавливает baseline.

Два домена могли честно выбрать один номер

AURP соединял независимые AppleTalk internets через IP или иной чужой network system, а также через point-to-point link. Отдельные администраторы могли использовать одинаковые network numbers. Конфликт появлялся только после объединения.

Протокол отделил общую идентичность от локального представления. Экспортируемая сеть имела UI. Роутер с remapping строил UI из уникального на туннеле DI и исходного номера или диапазона. В принимающей сети он выделял UI свободный номер из remapping range.

Старые узлы продолжали работать с привычными AppleTalk-числами. Граница переводила их в UI и обратно. Это была практичная совместимость, но локальный номер не нёс своего происхождения.

Один UI мог выглядеть по-разному в двух доменах. Один локальный номер мог после reuse относиться к двум UI в разные эпохи. Совпадение чисел не доказывало тождество, различие — не доказывало два объекта.

Динамический mapping превращал время в часть ключа

Static remapping резервировал известный номер для определённого UI. Он упрощал управление и расходовал конечный пул. Dynamic remapping выделял место по мере появления сетей и повышал ёмкость, но позволял повторное использование.

RFC 1504 советовал занимать старый номер только после исчерпания остальных и не передавать немедленно место только что исчезнувшей сети новой. Текущая таблица могла удалить строку, пока задержанные пакеты, cache, соседний роутер или отчёт всё ещё ссылались на старую эпоху.

Поэтому запись должна включать router, port, DI, original range, local alias, epoch, начало и withdrawal. Фраза «47 означает X» без времени становится неверной сразу после первого reuse.

Static mapping покупал стабильную корреляцию ценой пространства. Dynamic mapping покупал пространство, принимая долг по сохранению истории.

Переводчик знал не все места, где встречался адрес

Роутер мог переписывать network number в DDP header, NBP entity address и AURP routing data. При наличии DDP checksum он проверял его до изменения и ставил ноль после: прежняя сумма больше не относилась к новому пакету.

Но сторонний протокол мог спрятать AppleTalk-номер в неизвестной части данных. Роутер не понимал эту грамматику и оставлял внутреннюю ссылку прежней. Outer packet шёл по правильному маршруту; приложение получало неверный объект.

Network management показывал ещё один слой. Ответ через туннель мог содержать исходные, неотображённые номера. Management station должна была отдельно читать AURP remapping database и соединять её с локальным видом. RFC 1742 позже стандартизировал AppleTalk MIB для ports, RTMP tables и counters, но не превращал одно значение в полное доказательство идентичности.

Три панели могли показывать UI, local alias и original number. Все три были правдивы в своей области. Противоречие возникало в интерфейсе, который скрывал область.

Собственное отображение вернулось как чужая сеть

Для появления shadow network требовался дополнительный путь. Два AppleTalk internet соединялись туннелем и ещё одним маршрутом. UI удалённой сети отображался в локальный диапазон, распространялся внутри и возвращался к исходному exterior router через резервную связь.

На обратном пути у числа уже не было DI и original range, составлявших туннельный UI. Оно выглядело обычной локальной сетью. Роутер не мог определить, что видит собственный вывод, снова отображал диапазон и экспортировал новую запись.

Теперь два номера относились к одной физической сети. Следующий оборот добавлял третий. RFC 1504 назвал такие копии shadow networks. Цикл продолжался, пока apparent distance не превышала hop-count limit.

Лимит останавливал достижимость, не восстанавливал provenance. Удаление слишком далёкой route не показывало, чьей тенью она была.

Отображение само по себе не создавало ошибку. Резервный путь сам по себе тоже. Ошибка возникала, когда локальное представление выходило за границу и возвращалось без признаков исходного преобразования.

Одна виртуальная линия могла быть частично связной

AURP представлял multipoint tunnel как единый virtual data link. Exterior routers применяли split horizon: сообщали о своих local internets и не пересылали обратно через тот же tunnel сведения, полученные от другого exterior router.

Это предполагало прямую связь всех участников. В действительности A мог видеть B, B — C, а A и C — не видеть друг друга. Такая partial connectivity могла быть политикой или ошибкой; B обычно не мог определить намерение.

Иногда два отдельных tunnel честнее описывали топологию и позволяли B передавать информацию. Логическая метка «один link» не заменяла измерение adjacency.

Частичное внедрение разделяло способность обнаруживать

Remapping включался отдельно на каждом router. RFC 1504 предупреждал: смесь режимов создаёт номерные конфликты. Кроме того, роутеры с remapping выполняли соответствующую loop detection, без remapping — нет.

Loop между двумя nonremapping exterior routers мог остаться незамеченным, а remapping router увидел бы несколько shadow copies. Безопасность функции не складывалась автоматически из частичного внедрения.

Два резервных remapping router должны были использовать один DI для local internet и одинаково отображать remote UIs в local numbers. Документ предлагал полную ручную конфигурацию или будущее распространение состояния, но отмечал, что AURP тогда не поддерживал такую функцию.

Path redundancy появилась раньше, чем transactional identity redundancy.

Совпадение открывало расследование

Если размер полученного диапазона и zone list совпадали с локальной сетью, информация считалась loop-indicative. Это не был окончательный вердикт. RFC 1504 предлагал отправить AppleTalk packet в туннель и посмотреть, вернётся ли он через local port.

Сходство свойств давало гипотезу. Возвращение конкретного probe давало свидетельство пути в определённое время. Оно не доказывало намерение администратора, постоянство topology или результат каждого сервиса.

Раздел Security тоже узок. Network hiding и device hiding названы weak form of security; общие угрозы не рассматриваются. Невидимость в Chooser не означала аутентифицированное отсутствие.

Что нужно соединить в одном расследовании

Минимальная цепочка включает original <DI, range>, local mapping и epoch, connection и sequence, snapshot/event, ingress port и path, table version и next hop, probe или payload для нужного сервиса.

Два разных числа могут сворачиваться к одному UI. Одно число может разделяться на две эпохи. Правильная route может нести неподправленный embedded address. Только join различает реальную коллизию, двойное представление, reuse, возвращённую тень и application failure.

Чего источники не устанавливают

Источники не сообщают число AURP deployments, полную реализацию конкретным продуктом, реальный shadow-network incident или современное использование. RFC 1504 сохраняет дизайн, не running state.

RFC 1378 описывает переговоры AppleTalk в PPP и перенос AURP information, но не доказывает convergence. RFC 1742 задаёт management vocabulary, но не полноту конкретной remapping database. Тексты Lu Heng дают раскрытую аналитическую границу: specification, implementation, local decision, presentation и observed outcome остаются отдельными фактами.

Псевдоним был достаточно реальным, чтобы по нему пересылать пакет. Этого недостаточно, чтобы дать ему право объявить ещё одну сеть существующей.

Источники