Резюме

  • Внешняя таблица совместимости выявила четыре разных сбоя в процедуре передачи, предложенной вAFPUB-2019-V4-003-DRAFT02: ARIN и APNIC возражали против правила о соответствии исходного реестра, RIPE NCC — против последовательности с инициацией принимающим RIR, а LACNIC отметил оба несоответствия, хотя и не требовал взаимности.
  • Правильная идентификация документа имеет решающее значение.AFPUB-2019-V4-003-DRAFT02был подан 13 августа 2020 года; дата 8 октября 2021 года относится к отдельной линииAFPUB-2020-GEN-006-DRAFT02.
  • Проект 2 был предложен, обсуждён, оценён и помещён в архив. Ни объявление об условном примерном консенсусе, ни финальное обсуждение не сделали его принятым, ратифицированным, внедрённым или действующим.
  • AFRINIC мог правомерно аутентифицировать и обновлять записи, за которые он отвечал, координировать действия с совместимым RIR и готовить зависимые системы. Он не мог отменить правила другого реестра или превратить управленческое усмотрение в замену совместимости.
  • Разумной альтернативой был бы версионируемый парный сертификат совместимости, в котором указано, кто аутентифицирует каждую сторону, где начинается запрос, какая версия политики применяется и как все записи реестра и маршрутной безопасности изменяются атомарно.

L3 — Четыре маршрута приёма, которые не состыковались

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

Ответ ARIN касался предложения об исходной стороне. Draft 2 гласил, что исходной стороной должен быть текущий правообладатель ресурсов IPv4, зарегистрированный в любом RIR, и что она должна соответствовать политикам принимающего RIR. ARIN счёл это условие несовместимым со своей политикой межреестровых передач. APNIC пришёл к тому же основному выводу. В его оценке говорилось, что соответствующая формулировка является общей для Draft 2 и Draft 3, и договорённость признана несовместимой, в частности потому, что она требовала от исходной стороны соблюдения правил принимающего реестра.

RIPE NCC выявил другую точку отказа. Раздел 5.7.5 предписывал передающей стороне направить запрос принимающему RIR, используя стандартный шаблон и официальное соглашение о передаче. После одобрения принимающим RIR этот реестр уведомлял бы передающий RIR, исходную сторону и получателя, и ресурсы были бы переданы. Процедура RIPE NCC начиналась, напротив, с RIR, в котором ресурсы были зарегистрированы на тот момент. Поэтому он счёл последовательность Draft 2 несовместимой и нереализуемой.

Разногласие касалось не стремления разрешить перемещение, а первого авторитетного действия: какой реестр принимает запрос, когда исходная запись и средства проверки её держателя находятся в другом месте.

LACNIC не предъявлял требования взаимности, поэтому его ответ особенно полезен. Отсутствие требования взаимности не сделало конструкцию совместимой. LACNIC всё равно заявил, что требование к исходной стороне соблюдать политику другого RIR имеет мало смысла, и обнаружил, что предложенная инициация принимающим RIR не соответствует другим межреестровым соглашениям. Иными словами, устранение одного возможного политического барьера не исправило операционную последовательность. Реестр мог быть в принципе открытым и всё равно неспособным выполнить передачу в том виде, как она была составлена.

Эти четыре ответа были прямо привязаны кAFPUB-2019-V4-003-DRAFT02. Они не были общими вердиктами обо всех передачах ресурсов и не означали, что любая последующая версия потерпит неудачу. Совместимость привязана к тексту: к действующему пункту, направлению перемещения, виду и статусу ресурса, текущей политике каждого реестра и фактическим действиям его сотрудников. Измените один из этих входных параметров — и проверку нужно проводить заново.

Такая точность начинается с идентификации предложения. Рассматриваемый здесь Draft 2 — это Политика передачи ресурсов с номеромAFPUB-2019-V4-003-DRAFT02, версия 2.0, поданная 13 августа 2020 года для изменения раздела 5.7 Сводного руководства по политикам AFRINIC. В одном плановом документе этот идентификатор был сопоставлен с 8 октября 2021 года, но более поздняя дата относится к другому предложению,AFPUB-2020-GEN-006-DRAFT02. Идентификаторы и даты нельзя смешивать. Вывод о совместимости, привязанный к одному документу, не может перейти на другой лишь потому, что оба касаются передачи номерных ресурсов.

То же ограничение относится к институциональному статусу. Draft 2 был предложен, обсуждён, оценён и в итоге помещён в архив. Он был представлен на AFRINIC-32 17 сентября 2020 года. 21 сентября резюме сопредседателей объявило об условном примерном консенсусе и финальном обсуждении, отметило связанную с ARIN проблему взаимности и потребовало поправок. Это были этапы частного процесса разработки политики. Сами по себе или вместе они не поместили текст в руководство, не обеспечили ратификацию Советом и не создали реализованное правило передачи. Появление Draft 3 в тот же день подтверждает, что текст всё ещё двигался.

Более поздние черновики остаются более поздними черновиками, а отдельное предложение, поданное в 2021 году, остаётся отдельным. Последующая ратификация третьего черновика из другой линии не даёт недостающих доказательств внедрения для этого Draft 2.

