Классовая адресация IPv4 и рождение административного дефицита

Кратко

Сети, которой требовалось 300 обычных адресов узлов, не хватало 46 адресов: практическая ёмкость одной сети класса C составляла 254 адреса. Следующий нативный класс давал 65 534 обычных адреса узлов, а две сети класса C — 508, но возможной ценой дополнительного маршрута и большей координации. Классовая геометрия поэтому превращала выделение адресов в выбор между несопоставимыми издержками, а не в простое считывание потребности в узлах.
Три среза того времени показывают: сети класса C доминировали по числу выделенных единиц «номер сети», тогда как выделения класса A доминировали по представленной адресной ёмкости. В январе 1983 года 31 выделение класса A охватывало 99,648 % числовых значений адресов в опубликованных итогах; 1 042 сети класса C — 0,051 %.
Сохранившиеся материалы не дают сопоставимой выборки ранних заявок, отказов и решений. По ним нельзя установить общий эффект первого получателя, неравный доступ заявителей или критерии конкретного раннего решения о классе. Они подтверждают более узкий вывод: устойчивые выделения, сделанные до того, как позднейшие критерии стали явными, могли создавать правдоподобное опционное преимущество, обусловленное предшествующим путём.
Дефицит адресного пространства, рост состояния маршрутизации, задача выбора размера для отдельного заявителя и ограниченное административное внимание были разными ограничениями. Они проявлялись в разное время и часто указывали на разные варианты выделения.
Несколько сетей класса C, подсети, смежные блоки и региональное делегирование были реалистичными альтернативами того периода, но каждая несла издержки маршрутизации, оборудования, координации или администрирования. Корректная контрфактическая модель не может предполагать, что бесклассовая маршрутизация была доступна на протяжении всех 1980-х годов.

Сетевой планировщик, ожидавший 300 обычных узлов, сталкивался с точным разрывом. Одна сеть класса C содержала 256 возможных значений в своём восьмибитном поле локального адреса. С учётом позднее уточнённых ограничений на значения узлов из всех нулей и всех единиц она давала 254 обычных адреса узлов. Таким образом, требование превышало одну сеть класса C на 46 адресов, а не на два. Число два описывает разницу между 256 числовыми значениями и 254 обычными адресами узлов; оно не описывает нехватку относительно плана на 300 узлов.

Две сети класса C могли покрыть непосредственную потребность, обеспечив 508 обычных адресов узлов. Но они оставались двумя классовыми сетями: потенциально требовались две видимые вовне записи маршрутизации, две регистрации и дополнительная локальная координация. Следующий нативный класс, класс B, давал 65 536 числовых значений локальных адресов, то есть 65 534 обычных адреса узлов. Это примерно в 258,008 раза больше практической ёмкости сети класса C и более чем в 218 раз больше заявленной потребности в 300 узлов.

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

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

Геометрия создала границу принятия решений

RFC 791, опубликованный в сентябре 1981 года, определил интернет-адрес как четыре октета, то есть 32 бита. Его старшие биты выбирали один из трёх обычных форматов адреса и тем самым фиксировали разделение между номером сети и локальным адресом.

Класс того времени	Шаблон старших битов	Битов номера сети после шаблона	Битов локального адреса	Числовых значений в одной сети	Обычных адресов узлов по позднейшим уточнённым правилам	Современное обозначение
Класс A	`0`	7	24	16 777 216	16 777 214	/8
Класс B	`10`	14	16	65 536	65 534	/16
Класс C	`110`	21	8	256	254	/24

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

Отношение числовой ёмкости от одного класса к следующему составляло ровно 256. Класс A содержал (2^{24}) значений локальных адресов, класс B — (2^{16}), класс C — (2^8). После исключения обычных значений узлов из всех нулей и всех единиц практические отношения становились немного больше:

(16,777,214 / 65,534 = 256.007782) ёмкостей класса B в одном классе A.
(65,534 / 254 = 258.007874) ёмкостей класса C в одном классе B.

