Ограничение в 32 бита было техническим, а режим нормирования — политическим

Резюме

• RFC 791зафиксировал каждый исходный и целевой адрес IPv4 в 32 битах и первоначально интерпретировал обычные одноадресные адреса через три класса; он не предписывал региональные регистратуры, прогнозы спроса, тесты использования, зависимость от провайдеров, аудиты, санкции или апелляции.
• Номинальные (2^{32}), то есть 4 294 967 296, возможных 32-битных значений никогда не были единым пулом назначаемых публичных адресов хостов. Классовая структура, специальные значения, резервирования, удерживаемые распределения, видимость маршрутизации и фактическое использование создавали разные знаменатели, которые нельзя объединять.
• С 1993 по 1996 год опубликованные руководства выбирали значимые правила: 24-месячные прогнозы и пороги класса B в RFC 1466; агрегация на основе топологии в RFC 1519; и медленный старт выделений, иерархия провайдеров, тесты использования, аудиты, возврат адресов и апелляции к вышестоящей регистратуре в RFC 2050.
• Экономия и агрегация отвечали на реальные инженерные опасности, особенно на расточительное использование классов и рост таблиц маршрутизации. Политический элемент заключался не в изобретении дефицита, а в том, что идентифицируемые институты выбирали среди осуществимых способов распределения издержек, полномочий, исключений и средств защиты.
• Публичные записи о распределении показывают успешные результаты, а не запросы, отказы, пересмотры, задержки или неформальные указания, которые их породили. Текст и техническое обоснование режима можно реконструировать с большей уверенностью, чем его полный распределительный эффект.

Архитектура задала границу; администрирование выбрало критерий

Два датированных документа устанавливают это ключевое различие.

В сентябре 1981 года RFC 791 определил поле «Адрес источника» и поле «Адрес назначения», каждое шириной 32 бита. Он определил интернет-адрес как четыре октета и разделил его первоначальную обычную одноадресную интерпретацию между форматами класса A, класса B и класса C. Адрес класса A использовал один бит идентификации класса, семь битов номера сети и 24 бита локального адреса. Класс B использовал два бита класса, 14 битов номера сети и 16 битов локального адреса. Класс C использовал три бита класса, 21 бит номера сети и восемь битов локального адреса. Это были протокольные свойства, указанные в обсуждении адресации и спецификации заголовка.RFC 791, сентябрь 1981 года, разделы 2.3 и 3.1, страницы 7 и 11–12

В мае 1993 года RFC 1466 рекомендовал, чтобы регистратура выделяла смежные гранты класса C исходя из прогноза требуемых адресов конечных систем подписчика на следующие 24 месяца. Прогноз ниже 256 адресов соответствовал одному номеру сети класса C; ниже 512 — двум; ниже 1 024 — четырём; и так далее, до 64 смежных номеров сетей класса C для прогноза ниже 16 384. Для класса B в документе говорилось, что заявитель должен показать более 32 подсетейиболее 4 096 хостов, подкреплённых инженерным планом на следующие 24 месяца.RFC 1466, май 1993 года, разделы 4.2.1 и 4.3, страницы 6–8

RFC 1466 был информационным. Его уведомление о статусе прямо говорило, что документ не задаёт стандарт интернета. Автором была Elise Gerich; в аннотации отмечалась общая поддержка рекомендаций со стороны Federal Engineering Planning Group, действовавшей от имени Federal Networking Council, сопредседателей Intercontinental Engineering Planning Group и RIPE. Это сочетание свидетельствует об авторской рекомендации с институциональной поддержкой. Оно не доказывает, что каждая регистратура немедленно внедрила каждый порог, что акт стандартизации IETF сделал политику обязательной или что все затронутые сети с ней согласились.RFC 1466, статус, аннотация и благодарности, страницы 1 и 9

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

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

Одно адресное пространство породило несколько несовместимых знаменателей

Знакомая арифметика точна:

[2^{32}=4 294 967 296]

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

Биты класса немедленно делили это математическое пространство. Поле номера сети класса A содержало (2^7=128) битовых комбинаций; класс B содержал (2^{14}=16 384); класс C содержал (2^{21}=2 097 152). Административный учёт не рассматривал каждую сырую комбинацию как обычный номер сети. Таблица RFC 1466 за май 1992 года вместо этого насчитывала 126 сетей класса A, 16 383 класса B и 2 097 151 класса C. Эти цифры — популяции номеров сетей классовой схемы, а не значения адресов или организации.

