Кратко

  • Запись в PRL означает, что IPv4-адрес выбран кандидатом для Router Solicitation. Она не подтверждает, что по адресу всё ещё работает разрешённый маршрутизатор и что фильтр пропускает protocol 41.
  • Корректная Router Advertisement доказывает состоявшийся обмен управления, но не подменяет настройку адреса, NUD, обратную маршрутизацию и наблюдение приложения.
  • Общая публикация должна оставаться минимальной координацией. Текущую реальность доказывают участники, которые управляют DNS, underlay, фильтрами, маршрутами и сервисом.

Зелёный статус пережил устройство

В условном окне работ в 09:00 имя isatap.example.net возвращает два IPv4-адреса. Они совпадают с плановой PRL, и система помечает конфигурацию зелёным цветом.

В 09:03 один адрес ещё находится в кэше, хотя старый маршрутизатор вывели из трафика накануне. Замена установлена в другом сегменте сайта, где правило для protocol 41 не открыто. В 09:05 хост отправляет два одноадресных RS и получает только одну RA. В 09:08 у него уже есть IPv6-адрес и default router, но часть обратных маршрутов по-прежнему ведёт к выведенному узлу.

Сцена сконструирована из механизмов RFC 5214, RFC 6964 и Neighbor Discovery. Это не сообщение об аварии конкретной компании. DNS выдал именно опубликованные данные. Ошибка появилась там, где факт публикации превратили в вывод о работе всего сервиса.

Зачем небroadcast-ссылке каталог кандидатов

ISATAP инкапсулирует IPv6 в IPv4 и представляет IPv4-сеть как NBMA-канал для IPv6. В идентификатор интерфейса включается IPv4-адрес, поэтому нижележащий локатор можно вычислить без отдельного широковещательного разрешения.

Общедоступный IPv4 multicast не предполагается. Хост не может одним сообщением обратиться ко всем маршрутизаторам. Сначала он получает Potential Router List, затем отправляет запросы каждому кандидату напрямую.

PRL разрешено заполнять вручную, через vendor-specific option DHCPv4, через FQDN или иным локальным способом. Эти источники передают административное намерение. Они не проверяют процесс на устройстве, таблицу IPv4, ARP или межсетевой экран в момент использования.

У информации есть срок. Значение PrlRefreshInterval по умолчанию равно 3600 секундам. Если DNS возвращает TTL, следует использовать более ранний срок. Правило ограничивает старение кэша, но не обещает неизменность оборудования до конца TTL.

Статическое соответствие — не свидетельство владения

ISATAP извлекает IPv4-локатор из последних октетов адреса IPv6. При декапсуляции узел проверяет, соответствует ли внешний IPv4-источник встроенному значению во внутреннем ISATAP-адресе. Для маршрутизатора альтернативой служит членство источника в PRL.

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

Набор локаторов одного ISATAP-интерфейса не должен охватывать несколько сайтов. Но граница сайта не возникает из синтаксиса адреса. Её поддерживают IPv4-маршрутизация, именование, фильтры, инвентаризация и контроль изменений.

RFC 5214 рекомендует на границах фильтровать входящий IPv4 и protocol 41 от внешней инъекции. Внутренний узел тоже может притвориться маршрутизатором. Поэтому PRL должна быть актуальной, а механизм её разрешения — защищённым. Доверие к записи является результатом этих процессов, а не свойством строки.

Ответ маршрутизатора открывает следующий этап

Хост посылает RS по адресу кандидата. Рекламирующий ISATAP-интерфейс возвращает RA непосредственно инициатору. Link-local источник RA должен содержать IPv4-адрес одной из записей PRL.

Успешная RA — содержательное наблюдение. Управляющий пакет прошёл к кандидату, а ответ удовлетворил проверке источника. Однако затем хост ещё принимает сроки router, prefix и route, настраивает адрес, подтверждает соседа и использует data plane.

RFC 5214 говорит, что хостам следует выполнять Neighbor Unreachability Detection и после address resolution провести начальную проверку через NS/NA. Маршрутизаторы тоже могут это делать, хотя масштабирование состояния не всегда приемлемо. Ошибки ARP и постоянные ICMPv4-ошибки рассматриваются как признаки возможного отказа пути к соседу.

Поэтому доказательства не следует сжимать. Источник PRL и время обновления, IPv4 route и ARP, политика protocol 41, отправленный RS, принятая RA, сроки, адрес, NS/NA, NUD, двусторонний пакет, внешний адресат и транзакция приложения отвечают на разные вопросы.

Один anycast-адрес меняет физического ответчика

RFC 6964 допускает несколько рекламирующих маршрутизаторов для масштаба и разных сегментов. В PRL может находиться общий IPv4 anycast-адрес, а underlay выберет ближайший экземпляр.

Для доступности это полезно. Для доказательства конкретного состояния это означает, что одна строка скрывает несколько машин. Вчера отвечал A, после смены маршрута — B. Успех A ничего не говорит о версии ПО, MTU, фильтрах и IPv6-таблице B.

При разных обслуживаемых префиксах маршрутизаторам требуется IPv6 routing instance или companion gateways, чтобы обратный трафик попадал к правильному узлу. Отправленная одним устройством RA не распространяет эту привязку по всей сети.

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

RFC 9099 отмечает, что ISATAP уже используется нечасто, но его вопросы безопасности остаются полезными. Это качественная оценка, а не статистика развёртываний на 2026 год. Статья не делает такой статистики. Она сохраняет проверяемый вывод: автоматический поиск не является автоматическим доказательством результата.

Общий квиток без изменения протокола

Операционный квиток может связать сайт и границу locator set; источник PRL, значения, TTL и время; владельца каждого IPv4; IPv4 route и ARP для каждого сегмента; граничный фильтр; пары RS/RA; сроки; NS/NA и NUD; anycast membership; IPv6 routes; пакеты в обе стороны; внешнюю цель; транзакцию приложения; удаление старых записей и ручной конфигурации.

Это редакционное предложение BTW, а не новое требование RFC 5214. При выводе из эксплуатации оно не позволяет считать удаление DNS-имени доказательством того, что исчезли ручные клиенты, кэши и исключения protocol 41.

Running-Code Primacy Хэн Лу задаёт границу: общая спецификация хранит минимальные детерминированные правила интероперабельности и безопасности, а будущие состояния локально проверяют участники, выполняющие код. PRL координирует адрес вопроса. Фактическая сеть должна подтвердить ответ.

Источники

  1. RFC 5214
  2. RFC 5214 в IETF Datatracker
  3. Информация RFC 5214
  4. История RFC 5214
  5. RFC 4213
  6. RFC 4861
  7. RFC 4862
  8. RFC 6964
  9. RFC 6324
  10. RFC 9099
  11. RFC 6169
  12. RFC 7059
  13. RFC 7123
  14. RFC 3756
  15. RFC 4191
  16. RFC 1035
  17. RFC 2131
  18. RFC 4301
  19. Errata RFC 5214
  20. Heng Lu, Running-Code Primacy