Кратко

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

14 сентября участник списка политик LACNIC спросил, почему опция субделегирования видна в MiLACNIC, но отсутствует в Registro.br, и установлен ли срок. На следующий день участник со стороны Registro.br рассказал о совместной работе LACNIC и национальных интернет-регистратур (NIR) по внедрению правила и отметил, что у каждой системы есть собственные сложности. В другом ответе говорилось, что опция отображалась в MiLACNIC для ASN, знакомого автору сообщения, но пользоваться ею пока не приходилось. Поводом для вопроса послужил реальный пример: бразильский интернет-провайдер продавал выделенный канал компании не из Бразилии. (вопрос от 14 сентября; ответ о внедрении; пояснение примера)

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

В центре вопроса находится политика LACNIC LAC-2025-5 «Субделегирование IPv4-ресурсов третьим лицам». Официальная страница указывает дату ратификации — 24 марта 2026 года. Действующий текст касается IPv4 и задаёт условия допустимого субделегирования: требования к получателю, ограничения размера блока, критерии фактического использования или непосредственной потребности, связь блока с ASN получателя в WHOIS и запись события в публичном журнале перемещений. Окончательная ответственность остаётся за членом LACNIC, который выполняет субделегирование. После передачи или возврата ресурса также действует период ожидания. (действующий ратифицированный текст)

Эти ограничения не превращают каждое клиентское подключение в передачу ресурса. Напротив, они требуют точнее классифицировать отношения сторон. Если провайдер продаёт транспорт, продолжая использовать собственное адресное пространство, покупка выделенного канала не доказывает субделегирование. Если же провайдер отдельно предоставляет блок для операционного использования клиентом, коммерческое название услуги «канал» не отменяет ресурсные отношения. Публичная переписка не содержит данных, позволяющих выбрать один из вариантов.

Проверять нужно получателя ресурса, а не название услуги

Руководство LACNIC по запросам ресурсов помогает не смешивать разные категории. Поставщиков услуг веб-хостинга, колокации, виртуальных серверов или выделенных каналов оно рассматривает в контексте интернет-провайдеров. Отдельно выделяется организация, работающая на собственной инфраструктуре и не передающая блоки адресов третьим лицам. Запросы из Бразилии и Мексики направляются через соответствующие NIR. (руководство LACNIC)

Это руководство не классифицирует пример из списка рассылки. Однако оно показывает, почему словосочетание «выделенный канал» не отвечает на вопрос политики. Канал описывает покупаемую услугу — соединение сетевых точек. Запись о ресурсе относится к другому объекту: какая организация получает блок IPv4 и какие сведения связывают её с этим ресурсом. Один договор или счёт может объединять обе части; возможна и только одна из них.

Такая граница знакома экономике инфраструктуры. Компании объединяют пропускную способность, оборудование, обслуживание и адресацию, поскольку клиенту часто нужен готовый результат, а не перечень компонентов, которыми придётся управлять по отдельности. Пакетное предложение снижает издержки координации. Но оно может скрыть того, кто контролирует дефицитный ресурс и несёт связанные с ним обязанности перед регистратурой. Решение не в том, чтобы считать всякую комплексную услугу субделегированием. Сначала нужно определить ресурс и его получателя, а затем применить правило, созданное для таких отношений.

LAC-2025-5 задаёт конкретные параметры проверки. Блок должен укладываться в действующий диапазон размеров. Получатель должен соответствовать условиям, связанным с ASN и IPv6. Критерий использования различает уже имеющееся использование или немедленную потребность и план достичь более высокого порога в течение года. Запись WHOIS должна связать блок с ASN получателя, а публичный журнал — указать блок, ASN, дату и начало либо завершение события. Ответственность остаётся за членом, выполнившим субделегирование. Это не общие признаки отношений с клиентом, а поля конкретного режима управления ресурсами.

Гражданство клиента тоже не определяет расположение его сети. Формулировка «компания не из Бразилии» описывает компанию так, как её представил участник переписки, но не сообщает, где находятся маршрутизаторы, пользователи или используемое адресное пространство. Неизвестно и то, есть ли у клиента ASN и использует ли он адреса самого провайдера. География может влиять на то, какой NIR участвует в процессе, но она не заменяет сведения о получателе и ресурсе, требуемые политикой.