В таблице также зафиксировано 49 выделенных номеров сетей класса A, 7 354 выделенных номера класса B и 44 014 выделенных номеров класса C по состоянию на май 1992 года. Это успешные записи в конкретной административной таблице. Они не раскрывают ни число заявителей, ни то, сколько адресов было занято, анонсировано, достижимо или запрошено.RFC 1466, раздел 3, таблица 1, страница 3

Обоснованная проверка знаменателей, таким образом, разделяет следующие популяции.

Эти различия — не семантическая придирчивость. Каждая строка отвечает на другой вопрос. Распределение верхнего уровня уменьшает один административный пул, не показывая, что выделенное пространство анонсировано. Маршрут может покрывать большой блок с немногими занятыми конечными точками. Несколько маршрутов могут представлять одно распределение. Назначение может оставаться неиспользованным, тогда как один хост может иметь несколько адресов или интерфейсов. Сам RFC 791 предусматривал хосты с несколькими физическими интерфейсами и несколькими логическими интернет-адресами.

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

Обычная конвенция идентификаторов хостов того периода создавала ещё одну популяцию. RFC 1519 описывал сеть класса C как поддерживающую не более (2^8−2=254) обычных идентификаторов хостов, а класс B — не более (2^{16}−2=65 534), после исключения всех нулевых и всех единичных локальных значений, используемых в цитируемой конвенции. Это потенциальные обычные идентификаторы внутри одной сети, а не число подключённых хостов.RFC 1519, Предлагаемый стандарт, сентябрь 1993 года, раздел 1, страницы 1–2

Предположим, только для масштаба, что для каждого из 600 подключённых хостов требуется один идентификатор. 65 534 обычных идентификатора класса B обеспечили бы (65 534/600=109,223) от заявленной потребности, оставив (65 534−600=64 934) обычных идентификаторов за пределами этой непосредственной потребности. Расчёт демонстрирует классовую гранулярность; он не доказывает, что реальному заявителю на 600 хостов не нужен резерв, что у него плоская топология или что он мог бы использовать произвольный бесклассовый блок.

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

Более поздние свидетельства требуют такой же осторожности. Исследование потребления IPv4 CAIDA было построено из файла IANA, собранного 14 сентября 2005 года, и снимков WHOIS, сделанных 31 августа 2005 года для ARIN, APNIC, LACNIC и RIPE. В нём отсутствовал снимок AFRINIC. CAIDA устранила различия форматов, чтобы создать общее представление, и ограничила строки каждого RIR пространством, связанным с этой регистратурой в файле IANA, уменьшая дублирующиеся появления, вызванные миграцией и перекрёстными ссылками. Она объединила мигрировавший унаследованный материал в отдельный набор «various».CAIDA, «Темпы потребления IPv4», методология и оговорки

В её цифрах использовался объём адресов, обычно выражаемый в эквивалентах/8. Они различали распределения IANA, первое нижестоящее появление в реестре и наиболее специфичное назначение, найденное в данных. CAIDA прямо говорила, что графики показывали распределения, а не анонсы или достижимость. Она также объясняла, что очистка IANA присвоила август 1993 года многим унаследованным записям, для которых точные исторические даты были недоступны. Это задним числом заполненные административные даты, а не восстановленные даты транзакций.CAIDA, методология, оговорки и рисунки 1–7

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

Работа Richter, Allman, Bush и Paxson«Основы дефицита IPv4»ещё более поздняя. Статья была подана 10 ноября 2014 года, пересмотрена 27 февраля 2015 года и опубликована как редакционный вклад вACM Computer Communication Review45(2) в апреле 2015 года. Это ценный ретроспективный синтез и источник для технических, институциональных и связанных с периодом исчерпания событий. Она не может установить, что знал действующий субъект в 1981–1998 годах, как заявитель того периода ощущал регистратуру, был ли механизм развёрнут или придерживались ли современники более поздней рыночной или имущественной доктрины.Richter et al., «Основы дефицита IPv4», публикационная запись

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

Классовое расточительство и давление на маршрутизацию были реальными

