Кратко

  • RFC 8950 позволяет объявлять достижимость IPv4 и VPN-IPv4 через IPv6 next hop. Capability code 5 подтверждает лишь конкретную тройку NLRI AFI, NLRI SAFI и next-hop AFI; он не включает семейство и не доказывает достижимость next hop.
  • Получатель определяет тип next hop по длине кодирования. Route reflector обязан сохранить полученный encoding и не может передать NLRI клиенту, который не объявил его поддержку.
  • Надёжная миграция отдельно доказывает OPEN, точный MP_REACH_NLRI, import policy, IPv6-рекурсию, выбранный путь, FIB, adjacency или tunnel и реальные IPv4-пакеты. Зелёная сессия — только начало.

В 01:40 узел агрегации переводит транспортное ядро на единый IPv6 underlay. Клиенты и их префиксы остаются IPv4. Задача — сократить дублирование адресов и IGP-состояния в ядре, а не заменить клиентский продукт.

Два route reflector и большинство clients поддерживают механизм. Новый маршрутизатор объявляет в OPEN IPv4 unicast и Extended Next Hop Encoding. Старый объявляет только семейство. Обе сессии достигают Established.

Новый client получает и выбирает IPv4-маршрут, но resolver ищет IPv6 next hop в management VRF и выводит его через неверный интерфейс. Старый client маршрут не получает: reflector не уполномочен переписать IPv6 next hop в IPv4 ради совместимости.

Сценарий условный, границы нормативны. RFC 8950 не сливает IPv4 и IPv6. Он позволяет одной записи нести два типизированных утверждения: назначение — IPv4, адрес для движения к точке объявления — IPv6.

Назначение и next hop — разные сущности

NLRI описывает достижимые назначения. Next hop указывает, какой адрес получатель должен разрешить и использовать для пересылки. Частое совпадение семейств превратилось в привычку, но не в тождество.

MP-BGP явно разделяет поля. MP_REACH_NLRI несёт AFI, SAFI, длину и байты next hop, затем NLRI. RFC 4760 определяет контейнер. Старые определения IPv4 и VPN-IPv4 предусматривали IPv4-форму next hop и не давали общего способа описать IPv4-сервис поверх IPv6-ядра.

RFC 8950 расширяет допустимую комбинацию. AFI 1 по-прежнему означает IPv4 NLRI; для заданных SAFI next-hop AFI может быть 2. Адрес клиента не переводится, обязательство IPv4 не исчезает. Другая семья используется только для транспортной опоры.

Внедрение остаётся локальным. Оператор выбирает домен, peers и service families. Отказ не делает участника недействительным — он остаётся в другом compatibility set. Стандарт задаёт тонкое общее правило, а не центральный план миграции.

Термин «IPv6-only core» тоже требует границы. Единый underlay снижает дублирование, но не отменяет IPv4-клиентов, договоры, ценность адресных ресурсов, поддержку и риск. Название транспортного слоя не описывает весь продукт.

Capability 5 обещает точную тройку

Extended Next Hop Encoding зарегистрирован как code 5. Его value состоит из шестибайтовых троек: по два октета на NLRI AFI, NLRI SAFI и next-hop AFI. RFC 8950 рассматривает AFI 1, SAFI 1, 2, 4, 128 или 129 и next-hop AFI 2.

Поддержка IPv4 unicast не доказывает поддержку labeled unicast, multicast или VPN-IPv4. Релизы и платформы могут реализовывать разные подмножества. Поле extended-nexthop=true уничтожает нужную гранулярность.

Code 5 также не разрешает AFI/SAFI. Multiprotocol capability отдельно определяет, можно ли обмениваться семейством. Extended Next Hop Encoding лишь говорит, какую форму next hop понимает peer для уже разрешённого семейства.

Поэтому в OPEN нужны два доказательства: согласована ли MP-BGP family? Объявил ли получатель точную тройку? Session может быть Established при отрицательном ответе. Sender вправе использовать IPv6 next hop для IPv4 только после второго подтверждения.

Это пример Minimum Initial Specification: стабильный код, детерминированное правило и локальное решение. Если тройки нет, данная кодировка не используется на этой границе; центральный орган не объявляет сеть «переведённой».

Inventory должен хранить BGP instance, peer, версии, session epoch, все AFI/SAFI и каждую отправленную или принятую тройку. Поддержка продукта в документации — закупочный факт, не состояние работающей сессии.

Длина задаёт тип

Для AFI 1 и SAFI 1, 2 или 4 IPv6 next hop занимает 16 или 32 октета. Шестнадцать кодируют один адрес; тридцать два могут содержать global и затем link-local по RFC 2545.

Для VPN-IPv4 с SAFI 128 или 129 используются 24 или 48 октетов с восьмиоктетным нулевым Route Distinguisher. RFC 8950 исправил VPN encoding RFC 5549, согласовав текст с уже совместимыми реализациями и известной errata.

Receiver обязан определить протокол next hop из допустимой для AFI/SAFI длины. Это не декоративное поле. Телеметрия, превращающая всё в строку без типа, лишает аудит возможности проверить интерпретацию.