Что предложение пыталось сделать перемещаемым

Draft 2 исходил из реального пробела. Существовавшая схема не поддерживала двусторонний межреестровый механизм. Предложение предусматривало передачи внутри региона AFRINIC, в него и из него, а в постановке проблемы упоминались адреса IPv4 и номера AS. Оно открывало более широкую коммерческую поверхность, чем режим постоянного регионального плена: снимало действовавшие 12-месячные ограничения ожидания и не предлагало верхнего предела объёма передаваемых, выделяемых или назначаемых ресурсов, когда отправитель и получатель достигли взаимного соглашения, при условии соблюдения действующей политики.

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

Но пункты не определяли, кто может устанавливать факты, от которых зависели эти решения. Сотрудники AFRINIC спросили, почему исходная сторона должна соответствовать принимающему RIR, с которым у неё нет отношений. Они также отметили, что проверку держателя исходной записи нельзя завершить, если исходная сторона подаёт заявку напрямую принимающему RIR, а не реестру, хранящему исходную запись. Это тот же структурный разрыв, который позже проявился в ответах контрагентов.

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

Оценка сотрудников выявила дополнительную неопределённость. Они спросили, является ли предложенный стандартный шаблон общепринятым в мире. Они не нашли руководства для ресурсов, находящихся в споре, и предупредили о риске злоупотреблений при повторном выделении. Они выявили конфликт между пунктами о получателе 5.7.4.1 и 5.7.4.2: широкая формулировка допускала любую сторону с соглашением о передаче, тогда как согласно прочтению сотрудников получатель в регионе AFRINIC должен был быть членом AFRINIC и пройти оценку потребности. Оценка также отметила, что номера ASN упоминались в постановке проблемы, но не в оперативных пунктах об IPv4.

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

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

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

Механизм за политической формулировкой

Оценка сотрудников AFRINIC сделала операционную сторону необычно заметной. Межреестровая передача потенциально потребовала бы изменений в инструменте передачи MyAFRINIC, обратном DNS, авторизациях происхождения маршрутов RPKI, журналах передач и системе заявок. Сотрудники предполагали пересмотр процессов, координацию с RIR с совместимыми политиками, увеличение мощностей службы поддержки членов и инженерные работы по программному обеспечению. Фраза о том, что ресурсы «будут переданы», сжимает, таким образом, серию связанных действий.

Запись реестра должна перейти из одного согласованного состояния в другое. Контроль исходной стороны должен быть аутентифицирован. Правомочность получателя и применимый тест потребности должен решить институт, обладающий соответствующим правилом и отношениями. Двум RIR нужно сообщение, которое оба признают как одобрение. Регистрационная информация должна изменяться без создания момента, когда оба реестра выглядят авторитетными или ни один из них. Делегирование обратного DNS и состояние RPKI должны следовать за предполагаемым держателем. Публичная история передач и внутренние заявки должны сохранять, что произошло и почему.

Если одно зависимое изменение не удаётся, организациям нужно состояние отката, которое не дублирует признание и не оставляет ресурс без владельца.

Именно поэтому четыре ответа нельзя разумно читать как приглашение руководству AFRINIC делать исключения. Руководитель может направлять работу в рамках законных операционных полномочий AFRINIC. Руководство может обеспечить проверку записи, хранящейся в AFRINIC, готовность систем AFRINIC и обмен согласованными доказательствами с контрагентом. Оно не может заставить ARIN принять условие об исходной стороне, которое политика ARIN не признаёт, заставить RIPE NCC начать дело не с того конца его процедуры или создать отношения аутентификации между исходной стороной и принимающим реестром простым утверждением.

Практические риски ложатся на операторов, даже если документально не зафиксировано завершённых потерь. Описание практики передачи от NRS подчёркивает важность учётных записей реестра, одобрения, статуса членства, документации и политики, применимой в соответствующем RIR. LARUS добавляет точку зрения инфраструктурного оператора: управленческие решения могут незаметно влиять на непрерывность и планирование сделок через записи и зависимости, на которые опираются сети. При аккуратном применении здесь эти точки зрения показывают, почему неоднозначная передача создаёт риски дополнительной проверки, задержек и непрерывности.

Они не доказывают, что Draft 2 вызвал сбой, отклонённую сделку, ценовые потери или вред конкретному клиенту. Доступные материалы доказывают несовместимость конструкции и объём работ, который потребовался бы для внедрения, а не производственный инцидент.

Справедливое прочтение и его границы

Самое сильное благожелательное объяснение заслуживает быть изложенным без оговорок. Авторы увидели реальную экономическую и операционную проблему. Дефицит IPv4 повысил ценность возможности перемещать ресурсы между региональными системами. У AFRINIC был внутрирегиональный маршрут, но не было двустороннего межреестрового маршрута, которого добивалось предложение. Draft 2 пытался ослабить ограничения по объёму и срокам ожидания, сохранив проверку потребности для входящих ресурсов и соблюдение политики для исходящих передач.

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

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

Источники