Кратко

  • В информационном RFC 1375 Пол Робинсон предложил классы F, G, H и K, чтобы небольшим площадкам не требовался полный блок класса C.
  • Документ также рассматривал региональные коды и типы устройств, но ставил совместимость в зависимость от мостов, маршрутизаторов и ПО. Текстовое описание класса K расходится с его схемой.

Блок C мог оказаться слишком большим

RFC 1375 говорил не только о конечности 32-битного пространства IPv4. Фиксированные размеры классов подходили не каждой организации. В документе для сети класса C указано до 254 локальных адресов; площадка с четырьмя или пятью машинами, по оценке автора, могла оставить неиспользованными более 240. Робинсон ожидал роста небольших подключений, BBS, доступных через Telnet или FTP вместо телефонного вызова, а также принтеров, факсов и пейджеров, которым могли бы отправлять сообщения через Интернет.

Предложение меняло границы классов. Часть пространства класса C предлагалось отдать четырём новым меткам: F, G, H и K, с последовательно уменьшающимися локальными полями. Класс F предназначался для площадок примерно с 1–15 подключёнными адресами, H — для сетей, которые не должны были превысить семь, K — для одной или двух адресаций. Это по-прежнему была система заранее заданных классов, а не общее правило выбора любой длины префикса.

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

Совместимость была частью проекта

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

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

Класс K демонстрирует внутреннее расхождение опубликованной спецификации. В прозе указан семибитный префикс 1101111, 25-битный сетевой номер и один локальный бит. На следующей схеме напечатана другая последовательность (110100) и поле сети длиной 26 бит. Описания не могут задавать один и тот же формат. Расхождение видно в опубликованном тексте, но собранные источники не позволяют сказать, внедрял ли кто-либо предложение и повлияло ли это несоответствие на его судьбу.

Другой путь — префиксы переменной длины

В тот же период предлагались и другие ответы на давление адресного пространства и маршрутизации. RFC 1338 описывал иерархическое распределение адресов провайдерам и supernetting. RFC 1366 рассматривал распределение регистрационной функции и пространства сетевых номеров. В сентябре 1993 года RFC 1519 из серии Standards Track описал CIDR: распределение с масками переменной длины, часто из блока провайдера, вместе с агрегацией маршрутов. Для эффективной агрегации, говорилось в документе, изменения распределения и маршрутизирующих протоколов должны идти вместе.

Такой подход не требовал, чтобы каждый адрес объявлял именованный класс, регион или тип устройства. Значимой границей стала длина префикса. В 1995 году RFC 1812 потребовал от IPv4-маршрутизаторов поддержки подсетей и CIDR; RFC 1878 перечислил подсети переменной длины вплоть до маршрутов отдельного узла. Эти документы показывают позднейшую нормативную терминологию, но не доказывают, что CIDR напрямую заменил RFC 1375, и не объясняют, почему предложение Робинсона не продолжилось в стандартизации.

Note 48 Хенга Лу здесь выступает редакционной оптикой, а не источником сведений о 1992 годе. Она предлагает сначала увидеть в IP-адресе уникальную числовую метку, чьи записи должны оставаться согласованными. Отсюда возникает вопрос: что следует кодировать в самом адресе, а что оставить реестрам распределения, маскам, маршрутизации или именам приложений? RFC 1375 наделял биты значениями размера сети, региона и устройства; CIDR позже сосредоточился на переменной длине префиксов и агрегации. Различалась и точка, в которой сеть должна была выполнять работу по интерпретации адреса.

Источники