Global и link-local адреса имеют разную область. Global разрешается через таблицу; link-local уникален только вместе с интерфейсом и линком. fe80::1 без peer, interface и VRF не идентифицирует полный объект.

В unnumbered eBGP транспорт и capability могут быть правильны, а FIB — не иметь interface-scoped adjacency. Перезапуск или замена порта способны сохранить текст адреса и изменить действующий контекст.

В VPN нулевой RD в next-hop field не удаляет service RD или route targets маршрута. VPN identity и next-hop representation разделены.

Reflector не переводит отражённое

Если route reflector передаёт next hop без изменения, он обязан сохранить encoding. Если client не умеет его обработать, NLRI ему не распределяется. Замена IPv6 на IPv4 была бы новой routing decision с другой точкой рекурсии и failure domain.

Совместимость становится свойством топологии. Если один client создаёт encoding, который другие должны получить через общий reflector, соответствующие получатели нуждаются в поддержке. Upgrade одной границы может выявить недостаток другой без ошибки reflector.

Отсутствие выглядит тихо: старый client остаётся Established, получает другие IPv4-маршруты, reflector сохраняет нужный путь. Счётчик видит разницу, но не причину capability.

Доказательство связывает в одном epoch исходный UPDATE, принятую route reflector, OPEN целевого client и Adj-RIB-Out к нему. Причина должна называться «encoding unsupported», а не просто «prefix missing».

next-hop-self, route server и confederation меняют границу. Rewrite может быть легитимен, но тогда это локальное действие с владельцем и доказательством, а не прозрачная reflection.

Рекурсия превращает синтаксис в эксплуатацию

После приёма UPDATE получатель разрешает IPv6 next hop: выбирает table или VRF, находит underlay route, проходит рекурсию, связывает adjacency или tunnel и программирует FIB.

Каждый переход способен сломаться отдельно: адрес отсутствует в IGP, есть только global route, рекурсивная цепь незавершена, Neighbor Discovery не отвечает, нет label или SID, MTU мала после encapsulation, line card отстаёт.

Лестница доказательств:

  1. объявлена MP-BGP family;
  2. объявлена точная extended-next-hop тройка;
  3. на wire присутствует ожидаемый MP_REACH_NLRI;
  4. type разобран правильно;
  5. import policy приняла route;
  6. путь выбран;
  7. next hop разрешён в нужном context;
  8. IPv4 destination запрограммирован в FIB;
  9. IPv4-пакеты дошли и вернулись.

Ни одна ступень не гарантирует следующую. «BGP видит маршрут» слишком грубо. Dashboard может объединять состояния, но обязан сохранять источник каждого перехода.

Rollback требует той же точности. Возврат к IPv4 next hop может потребовать старого underlay, next-hop-self, прежних capabilities и порядка объявлений. Выключить code 5 без восстановления resolver path — не rollback.

У security появляется IPv6-поверхность

RFC 8950 не аутентифицирует маршруты. Защищённая session может нести неразрешённый анонс. RPKI origin validation проверяет origin AS IPv4-префикса, но не безопасность и достижимость IPv6 next hop.

Инструменты с предположением «IPv4 route — IPv4 next hop» пропустят новый объект. RFC предупреждает, что IPv6 next hop создаёт дополнительную возможность divert traffic через промежуточную IPv6-инфраструктуру, включая hijacking и denial of service. Необычный IPv4-mapped IPv6 также требует корректной проверки.

Ответ — не запрет всех межсемейных routes, а явная авторизация: какие peers, service families, IPv6 scopes, tables и tunnels разрешены и какие IPv4-services могут от них зависеть.

Transport authentication, GTSM, prefix policy, RPKI, next-hop authorization, underlay security и packet validation остаются разными controls. Их корреляция полезна; смешение значений создаёт ложную уверенность.

Canary проходит обе семьи

До включения выбрать ограниченный IPv4 prefix и ожидаемый IPv6 next hop. Сохранить route, FIB, packet path, peer, resolver context и ожидаемые тройки на всех speakers.

В новом session epoch захватить оба OPEN и отдельно проверить Multiprotocol и code 5. Затем проверить UPDATE: AFI 1, SAFI, длину 16/32 или 24/48, IPv6 bytes и NLRI.

С reflector доказать сохранение next hop и поддержку каждого client. На каждом receiver сохранить pre/post-policy, selected path, recursive lookup, table, adjacency/tunnel и FIB.

Отправить репрезентативный IPv4 traffic с source, destination, направлением, return path, размером и epoch. Ping не покрывает encapsulation и MTU. Затем withdraw canary и подтвердить очистку Adj-RIB-Out, RIB, recursion и FIB.

Старая config в Git не доказывает возврат. Прежний путь должен снова нести пакеты в текущей сети.

RFC задаёт язык, vendors реализуют, operators выбирают, running network даёт итог. Назначение не становится IPv6 из-за IPv6 core. Номер capability в OPEN не становится forwarding authority. Маршрут заслуживает доверия только при согласии type, policy, recursion, hardware и packets.