Резюме

  • Адресация по интернет-протоколу изначально не имела пяти территориальных делений. Географическое администрирование возникло с 1990 года как ответ на международный рост, языковые и сервисные потребности, нагрузку на реестры, экономию адресов и попытку сделать непрерывные выделения совместимыми с агрегированием маршрутов.
  • RFC 1174 рекомендовал международное делегирование при сохранении центральных функций IANA и Интернет-реестра; RFC 1466 предлагал четыре основные зоны выделения, но также сохранял мультирегиональное пространство, три диапазонаOthers, прямое центральное обслуживание и реестр по умолчанию для неохваченных зон.
  • Нынешняя карта из пяти регионов закрепилась через раздельные операционные запуски, делегирование адресных блоков, регистрацию юридических лиц, двусторонние переходы, решения ICANN о признании, а также документы ASO и NRO. Эти этапы произошли не одновременно, и их не следует проецировать в прошлое.
  • Административный регион обслуживания, юридический адрес получателя, эксплуатация сети, происхождение BGP-маршрута, регистрация реестра как организации и применимое право не обязательно совпадают. Изученные документы подтверждают разделимость и изменения институциональных границ, а не частоту многомерных расхождений; нерешённым остаётся вопрос, были ли исключительные границы обслуживания оптимальными, оспоримыми или репрезентативными.

9 декабря 2002 года: сорок три сети-кандидата поступают на проверку перед передачей

9 декабря 2002 года четыре региональные интернет-регистратуры начали работу перед передачей по тестовой выборке из 43 сетей-кандидатов внутри129.0.0.0/8. Записи возникли в ранних регистрационных механизмах, которые позже унаследовала Американская регистратура интернет-номеров, а держатели ресурсов рассматривались как кандидаты на обслуживание со стороны Сетевого координационного центра RIPE.

Опубликованная процедурапроекта Early Registration Transferразделяла несколько этапов. Подготовка перед передачей началась 9 декабря. Уведомления контактов планировались на 11 декабря. Передача базы данных была запланирована на 10 января 2003 года, при этом разрешение конфликтов могло продолжаться и позже. Объявление носило перспективный характер, поэтому оно не подтверждает ни окончательное завершение всех 43 кандидатов, ни завершённое перемещение в декабре 2002 года.

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

Содержащий/8оставался блоком, где «преобладает ARIN». Проект касался отдельных регистраций, а не переклассификации всего диапазона как европейского. Это была задача ретроспективного исправления: глобально уникальные номера были зарегистрированы до того, как более поздняя региональная система предложила для них устоявшееся административное назначение.

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

Административное исправление имело операционные последствия. Контакты реестра, полномочия на обслуживание, обратное делегирование, документация и будущие запросы зависели от ответственного института. Вместе с тем запланированная передача базы данных отличалась от физического развёртывания и распространения маршрутов. Запись реестра могла переместиться, тогда как связанное оборудование и маршрутные договорённости оставались прежними.

Таким образом, ERX показывает региональную систему в зрелом состоянии. В 1989 году не существовало карты из пяти регистратур, по которой унаследованную запись можно было бы счесть ошибочно размещённой. К 2002 году региональное деление устоялось достаточно, чтобы четыре регистратуры рассматривали историческое размещение как исправимую аномалию. География стала одновременно проспективной, направляя новое делегирование, и ретроспективной, реорганизуя записи, созданные до появления карты.

У протокола адреса появились раньше, чем у администрирования — континенты

Интернет-протокол предложил общую архитектуру адресации до того, как администрирование номеров обрело региональные границы обслуживания.RFC 791, опубликованный в сентябре 1981 года, определил 32-битные адреса источника и назначения в заголовке интернет-пакета. Его классовые форматы делили биты между сетевой и локальной частями. Они не содержали поля для Европы, Северной Америки, Африки, Латинской Америки или Азиатско-Тихоокеанского региона.

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

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

К августу 1990 годаRFC 1174описывал две центральные функции. Функцию IANA — Администрации адресного пространства Интернета — выполнял Институт информационных наук Университета Южной Калифорнии. Функцию Интернет-реестра выполнял SRI International в Сетевом информационном центре DDN. IANA выделяла идентификаторы и могла делегировать ответственность; Интернет-реестр собирал и поддерживал регистрационную информацию.

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

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

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

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