Разница между порталами — вопрос, а не установленный сбой

Сентябрьскую переписку следует считать ограниченным свидетельством хода внедрения. 1 сентября представитель LACNIC по вопросам политики сообщил, что реализация ожидается до конца года, сначала в базовом объёме, а технические сложности ещё предстоит решить. Затем участник рассказал, что видел опцию в одной системе, но не в другой. В ответе упоминались совместная работа и особенности каждой системы. Ещё один участник сказал, что опция была видна в MiLACNIC для знакомого ASN, но пользоваться ею он пока не пробовал. (сообщение о внедрении от 1 сентября)

Из этих сообщений следует, что на этапе продолжающегося внедрения пользователи выясняли, как новое правило будет отображаться в разных интерфейсах. Они не доказывают, что один из порталов работал со сбоем, что опция была доступна всем пользователям MiLACNIC, что к тому моменту она уже должна была появиться в Registro.br или что срок внедрения нарушили. Это датированные наблюдения и пояснения, а не контролируемое сравнение работы систем.

Практическая проблема всё же существует: правило, зависящее от получателя, блока, ASN и события с конкретной датой, должно быть доступно членам и, когда это необходимо, NIR. Если пользователь не находит нужную опцию, подача сведений может задержаться или стать неопределённой. Но издержки следует измерять на проверенных примерах, а не выводить из одного обсуждения. Возможны разные причины: права учётной записи, сами ресурсные отношения, этап развёртывания портала или недостаток опыта пользователя. Пока оператор не установил причину, выбирать одну из них преждевременно.

Рабочая последовательность начинается с адресного блока. Затем нужно определить, кто его получает или контролирует, каков ASN получателя и какая запись в реестре имеет отношение к делу. После этого можно проверить применимость условий политики и необходимость публичной записи события. Лишь затем следует выяснять, позволяет ли портал зарегистрировать событие. Если начать с отсутствующего пункта меню и сделать вывод о субделегировании, неопределённость интерфейса превратится в юридическое или техническое утверждение.

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

Что должна содержать полезная запись о внедрении

Для члена LACNIC надёжный процесс должен до отправки заявки показать основные сведения об отношениях с ресурсом: блок, предполагаемого получателя, его ASN, основание использования или немедленной потребности, дату начала либо завершения договорённости. Если политика применяется, данные реестра и запись в публичном журнале должны совпадать. Если она не применяется — например, провайдер оставляет адреса у себя и не передаёт блок третьим лицам — причина должна быть столь же понятной клиенту и сотруднику, обрабатывающему запрос.

Для LACNIC и NIR вопрос внедрения не сводится к наличию кнопки. Член должен понимать, какая система обслуживает его учётную запись, можно ли внести в соответствующий процесс все нужные поля и сопоставить отправленное событие с записью о ресурсе. Переписка сентября этого не проясняет. Последующее сообщение могло бы описать этапы внедрения, ответственность разных порталов и маршрут для членов, чьи учётные записи или ресурсы ведёт NIR.

Это не означает, что нужно публиковать договоры или коммерческие данные клиента. Политика требует публичного события с определёнными полями. Полезное подтверждение операции может показать эти поля и состояние системы, не раскрывая условия сделки. Если подходящего субделегирования нет, может быть достаточно частного ответа службы поддержки; публичный журнал не должен создавать впечатление о событии, которого не было.

Вывод сдержанный, но значимый. По выделенному каналу могут передаваться адреса, а коммерческое предложение может объединять несколько сетевых компонентов. Но ответ не содержится ни в маркетинговом названии услуги, ни в гражданстве клиента, ни в наличии пункта меню. Он зависит от того, кто получил ресурс IPv4, как зарегистрированы эти отношения и выполнены ли действующие условия. Публичные сведения ставят вопрос, но не разрешают его.

Другие официальные языковые версии LAC-2025-5