Кратко

  • Префикс IPv6 site-local FEC0::/10 давал внутренние адреса без глобального префикса, но не указывал, какому сайту принадлежит адрес.
  • RFC 4193 заменил зависимость от границы сайта локально создаваемыми префиксами с высокой вероятностью уникальности, оставив маршрутизацию локальной задаче.

Анализ

Вторая половина адреса хранилась на узле

Приложение запомнило FEC0::1234:5678:9ABC и попыталось подключиться. Для узла с несколькими сетевыми подключениями или мобильного устройства одной шестнадцатеричной строки могло не хватить: требовалось указать сайт с помощью идентификатора зоны вроде %1. На другом экземпляре узла тот же сайт мог обозначаться как %2. Адрес выглядел переносимым, а недостающая часть жила в локальном состоянии хоста.

Такова была неудобная цена IPv6-адресов unicast site-local. RFC 3513, опубликованный в апреле 2003 года, определил FEC0::/10 для использования внутри сайта без глобального префикса. За префиксом следовали 54-битный идентификатор подсети и 64-битный идентификатор интерфейса. Маршрутизаторы не должны были передавать такие пакеты за границы сайта. Сеть могла пользоваться IPv6 внутри себя, не получая сначала глобально маршрутизируемый блок.

Но адрес не указывал, какой именно сайт делает его локальным. FEC0::1 мог существовать одновременно в двух сайтах. RFC 3879 за сентябрь 2004 года описывает последствия: приложениям приходилось управлять дополнительным идентификатором сайта; буквальный адрес нельзя было надежно сохранить как независимую от хоста цель или просто получить из DNS; программы, передававшие IP-адреса дальше, могли унести эту неоднозначность за локальную границу.

Слову «сайт» поручили слишком много разных границ. Корпоративная сеть, кампус, географическая площадка, домен маршрутизации, зона межсетевого экрана и административная граница не обязаны совпадать. RFC 3879 перечисляет границы безопасности, достижимости, маршрутизации, QoS, управления и финансирования. DMZ для одной задачи могла быть внутри, а для другой — снаружи. У пакета один адрес; у организации несколько карт.

Маршрутизаторам достался тот же спор. Если значение одного и того же site-local-адреса зависело от интерфейса, на который пришел пакет, многосайтовому маршрутизатору требовались отдельные для каждого сайта маршруты и особая обработка таблиц пересылки. Туннели и виртуализированные таблицы могли принять эту работу на себя, но не превращали «сайт» в универсальную единицу.

Польза была реальной: внутренние адреса без глобального префикса и граница, на которой маршрутизатор мог фильтровать трафик. В 2003 году рабочая группа IPv6 стала двигаться к замене. RFC 3879 фиксирует некоторое согласие в марте и подтверждение в июле, одновременно отмечая, что до единогласия было далеко. Документ сентября 2004 года отменил FEC0::/10, но разрешил существующим реализациям и сетям продолжить его использование до стандартизации замены. Повторно выделить этот префикс для другой цели можно было только после будущего стандартизирующего решения IETF.

В октябре 2005 года RFC 4193 предложил замену. Уникальные локальные IPv6-адреса используют FC00::/7; в локально назначаемом префиксе псевдослучайно создается 40-битный Global ID, затем идут 16-битный идентификатор подсети и 64-битный идентификатор интерфейса. «Global» здесь обозначает предполагаемую уникальность префикса, а не доступность из Интернета. RFC обещает высокую вероятность уникальности, не гарантию. Эти адреса предназначены для локальной связи, могут маршрутизироваться между ограниченным набором сайтов и не должны распространяться в глобальной маршрутизации Интернета.

Это важно при объединении сетей. Вероятность конфликта независимо созданных ULA-префиксов невелика, поэтому слияние или частное соединение сетей обычно позволяет избежать перенумерации интерфейсов. Маршруты между площадками всё равно нужно настроить явно. Адресу больше не нужно кодировать универсальное определение «сайта»: локальная сеть решает, куда его понесут маршруты и фильтры.

В феврале 2006 года RFC 4291 включил отмену старого поведения в архитектуру адресации IPv6: новые реализации не должны поддерживать особую обработку FEC0::/10. Последовательность RFC объясняет изменение дизайна, но не считает, сколько систем всё еще использует префикс. Для оценки распространенности нужны свежие данные по хостам, маршрутизаторам или трафику.

Источники