Первое непосредственное давление исходило от гранулярности. Организация, которой требовалось более 254 обычных идентификаторов хостов, не имела нативной классовой единицы распределения, пропорциональной потребности в 300, 600 или 4 000. Класс B мог быть слишком большим. Набор классов C мог быть ближе по объёму адресов, но сложнее в управлении и, до эффективной агрегации, дороже для глобальной системы маршрутизации.

Подсети помогали внутри существующей классовой сети. RFC 950, спецификация на пути стандартизации от августа 1985 года, определял маску адреса, которая делила поле локального адреса на части подсети и хоста. Организация могла использовать один внешне распознаваемый номер сети для нескольких внутренних подсетей, а не анонсировать каждый внутренний кабель как независимую сеть. Сам по себе он не позволял регистратуре выдавать произвольные глобально маршрутизируемые длины префиксов интернету, чьи междоменные механизмы всё ещё полагались на классовую интерпретацию.RFC 950, август 1985 года, раздел 2.1, страницы 4–6

Вторым давлением была таблица пересылки. Замена одного прежнего выделения класса B на 16 отдельно анонсируемых сетей класса C могла сохранить номер сети класса B, добавив 16 записей маршрутизации там, где агрегация была недоступна. Экономия адресов и экономия маршрутизации могли, таким образом, указывать в противоположные стороны.

RFC 1519, опубликованный как Предлагаемый стандарт в сентябре 1993 года, описывал три проблемы: быстрое истощение номеров сетей класса B, рост таблиц маршрутизации за пределы возможностей доступного программного обеспечения и маршрутизаторов и возможное исчерпание 32-битного пространства. Его непосредственной стратегией был CIDR: выдавать блоки более подходящего размера и смежности, выравнивать распределение по топологии и анонсировать агрегаты, когда поддержка протоколов и связанность это позволяли.RFC 1519, статус и разделы 1–3, страницы 1–9

Его количественная аргументация требует как точной таблицы, так и округлённого текста.

Таблица I, источником которой указан MERIT, зафиксировала 4 526 анонсируемых маршрутов в январе 1992 года и 8 561 в декабре 1992 года. Раздел 3.3.2 вместо этого описывал январскую базу маршрутизации NSFNET как содержащую «примерно 4 700» записей, а декабрьскую таблицу — как содержащую 8 500. В нём говорилось, что историческая таблица в среднем удваивалась каждые десять месяцев в период с 1988 по 1991 год, и публиковался прогноз примерно 30 000 записей через два года после январского базового уровня 1992 года.RFC 1519, таблица I и раздел 3.3.2, страницы 7–9

Этот прогноз не следует из заявленных округлённых исходных данных:

[4 700\times 2^{24/10}=24 806,75]

Используя точное январское наблюдение из таблицы I, получаем:

[4 526\times 2^{24/10}=23 888,37]

Ни один результат не равен примерно 30 000 при обычном округлении. Статья может сохранить 30 000 только как опубликованный, несогласованный прогноз авторов RFC. Источник не объясняет расхождение примерно в 5 193 записи между 30 000 и результатом из округлённых исходных данных. Было бы некорректно изобретать другой базовый уровень, интервал роста или скрытую корректировку, чтобы закрыть разрыв.

Сравнение с декабрём проще. Наблюдаемой единицей таблицы I были 8 561 анонсируемый маршрут в декабре 1992 года. Раздел 3.3.2 округлял это до 8 500 и сравнивал с более чем 9 400, предсказанными более ранней кривой. Авторы говорили, что не могут определить, означает ли более низкое наблюдение значимое изменение роста. Это были наблюдения и прогнозы из контекста MERIT/NSFNET, а не перепись всех маршрутизаторов или физический предел, при котором интернет отказал бы.

RFC также рассматривал эффект выдачи от четырёх до 16 маршрутов класса C там, где ранее мог использоваться класс B. Он условно прогнозировал, что таблица маршрутизации может превысить 10 000 записей в течение шести месяцев и 20 000 в течение года. Это были сценарные результаты, основанные на отдельно анонсируемых сетях класса C, а не наблюдаемые исходы. Агрегация была призвана предотвратить именно такое умножение.

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

Переход не был автоматическим. RFC 1338, информационное предложение, опубликованное в июне 1992 года и позднее заменённое RFC 1519, предупреждал, что требуются как новый план адресации, так и изменения протоколов междоменной маршрутизации. В нём говорилось, что таблицы маршрутизации могут расти очень быстро в интервале между внедрением топологически ориентированных распределений и внедрением совместимых протоколов.RFC 1338, июнь 1992 года, раздел 2.1, страница 4