RFC 1174 предложил распределение, сохранив центр

RFC 1174 был информационным RFC, опубликованным в августе 1990 года. Он фиксировал официальную точку зрения Совета по архитектуре Интернета, а не стандарт Интернета. Его рекомендации были адресованы Федеральному совету по сетям США через спонсорские и технико-управленческие механизмы того периода.

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

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

Ожидалось, что Координационный комитет по межконтинентальным исследовательским сетям будет одобрять организации, способные получать блоки и дальнейшие полномочия на назначение. Реестры-кандидаты должны были встретиться с IANA и Интернет-реестром и документировать свои операционные процедуры. Таким образом, делегирование зависело от институциональной пригодности, координации и определённого процесса, а не только от местоположения.

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

Документ останавливался далеко от позднейшей схемы из пяти регионов. Он не проводил постоянных континентальных границ и не называл ни одну из организаций, которые впоследствии станут ARIN, LACNIC или AFRINIC. Рекомендация о распределении сама по себе не была действующим реестром, делегированием блока или решением о признании.

RFC 1174 также рассматривал регистрацию и связность отдельно. Его приложение о статусе подключения рекомендовало убрать из регистрационных записей простой статус «подключено» и вместо этого фиксировать политики допустимого использования и транзита. Для сетей за пределами США критерии доступа Соединённых Штатов имели значение только там, где трафик использовал сети, финансируемые на федеральном уровне. Регистрация сама по себе не гарантировала, что сеть маршрутизируется, публично достижима или имеет право использовать конкретный транзитный путь.

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

Реализация шла через конкретные сообщества. Европейские сетевые операторы начали встречаться в рамках RIPE в 1989 году, но координационное сообщество ещё не было действующим реестром. Позднейшее учреждение RIPE NCC, делегирование, механизмы перенаправления, регистрация юридического лица и операционная независимость давали разные части региональной структуры.

RFC 1466 нарисовал оговорённый географический план

К маю 1993 годаRFC 1466предложил более явную географическую конструкцию. Информационный RFC, автором которого была Элиз Герих из Merit Network, заменил RFC 1366 и позже был заменён RFC 2050. В нём сообщалось о рассмотрении Федеральной группой инженерного планирования от имени Федерального совета по сетям, сопредседателями Межконтинентальной группы инженерного планирования и RIPE при общем консенсусе этих групп.

RFC 1466 связывал региональное обслуживание с меняющейся популяцией Интернета. Реестры, работающие в разных географических зонах, могли учитывать местные языки и обычаи. От регионального реестра-кандидата ожидались признание среди сетевых провайдеров и абонентов, положение за пределами собственно реестровой функции и ресурсы, достаточные для стабильного, своевременного и надёжного обслуживания. Он также должен был следовать руководствам IANA и Интернет-реестра и координировать практики субвыделения.

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

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

Адресный план содержал аналогичные оговорки. RFC 1466 делил диапазон от192.0.0.0до207.255.255.255на восемь равных диапазонов/7. Каждый/7включал 131 072 прежних сетевых единиц класса C/24, что эквивалентно 33 554 432 отдельным адресам IPv4. Четыре зоны, названные в документе, былиЕвропа, Северная Америка, Тихоокеанский регион и Южная и Центральная Америка.

Обозначение в RFC 1466Диапазон адресовРазмер
Многорегиональный192.0.0.0193.255.255.255Один/7: 131 072 единицы/24, или 33 554 432 адреса IPv4
Европа194.0.0.0195.255.255.255Один/7: 131 072 единицы/24, или 33 554 432 адреса IPv4
Прочие196.0.0.0197.255.255.255Один/7: 131 072 единицы/24, или 33 554 432 адреса IPv4
Северная Америка198.0.0.0199.255.255.255Один/7: 131 072 единицы/24, или 33 554 432 адреса IPv4
Южная и Центральная Америка200.0.0.0201.255.255.255Один/7: 131 072 единицы/24, или 33 554 432 адреса IPv4
Тихоокеанский регион202.0.0.0203.255.255.255Один/7: 131 072 единицы/24, или 33 554 432 адреса IPv4
Прочие204.0.0.0205.255.255.255Один/7: 131 072 единицы/24, или 33 554 432 адреса IPv4
Прочие206.0.0.0207.255.255.255Один/7: 131 072 единицы/24, или 33 554 432 адреса IPv4

