Кратко

  • Проверка RFC 3964 связывала внешний источник IPv4 со значением внутри адреса 6to4, но доказывала лишь локальную согласованность, а не личность, полномочия ретранслятора или доставку.
  • После декапсуляции внешний заголовок исчезал из обычной обработки IPv6, поэтому пару заголовков, конкретный экземпляр ретранслятора и результаты отдельных проверок следовало фиксировать до преобразования.

В конце инцидента остаётся адрес IPv6. Его видит получатель и сохраняет приложение. Жалоба при этом может прийти оператору ретранслятора, чей IPv4 оказался на пути. Между этими записями был ещё один заголовок, но штатная декапсуляция уже его уничтожила. Именно этот разрыв исследовал RFC 3964.

Механизм появился в RFC 3056. Узел с глобальным IPv4 строил префикс 2002:V4ADDR::/48. При обмене двух площадок 6to4 встроенное значение задавало IPv4-адрес назначения для протокола 41. Для связи с нативным IPv6 требовался ретранслятор, снимавший или добавлявший внешнюю оболочку.

Так адрес заменял часть настройки маршрута. Одновременно пакет нёс два утверждения. Внешний заголовок показывал наблюдаемый IPv4-конец туннеля. Внутренний заявлял источник IPv6. Удаление первого не подтверждало второе.

Совпадение адресов было проверкой, а не удостоверением

Если внутренний источник относился к 6to4, ретранслятор должен был сравнить IPv4 внутри 2002:V4ADDR::/48 с внешним источником. Несовпадение означало отбрасывание. Нельзя было принимать multicast, broadcast, loopback, частные и другие специальные значения как глобальные концы туннеля. Границы опирались на требования к маршрутизаторам RFC 1812; современную классификацию даёт реестр IANA специальных адресов IPv4.

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

Фильтрация источника могла усилить ограничение. RFC 2827 / BCP 38 требовал отсекать неправдоподобные IPv4-источники рядом с сетью отправителя; RFC 3704 / BCP 84 учитывал многосвязные сети. Подмена префикса 6to4 тогда требовала согласованной подмены внешнего IPv4 и прохождения фильтра. Но даже пропуск фильтром подтверждал правдоподобие для подключения или таблицы маршрутов, а не человека или организацию.

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

Когда трафик шёл из нативного IPv6 к площадке 6to4, внутренний источник не содержал V4ADDR. Внешним источником обычно служил ретранслятор, однако RFC 3964 признавал: принимающий маршрутизатор 6to4 с трудом отличает законный relay от третьей стороны, играющей его роль. Получение протокола 41 являлось фактом транспорта, а не мандатом.

Это напоминает границу доверия в Neighbor Discovery из RFC 3756. Способность говорить в канале не даёт права быть маршрутизатором. Для 6to4 логическим каналом становилась широкая сеть IPv4, поэтому достижимость и полномочие расходились ещё сильнее.

RFC 3964 распределял защиту по отдельным вопросам: совпал ли внешний источник со встроенным; допустим ли класс адреса; соответствует ли направление; не пытается ли relay переслать 6to4 обратно в 6to4; принадлежит ли назначение локальному префиксу; ограничены ли маршрут и скорость. Один флаг «валиден» скрыл бы, что именно было проверено, не проверено или неприменимо.

Слабое наблюдение всё равно оставалось наблюдением

В приложении к RFC до декапсуляции показаны четыре адреса, после неё — только два внутренних. Документ отмечал, что ретрансляторы обычно не журналировали IPv4-адреса, считая их информацией канального уровня. Поэтому атака с узла IPv4 могла продолжиться как IPv6, тогда как след src_v4 терялся.

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

Нужна была связанная запись: входной интерфейс, фактический экземпляр, внешняя пара IPv4, внутренняя пара IPv6, время, протокол, состояние маршрута и каждый вердикт. Сама декапсуляция становилась отдельным событием; решение пересылки IPv6, удалённый приём и результат приложения — последующими квитанциями. Только так жалобу можно было вернуть к границе без автоматического обвинения ретранслятора.

RFC 6169 позже обобщил проблему туннелей: фильтры несущей сети не применяются автоматически к внутренним адресам, устройства без понимания туннеля теряют видимость, а эквивалентный контроль должны выполнять концы. Успех преобразования и сохранность доказательств были разными исходами.

Anycast находил ретранслятор, но не называл его

RFC 3068 назначил 192.88.99.1 anycast-адресом для 6to4. Маршрутизация IPv4 выбирала близкий relay; неисправный экземпляр мог снять объявление, и сеть выбирала другой. Это упрощало подключение, но сам RFC указывал на трудность определить конкретный использованный ретранслятор.

Маршрут к 192.88.99.1 доказывал только выбор некоторого объявления. Он не доказывал готовность узла обслуживать трафик, наличие нативного IPv6, выполнение проверок, достаточную мощность или совпадение обратного пути. Доступности нужна заменяемость экземпляров; расследованию — точная фиксация экземпляра.

RFC 6343 в 2011 году описал чёрные дыры, неуправляемые и нежелающие пересылать ретрансляторы, разные relay для прямого и обратного пути и сбои stateful-фильтров при смене внешнего источника. Объявление маршрута привлекало трафик, но не являлось квитанцией услуги.

В 2015 году RFC 7526 формально объявил устаревшими anycast 6to4 и 192.88.99.1. Он не отменил основной механизм RFC 3056 и не отменил 2002::/16. Изменение нормативного статуса не доказывает, что все узлы, маршруты и остаточные пакеты исчезли.

Доказательная цепочка была длиннее туннеля

RFC 3964 отдельно рассматривал отказ в обслуживании, отражение, «отмывание» пакетов, локальный IPv4 broadcast, кражу услуги и административное злоупотребление. Ретранслятор мог выглядеть источником чужого трафика. Поддельный внутренний адрес мог направить ответы жертве. Нижележащий журнал мог сохранить лишь внутреннее утверждение.

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

Основа исследования — текст RFC 3964, карточка RFC Editor и список исправлений. Две подтверждённые технические errata исправляют адрес назначения в примере и опечатку в anycast-префиксе; они не документируют эксплуатационный инцидент. Контекст дают RFC 3056, 3068, 2827, 3704, 6343, 7526, 6169, 1812 и 3756. Они не доказывают конкретную атаку, дефект продукта, жертву, масштаб или повсеместную фильтрацию.