Кратко

  • RFC 917 не был стандартом: он сообщал о работе IP-подсетей в Стэнфорде с начала 1982 года; к 1984-му документ насчитывал около 330 узлов и 18 подсетей.
  • Стэнфорд сопоставил IP-подсети с существовавшими номерами сетей Pup. RFC 917 предложил выбирать ширину поля для каждой сети, а RFC 950 стандартизовал процедуры для хостов в 1985 году.

Числа RFC 917 относятся к одному месту, а не ко всему Интернету: около 330 узлов, 18 подсетей и примерно столько же шлюзов в Стэнфорде. Джеффри Могул опубликовал документ в октябре 1984 года как предложение, открытое для обсуждения и улучшений. В нём говорится, что IP-подсети Стэнфорда действовали с начала 1982-го. Практика предшествовала общей процедуре.

Она выросла из сети, которая уже работала. С 1979 года Стэнфорд использовал Pup на нескольких экспериментальных Ethernet-сетях. При переходе на IP университет выбрал восьмибитное поле номера подсети: оно совпадало с номером сети Pup для соответствующего Ethernet. Восьмибитный номер узла Pup стал полем узла IP. Адресная структура IP наложилась на локальную схему идентификаторов, которую уже обслуживали.

Та же преемственность проявилась в маршрутизации. Таблицы IP поддерживал процесс обновления таблиц Pup, преобразуя номера сетей в номера подсетей. Шлюзы, понимавшие только Pup, пересылали IP-дейтаграммы по маршрутам Pup, но не изменяли поле Time-to-Live в заголовке IP. Многосетевые интернет-хосты, выполнявшие роль шлюзов, TTL корректировали. Могул отметил, что в описанной системе не наблюдалось сбоев из-за циклов пересылки. Это отчет о конкретной установке, а не основание повсеместно игнорировать TTL.

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

В MIT задача выглядела иначе. До деления номеров сети на классы отдельный IP-номер для каждой локальной линии занял бы значительную часть доступного адресного пространства. MIT оставил один номер сети, а 24-битное поле «остатка» разделил на три восьмибитные части: подсеть, резервный участок с обязательным нулём и узел. Номер подсети совпадал с восьмибитным номером в CHAOS. План динамического обмена маршрутами между шлюзами не воплотили, поэтому остались статические таблицы. ICMP Host Redirect уменьшали необходимый объём изменений программ хостов.

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

Для загрузки бездисковых рабочих станций RFC 917 предложил ICMP Address Format Request и Address Format Reply, чтобы узнать ширину поля. Сохранённая локальная настройка также оставалась допустимой. Если шлюз не отвечал, узел мог начать с нулевой ширины, а затем изменить интерпретацию после объявления фактического значения. Эти предложенные сообщения не следует путать с более поздними Address Mask в RFC 950.

В апреле 1985 года RFC 940 описал проблему совместимости: хосты разных поставщиков могли по-разному решать, отправлять ли пакет напрямую или через шлюз. RFC 950 в августе указал, что основан на RFC 917, и настоятельно рекомендовал общую процедуру для хостов при использовании подсетей. Взаимодействие самих шлюзов он описал не полностью. Сначала существовали местные схемы, затем появился общий проект и только после него — стандарт.

Note 64 Хэнга Лу здесь служит редакционной оптикой: минимальные общие правила могут оставлять внутренний выбор организации. Она не доказывает намерения Могула, Стэнфорда, MIT или Постела.