Это не была современная карта пяти RIR. Африка не имела отдельной зоны выделения. Ни Ближний Восток, ни Центральная Азия не появлялись как самостоятельная категория. Три диапазона были помечены какПрочие, аМногорегиональныйохватывал более ранние назначения. План оставлял место для унаследованных записей и регионов без назначенного реестра.

Географическое деление также применялось неравномерно по адресному инвентарю. RFC 1466 сохранял центральный контроль над пространством класса A и вводил отдельные ограничения на обращение с классом B. Его региональный план касался прежде всего прежнего инвентаря класса C, где непрерывные блоки могли поддерживать более систематические нижестоящие назначения.

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

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

Современный емуRFC 1467, опубликованный в августе 1993 года, сообщал, что RIPE NCC запросил статус регионального реестра и получил диапазон194.0.0.0195.255.255.255для европейского интернет-сообщества. RIPE NCC также администрировал193.0.0.0/8, полученный до географического плана. Интернет-реестр продолжал обслуживать регионы, не имеющие назначенного реестра.

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

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

RFC 2050 зафиксировал период трёх реестров

RFC 2050заменил RFC 1466 в ноябре 1996 года. Он был опубликован как Best Current Practice 12, или BCP 12. Его институциональное описание нужно читать в контексте того периода, а не через более позднюю карту пяти RIR.

На момент публикации RFC 2050 называл три региональные интернет-регистратуры: InterNIC для Северной Америки, RIPE NCC для Европы и APNIC для Азиатско-Тихоокеанского региона. Он также описывал обслуживание, распространявшееся на зоны вокруг этих основных регионов. ARIN, начавший работу в декабре 1997 года, не следует задним числом подставлять вместо InterNIC в описании RFC от ноября 1996 года.

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

RFC 2050 также сохранял гибкость за пределами назначенной зоны обслуживания. Интернет-провайдер, расположенный в регионе без регионального реестра, мог обратиться в любой региональный реестр. Это ещё одно доказательство того, что система того периода ещё не стала исчерпывающим набором исключительных континентальных ворот.

Выделение или назначение не давало гарантии маршрутизируемости. Провайдеры по-прежнему решали, какие маршруты принимать и распространять. Иерархическое выделение могло поддерживать агрегирование, но политика маршрутизации и топология определяли видимость.

RFC 2050 сейчас имеет статус Historic и был заменёнRFC 7020. Его текущий статус не отменяет его исторической ценности. Он фиксирует, как адресное администрирование описывало себя в ноябре 1996 года: три региональных института, неполное географическое замыкание, иерархия родительских реестров и операционное различие между регистрацией и маршрутизацией.

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

Пять институтов обрели полномочия в разные даты

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

