Кратко

  • RFC 4012 сохранил прежний смысл import, export и default для IPv4 unicast и добавил атрибуты mp-* с выбором семейства.
  • Если в новых атрибутах опустить AFI, действует any для IPv4/IPv6 unicast и multicast; это не означает «семейство не задано».

Пропущенный AFI — не пустая область действия

Увидев mp-import без оговорки afi, читатель может решить, что семейство адресов не указано. RFC 4012 устанавливает обратное: пропуск означает any — определённую область, включающую IPv4 unicast, IPv4 multicast, IPv6 unicast и IPv6 multicast. Слова в строке нет, но правило есть; интерпретатору и оператору не нужно угадывать его.

Это значение по умолчанию относится только к новым атрибутам mp-*. Старые import, export и default сохраняют прежний смысл IPv4 unicast. Поэтому существующие записи не меняют значение незаметно, а многопротокольная запись без AFI всё равно имеет определённую область. Прежде чем читать само правило, полезно выяснить, какую область грамматика уже задала пропуском.

Исходная модель была рассчитана на IPv4 unicast

RFC 2622, опубликованный в 1999 году, определил RPSL для описания политик IPv4 unicast. Атрибуты import, export и default читались именно в этом контексте. В марте 2005 года RFC 4012 расширил модель на IPv6 и multicast, сохраняя совместимость с прежним употреблением. RFC 2622 RFC 4012

Смысл старых атрибутов остался прежним: они по-прежнему относились к IPv4 unicast. Для многопротокольных правил появились mp-import, mp-export и mp-default. Параметр afi позволяет указать, например, ipv6.unicast или ipv6.multicast, а также более широкий охват. Если необязательная запись AFI пропущена у атрибута mp-*, RFC 4012 задаёт область any, то есть все четыре описанных семейства. Это правило интерпретации текста RPSL, а не гарантия поддержки или применения всех семейств оборудованием. RFC 4012, разделы 2.1–2.5

Эта точность важна для сетей, где IPv4 и IPv6 используют разные соседства, фильтры, next hop и процедуры объявления. Реестр теперь может указать область политики, не предлагая считать её одинаковой для обоих семейств. Но выбор остаётся за оператором.

Словарь позволяет объединять области: ipv4 и ipv6 включают unicast и multicast своей версии; any.unicast и any.multicast объединяют один вид передачи для обеих версий; any охватывает все четыре базовые комбинации. Краткость здесь достигается именованием объединений, а не неявностью их границ.

Одинаковое сокращение AFI, но разные уровни

RFC 4012 также добавил класс route6, однако ключ объекта и разрешение на его изменение — отдельные вопросы, не связанные с необязательной оговоркой AFI; это разрешение рассматривает RFC 2725. Здесь это упоминание лишь обозначает границу темы, а не открывает вторую линию. RFC 4012, раздел 3 RFC 2725

BGP тоже использует AFI/SAFI, но RFC 4760 связывает их с областью сетевой достижимости и next hop в сообщениях UPDATE. Необязательная AFI в RFC 4012 ограничивает выражение политики RPSL. Совпадение сокращений не делает эти утверждения взаимозаменяемыми: выбор маршрута и его объявление отдельным соседям относятся к работе протокола, описанной в RFC 4271. RFC 4271 RFC 4760

Именованные объединения сделали синтаксис комбинируемым

Фраза «RPSL научился описывать IPv6» верна, но неполна. RFC 4012 позволил явно задавать область семейства для политики и назвал объединения версий и видов трафика. Это описание языка, а не утверждение, что сети стали одинаково использовать обе версии.

В сети с двумя стеками такая разница не формальна. Политика для afi ipv6.unicast уже, чем для afi any, а фильтры и объявления действительно могут отличаться. И всё же точность записи сама по себе не определяет, что автономная система загрузит на свои устройства.

RFC 8212, опубликованный в 2017 году, задаёт более позднюю временную отметку: он требует явной политики для EBGP, но регулирует поведение BGP и не меняет трактовку пропущенной AFI в RPSL по RFC 4012. RFC 8212

Редакционная рамка здесь опирается на заметки Лу Хэна №65 и №64: общие правила должны ограничиваться нуждами взаимодействия систем, а изменения приобретают силу благодаря их принятию работающими участниками. Это не предположение о взглядах авторов RFC 4012. Рамка помогает отделить слой описания от слоя исполнения: RPSLng делает политику понятнее, но загружает её и объявляет маршруты система, в которой работает BGP. Заметка 65 Заметка 64

Эти документы не содержат оценки распространённости RPSLng, полноты реестров, конфигурации конкретного оператора или результатов внедрения IPv6. Подтверждённый вывод уже: RFC 4012 сделал область выражения политики RPSL точнее и однозначнее.

Первичные источники