BGP-4 предоставил спецификацию для переноса бесклассовых префиксов и агрегации маршрутов, но статус публикации нельзя путать с развёртыванием. RFC 1654 был спецификацией BGP-4 на пути стандартизации в июле 1994 года. RFC 1771, также на пути стандартизации, заменил его в марте 1995 года и описывал поддержку IP-префиксов, удаление концепции класса сети в BGP и агрегацию маршрутов и AS-путей.RFC 1654, июль 1994 года, статус и разделы 1–2, страницы 1–2;RFC 1771, март 1995 года, статус и разделы 1–2, страницы 1–2

Эти публикации устанавливают статус спецификации и документированную возможность. Они не устанавливают, сколько маршрутизаторов работало с BGP-4 на заданную дату, какие сети обменивались бесклассовыми маршрутами, какая часть таблицы была агрегирована и было ли внедрение всеобщим к 1998 году. Без названной серии снимков маршрутизации, даты наблюдения, популяции и точки наблюдения никакое числовое утверждение о скорости развёртывания или о том, что «к 1998 году это установилось», не обосновано.

Правило прогноза распределяло неопределённость

Правило класса B из RFC 1466 наиболее ясно показывает институциональный выбор. Его заявленные критерии требовали более 32 подсетейиболее 4 096 хостов. Заявитель также должен был показать, почему блок классов C неразумен, и предоставить ожидаемые числа хостов и подсетей на следующие 24 месяца. Если план не оправдывал класс B, заявленным результатом был блок классов C. Заявитель, не прошедший числовые критерии, но не способный использовать классы C, мог представить инженерное обоснование. Документ называл пороги предложенными критериями, а не протокольной инвариантой.RFC 1466, раздел 4.2.1, страницы 6–7

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

RFC 1466 признавал бремя. В нём говорилось, что ограничения на выделение класса B могут потребовать от некоторых организаций дополнительных ресурсов для использования нескольких номеров сетей класса C. Документ считал эту цену неприятной, но необходимой для экономии. Это необычно прямое свидетельство распределения издержек: авторская рекомендация выбрала правило экономии и указала дополнительные инженерные расходы затронутых заявителей как следствие.RFC 1466, раздел 4.2, страница 6

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

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

Бесклассовое распределение было более технически обоснованной альтернативой к 1993 году, но только в пределах. RFC 1338 предложил смежные блоки провайдеров в июне 1992 года, а RFC 1519 определил стратегию назначения и агрегации CIDR в сентябре 1993 года. Их собственные предупреждения показывают требуемые допущения: регистратуры должны были выделять по подходящим границам, провайдеры — поддерживать топологически выровненные блоки, а междоменные протоколы и маршрутизаторы — поддерживать произвольные пары «сеть и маска». Прежде чем эти условия были достаточно реализованы, выдача более мелких блоков могла умножать маршруты, а не сокращать их.

RFC 2050 изменил конструкцию прогноза в ноябре 1996 года. Он отделил распределения интернет-провайдерам от назначений конечным предприятиям. Раздел 2.1 говорил, что новые интернет-провайдеры получали минимальное распределение исходя из непосредственных потребностей. Более поздние распределения могли расти после того, как провайдер предоставит проверку использования, а дополнительное пространство должно было поддерживать примерно три месяца нижестоящих назначений. Прогнозируемая клиентская база, как утверждалось, мало влияла; управляли продемонстрированные потребности.RFC 2050, BCP 12, ноябрь 1996 года, раздел 2.1, страницы 4–5

Знаменитые 25 и 50 процентов относились к другому месту. Они появились в разделе 3.1, в рамках назначений конечным предприятиям: 25 % немедленного использования и 50 % использования в течение одного года. Раздел 3.6 определял числитель как число хостов, подключённых к сети, а знаменатель — как общее возможное число хостов в этой сети. Критерий одного года, таким образом, означал, что подключённые хосты должны были достичь не менее 50 % возможной популяции хостов сети в течение этого горизонта. Это не было отношением клиентов к адресам, назначенных адресов к размеру распределения, интерфейсов к адресам или нижестоящих назначений к распределению провайдера.RFC 2050, разделы 3.1 и 3.6, страницы 7 и 9

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

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