ДатаСобытиеЧто устанавливает дата
1989Европейские сетевые операторы начали встречи RIPEСуществовало региональное координационное сообщество.
Апрель 1992RIPE NCC был официально учреждён в АмстердамеБыл создан укомплектованный координационный центр.
1 мая 1992RIPE NCC действовал как делегированный реестрНачалось делегированное реестровое обслуживание.
1 августа 1992Интернет-реестр начал пересылать все европейские заявки в RIPE NCCЕвропейское перенаправление стало систематическим.
Сентябрь 1993Пилотный проект APNIC начал работать в ТокиоДействовал региональный эксперимент по обслуживанию Азиатско-Тихоокеанского региона.
10 января 1994Исторические записи о делегировании датируют получение APNIC эквивалентного блока202/7APNIC имел региональный адресный инвентарь для администрирования.
Апрель 1994Ретроспективная история APNIC относит публичное признание его статуса к этому месяцуСообщение о признании отличается от январской записи о делегировании.
1996APNIC Ltd была зарегистрирована на Сейшельских ОстровахСейшельская структура составляла часть институциональной конструкции APNIC.
18 апреля 1997Были оформлены первоначальные учредительные документы ARIN в ВирджинииДатированные документы существовали; сами по себе они не устанавливают дату подачи в штате или дату юридического образования.
12 ноября 1997Были депонированы документы нидерландской ассоциации RIPE NCCРегистрационная документация была завершена до операционной передачи.
Декабрь 1997ARIN начал работать как независимый реестрСевероамериканское регистрационное обслуживание операционно отделилось от InterNIC.
1 января 1998Новая ассоциация RIPE NCC приняла деятельностьНезависимое институциональное функционирование последовало за регистрацией.
Август 1998APNIC завершил операционный переезд в Брисбен через более позднюю австралийскую корпоративную структуруОбслуживание переместилось из Японии в Австралию без слияния APNIC Ltd и APNIC Pty Ltd в одну организацию.
23 августа 1999Представители шести региональных организаций подписали учредительное соглашение LACNICИнститут Латинской Америки и Карибского бассейна был создан до признания.
18 октября 1999Был подписан первый меморандум ASO между ICANN и RIRAPNIC, ARIN и RIPE NCC вступили в формальные консультативные отношения по политике с ICANN.
4 июня 2001ICANN принял ICP-2Были приняты критерии признания новых RIR.
Июль и октябрь 2001ARIN и LACNIC согласовали детали перехода, а затем зону обслуживанияДвусторонняя граница и переход обслуживания оформились до одобрения.
Ноябрь 2001Сотрудники LACNIC присоединились к анализу соответствующих заявок ARINОперационная подготовка предшествовала прямому обслуживанию.
14 марта 2002LACNIC получил предварительное одобрениеПредварительное признание предшествовало началу обслуживания и окончательному признанию.
30 июля 2002LACNIC начал прямое регистрационное обслуживание под наблюдением ARINОперационная ответственность началась в наблюдаемой форме.
30 октября 2002LACNIC подписал документ о присоединении к ASOПрисоединение было подписано до вступления в силу.
31 октября 2002Присоединение LACNIC к ASO вступило в силу, и ICANN предоставил окончательное признаниеЧленство в координации и признание совпали в эту дату, не став одним юридическим актом.
11 ноября 2002ARIN и LACNIC подписали документы о передачеДокументы предшествовали фактической передаче.
18 ноября 2002Передача полномочий от ARIN к LACNIC вступила в силуСогласованная передача обслуживания стала действующей.
24 октября 2003APNIC, ARIN, LACNIC и RIPE NCC подписали меморандум NROЧетыре RIR создали коллективный координационный механизм.
2004AFRINIC зарегистрирован на МаврикииБудущий африканский реестр получил институциональный дом до передачи обслуживания и окончательного признания.
30 сентября 2004ICANN предварительно признал AFRINICПредварительное признание предшествовало операционной передаче.
21 октября 2004ICANN и NRO подписали новый меморандум ASONRO принял роль ASO, а соглашение касалось определения зон обслуживания.
21 февраля 2005APNIC, ARIN и RIPE NCC передали AFRINIC обслуживание африканского регионаAFRINIC стал операционно ответственным по всей своей зоне обслуживания.
8 апреля 2005ICANN предоставил AFRINIC окончательное признаниеПятая RIR получила окончательное институциональное признание.
25 апреля 2005AFRINIC и NRO подписали соответствующий документ о членствеДатированный документ формализовал отношения.
27 апреля 2005История ASO фиксирует, что AFRINIC стал пятым членом NROЗафиксированное членство последовало за датой документа.

Последовательность RIPE NCC показывает, почему одна годовщина не может нести всю институциональную историю. Встречи RIPE создали сообщество в 1989 году. Формальное учреждение последовало в апреле 1992 года. Деятельность в качестве делегированного реестра документирована с 1 мая, а пересылка Интернет-реестром всех европейских заявок началась 1 августа. Документы нидерландской ассоциации были депонированы 12 ноября 1997 года, тогда как деятельность ассоциация приняла 1 января 1998 года.

История APNIC столь же многослойна. Его токийский пилот начался в сентябре 1993 года и завершился с 27 членами из 12 экономик. Эквивалентное делегирование202/7датировано 10 января 1994 года, тогда как ретроспективная институциональная история описывает публичное признание в апреле. Обе записи можно сохранить, поскольку они относятся к разным документальным стадиям.