Исключения нужно датировать. RFC 791 установил классовую геометрию, но не публиковал современную таблицу пригодных для использования узлов.RFC 950, выпущенный в 1985 году, разъяснил особые значения полей из нулей и из всех единиц в контексте подсетей и широковещательных адресов.RFC 1122в 1989 году указал, что поля узла, сети и подсети не могут принимать значения из всех нулей или всех единиц, кроме определённых особых случаев.

Для сравнения выделений наименее зависимой от допущений мерой служат полные числовые значения: (2^{24}), (2^{16}) или (2^8) на сеть. Для реконструкции задачи заявителя об обычной ёмкости узлов по позднейшим уточнённым правилам подходят знакомые цифры «минус два». Смешение этих двух мер даёт вводящие в заблуждение утверждения, как показывает пример с 300 узлами.

Шаблоны старших битов делили всё 32-битное пространство неравномерно. Адреса, начинающиеся с0, занимали половину всех битовых строк. Шаблон10занимал четверть. Шаблон110— одну восьмую. Остальные шаблоны старших битов были зарезервированы или разработаны для других целей, включая многоадресную рассылку и эксперименты. Поэтому небольшое число номеров сетей класса A контролировало огромную часть числового адресного пространства, тогда как гораздо больший запас номеров сетей класса C занимал меньшую долю.

Это различие между единицами «номер сети» и представленной ёмкостью принципиально. Реестр мог содержать тысячи записей класса C и лишь несколько десятков записей класса A, из-за чего класс C выглядел доминирующим по объёму работы. Тот же реестр, измеренный по числовым значениям адресов, мог быть подавляюще сосредоточен в классе A. Ни один знаменатель сам по себе не ошибочен. Они отвечают на разные вопросы.

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

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

Маршрутизация делала крупную единицу операционно привлекательной

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

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

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

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

Арифметика подсетей показывает, почему класс B становился привлекательным для растущего кампуса. Если шесть битов его 16-битного локального поля использовались под подсети, исходная геометрия давала 64 шаблона подсетей и 1 024 шаблона узлов внутри каждой подсети. По принятой тогда конвенции, исключавшей шаблоны подсетей из всех нулей и всех единиц, оставалось 62 обычные подсети. С применением обычных исключений для узлов в каждой подсети оставалось 1 022 значения узлов. Произведение составляло:

[62 \times 1,022 = 63,364]

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

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

Эксплуатационное руководство 1989 года RFC 1118 прямо описало проблему совместимости. Многие доступные программы, особенно 4.2BSD, не могли работать с адресами в подсетях без дополнительного ПО, тогда как 4.3BSD поддерживал подсети в исходном виде. Другие системы различались. Некоторые могли работать как оконечные узлы, но не как шлюзы внутри части сети, разбитой на подсети.

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

Дилемма распределителя была не просто «большой блок против малого блока». Это был выбор между ресурсами, расходуемыми в разных местах:

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

Рост состояния маршрутизации делал этот обмен всё более насущным.RFC 1338привёл серию Merit: 173 анонсируемых маршрута в июле 1988 года, 603 в июле 1989 года и 4 775 в феврале 1992 года. Полное сравнение с июля 1988 по февраль 1992 года:

[4,775 / 173 = 27.601]

Это рост в 27,601 раза за 43 месяца. Более короткое сравнение с июля 1989 по февраль 1992 года:

[4,775 / 603 = 7.919]

Это рост в 7,919 раза за 31 месяц. Это разные сравнения, и их не следует объединять.

RFC 1338 утверждал, что выделение четырёх–шестнадцати сетей класса C вместо одной класса B могло замедлить исчерпание класса B, но ухудшить рост таблиц маршрутизации, если только междоменные протоколы маршрутизации не смогут представлять произвольные агрегаты «сеть + маска». Предложенное средство поэтому зависело не только от нового правила регистрации. Маршрутизаторы и протоколы должны были нести информацию, не укладывающуюся в старые классовые границы.

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

