Кратко

  • Опубликованный 28 марта 2018 года документ об обновлении IPv6 PI имел обозначение AFPUB-2018-V6-004-DRAFT01. Обозначение V6-003 принадлежало отдельному обновлению первоначального выделения IPv6 для LIR, поэтому смешение этих двух инструментов меняет и адресата, и смысл решения.
  • Сильная сторона V6-004 заключалась в устранении требования иметь прошлое в IPv4 PI, в объективной привязке размера к конечным площадкам и в возможности исправить первоначально недостаточный размер. Это помогало конечной организации получить устойчивую сетевую идентичность без зависимости от одного вышестоящего провайдера.
  • Проверка личности, контроля, отсутствия дублирования, числа площадок и разумного размера префикса служит узкой технической координации. Требование доказать институционально одобряемую модель бизнеса, непременно анонсировать префикс глобально или подчинить выбор маршрутизации наказанию выходит за пределы этой функции.
  • AFRINIC — частный технический регистратор записей, а не суверен, регулятор или суд. Надлежащая конструкция сохраняет точный реестр и совместимость маршрутизации, но оставляет выбор провайдера, многоадресности, частного использования и сетевого дизайна оператору.

L3 — IPv6-шлюз, для которого больше не требовалась история IPv4

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

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

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

Именно эту зависимость устранял проект, опубликованный 28 марта 2018 года. Его правильное обозначение — AFPUB-2018-V6-004-DRAFT01. Это не мелкая редакционная подробность. AFPUB-2018-V6-003 относился к другому предложению — IPv6 Initial Allocation Update — и затрагивал первоначальные и последующие выделения для LIR. V6-004 был IPv6 PI Update и касался пути конечной организации к провайдеронезависимому пространству. Если назвать его V6-003, исчезает граница между адресами, которыми LIR обслуживает клиентов, и адресами, которые конечный пользователь удерживает ради собственной сетевой идентичности.

Тогда анализ незаметно отвечает уже не на тот институциональный вопрос.

Публикация проекта тоже должна оставаться на своём месте в хронологии. 28 марта появился Draft 1; это был проверяемый акт опубликования предложения, а не момент, когда оно уже приобрело операционную силу. На встрече AFRINIC-28 6 июня автор объяснял, что исчерпание IPv4 сделало прежнюю зависимость нелогичной, и описывал возможность получить IPv6 PI без IPv4 PI. Участники обсуждали двенадцатимесячное условие, сохранение принципа HD-ratio и вопрос о том, должен ли персонал отслеживать маршрутизацию. Сохранилось одно возражение в пользу прежней квалификации до выработки самостоятельных критериев IPv6.

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

Переход к last call был процедурным событием. Он не был ни публикацией 28 марта, ни ратификацией, ни реализацией, ни превращением частной организации в орган публичной власти. Протокол Совета позднее зафиксировал резолюцию 201808.449 от 7–8 августа: V6-004 Draft 1 был ратифицирован, а персоналу поручили его реализовать. В истории редакций консолидированного руководства изменения затем появились в разделах 6.8–6.8.4 с датой 1 ноября. Наконец, сообщение от 29 ноября говорило о частичной реализации и о том, что автоматизация отдельных положений ещё ожидалась.

Каждая дата описывает отдельную стадию; перенос поздней силы назад на день публикации исказил бы свидетельства.

Архитектура предложения давала конечной организации новый маршрут, но не отменяла проверки. Заявитель должен был быть не LIR, а конечным пользователем, вступить или состоять в отношениях членства конечного пользователя с AFRINIC, показать число конечных площадок и обосновать потребность. Запрошенное пространство предполагалось развернуть в течение двенадцати месяцев. Такая схема соединяла снятие исторического барьера с доказательствами того, что перед реестром находится определимая организация и конкретная сеть, а не абстрактный запрос на запас адресов.

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

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

В этой логике /48 на площадку — не награда и не свидетельство собственности. Это единица планирования, позволяющая конечной сети строить внутреннюю иерархию адресов без воспроизведения искусственной скудости IPv4. Ниббл-выравнивание облегчает чтение и делегирование границ. Разреженное распределение и резерв смежного роста могут уменьшить будущую фрагментацию. Однако даже технически удобная единица должна оставаться средством согласованного учёта. Она не даёт реестратору права решать, заслуживает ли определённый сектор экономики современной сети, или навязывать всем одинаковую внутреннюю топологию.

Не менее значим был механизм исправления первоначального назначения. План площадок может измениться после подачи заявки: организация приобретает объект, объединяет сети, отделяет подразделение, переносит сервисы или обнаруживает, что первоначальная оценка была слишком осторожной. AFRINIC-28 зафиксировал, что V6-004 добавлял путь исправления, когда первоначальный размер IPv6 PI переставал соответствовать новому плану. В лучшем варианте такой путь сокращает необходимость многократной перенумерации. Вместо того чтобы навечно наказать заявителя за раннюю ошибку прогноза, реестр может проверить обновлённые факты и записать подходящий размер.

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

Отдельным элементом была агрегация. Когда PI-пространство анонсируется, текст стремился к максимально практичной агрегации, чтобы не увеличивать без необходимости глобальную таблицу маршрутов. Эта забота имеет техническое содержание. Каждый независимо видимый маршрут требует состояния в маршрутизаторах, обработки обновлений, фильтрации и операционной диагностики. Если один связный префикс может честно описать достижимость тех же площадок, множество более специфичных анонсов не всегда оправдано. Реестр вправе объяснить этот эффект и строить выдачу так, чтобы не создавать бессмысленную фрагментацию.

Но уже на обсуждении проявилась опасная неоднозначность. Участники спрашивали, что произойдёт, если назначенное пространство не будет анонсировано за двенадцать месяцев, остаётся ли HD-ratio и должен ли AFRINIC контролировать маршрутизацию. Запись передаёт ответ автора: принцип HD-ratio оставался, а персоналу не давалось указания наблюдать за таблицами маршрутов. Позднейший проект разъяснения 2019 года показал, почему вопрос был существенным.

В V6-004 сохранилась фраза, допускавшая чтение, будто неанонсированное после двенадцати месяцев пространство подлежит возврату, хотя существуют нормальные сценарии PI, не требующие глобального анонса, включая локальные сети обмена трафиком и частные сети.

Позднее разъяснение нельзя подставлять в мартовский текст как будто оно уже существовало. Оно также не доказывает, что у какой-либо названной организации действительно забрали ресурс. В закрытом наборе свидетельств нет ни такого случая, ни имени отклонённого заявителя. Тем не менее разъяснение выявляет ограниченный дефект первоначальной архитектуры: срок развёртывания и факт глобального анонса могли быть слиты в один критерий. Сеть способна использовать адреса внутри контролируемой инфраструктуры, на пиринговой локальной среде или в частном контуре и при этом не объявлять их всему Интернету.

Отсутствие глобального маршрута не равно отсутствию сети.

Эта оговорка возвращает анализ к точному предмету. V6-004 не был обещанием, что каждый оператор мира примет любой зарегистрированный маршрут. Регистрация уникального префикса, наличие авторизации на его объявление и фактическая фильтрация у независимых сетей — разные уровни. Публичные свидетельства не содержат количественной оценки того, сколько дополнительных маршрутов породило предложение. Они не называют отказов, изъятий или перенумераций и не доказывают универсальную маршрутизируемость всех PI-префиксов. Поэтому успех проекта нельзя объявить на основании несуществующей статистики.

Проверяемый результат его конструкции уже: устранение зависимости от IPv4 PI и формирование отдельного пути для конечной организации.

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