Кратко

  • RFC 1887 описывал multihoming как выбор плательщика: независимый префикс экономит сайту renumbering, но добавляет глобальный маршрут; адреса провайдера агрегируются, но связывают внутреннюю нумерацию с подключением.
  • RFC 2073 выделил Registry ID, Provider ID и Subscriber ID; RFC 2374 убрал биты реестра, а RFC 3587 признал исторической и сменившую их структуру TLA/NLA.
  • Иерархическое агрегирование не исчезло. Из формата исчезло предположение, что одна административная лестница должна навсегда стать смыслом адреса.

Большое адресное пространство не увеличило память каждого роутера до бесконечности

RFC 1887, опубликованный в декабре 1995 года, начинал с объёма информации о достижимости. Если множество сайтов получает смежные блоки от одного провайдера, тот может объявить один общий префикс. Удалённые сети хранят и пересчитывают меньше записей.

Это продолжало логику CIDR из RFC 1518 и RFC 1519: произвольная длина префикса и longest-prefix match позволяли адресации следовать топологии. 128 бит устраняли одну тесноту, но не дефицит памяти, пропускной способности обновлений и времени сходимости.

RFC 1887 прямо назвал напряжение между эффективностью и децентрализованным контролем. Администрирование можно распределить, но полезная агрегация требует соответствия реальным соединениям. Границы компании, страны, реестра и физической сети не обязаны совпадать. Исключение не исчезает; архитектура выбирает, кто его несёт.

У четырёх решений multihoming были разные счета

Независимый от провайдеров префикс сохранял одну внутреннюю схему и один агрегат сайта. Но он не входил в агрегат конкретного провайдера, поэтому отдельную запись могли хранить сети по всему миру.

Префикс от каждого подключения позволял каждому провайдеру агрегировать своих клиентов. Однако отказ линии мог лишить достижимости адреса, полученные через неё. Смена внешнего подключения требовала менять внутренние адреса. Дополнительные резервные маршруты уменьшали риск и одновременно выгоду агрегирования.

Третий вариант выбирал основной префикс и ограниченно распространял более прямые пути. Четвёртый предлагал общий префикс клиентам с одной и той же комбинацией провайдеров. Все варианты перемещали таблицы, координацию и зависимость, а не уничтожали их.

В итоговом разделе RFC 1887 подчёркивал: каждый подход возлагает разную реальную, то есть финансовую, стоимость на multihomed-организации и транзитные домены, включая домены без прямой связи с клиентом. Политика принятия и распространения «чужих» префиксов определяла, где этот счёт будет оплачен.

Административная цепочка стала разметкой битов

RFC 2073 в январе 1997 года определил трёхбитный Format Prefix, пятибитный Registry ID, затем Provider ID, Subscriber ID и 64-битную внутреннюю часть.

IANA назывался главным реестром; значения выделялись также для multi-regional IANA, RIPE NCC, INTERNIC и APNIC. Реестры проектировали пространство провайдеров и абонентов, провайдер — идентификаторы абонентов, абонент — локальную часть.

Но маршрутизатор не интерпретировал названия учреждений. Он выбирал самое длинное совпадение префикса. Другие unicast-форматы не запрещались, а абонент мог получить независимое пространство непосредственно от реестра.

Название Provider ID поэтому не доказывало действующий договор, BGP-origin, собственность или доставку пакета. Оно фиксировало место в конкретной модели распределения.

Сначала исчезли пять бит реестра

RFC 2374 заменил RFC 2073 в июле 1998 года. Биты реестра убрали как ненужные для агрегации. Новая схема использовала TLA, NLA, SLA и 64-битный Interface ID, отделяя публичную топологию от топологии сайта.

Допускалась агрегация через провайдеров и точки обмена. Подключённый к exchange сайт теоретически мог менять дальнего оператора без renumbering и использовать нескольких без префикса от каждого. Однако механизмы выбора и переносимости документ намеренно не определял. Возможность в формате ещё не была процедурой с проверкой, сроками и восстановлением.

В августе 2003 года RFC 3587 сделал RFC 2374 и TLA/NLA историческими. Фиксированную схему заменила согласованная политика RIR. Авторы отмечали, что TLA/NLA может быть не лучшим техническим подходом на данной стадии внедрения, а политика, вероятно, продолжит меняться.

Осталась общая форма: global routing prefix, subnet ID и interface ID. RIR и ISP по-прежнему могли иерархически строить глобальный префикс, сайт — свою подсеть. Сохранилась функция; исчезли навечно закреплённые названия внешних ролей.

Renumbering без общего дня переключения остаётся renumbering

RFC 4192 предложил make-before-break: старый и новый префиксы временно сосуществуют, пока меняются DNS, маршрутизация и конфигурация. Это снижает перерыв, но не находит автоматически адреса в ACL, мониторинге, сертификатах и приложениях.

RFC 4984 зафиксировал, что для некоторых сайтов такие зависимости делают renumbering практически невозможным. PI-пространство избегает привязки к провайдеру, но добавляет неагрегируемую глобальную запись. PA-пространство агрегируется у выдавшего провайдера, однако объявление через другого может вынудить deaggregation.

Отчёт описал перегрузку семантики locator/identifier. Локатор должен следовать меняющейся топологии; идентификатор ожидают стабильным. Одно число не может всегда оптимизировать оба свойства.

Даже общая рекомендация /48 из RFC 3177 была пересмотрена. RFC 6177 в 2011 году отказался от одного размера и предупредил, что несколько фиксированных границ могут стать новыми классами в коде и практике. Принцип достаточного пространства сохранился, точный размер вернулся к операционному решению.

Один префикс связывает доказательства, но не сливает их

Запись реестра подтверждает делегирование по определённой политике и дате. Наблюдение BGP подтверждает origin, видимый из конкретной точки. Договор подтверждает коммерческое обязательство. Телеметрия подтверждает путь и результат. Общий префикс позволяет связать записи, но не заменяет одну другой.

История RFC 1887–3587 показывает полезную обратимость: операционную цель измеряют, а институциональную реализацию пересматривают. Источник выделения, origin, правила принятия, договор провайдера, зависимости renumbering и итог сервиса следует хранить раздельно.

Маршруты нужно агрегировать. Полномочия — нет.

Источники