Ранний интерфейс принятия решений остаётся неполным

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

В сентябре 1981 годаRFC 790опубликовал выделенные номера сетей и направил запросы на выделение Джону Постелу в Институт информационных наук Университета Южной Калифорнии. Реестр показывал выделенные, зарезервированные и невыделенные номера, но не публиковал полного общего теста для выбора между классами A, B и C.

К январю 1983 годаRFC 820зафиксировал более развитую политическую среду. Он помечал выделения как исследовательско-конструкторские, оборонные или коммерческие. В приложении были обобщены рекомендации, согласованные в сентябре 1982 года между офисом программы Defense Data Network и DARPA. Для исследовательского сообщества рекомендации связывали выдачу идентификаторов сетей с подтверждением того, что заявитель приобретает стандартное шлюзовое ПО или реализует шлюз, отвечающий требованиям External Gateway Protocol.

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

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

Институциональное устройство менялось в течение десятилетия. Путеводитель Музея компьютерной истории по документам SRI ARC/NIC (Guide to the SRI ARC/NIC Records) датирует передачу администрирования Assigned Numbers и глобального выделения IP-адресов от USC-ISI контракту SRI NIC 1987 годом. Архивный справочник указывает на переписку и материалы по именованию и адресации, которые могут содержать записи о заявках, но сам по себе не раскрывает логику ни одного отдельного решения о классе.

RFC 1118в 1989 году дал публичное описание процедуры для заявителя. Желающей подключиться сети предписывалось отправить сообщение на[email protected], запросить шаблон connected-address, заполнить его и вернуть. Выделенный адрес затем присылался электронной или обычной почтой. Руководство добавляло, что номеров класса A осталось мало и что на практике большинству заявителей приходится выбирать между классами B и C.

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

Сохранившееся подтверждение, отправленное Бристольскому университету, столь же ограниченно. Университет воспроизводит сообщение от 8 марта 1991 года, выделяющее сеть класса B137.222.0.0сети BRISTOL-NET. В нём указаны класс, номер, технический контакт и дата. Получателю также даны советы по регистрации в таблице узлов, широковещательной адресации и разрешению адресов.

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

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

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

В августе 1990 годаRFC 1174описал институциональные роли более формально. Функция IANA в USC-ISI сохраняла центральные полномочия по выделению и назначению числовых идентификаторов и дискреционные полномочия делегировать части этой ответственности. Ответственность за идентификаторы сетей и автономных систем была возложена на Internet Registry, которую SRI International вела в DDN-NIC. Документ рекомендовал сохранить центральные функции IANA и Internet Registry, делегируя блоки одобренным организациям по всему миру.

Эти роли нельзя смешивать. Функция IANA, Internet Registry, служба NIC и Internet Activities Board занимали смежные, но разные позиции. IAB выпускал рекомендации. Функция IANA обладала полномочиями выделения и делегирования. Internet Registry собирала и вела записи и обрабатывала выделение номеров. Заявитель обычно сталкивался с системой через хостмейстера и полученный номер.

RFC 1174 доказывает, что к 1990 году усмотрение и делегирование были признанными институциональными понятиями. Он не доказывает, как усмотрение применялось в конкретном случае 1983 или 1991 года.

Измерение распределения без выдуманных заявителей

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

Используемая здесь единица — одна классовая единица «номер сети» в том виде, как её считает цитируемый источник. Это не организация, не заявитель, не маршрутизируемый префикс, не узел, не нынешний держатель, не передача и не экономическая сделка. Если источник связывает диапазон, содержащий 1 024 сети класса C, с одним именем, измерение насчитывает 1 024 классовые единицы. Оно не утверждает, что диапазон представляет 1 024 бенефициаров.

Три опубликованных среза дают полезные точки сравнения:

итоги RFC 820 за январь 1983 года по выделенным номерам сетей классов A, B и C;
RFC 1166, опубликованный в июле 1990 года, и его итоги по сетям, выделенным для использования в интернете и независимо;
RFC 1466, опубликованный в мае 1993 года, и его таблица под названием «Network Number Statistics (May 1992)».

