Кратко

  • RFC 9910 определяет rdap-down как поиск непосредственных дочерних объектов, а rdap-bottom — как набор наиболее конкретных регистрационных объектов, совместно покрывающих запрошенный диапазон.
  • В живом ответе ARIN для /21 оказались активное прямое выделение /22 и административный /8; /8 покрывает остаток, но не становится дочерним объектом /21.

Ящик с перевёрнутой геометрией

Форма ответа сначала кажется невозможной. Для 149.112.152.0/21 служба ARIN вернула NET-149-112-152-0-1, активное прямое выделение в виде /22, и NET-149-0-0-0-0, административный объект в виде /8.

/8 не может быть более конкретным потомком /21. Служба этого и не утверждает. Противоречие возникает, если понимать bottom как «все листья под узлом». В RFC 9910 вопрос иной: какие наиболее конкретные доступные регистрационные объекты вместе покрывают всё значение интернет-ресурса, переданное клиентом?

/22 покрывает лишь половину /21. Для остальных адресов наиболее конкретным зарегистрированным объектом в ответе оказался /8. Поэтому набор пересекается. Это не разбиение на непересекающихся потомков, а описание полного покрытия средствами реестра.

Down и Bottom решают разные задачи

Парный запрос показывает различие. rdap-down для того же /21 вернул только /22. Эта связь ищет следующий уровень зарегистрированных объектов непосредственно ниже входного диапазона. /8 таким ребёнком не является.

rdap-bottom вычисляет покрытие. Если более конкретные объекты охватывают лишь часть диапазона, более широкий объект остаётся для остатка. RFC 9910 прямо говорит, что bottom-объекты могут пересекаться и что среди них может быть объект менее конкретный, чем запрос. ARIN описывает ту же логику: если найденные bottom-объекты не покрывают всё значение, возвращается и наиболее конкретный сетевой объект для остатка.

Это избавляет клиента от рекурсивной сборки дерева. Риск появляется при отображении. Если каждую строку назвать «подвыделением», объект покрытия превратится в ложную родственную связь. Префикс верен; потеряна причина его включения.

Что действительно доказывает ответ

Элементы являются объектами ip network. Они содержат идентификаторы, начальные и конечные адреса, CIDR, тип по модели ARIN и статус. В снимке /22 — активный DIRECT ALLOCATION, а /8 имеет статус administrative.

Это свойства регистрационной поверхности. Они не доказывают объявление BGP, достижимость, трафик или авторизацию ROA. Необязательные массивы исходных ASN в обоих объектах были пусты. Пустое поле не доказывает отсутствия маршрута; оно описывает один ответ в один момент.

RFC 9083 определяет объект IP-сети как регистрационную информацию. RFC 9082 говорит, что обычный IP-поиск нацелен на наиболее конкретную зарегистрированную сеть, полностью содержащую запрос. Геометрия регистрации не становится состоянием работающей сети.

Сохранять связь вместе с данными

Проверяемая запись хранит тип связи, входной диапазон, время, handle, границы, CIDR, тип и статус каждого результата. Тогда /8 понятен: это регистрационное покрытие части, не покрытой /22.

Коллекторы BGP, объекты IRR, проверка RPKI и внутренний учёт остаются отдельными источниками. Bottom описывает покрытие реестра, а не доступ к маршрутизатору, контроль учётной записи, юридическое право или видимость маршрута.

Без названия связи точный ответ превращается в выдуманное дерево делегирования. Корректная подпись буквальна: покрытие запрошенного диапазона наиболее низкими доступными зарегистрированными объектами.

Источники