Корпоративная история требует особой осторожности. APNIC Ltd на Сейшельских Островах, зарегистрированная в 1996 году, отличалась от APNIC Pty Ltd в Австралии. Годовой отчёт за 1998 год фиксирует более позднюю австралийскую структуру и завершение операционного переезда в Брисбен в августе 1998 года. Изученные здесь документы поддерживают это разделение и передачу обслуживания, но не дают оснований приписывать каждое более раннее соглашение или обязательство по обслуживанию членов структуре, для которой соответствующий документ не предоставлен.

Первоначальные учредительные документы ARIN несут дату 18 апреля 1997 года и были изменены в июне и августе. Датированный документ доказывает оформление учредительных документов, тогда как для установления точной даты юридического образования потребовались бы подача в штате или действующая запись.Институциональная история ARINотносит начало его независимой работы к декабрю 1997 года.Архив учредительных документови история работы, таким образом, отвечают на разные вопросы.

Хронология LACNIC необычно подробна. Егогодовой отчёт за 2002 годописывает соглашения о переходе июля и октября 2001 года и участие LACNIC в анализе соответствующих заявок ARIN с ноября. Предварительное одобрение 14 марта 2002 года предшествовало прямому обслуживанию 30 июля. Документ о присоединении к ASO был подписан 30 октября и вступил в силу 31 октября — в день окончательного признания. Документы о передаче последовали 11 ноября и вступили в силу 18 ноября.

AFRINIC аналогично отделял институциональное формирование от региональной работы. Регистрация на Маврикии, предварительное признание 30 сентября 2004 года, передача обслуживания 21 февраля 2005 года, окончательное признание 8 апреля, документ NRO от 25 апреля и членство, зафиксированное 27 апреля, были связанными вехами, а не взаимозаменяемыми ярлыками.

Первая хронология ASO содержит меньшее документальное расхождение, которое стоит сохранить. Меморандум 1999 года указывает, что он был подписан 18 октября, тогда как более поздняя история ASO относит формальное учреждение к 19 октября. Дата документа и ретроспективная годовщина могут сосуществовать как разные утверждения.

Вместе эти вехи объясняют, как административная география стала долговечной. Сообщества организовывались; сотрудники обрабатывали запросы; адресные блоки делегировались; перенаправления становились рутиной; корпорации принимали обязанности; действующие реестры согласовывали передачу; ICANN признавал новые реестры; документы ASO или NRO связывали их с глобальной координацией. Ни одно событие не выполняло все эти функции.

Свидетельства о сервисной мощности и механизмах маршрутизации

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

Документ RIPE от мая 1992 года сообщал о более чем 60 организациях-участниках и более чем 170 000 достижимых компьютеров в Европе. Это были периодические институциональные и хостовые показатели достижимости, а не число заявителей, выделений, пользователей или независимо подтверждённых результатов обслуживания. Тем не менее они показывают масштаб координационной среды вокруг нового центра.

Участники RIPE документировали европейское использование адресов до того, как NCC начал распределять пространство. С мая 1992 года он действовал как делегированный реестр, а с августа все европейские заявки пересылались ему. Последовательность демонстрирует действующий региональный приём запросов, опирающийся на устоявшееся техническое сообщество.

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

Тот же отчёт описывал переведённые материалы, документацию для членов, обучение и усилия по повышению предсказуемости обработки запросов. Эти действия соответствовали обоснованиям, выраженным в RFC 1466: коммуникация на разных языках, знания персонала и более тесные связи с региональными операторами. Национальные интернет-реестры и другие субрегиональные механизмы добавляли локальные интерфейсы внутри более широкой зоны обслуживания Азиатско-Тихоокеанского региона.

Свидетельства о маршрутизации дают более твёрдый рассказ о механизме. В январе 1992 года контекст таблицы маршрутизации без маршрута по умолчанию или NSFNET, описанный вRFC 1519, содержал около 4 700 маршрутов. Исторический ряд 1988–1991 годов примерно удваивался каждые десять месяцев. К декабрю 1992 года значение таблицы составляло 8 561, что разумно описывать как около 8 500 маршрутов.

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

Более поздний обзор вRFC 4632, использующий наблюдения по март 2005 года, связывал резкое сокращение числа записей таблицы маршрутизации в 1994 году с развёртыванием провайдерами BGP-4 и агрегированием суперсетевых блоков CIDR. Затем рост стал примерно линейным с середины 1994 до начала 1999 года, после чего вновь ускорился из-за мультихоминга и управления трафиком, порождавших более специфичные маршруты.