Зарезервированные и невыделенные диапазоны, номера автономных систем, многоадресное пространство и экспериментальные классы исключены. Представленные числовые значения рассчитываются умножением каждого числа из источника на (2^{24}), (2^{16}) или (2^8). Расчёт не вычитает резервирование узлов, подсетей или широковещательных адресов, поскольку получатели могли по-разному структурировать свои локальные поля и поскольку цель — измерить числовую ёмкость, охваченную каждым классовым выделением.

Для января 1983 года:

[(31 \times 16,777,216) + (24 \times 65,536) + (1,042 \times 256) = 521,933,312]

Для июля 1990 года:

[(34 \times 16,777,216) + (2,533 \times 65,536) + (16,214 \times 256) = 740,578,816]

Для статистики мая 1992 года:

[(49 \times 16,777,216) + (7,354 \times 65,536) + (44,014 \times 256) = 1,315,302,912]

Срез и определение источника	Сетей класса A	Сетей класса B	Сетей класса C	Всего классовых единиц	Представлено числовых значений адресов	Доля A	Доля B	Доля C
Январь 1983 года, итоги выделений в RFC 820	31	24	1 042	1 097	521 933 312	99,648 %	0,301 %	0,051 %
Июль 1990 года, выделения для интернета и независимого использования в RFC 1166	34	2 533	16 214	18 781	740 578 816	77,024 %	22,415 %	0,560 %
Статистика мая 1992 года, воспроизведённая в RFC 1466	49	7 354	44 014	51 417	1 315 302 912	62,501 %	36,642 %	0,857 %

Сети класса C доминировали по числу единиц «номер сети» во всех трёх выбранных срезах. Они не доминировали по представленной ёмкости. В январе 1983 года 31 выделение класса A охватывало 99,648 % числовых значений адресов в опубликованных итогах. На 1 042 единицы класса C приходилось 0,051 %.

Первая строка содержит важную концентрацию. RFC 820 связывал диапазон от192.1.xxxдо192.4.xxxс «локальными сетями BBN». Каждое полное значение второго октета покрывало 256 номеров сетей класса C. Четыре таких значения покрывали:

[4 \times 256 = 1,024]

Эти 1 024 единицы составляли:

[1,024 / 1,042 = 98.272553%]

числа сетей класса C в итоге за январь 1983 года. Их совокупная числовая ёмкость составляла:

[1,024 \times 256 = 262,144]

По сырой числовой ёмкости это равнялось четырём сетям класса B:

[4 \times 65,536 = 262,144]

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

Опубликованная таблица не объясняет почему. Она не показывает, маршрутизировались ли сети BBN отдельно, использовались ли для тестирования, резервировались ли под разные локальные среды или организовывались по какому-то иному техническому плану. Замена на четыре сети класса B в контрфактической модели сохраняет сырую ёмкость, но не обязательно топологию, эксперименты, поведение маршрутизации или задуманную административную структуру. Поэтому диапазон — аргумент против упрощённого прочтения «одна организация — один класс», а не свидетельство о логике первоначального администратора.

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

Срез 1990 года вводит другой знаменатель. RFC 1166 отдельно сообщил о 4 210 сетях, выделенных для ARPA-Internet и DDN-Internet, и о 18 781 сети, выделенной для использования в интернете и независимо. В подключённое подмножество входило 29 сетей класса A, 1 209 класса B и 2 972 класса C. Более широкий итог выделений содержал 34 сети класса A, 2 533 класса B и 16 214 класса C.

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

Источники 1992 года предостерегают от натягивания срезов на ложнопрецизионный непрерывный ряд. RFC 1338 сообщил, что анализ файлаnetwork-contacts.txtу DDN-NIC обнаружил 46 выделенных номеров класса A и 5 467 — класса B на 25 февраля 1992 года. RFC 1466 позднее воспроизвёл итоги мая 1992 года: 49 и 7 354. Документы также использовали разные знаменатели пула класса B: 16 256 в RFC 1338 и 16 383 в RFC 1466.

