Кратко

  • RFC 950 добавил ICMP Address Mask Request/Reply для получения 32-битной маски при загрузке; отсутствие ответа вело к классовому резерву, который мог оказаться неверным.
  • RFC 1122 разрешал Reply только явно настроенному authoritative agent: изученная маска не давала права отвечать, а первый принятый ответ закрывал окно.
  • DHCP позже передавал маску с другими параметрами и включал либо выключал старые роли; RFC 6918 объявил типы 17 и 18 Deprecated как вытесненные.

Адрес не содержал локальную границу

RFC 950 выбрал 32-битную маску, поскольку организация сама решала, какие локальные биты обозначают подсеть. Внутреннюю структуру нельзя было вывести из глобального IPv4-адреса.

Маска управляла пересылкой: совпадение замаскированных собственного и целевого адресов означало прямую доставку, различие — gateway. Ошибка меняла состав соседей.

Файл подходил машине с диском. Бездеисковая workstation при загрузке нуждалась в адресе, шлюзе, DNS и маске. RFC 950 предпочитал общую доставку boot server, но предусмотрел отдельный ICMP-вопрос.

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

Резерв был действием, а не выводом

Хост применял маску Internet network number — классовую несегментированную границу. RFC называл её наиболее безопасным выбором, но прямо говорил, что она может быть ошибочной.

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

Отрицательное свидетельство позволяло обратимое действие для продолжения работы. Оно не становилось положительным знанием о топологии.

Такая дисциплина важнее формата: неопределённость не запрещает fallback, но запрещает выдавать его за установленный факт.

Вопрос слышала вся линия

Хост broadcast-ил Address Mask Request. Gateway или host в его роли отвечал маской входной подсети. При нулевом source, когда проситель ещё не знал адреса, Reply тоже broadcast-ился.

Сообщение несло Type, Code 0, Checksum, Identifier, Sequence Number и 32-битный Address Mask. Реестр называет Request типом 17, Reply типом 18.

Identifier и Sequence помогали сопоставлению, но RFC 950 разрешал его не делать: предполагалась одна верная маска на LAN. Несколько gateways могли отвечать одинаково.

Корреляция не давала полномочий. Связь с вопросом не показывала, что отправитель вправе определять настройку LAN. Маска была общим свойством attachment.

Вернувшийся агент исправлял прошлое

При запуске gateway должен был broadcast-ить unsolicited Reply. Хост с иной догадкой менял маску.

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

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

Fallback можно было использовать для себя, но нельзя было экспортировать. Работоспособность не была делегированием.

Полномочие требовало явной настройки

RFC 1122 требовал, чтобы Reply отправлял только явно настроенный authoritative agent. Им мог быть host или gateway; тип устройства не назначал роль.

Получение Reply не передавало полномочия. Изученную маску нельзя было использовать для ответов третьим лицам. Знание и мандат различались.

Причиной были hosts, небрежно рассылавшие неверные маски. Проверки значения было недостаточно; говорящего выбирало административное действие.

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

Первый ответ выигрывал

RFC 1122 допускал static и dynamic источники. При включённом discovery запрос повторялся. Первый Reply, solicited или unsolicited, устанавливал маску; поздние молча игнорировались.

First-wins ограничивал колебания, но не аутентифицировал. Правдоподобная ложная реплика могла прийти первой.

Reasonableness check отвергал all-one и ожидал zero либо установленные старшие восемь бит. Он ловил абсурд, не подтверждая намерение администратора.

При выключенном механизме host не спрашивал и игнорировал Replies. Понимание типа не открывало изменение настройки.

Одна маска концентрировала последствия

Общее значение упрощало работу нескольких agents и снимало строгую корреляцию. Ошибка зато затрагивала всех обнаруживающих hosts.

Многосвязному host требовалась маска на каждую LAN. Значение относилось к адресу на interface, а не к глобальной личности машины.

Отдельный вопрос отрывал маску от адреса, router и остальных boot facts. Верные по отдельности ответы могли описывать разные моменты.

Позднейшая архитектура объединила связанные параметры в одной конфигурационной связи.

DHCP управлял переходом

RFC 2131 описал RARP, ICMP, BOOTP и другие фрагменты. DHCP объединил назначение адреса и конфигурацию в stateful exchange.

ICMP не исчез немедленно. Mask request оставался механизмом, а subnet mask — параметром interface.

RFC 2132 определил Option 1 с четырьмя октетами Subnet Mask. Перед Router option маска должна идти раньше для правильной интерпретации адресов.

Option 29 Perform Mask Discovery включал ICMP-вопросы; Option 30 Mask Supplier — ответы. Новый канал доставлял значение и управлял старыми ролями.

DHCP-инструкция Supplier была явной конфигурацией. Услышанный ICMP Reply ею не был. Граница полномочий сохранилась.

Единица согласованности выросла

Сервер, назначающий адрес, мог одновременно дать маску. Молчание вспомогательного протокола больше не решало в одиночку вопрос о subnetting.

DHCP не становился безошибочным, но делал происхождение набора заметнее и позволял явно закрыть legacy path.

Options 29/30 показывают постепенную миграцию: прямую доставку, отключение дублирующего discovery или намеренное сохранение.

Практика сменилась до того, как registry формально отметил завершение.

Deprecated сохранил память

RFC 6918 объявил несколько ICMPv4 типов Deprecated. Address Mask Request/Reply были вытеснены механизмами вроде DHCP для host configuration.

Номера не удалялись и нулевое развёртывание не утверждалось. Новые проекты не должны были зависеть от них.

RFC 7279 перечисляет 17 и 18 как Deprecated. Историческая координата мешает несовместимо переиспользовать старые bytes.

Этапы были постепенными: локальный вопрос, строгий agent, DHCP-управляемое сосуществование и формальная deprecation.

Что доказывает Reply

Capture типа 18 доказывает наблюдение ICMP с заявленной маской и видимыми полями. Identifier/Sequence могут связать его с Request.

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

Request без ответа показывает лишь отсутствие наблюдаемого Reply в интервале. Несуществование, отказ, фильтр и потеря выглядят одинаково. Fallback доказывает правило host, не topology.

Урок отделяет данные, решение и мандат. Ответ направляет forwarding, тишина разрешает исправимую догадку; ни то ни другое само не создаёт права конфигурировать других.

Источники и пределы

Закрытый набор: RFC 950, RFC 1122, RFC 2131, RFC 2132, RFC 6918, RFC 7279. Он подтверждает дизайн, требования, переход и статус, но не deployment, полномочие конкретного sender, vendor compliance или правильность реальной маски.