Кратко

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

На разборе сбоя каждый приносит верное свидетельство. DNS вернул адрес. Операционная система настроила глобальный IPv6. Маршрутизатор по умолчанию отвечает. Приложение всё равно ждёт до тайм-аута. Противоречия нет: имя могло прийти из корпоративной VPN, источник — из префикса домашнего провайдера, а первый переход — из мобильной сети.

Именно такую потерю связи между параметрами рассматривает RFC 7157, IPv6 Multihoming without Network Address Translation. Документ опубликован в марте 2014 года как информационный RFC, отражающий консенсус IETF. O. Troan указан редактором, вместе с David Miles, Satoru Matsushima, Takashi Okimoto и Dan Wing. Официальный профиль Ole Trøan в Datatracker также перечисляет эту работу. Запись подтверждает участие в коллективном тексте, но не единоличное изобретение, управление внедрениями или авторство последующих стандартов.

Ключевое наблюдение касается не одной трансляции адресов. Пограничное устройство NAPT в типичной IPv4-сети часто объединяет три функции: выбирает внешний адрес источника, определяет следующий переход и иногда посредничает в DNS. Внутренний узел видит один частный адрес и один выход. Связь между публичным префиксом, провайдером, путём и пространством имён остаётся внутри коробки.

В IPv6 небольшой площадке могут выдать по глобальному префиксу два провайдера. Ноутбук способен одновременно держать Wi‑Fi, мобильный интерфейс и корпоративный туннель. Это открывает путь к прозрачной сквозной связи без невидимой трансляции каждого потока. Однако изобилие адресов не определяет, какие настройки принадлежат одному контексту предоставления связи.

RFC 7157 выделяет три решения до первого пакета. Узлу нужен подходящий к назначению адрес источника, совместимый с ним первый переход и рекурсивный DNS-сервер, знающий нужное пространство имён. Провайдеры часто фильтруют входящий трафик по источнику. Поэтому пакет с законным префиксом провайдера A может быть отброшен на выходе провайдера B. Допустимость деталей не означает допустимость набора.

Первое решение — источник. RFC 6724 определяет стандартные алгоритмы выбора исходных и конечных адресов и административную таблицу политики. RFC 7157 отмечает, что при нескольких провайдерских префиксах правила по умолчанию не всегда однозначно выбирают нужный источник. RFC 7078 задаёт DHCPv6-опцию для распространения таблицы. Полученная опция доказывает доставку конфигурации, но не её установку, актуальность и фактическое применение к рассматриваемому пакету.

Второе решение — дверь. Несколько Router Advertisement могут оставить несколько действительных маршрутизаторов по умолчанию. Произвольный выбор способен передать правильный источник тому upstream, который его не принимает. Позднее RFC 8028 на треке стандартов зафиксировал порядок: узел сначала выбирает источник, затем первый маршрутизатор, объявлявший его префикс. Авторы RFC 8028 — Fred Baker и Brian Carpenter. Ole Troan отмечен в благодарностях за важный текст; вклад не превращает его в автора документа.

Третье решение — DNS-контекст. Внутреннее имя может существовать только в VPN. Провайдер может давать разные ответы в зависимости от источника запроса. Самый быстрый резолвер способен вернуть настоящий адрес, недоступный через выбранный выход. RFC 7157 обсуждает политику по пространству доменных имён и ссылается на DHCPv6-механизм RFC 6731. Смысл ответа сохраняется, только если вместе с ним известны интерфейс и источник запроса, резолвер и домен предоставления.

Решения идут последовательно, но принадлежат разным участникам. Приложение задаёт имя и намерение. DNS-политика выбирает контекст и получает адреса назначения. Узел выбирает источник. Маршрутизация — первый переход. Шлюз и фильтры провайдера принимают следующее решение. Удалённая сторона отвечает или молчит. Одна строка «IPv6 работает» стирает связи, без которых следующий отказ нельзя локализовать.

Альтернативы тоже нельзя превращать в лозунг. RFC 7157 предлагает по возможности избегать NAT и NPTv6 ради сквозной прозрачности. Одновременно вывод признаёт подходящими решения на основе DHCPv6 и допускает необходимость NPTv6 как промежуточного шага. Архитектурная цель и миграционная мера совместимы. RFC 6296 описывает stateless-трансляцию префиксов IPv6, но не предписывает её всем сетям и не запрещает повсеместно.

Последующие RFC развили способ сохранять принадлежность параметров. RFC 7556 называет Provisioning Domain, PvD, согласованный набор сетевой конфигурации: префиксы источника, DNS-серверы и суффиксы, шлюз по умолчанию и другие сведения. Модель препятствует случайному смешению разных доменов. RFC 8801 добавляет FQDN-идентификатор PvD в объявления маршрутизатора и необязательные JSON-данные. Идентификатор помогает связать записи, но не гарантирует доверие, текущую достижимость или успех приложения.

Поэтому объект аудита — одна попытка соединения. Общий идентификатор связывает имя и цель приложения, DNS-PvD и резолвер, источник и интерфейс запроса, набор ответов и TTL, выбранное назначение, кандидатов источника, фактический источник, версию политики, кандидатов-маршрутизаторов, первый переход, объявленные префиксы и сроки, состояние соседа и маршрута, решение фильтра, изменения при повторе и доступное наблюдение на upstream или удалённой стороне. Монотонное время сохраняет порядок при коррекции системных часов.

У каждого поля свой предел. Настроенный адрес не обязательно выбран. Выбранный источник ещё не принят провайдером. Объявление маршрутизатора не подтверждает пересылку. DNS-ответ не доказывает доставку. Даже ответ приложения подтверждает лишь одну комбинацию в один момент, но не все назначения, пространства имён и резервные пути.

В этом сохраняется ценность редакторского вклада Trøan. RFC 7157 разложил решения, которые раньше поглощала одна коробка. Прозрачность — не отсутствие управления, а возможность увидеть исходные данные, владельца решения, срок действия и способ отмены.

Источники