Кратко

  • RFC 5220 описал «полузакрытую» сеть IPv6, где правило выбора адреса источника могло отдать предпочтение префиксу, недоступному для возвратного трафика из Интернета.
  • Адрес источника выбирает хост, а следующий маршрутизатор определяется отдельно. RFC фиксирует возможное рассогласование, а не конкретное внедрение, долю отказов или поведение всех многоподключённых хостов.

Два действительных префикса — и недостижимый ответ

Опубликованный в июле 2008 года RFC 5220 — информационный документ о выборе IPv6-адресов в сети с несколькими префиксами. Он не вводил новый формат пакета. Вместо этого авторы собрали ситуации, в которых стандартные правила выбора источника и назначения из RFC 3484 трудно применять на практике, особенно к хостам, чьи пользователи не могут вручную поддерживать таблицу сетевой политики.

Самый наглядный пример назван «полузакрытой сетью». Небольшая площадка подключена к двум вышестоящим сетям: одна даёт обычный доступ в Интернет, другая является закрытой сетью, например через VPN. У хоста есть действительный IPv6-адрес из каждой. Сотрудник внутри закрытой сети может обратиться к внутреннему адресу; публичный сервер не может доставить ответ к этому же префиксу через открытый Интернет.

Проблема возникает, когда хост сам устанавливает соединение с публичным узлом. В примере RFC 5220 правило наиболее длинного совпадающего префикса может выбрать адрес закрытой сети как исходный. При этом маршрут по умолчанию на площадке способен отправить пакет провайдеру Интернета. Тот может отбросить исходный префикс, который не выдавал. Даже если пакет выйдет наружу, ответ публичного сервера будет адресован закрытому префиксу и не вернётся по общедоступному маршруту. Действительность адреса не означает, что соединение работает в обе стороны.

Текст различает две точки отказа. Фильтр провайдера на входе может отбросить исходящий пакет, потому что его источник не принадлежит этому провайдеру. Либо возвратная область может быть закрытой, и ответ не дойдёт, даже если исходный пакет приняли. Это не просто проблема DNS и не доказательство неверного формата адреса хоста.

Префикс не сообщал политику вышестоящей сети

RFC 3484 задавал стандартные правила сравнения адресов-кандидатов, но не сообщал хосту автоматически, какой провайдер понесёт пакет и сможет ли выбранный исходный префикс получить ответ по этому пути. Поэтому RFC 5220 рассматривает эти случаи как рассогласование выбора хоста и политики маршрутизации сети. В примере с полузакрытой сетью ошибочного выбора можно было избежать настройкой таблицы политики на хосте, но для этого требовалось знать топологию и поддерживать правила в актуальном состоянии.

Документ ограничивает и собственные выводы. Он отделяет задачи, решаемые имеющимися правилами выбора, от случаев, где могут потребоваться дополнительные сведения или другой механизм. В нём не говорится, что все многопровайдерные сети IPv6 были неисправны, и не оценивается доля таких случаев в эксплуатации. Схема показывает возможный путь отказа, который стоит проверить, а не отчёт о реальной аварии.

Позднее стандарты яснее обозначили часть этой границы. RFC 6724 заменил RFC 3484. В 2016 году стандартный RFC 8028 описал выбор хостом первого маршрутизатора в сети с несколькими префиксами и связь между объявленным префиксом, адресом источника и маршрутом выхода. Это помогает проследить развитие стандартов, но не доказывает распространённость сценариев 2008 года и не отменяет проверку обратного пути в реальной сети.

Предупреждение в стандарте — не замер трафика

Исторический вклад RFC 5220 — в разделении взаимосвязанных, но невзаимозаменяемых фактов: адреса источника, следующего узла, фильтра провайдера и обратной достижимости. Документ описывает правдоподобные конфигурации и анализирует их. В нём нет переписи операционных систем, захвата пакетов, названного инцидента или сравнения до и после. Чтобы понять, сколько хостов действительно выбирали неверный адрес или насколько поздние работы улучшили реальную связь, нужны отдельные свидетельства реализации и эксплуатации.

Источники

  1. RFC 5220 — Проблема выбора адресов по умолчанию в сетях с несколькими префиксами
  2. RFC 3484 — Выбор адресов IPv6 по умолчанию
  3. RFC 6724 — Выбор адресов IPv6 по умолчанию
  4. RFC 8028 — Выбор первого маршрутизатора хостами в сети с несколькими префиксами
  5. RFC 2827 — Фильтрация входящего трафика
  6. RFC 4193 — Уникальные локальные одноадресные адреса IPv6
  7. Запись RFC 5220 в редакторе RFC
  8. Запись RFC 8028 в редакторе RFC