Было бы небезопасно интерпретировать всю разницу как всплеск выделений за три месяца. Файлы, фильтры, обработка зарезервированных диапазонов или смысл слова «allocated» могли различаться. Без датированных исходных файлов и правил их преобразования расхождение нельзя разрешить по одним лишь двум итогам. Современники явно воспринимали быстрый рост, но это восприятие не делает несопоставимые измерения взаимозаменяемыми.

Имена получателей не восполняют отсутствующий знаменатель

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

Записи класса A в RFC 1166 включали явно не американские случаи: RSRE в Соединённом Королевстве, CAN-INET в Канаде и JAPAN-A с контактом в Токийском университете. Более ранние реестры включали Университетский колледж Лондона и трансатлантические пакетные или спутниковые сети. Этого достаточно, чтобы отвергнуть утверждение о том, что выделения крупных классов были исключительно американскими. Но этого недостаточно для надёжного процентного распределения по странам.

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

Имена также меняют единицу наблюдения. Несколько записей могут принадлежать одной организации; одна запись может обслуживать несколько организаций или площадок. Диапазон класса C у BBN — самый наглядный пример множества единиц «номер сети» под одним именем. Позднейшее использование Merit сети 35 в нескольких автономных системах иллюстрирует обратную проблему: одна классовая сеть могла участвовать в распределённой схеме маршрутизации.

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

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

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

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

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

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

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

Неполный ранний интерфейс не следует путать с полным отсутствием критериев. В записи видны некоторые ранние правила правомочности и гораздо более явные позднейшие руководства по выделению.

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

К 1990 году RFC 1174 прямо говорил языком дефицита. Быстрый рост и интернационализация делали дальнейшее делегирование своевременным, а идентификаторы классов A и B описывались как всё более дефицитные ресурсы, требующие тщательного выделения. Документ соединил заботу о ёмкости с административной. Глобальная совокупность заявителей зависела от функций, по-прежнему сосредоточенных в американских институтах, тогда как число сетей и записей росло.

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

RFC 1366, опубликованный в октябре 1992 года, превратил это направление в более конкретные правила. От кандидатов в региональные реестры ожидалось признание в своих географических зонах, стабильность, надлежащее ресурсное обеспечение и приверженность общим руководствам IANA и Internet Registry. Центральные функции сохраняли ответственность за пространство класса B, а региональные реестры помогали в оценке.

Для класса B RFC 1366 назвал два критерия: план подсетей с документальным подтверждением более 32 подсетей и более 4 096 узлов. Допускалось рассмотрение в индивидуальном порядке там, где блок сетей класса C технически непригоден. Для класса C предлагались побитово смежные блоки размером по потребности и 24-месячному прогнозу.

Критерии сделали некоторые факторы публичными, оставив место для усмотрения. «Более 32 подсетей» зависело от предлагаемой топологии. «Более 4 096 узлов» зависело от того, что считать узлом и описывает ли число текущее развёртывание или правдоподобный рост. Техническая непригодность требовала объяснения, а не автоматического расчёта.

Канонический источник того периодаRIPE-048, опубликованный 1 августа 1992 года, показывает развивающийся европейский интерфейс. В нём говорилось, что RIPE NCC обрабатывает запросы европейских организаций и что заявители обычно возвращают присланные материалы через IP-провайдера или RIPE NCC. Документ связывал выделение с отношениями с провайдером и планируемой внешней связностью.

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

Документ ссылался на отдельный одностраничный информационный лист о классе B, но просмотренный текст RIPE-048 этот лист не воспроизводит. Поэтому было бы некорректно приписывать самому RIPE-048 подробный перечень полей о прогнозе узлов, подсетях и утилизации. Прямое подтверждение в документе уже: ожидаемый размер и структура, контекст провайдера или связности, пригодность класса C, детальное обоснование для класса A и возможность длительного глобального рассмотрения.