Эта история поддерживает цепочку вклада, а не единый эффект географического подхода. Региональное и провайдерское делегирование помогало создавать агрегируемые блоки. BGP-4 и практика провайдеров превращали часть этих блоков в агрегированные анонсы. Более поздние операционные требования ограничивали сокращение.

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

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

Три институциональных пограничных случая

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

ERX и унаследованное хранение

Тест129.0.0.0/8возник потому, что ранние регистрации накопились до появления более поздней карты обслуживания. ARIN унаследовал записи от центральных механизмов, даже если сети-кандидаты были связаны с регионом, который обслуживает RIPE NCC.

9 декабря 2002 года регистратуры начали работу перед передачей по 43 кандидатам. Они планировали уведомления контактов на 11 декабря и передачу базы данных на 10 января 2003 года. Конфликты записей и вопросы подтверждающих документов могли решаться и позже. Объявление не даёт окончательного числа завершённых кандидатов, поэтому выборка является набором перед передачей, а не проверенным итогом завершения.

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

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

Институциональный переезд APNIC

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

Годовой отчёт за 1998 год отличает APNIC Ltd на Сейшельских Островах от APNIC Pty Ltd в Австралии. Он фиксирует завершение операционного переезда в Брисбен в августе 1998 года без перерыва в обычном обслуживании. Две корпоративные структуры и перемещение операций поэтому должны оставаться раздельными в истории.

Этот случай устанавливает институциональную разделимость. Регион обслуживания Азиатско-Тихоокеанского региона сохранялся, пока секретариат перемещался из Японии в Австралию и менялась корпоративная структура. Свидетельства не прослеживают ресурсы названного члена через юридический адрес, физическое развёртывание, происхождение BGP и регулирующий контракт. Эти измерения на уровне держателя ресурсов неизвестны, а не доказанно не совпадают.

Национальные интернет-реестры добавляли ещё один административный слой. Они могли предоставлять национальные или языковые интерфейсы внутри более крупного региона APNIC. Многонациональные провайдеры представляли иную организационную проблему. APNIC экспериментировал с конфедеративными механизмами, позволявшими крупным провайдерам поддерживать отдельные пулы выделения, а институциональная история фиксирует финансовые и административные опасения, приведшие к приостановке новых конфедераций интернет-провайдеров в 1998 году.

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

Переход Африки к AFRINIC

Изначально Африка не имела единого регионального реестра. К 2001 годуICP-2описывал обслуживание, разделённое между ARIN и RIPE NCC, а APNIC также обслуживал часть региона во время более позднего перехода. Административное покрытие пересекало институциональные границы до того, как AFRINIC принял региональную роль.

AFRINIC зарегистрирован на Маврикии в 2004 году. Егоисторический обзорразмещает технические операции в Южной Африке, резервное копирование и аварийное восстановление в Египте, а координацию обучения в Гане. Эти факты описывают распределённые институциональные операции реестра, а не расположение каждой сети-члена.

Предварительное признание пришло 30 сентября 2004 года. 21 февраля 2005 года APNIC, ARIN и RIPE NCC передали AFRINIC обслуживание африканского региона. ICANN описывал AFRINIC как полностью работоспособный на этом этапе, тогда как окончательное признание последовало 8 апреля. Документ NRO и зафиксированное членство появились позже в апреле.

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

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

Заявка AFRINIC включала план перехода, устав, механизмы финансирования и доказательства поддержки. Действующие RIR рекомендовали признание, а ICANN оценивал соответствие. Эти записи устанавливают структурированный институциональный процесс. Они оставляют открытым, в какой степени исключительные границы обслуживания представляли каждого затронутого оператора или учитывали возражения в отдельных случаях.

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

Признание превратило практику в долговечную систему границ

ICP-2 преобразовал более раннюю региональную практику в более явную рамку признания. APNIC, ARIN и RIPE NCC разработали критерии в ответ на ICANN. Адресный совет ASO рекомендовал их, а совет директоров ICANN принял их 4 июня 2001 года.

Меморандум ASO 2004 года цитирует ICP-2 как опубликованный ICANN 7 июля 2001 года. Текущий URL ICANN является более поздним хостом текста 2001 года, несмотря на дату, встроенную в путь. Принятие, цитируемая публикация и более поздний хостинг — документальные стадии, а не конкурирующие версии базовой рамки.

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

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

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