Иерархия превратила топологию в зависимость

RFC 1466 предлагал разделить части пространства номеров формата класса C на крупные географические блоки и делегировать основную ответственность за распределение квалифицированным региональным регистратурам. Он описывал разделение как «в первую очередь административное деление», призванное поддержать распределённую регистрацию. Он отдавал предпочтение одной региональной регистратуре на этом уровне, ожидал, что организация будет признана и адекватно обеспечена ресурсами, и требовал приверженности руководствам IANA и центральной интернет-регистратуры. Центральная регистратура оставалась доступной для обслуживания подписчика при необходимости, хотя могла направить его в региональный орган.RFC 1466, разделы 2, 3 и 4.3, страницы 2–4 и 7

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

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

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

RFC 1519 сдвинул иерархию в сторону топологии провайдеров. Он рекомендовал, чтобы большинство, если не все, номера сетей распределялись через поставщиков услуг. Его инженерное обоснование было прямым: адреса, взятые из блока провайдера, могли быть представлены агрегатом провайдера, тогда как независимо расположенные блоки часто требовали более специфичных маршрутов. Документ также утверждал, что распределённое распределение снижает бюрократическое бремя на центральные органы нумерации.RFC 1519, разделы 2.2 и 3, страницы 5–8

RFC 2050 описывал трёхуровневую систему регистратур: IANA, региональные интернет-регистратуры и локальные интернет-регистратуры. В рамках провайдеров интернет-провайдер, обменивающийся маршрутами в нескольких точках без маршрута по умолчанию, мог запрашивать пространство напрямую у своей региональной регистратуры. Другим интернет-провайдерам было сказано запрашивать пространство у вышестоящего провайдера. Прямой региональный доступ связывался с мультихоумингом или подключением к крупной нейтральной точке обмена, которую RFC определял как соединяющую четырёх или более несвязанных интернет-провайдеров.RFC 2050, разделы 1.1 и 2.1, страницы 3–4

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

Издержки уже признавались. RFC 1900, информационное заявление Internet Architecture Board в феврале 1996 года, говорил, что организации, не выполнившие перенумерацию после смены провайдера, могут столкнуться с ограниченной связностью, дополнительными затратами на поддержку возникающего объёма маршрутизации или с тем и другим. Его название,«Перенумерация требует доработки», отражало состояние техники. Он призывал к разработке и внедрению механизмов, облегчающих изменения; он не сообщал, что перенумерация стала дешёвой или рутинной.RFC 1900, февраль 1996 года, раздел 1, страницы 2–3

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

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

Аудиторские полномочия существовали на бумаге; их практика остаётся неизмеренной

Третий институциональный выбор касался проверки и последствий.

RFC 1466 позволял центральной интернет-регистратуре получать учётные и инженерные планы по делегированным региональным распределениям и проверять их на соответствие руководствам. Исключения из критериев размера классов C должны были решаться в каждом случае отдельно. Документ не предусматривал реестра исключений, стандартного срока ответа, опубликованного бремени доказывания или независимого рецензента.RFC 1466, разделы 4.2.2 и 4.3, страницы 7–8

RFC 2050 описывал более обширный набор доказательств. Регистратура могла требовать маски подсетей, число хостов, топологию, планы маршрутизации, графики развёртывания, предыдущие назначения и подтверждения. Пространство, ранее находившееся у подразделений или дочерних компаний под общим родителем, могло рассматриваться на уровне предприятия. Запросы обрабатывались в каждом случае отдельно, при этом эффективность маршрутизации была среди релевантных соображений.RFC 2050, разделы 3.2–3.5, страницы 8–9

Раздел 4 утверждал, что все запросы адресов подлежат аудиту и проверке любыми средствами, которые региональная регистратура сочтёт подходящими. Если обнаруживалось, что назначение основано на ложной информации, регистратура могла аннулировать запрос и вернуть назначенные адреса в свободный пул. Раздел 3.1 отдельно утверждал, что адрес остаётся действительным, пока квалифицирующие критерии продолжают выполняться, и резервировал полномочие аннулирования, когда потребность больше не существует. Рекомендация о возврате из раздела 2.1 применялась к клиентским адресам, полученным от провайдера, когда подключение заканчивалось. Это были связанные, но разные полномочия: аннулирование за ложную информацию, проверка сохраняющейся потребности и возврат при смене провайдера.RFC 2050, разделы 2.1, 3.1 и 4, страницы 4–5, 7 и 10