RFC 1466, опубликованный в мае 1993 года, даёт детальные поля напрямую. От заявителя на класс B ожидалось документальное подтверждение более 32 подсетей и более 4 096 узлов. Инженерный план должен был объяснять, почему блок сетей класса C нецелесообразен, и включать число узлов, ожидаемое в течение 24 месяцев, и число узлов на подсеть за этот же период. Планы должны были оставаться конфиденциальными и использоваться для оценки обоснованности заявки. Заявитель, не прошедший проверку, получал блок класса C, при этом исключения оставались возможными.

Для класса C RFC 1466 установил лестницу смежных выделений на основе 24-месячного прогноза абонента:

Прогнозируемая потребность	Выделение по умолчанию
Менее 256 адресов	1 сеть класса C
Менее 512	2 смежные сети класса C
Менее 1 024	4 смежные сети класса C
Менее 2 048	8 смежных сетей класса C
Менее 4 096	16 смежных сетей класса C
Менее 8 192	32 смежные сети класса C
Менее 16 384	64 смежные сети класса C

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

Политика допускала корректировку под топологию. Организация с 600 узлами, равномерно распределёнными по десяти сетям Ethernet, могла получить десять сетей класса C — по одной на локальную сеть, — если подкрепляла отклонение инженерным планом. Реестры могли также потребовать объяснения там, где отказ от разбиения сетей класса C на подсети вёл к чрезмерному расходу пространства.

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

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

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

Диапазон BBN подрывает тезис о том, что видные действующие держатели неизменно получали один крупный класс. В январе 1983 года на «локальные сети BBN» приходилось 1 024 из 1 042 единиц класса C в итоге источника. Четыре сети класса B дали бы ту же сырую числовую ёмкость в четырёх классовых единицах. Однако реестр показывал мелкий класс оптом.

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

Бристоль оспаривает другое утверждение. Европейский университет получил сеть класса B 8 марта 1991 года — после того как рост маршрутизации стал очевиден и до публикации детальных критериев 1992–1993 годов. Подтверждение исключает абсолютный тезис о том, что классы среднего размера из прежней эпохи были закрыты для неамериканских университетов.

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

Сеть 35 организации Merit даёт операционный пограничный случай. RFC 1166 перечислял сеть 35 среди выделений класса A.RFC 1482, опубликованный в июле 1993 года, показал её настроенной на магистрали NSFNET T3 так, что анонсы маршрутов можно было ожидать от шести автономных систем.

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

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

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

Четыре давления действовали в разном темпе

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

Дефицит конечного адресного пространства касался ограниченного 32-битного пространства и, более непосредственно, ограниченных запасов номеров сетей классов A и B. Класс A охватывал (2^{24}) числовых значений локальных адресов и расходовал один из примерно 126 обычных слотов номеров сетей, признаваемых таблицами того времени. RFC 1466 сообщал, что по его политическим определениям невыделенными или незарезервированными оставалось лишь около 11 номеров класса A, а верхняя половина пространства класса A резервировалась на неопределённый срок.

Дефицит состояния маршрутизации касался памяти, вычислений, обновлений протоколов и операционной стабильности. Он мог стать острым, пока большие части числового адресного пространства оставались невыделенными. Каждая отдельно видимая сеть класса C могла добавлять адресата в таблицу маршрутизатора. Предупреждение RFC 1118 об узлах, ограниченных примерно 700 сетями, и ряд данных о маршрутизации в RFC 1338 показывают, почему одна сеть класса B с подсетями могла выглядеть операционно дешевле нескольких меньших сетей.

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

Административное внимание касалось способности принимать формы, задавать вопросы, оценивать планы, сверять записи, координировать делегирование и возвращать решения. RFC 1174 связывал дальнейшее делегирование с быстрым ростом и интернационализацией. RFC 1466 говорил, что спрос значительно вырос за два года и что выделение требует более системного подхода. RIPE-048 предупреждал, что глобальное рассмотрение запроса класса A может занять несколько месяцев.

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

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

