Кратко

  • Опция IPv4 типа 7 заранее отводила конечный набор четырёхоктетных ячеек, куда сотрудничающие узлы пересылки могли записывать адреса, не управляя выбором пути.
  • Малый объём, отсутствие аутентификации и раскрытие топологии со временем изменили норму: вместо обработки по умолчанию появилась рекомендация по умолчанию отбрасывать такие пакеты.

Указатель и четыре октета

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

RFC 791 предписывал модулю, пересылающему дейтаграмму, записать собственный адрес в том виде, в каком он известен в среде следующего участка. RFC 1812 уточнил правило для маршрутизатора: нужен адрес логического выходного интерфейса, а для ненумерованного интерфейса—стабильный router-id. Запись обозначила используемую на выходе идентичность, а не обязательно всё физическое устройство.

Увеличить область в пути было невозможно. Если указатель вышел за длину, место закончилось, и пакет продолжал путь без новой записи. Если оставалось от одного до трёх октетов, полной адресной ячейки уже не было: RFC 791 считал исходную дейтаграмму ошибочной и требовал отбросить её, допуская ICMP Parameter Problem. Опция могла встретиться лишь один раз и при фрагментации сохранялась только в первом фрагменте.

Предел в девять адресов следует из размеров заголовка. Максимум IPv4—60 октетов, из которых 20 занимает фиксированная часть. Если почти все оставшиеся 40 отдать Record Route, после трёх служебных октетов останется 37—место для девяти полных адресов. Это арифметический максимум без других существенных опций, а не обещание получить ответы от девяти переходов.

Наблюдение без права выбирать путь

Loose и Strict Source and Record Route использовали заданные отправителем промежуточные адреса при пересылке. Тип 7 принципиально отличался: обычная маршрутизация выбирала дорогу, а пакет лишь просил фактически встретившиеся системы оставить наблюдение.

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

RFC 1122 сделал создание и обработку Record Route необязательными для хостов. Однако в ответе ICMP Echo следовало обновить полученную опцию и вернуть её без усечения, чтобы список охватывал путь туда и обратно. Польза диагностики зависела от согласия каждой административной границы.

Как поменялось значение по умолчанию

В 1995 году RFC 1812 требовал от маршрутизаторов поддерживать Record Route в пересылаемых пакетах. Можно было добавить настройку пропуска без изменений, но по умолчанию запись должна была работать. Риск раскрытия топологии признавался, однако сотрудничество оставалось исходной нормой.

В 2014 году RFC 7126 предложил обратную норму. Опция могла помогать в картировании сети, хотя её ограниченный объём снижал пользу. Блокировка ломала диагностику, специально использующую RR, но не обычный ping; более того, повсеместное отбрасывание уже сделало подобные методы почти неприменимыми на произвольных путях. Рекомендация требовала отдельной настройки для отбрасывания, игнорирования или полной обработки, с документированным значением «отбрасывать» по умолчанию.

Источники