Кратко

  • В 2001 году 6to4 позволил сайту вывести префикс IPv6 в диапазоне 2002::/16 из глобально уникального адреса IPv4 и пересылать трафик через IPv4 без предварительного согласования каждого туннеля.
  • Позднее anycast сделал ретранслятор внешне автоматическим, но прямой и обратный пути могли зависеть от разных операторов без общей ответственности. Фильтрация, плохие маршруты и включение по умолчанию превратили удобство в повторяющиеся сбои.
  • RFC 7526 в 2015 году вывел из употребления механизм anycast-ретрансляции 6to4. Базовый unicast 6to4 и префикс 2002::/16 он не отменил — это различие важно и при чтении нынешнего реестра.

Адрес раньше договорённости

Самая запоминающаяся часть 6to4 — арифметика. Тридцать два бита глобально уникального адреса IPv4 помещались после префикса 2002, и сайт получал /48. В обозначениях RFC 3056 результат выглядел как 2002:V4ADDR::/48. Сеть без нативной услуги IPv6 могла раздавать внутри адреса из этого префикса. На границе маршрутизатор 6to4 напрямую вкладывал пакет IPv6 в пакет IPv4, используя протокол 41.

RFC 3056 был опубликован в феврале 2001 года и называл 6to4 необязательным временным механизмом, а не постоянной частью архитектуры IPv6. Обещание было уже и практичнее: сайты могли связываться через Интернет IPv4, не настраивая отдельный туннель к каждому собеседнику и не получая заранее обычный префикс IPv6 для этой цели. Адрес IPv4 одновременно служил исходным материалом и указателем местоположения.

У удобства с самого начала были границы. Частный адрес IPv4 не мог дать глобально осмысленный префикс 6to4. При смене адреса IPv4 менялся и выведенный из него префикс. Наконец, кому-то всё равно предстояло переносить пакеты между миром 6to4 и нативным IPv6. Создание адреса удалось автоматизировать; всеобщую достижимость — нет.

Ретранслятор, исчезнувший из поля зрения

Когда обменивались два сайта 6to4, встроенный адрес IPv4 сообщал каждому из них, куда направить туннель. Связь между сайтом 6to4 и нативным адресатом IPv6 была сложнее: требовался ретранслятор, понимавший оба мира.

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

Переключатель скрывал асимметрию. Ретранслятор исходящего трафика не обязательно совпадал с ретранслятором обратного пути. Нативная сеть IPv6, отправляя пакет к 2002::/16, могла выбрать другую точку под управлением другого оператора и с иной политикой маршрутизации. Двум ретрансляторам не требовалось даже знать друг о друге. Успех зависел от согласованной услуги нескольких организаций, но механизм не создавал между ними ни договора, ни единого владельца полного пути туда и обратно.

В формате адреса этот изъян не проявлялся. Адрес 6to4 мог быть сформирован в точности по документу, а его пакеты встречали межсетевой экран, отбрасывавший протокол 41, отсутствующее объявление маршрута, неудачно расположенный ретранслятор или обратный путь в чёрную дыру. Префикс оставался корректным, а соединение всё равно не работало.

Как запасной путь скрывал счёт

RFC 3964, опубликованный в 2004 году, сосредоточился на безопасности. Ретранслятору следовало проверять, совпадает ли источник IPv4 туннеля с адресом IPv4, встроенным в исходный адрес 6to4. Без фильтрации поддельный трафик можно было отражать, отмывать через переходную систему или затруднять установление его происхождения. Документ не объявлял каждый ретранслятор враждебным. Он показывал, что автоматическая инкапсуляция пересекает границы доверия, которые один лишь адрес контролировать не способен.

К 2011 году RFC 6343 мог описать более широкий операционный опыт. В нём отмечались фильтры, блокировавшие протокол 41, отсутствующие или недоступные ретрансляторы, а также пути, работавшие в одном направлении и ломавшиеся в другом. Документ ссылался на эксперименты того времени, где частота отказов соединений 6to4 находилась примерно в диапазоне 9–20 процентов. Это не было всемирной переписью, но масштаб оказался достаточным, чтобы средство перехода стало заметной проблемой надёжности.

Расходы часто не исчезали, а маскировались. Приложение с двумя стеками могло попробовать IPv6, подождать сбоя 6to4 и лишь затем вернуться к IPv4. Пользователю казалось, что страница просто медленно открывается. Для разработчика программного обеспечения естественной защитой было предпочитать исправные нативные пути и запускать альтернативы наперегонки, как позднее делали стратегии наподобие Happy Eyeballs. Каждый слой уменьшал видимый ему симптом, но неопределённая ответственность за систему ретрансляторов сохранялась.

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

Отказ от кратчайшего пути, а не переписывание прошлого

RFC 7526 оформил отступление в мае 2015 года. Он вывел из употребления anycast-механизм 6to4, перевёл RFC 3068 и связанный RFC 6732 в категорию Historic и призвал прекратить объявления anycast-маршрута и обслуживание ретрансляторов на 192.88.99.1. Реализациям предписывалось отключать 6to4 по умолчанию. Публичный кратчайший путь перестал считаться рекомендуемой инфраструктурой перехода.

Границы этого решения легко размыть. RFC 7526 прямо не отменял базовый unicast-механизм 6to4 из RFC 3056 и не отменял префикс 2002::/16. В действующем реестре специальных адресов IPv6 IANA этот блок по-прежнему указан как 6to4. Запись в реестре фиксирует архитектурное назначение, но не обещает существования или пригодности публичного пути через ретранслятор.

Поэтому история заканчивается не удалением. Процесс стандартизации мог отозвать операционную рекомендацию и сохранить словарь, нужный для распознавания старых адресов, управляемых схем и остаточных систем. Увидев сегодня 2002::/16, оператор должен считать его свидетельством механизма, а не свидетельством того, что anycast-служба пережила пересмотр.