Дефицит не был одним событием. Это был набор несостыкованных ограничений.

Все реалистичные альтернативы несли издержки

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

Рассмотрим организацию, ожидающую 1 000 обычных узлов. Четыре сети класса C давали:

[4 \times 254 = 1,016]

обычных адресов узлов. Одна сеть класса B давала 65 534. С точки зрения экономии адресов четыре сети класса C были несравненно лучше. В классовой системе маршрутизации они могли требовать четырёх видимых вовне записей о сетях. Совет RFC 1118 анонсировать кампусу не более двух отдельных сетей к 1989 году делал эту издержку материальной.

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

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

Третий вариант — выделить смежные сети класса C в подготовке к позднейшей агрегации. Смежность помогала сохранить возможность представить несколько сетей одним префиксом, когда протоколы маршрутизации и маршрутизаторы поддержат произвольную информацию «сеть + маска». До такой поддержки классовая система по-прежнему интерпретировала компоненты как отдельные сети класса C. Одна лишь смежность не заставляла маршрутные записи исчезать.

RFC 1338 сделал эту зависимость явной. Его предлагаемый план выделения мог давать средним организациям блоки класса C подходящего размера, но маршрутная выгода требовала, чтобы междоменные протоколы представляли произвольные адресаты «сеть + маска». Многосвязные организации могли по-прежнему нуждаться в более конкретных анонсах. Развёртывание требовало изменений ПО, операционной координации и согласия между NIC, IANA и поставщиками услуг.

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

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

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

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

Ещё одна возможность — требовать более частой перенумерации или изъятия. Это могло бы вернуть неиспользуемую ёмкость, но легло бы издержками на узлы, шлюзы, контроль доступа, документацию, сети корреспондентов и операционный персонал. Рекомендация преемственности в RFC 820 показывает, что затруднения перенумерации уже признавались. Правило, игнорирующее эти издержки, экономило бы адресные значения, экспортируя разрушения операторам.

Каждая альтернатива поэтому по-разному оценивала дефицит:

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

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

Что изменилось, что сохранилось и чего нельзя вывести

Свидетельства поддерживают разделённое распределение причинности.

Классовая конструкция создала разрывы. 32-битный адрес можно было разделить иначе, но развёрнутая архитектура предлагала фиксированные границы A, B и C. Для потребности чуть выше 254 обычных узлов не было нативного класса с умеренным увеличением. Это было свойство протокола.

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

Административная политика определяла, как система отвечала. Ранние опубликованные материалы содержали критерии правомочности и готовности шлюза, но не реконструируют полный интерфейс выбора класса. К 1990–1993 годам публичная запись прямо обсуждала дефицит, делегирование, пороги узлов и подсетей, 24-месячные прогнозы, инженерные планы и исключения. Усмотрение становилось более структурированным, не исчезая.

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

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

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

Современные свидетельства подтверждают устойчивость, не разрешая ранних мотивов. Исследование 2017 года по зарегистрированным передачам IPv4 показало, что легаси-пространство составляло 63,82 % адресного пространства в его выборке зарегистрированных передач. Та же работа показала, почему позднейшие записи нужно интерпретировать осторожно: изменения маршрутизации могут отражать смену провайдера, перераспределение, организационную реструктуризацию или сложное управление адресами, а не продажу.

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

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

Исторический вывод поэтому ограничен, но значим. Классовая адресация IPv4 превратила техническую дискретность в административную границу принятия решений. Ограничения маршрутизации иногда делали более крупную единицу оправданной. Ограничения оборудования иногда делали подсети дорогими. Ранние заявители и администраторы работали с прогнозами, которые сегодня нельзя реконструировать по готовым реестрам. Позднейшие политики сделали критерии балансировки более явными и сместили работу к региональным и провайдерским институтам.

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

Эпоха классовой адресации и рождение административного дефицита

Почему это важно