Текст также предусматривал иерархическую проверку. Раздел 6 позволял организации, недовольной назначившей регистратурой, подать апелляцию в вышестоящую регистратуру. Соответствующая документация должна была быть доступна, а дальнейшая апелляция могла подниматься по цепочке до IANA. Каждая регистратура должна была документировать свой процесс апелляции. Рецензент оставался внутри той же иерархии регистратур; RFC не создавал внешнего трибунала.RFC 2050, раздел 6, страница 11

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

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

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

Запись RIPE доказывает меньше, чем досье о выделении

Эпизод RIPE даёт свидетельство делегированной работы, но не полное решение о распределении.

RIPE-062,«Процедуры регистрации интернет-номеров RIPE NCC», версия 0.5 от июля 1992 года, появился как Приложение A к первому квартальному отчёту RIPE NCC. В нём говорилось, что RIPE NCC действует с 1 мая 1992 года как делегированная регистратура европейских номеров интернет-сетей. Его процедура состояла в предоставлении номеров поставщикам услуг и национальным или локальным координационным органам, а не напрямую отдельным организациям. Он позволял поставщикам услуг запрашивать номера сетей класса B по одному и требовал обоснования на основе размера организации, существующей сети, ожидаемого роста и невозможности использовать блок класса C.RIPE-062, версия 0.5, июль 1992 года, страница 25 и далее

Раздел 3 RFC 1466 позже зафиксировал два более узких факта. RIPE NCC уже получил интервал номеров сетей класса C от 193.0.0 до 193.255.255 до принятия предложения RFC, и он согласился выделять в этом интервале по руководствам RFC 1466.RFC 1466, раздел 3, страница 3

Интервал содержит (2^{16}=65 536) номеров сетей класса C размером/24. Выраженный как более поздний CIDR-интервал 193.0.0.0/8, он покрывает (2^{32-8}=16 777 216) номинальных значений адресов. Первое число считает единицы номеров сетей класса C; второе — двоичные значения, покрываемые интервалом. Ни одно не измеряет подключённые хосты, нижестоящие выделения, анонсы, использование или объём, запрошенный RIPE NCC.

Сохранившиеся записи не содержат исходный запрос, формальный акт выделения, меморандум о решении, рассмотренные альтернативные размеры блоков, согласованные условия или точную дату выделения. RIPE-062 доказывает делегированную процедуру. RFC 1466 доказывает предшествующее владение блоком 193.* и согласие использовать новые руководства. Распределённое администрирование и потенциальная агрегация были целями окружающего политического плана; их нельзя утверждать как задокументированный мотив или согласованное условие этого конкретного выделения.

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

Технические ответы появлялись поэтапно

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

Частное пространство иллюстрирует разницу между спецификацией и заменой. RFC 1918, BCP 5 в феврале 1996 года, резервировал три блока для частных интерсетей. Он требовал, чтобы предприятие решало, каким хостам не нужна внешняя связность на сетевом уровне. Перемещение хоста между частным и публичным статусом включало изменение его IP-адреса, соответствующих записей DNS и конфигурационных файлов на других хостах, которые ссылались на этот адрес. Частная маршрутная информация не должна была распространяться через границы предприятия, а частные ссылки DNS требовали изоляции.RFC 1918, февраль 1996 года, разделы 2–5, страницы 3–7

NAT к маю 1994 года был больше, чем концепцией, но меньше, чем доказанным универсальным решением. RFC 1631 был информационным и описывал предварительный проект. Раздел 3 пояснял, что приложения, переносящие IP-адрес в своих данных, могли отказывать, если транслятор не распознавал и не переписывал содержимое; шифрование могло сделать это невозможным. Раздел 4 указывал экспериментальные реализации в программном обеспечении KA9Q и маршрутизаторе Cray Communications, протестированные с Telnet и FTP, и говорил, что прототипы демонстрировали прозрачность только в пределах ограничений, указанных в статье.RFC 1631, май 1994 года, разделы 3 и 4, страницы 6–9

