Кратко

  • Индивидуальный проект от 21 июля вводит Specific Local Address Table, SLAT. Разные клиенты сервера маршрутов видят разные локальные IPv4-имена следующего перехода для одного физического участника.
  • Сервер меняет NEXT_HOP для старого получателя по столбцу этого получателя. Прокси ARP/ND точки обмена должен разрешить псевдоним в правильного соседа. Объявление маршрута и доставка пакета зависят от одного живого реестра.
  • RFC 7947 требует от сервера маршрутов передавать NEXT_HOP без изменений. Проект создавал бы исключение; двусторонним сеансам вне сервера нужна опубликованная таблица или собственный перевод.

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

RFC 8950 позволяет объявлять IPv4-достижимость с IPv6-адресом следующего перехода после согласования нужной возможности. Старый маршрутизатор от чужого согласования не обновится. Проект перевода различает Legacy, которому нужен IPv4, Supporting, способный принять обе формы, и Unnumbered, который работает с IPv6 и не поддерживает IPv4 Next Hop. Сервер маршрутов сводит три представления о том же соседе.

Точка обмена сначала регистрирует уникальную тройку для каждого участника: MAC-адрес, локальный для канала IPv6 и глобальный IPv6. Так получается Local Address Table. С каждым Legacy- или Supporting-клиентом она затем согласует собственный локальный IPv4-префикс и добавляет в таблицу столбец псевдонимов. Это SLAT. В примере проекта один и тот же сосед выглядит как 10.0.0.10 для одного клиента и 192.0.2.10 для другого. Имена разные, устройство одно.

Сервер обязан выбирать столбец на входе и выходе. Получив IPv4-маршрут с IPv4 NEXT_HOP, он заменяет поле на IPv6-адрес отправителя из SLAT. Отдавая маршрут получателю Legacy, подставляет IPv4-псевдоним отправителя из столбца именно этого получателя. Для Unnumbered поле не переписывается; для Supporting проект также рекомендует его сохранить. Если адрес следующего перехода никому не назначен в SLAT, объявление не должно распространяться. Книга адресов теперь определяет, какое заявление о достижимости допускается к остальным.

Другая половина механизма живёт в локальной сети. Точка обмена наблюдает ARP и Neighbor Discovery, отвечает каждому клиенту из нужного столбца и в предложенной схеме препятствует прямой передаче таких запросов между клиентами. Если сервер назвал один псевдоним, а прокси сопоставил его с MAC другого участника, маршрут останется в BGP, но пакет попадёт не туда. Для оценки конкретного внедрения требуется единая запись объявления, строки SLAT, ответа ARP/ND, разрешения в FIB и пути пакета; после смены адреса участника испытание повторяют.

Это расширение власти сервера маршрутов. Раздел 2.2.1 RFC 7947 требует пропускать NEXT_HOP неизменным: сервер сам не несёт трафик участников. Новый проект явно отступает от правила ради перевода. В основной схеме SLAT сервер всё ещё не передаёт пользовательские пакеты, но управляет именем, по которому клиент ищет физического соседа. Прокси должен пользоваться той же записью. Авторы советуют единый источник назначений и регулярную проверку, что все формы адреса ведут к одному участнику.

Переход запланирован поэтапно. Сначала наблюдение ARP/ND. Затем новый сервер с IPv6 Next Hop для IPv4-маршрутов работает рядом со старым. Первые столбцы SLAT могут повторять нынешние публичные IPv4-назначения; по мере сокращения запаса клиентов переводят на локальные префиксы, в том числе частные. Параллельная работа сохраняет возможность отката и одновременно заставляет проверять две разные картины адресов.

Двусторонний BGP-сеанс обходит центральный перевод. Для таких пар проект требует публиковать свежую SLAT, чтобы они переводили адреса сами. Looking Glass предлагается показывать исходный IPv4 Next Hop, реальный IPv6 Next Hop и выходной псевдоним для выбранного получателя. Один локальный адрес без этих связей легко принять за глобальную идентичность соседа. Альтернативная машина-прокси действительно пересылает пакеты между двумя доменами; для неё действуют другие границы отказа.

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

Проект Route Server Next Hop Translation, версия 02 · RFC 7947 · RFC 8950 · RFC 9161