Процесс отбора шёл через несколько кругов. Действующие RIR разрабатывали рамку. Адресный совет ASO рекомендовал её. Сообщества заявителей собирали доказательства поддержки. Действующие реестры согласовывали переходы, а ICANN выдавал предварительное или окончательное признание. Зона обслуживания LACNIC возникла через соглашение с ARIN; переход AFRINIC включал три действующих реестра и рекомендацию NRO.

Изученные здесь документы касаются управления ресурсами интернет-номеров, регистрационных услуг, координации и признания. Они не претендуют на то, чтобы сделать RIR правительством своей зоны обслуживания или установить всеобъемлющий режим собственности или коллизионного права. Проверка поддержки в ICP-2 была сосредоточена на LIR и интернет-провайдерах, а не на национальных электоратах.

Меморандум ASO между ICANN и NRO 2004 годасделал картографическую роль реестровой системы явной. Он предусматривал, что регионы, обслуживаемые каждым RIR, будут определяться RIR по их собственному выбору, а NRO обеспечит покрытие всех возможных зон обслуживания.

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

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

Альтернативы, которые вытеснила география

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

Функциональная модель разделила бы обязанности между специализированными органами. Один институт мог выделять пространство IPv4, другой — назначать номера автономных систем, третий — вести регистрационные данные, а четвёртый — управлять обратным делегированием или аудитами использования. Раннее администрирование уже отделяло выделение IANA от ведения записей Интернет-реестра, тогда как провайдеры и местные реестры занимались нижестоящими назначениями.

Такая специализация могла концентрировать экспертизу. Её главной трудностью была бы координация между зависимыми функциями. Заявителю могли понадобиться адреса, номер автономной системы, обратный DNS и аутентификация записей от нескольких органов. Исправления и апелляции требовали бы ясного правила приоритета, а уникальность по-прежнему зависела бы от общего авторитетного представления.

Язык давал второй организующий принцип. RFC 1466 прямо ссылался на язык как на обоснование регионального обслуживания. Испаноязычные операторы в Европе и Америке, арабоязычные операторы в Африке и на Ближнем Востоке или англоязычные операторы в нескольких регионах могли бы выиграть от сервисной службы, построенной вокруг коммуникации, а не континентов.

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

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

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

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

Несколько исторических конструкций указывали в этом направлении. RFC 1174 предлагал делегированные реестры с центральными агрегированными записями. RFC 1466 сохранял прямое обслуживание Интернет-реестра и перенаправления. RFC 2050 описывал местные реестры, назначения провайдеров, региональные реестры и апелляции к родительским реестрам. ERX показал, что регистрационная информация и обратное делегирование могли по крайней мере войти в процесс передачи между регистратурами.

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

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

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

Зависимость от пройденного пути сделала региональную карту дорогой для замены

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

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

Корпоративные структуры добавляли обязательства в сфере занятости, налогообложения, закупок, банковского обслуживания, ответственности и контрактов. RIPE NCC действовал через свою нидерландскую ассоциацию. ARIN стал независимым институтом из Вирджинии. Сейшельская и австралийская структуры APNIC составляли отдельные части его корпоративного перехода. LACNIC развивал свою региональную институциональную базу, а AFRINIC зарегистрировался на Маврикии.

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

Документы о признании добавляли ещё один слой непрерывности. APNIC, ARIN и RIPE NCC подписали первый меморандум ASO в октябре 1999 года. APNIC, ARIN, LACNIC и RIPE NCC создали NRO черезмеморандум от 24 октября 2003 года. Меморандум ASO 2004 года поставил NRO в роль ASO, а AFRINIC присоединился после признания через свой документ от апреля 2005 года и членство.

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

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

Адресный инвентарь вносил собственную инерцию. RFC 1466 связывал определённые диапазоны/7с географическими зонами, сохраняя пространствоМногорегиональныйиПрочие. Более поздние выделения IANA продолжали иерархическую блочную структуру. Префикс, таким образом, мог нести административную родословную, не раскрывая своё текущее развёртывание или происхождение маршрута.

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

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

Регистрация, маршрутизация, юрисдикция и собственность остаются раздельными

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

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

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

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

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

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

География стала инфраструктурой

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

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

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