IPv6 изменил архитектурный знаменатель. RFC 1883, спецификация на пути стандартизации, опубликованная в декабре 1995 года, увеличила размер IP-адреса с 32 до 128 битов. Он не заменил установленные хосты, маршрутизаторы, приложения или операционные процедуры IPv4 при публикации. Для регистратуры, обрабатывающей запрос IPv4 в 1996 году, IPv6 был заданным преемником, а не доказательством того, что непосредственная проблема распределения IPv4 исчезла.RFC 1883, декабрь 1995 года, статус и раздел 1, страницы 1 и 3

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

Улучшение оборудования оставалось условной возможностью. RFC 2050 утверждал, что ограничения адресации отражали технологию маршрутизаторов, практику назначения и архитектурную историю. Документ сообщал вывод его авторов, рецензировавшей рабочей группы IETF и IESG о том, что никакая другая развёртываемая на тот момент технология не преодолевала эти ограничения, допуская пересмотр, если маршрутизаторы позже будут обрабатывать более крупные, более динамичные таблицы или агрегация станет возможной другими средствами. Это современная институциональная оценка технологии, а не эталон каждого маршрутизатора и не доказательство того, что сопутствующие параметры прогноза, аудита и апелляций были институционально уникальны.RFC 2050, Введение, страница 2

RFC 2050 отражал практику, не получая одобрения политики

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

RFC 2050 был BCP 12, опубликован в ноябре 1996 года, авторы — Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg и Jon Postel. Его аннотация описывала политики, которые тогда использовались региональными регистратурами для реализации руководств, разработанных IANA, и говорила, что правила остаются предметом пересмотра.RFC 2050, титульная страница, аннотация и Введение, страницы 1–2

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

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

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

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

Сильнейшая инженерная защита выдерживает проверку

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

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

Бесклассовое распределение исправляло серьёзное несоответствие размеров. Выбор между 254 и 65 534 обычными идентификаторами был плохо приспособлен к сетям среднего размера. Смежные префиксы могли приближать потребность точнее, чем нативный класс B, избегая произвольного набора несвязанных классов C.

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

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

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

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

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

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

Ограниченное сравнение 1996 года определяет полномочия, а не исходы

Полезный контрфактический сценарий можно задать на ноябрь 1996 года, когда был опубликован RFC 2050. Зафиксируем 32-битные поля IPv4, установленные остатки бесклассово-способных и классовых систем того периода, доступные тогда спецификации BGP-4, ограниченные ресурсы маршрутизаторов, неопределённый спрос, дорогую перенумерацию и отсутствие немедленного всеобщего перехода на IPv6. Не будем предполагать всеобщее развёртывание BGP-4, NAT или частных адресов, потому что цитируемые спецификации не измеряют внедрение.

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

Теперь аналитически изменим три институциональных параметра.

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

Без историй запросов, ошибок прогноза и данных о назначениях ни одна величина не оценима.

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

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

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

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

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

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

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

Четыре вывода с разным уровнем уверенности

Архитектурный факт самый сильный. RFC 791 зафиксировал каждое поле источника и назначения IPv4 в 32 битах. Результатом стали (2^{32}) номинальных значений на поле, а не неограниченное пространство имён и не 4 294 967 296 назначаемых публичных хостов.

Классовые и маршрутизационные последствия также хорошо подтверждены. Большие разрывы между обычной ёмкостью хостов класса C и класса B делали выделения среднего размера неэффективными. Несколько классов C могли сэкономить номер сети класса B, добавляя маршруты. Таблица MERIT в RFC 1519 зафиксировала 4 526 анонсируемых маршрутов в январе 1992 года и 8 561 в декабре 1992 года. Её прогноз примерно 30 000 на два года не воспроизводится из заявленной формулы удвоения, но лежащая в основе озабоченность ростом маршрутов и классовой гранулярностью не зависела только от этой арифметической ошибки.

Административные решения идентифицируемы. Информационный RFC Gerich рекомендовал 24-месячные прогнозы, пороги, географические деления, аудиты и исключения для конкретных случаев. Авторы CIDR связали распределение с топологией провайдеров и бесклассовой агрегацией. Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg и Jon Postel задокументировали медленный старт, иерархию, тесты использования подключённых хостов, аудиторские полномочия, аннулирование, возврат и иерархическую апелляцию BCP 12. IANA, региональные и локальные регистратуры, провайдеры и транзитные сети занимали разные роли внедрения.

IESG принял RFC 2050 как точное отражение текущей практики, оставив одобрение политики.

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

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

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