Кратко

  • Опция IPv4 типа 68 давала участникам ограниченное место внутри пакета для временных меток или пар из адреса и времени.
  • Требования к хостам и маршрутизаторам сохраняли сотрудничество, однако отсутствие аутентификации, рассинхрон часов, раскрытие сведений и фильтрация сузили практическую пользу.

Память маршрута, ограниченная сорока октетами

В RFC 791 Internet Timestamp не был готовым временем, поставленным отправителем. Пакет резервировал изменяемую область типа 68, куда системы по пути могли добавлять наблюдения. Copy bit равнялся нулю, поэтому после фрагментации опция оставалась лишь в первом фрагменте. В одной дейтаграмме она могла встретиться только один раз.

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

Флаг 0 собирал последовательные 32-битные метки. Флаг 1 требовал сначала записать интернет-адрес системы, а затем время. При флаге 3 адреса задавались заранее, и запись появлялась лишь тогда, когда следующий адрес совпадал с адресом обрабатывающего устройства. Нормальным значением считалось число миллисекунд после полуночи по всемирному времени. Если такая шкала была недоступна, разрешалось другое время, но старший бит должен был отметить его как нестандартное.

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

Необязательные хосты и обязанные маршрутизаторы

RFC 1122 оставил хостам выбор: они могли не создавать и не обрабатывать опцию. Но реализация должна была соблюдать контракт. Источник записывал собственное время, когда это позволял режим; получатель по возможности добавлял текущее значение до передачи опции верхнему уровню. Предпочтительной шкалой оставались миллисекунды с полуночи UT, а неправильная или иная шкала требовала отметки нестандартного значения.

RFC 1812 потребовал от маршрутизаторов поддерживать Timestamp в пересылаемых пакетах. В режиме 3 было достаточно совпадения следующего заданного адреса с любым адресом маршрутизатора, а не только со входным или выходным интерфейсом. Реализация могла иметь переключатель, оставляющий режимы 0 и 1 без изменения, но по умолчанию он должен был быть выключен. Документ одновременно подчёркивал: запись ближе к моменту приёма полезнее, однако несинхронные часы ограничивают её смысл.

Диагностика, которая раскрывает наблюдателя

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

Кроме того, метод зависел от каждого фильтра на пути. Обычный ping обходился без IPv4-опций, а проверка с типом 68 ломалась на первой границе, где их отбрасывали. RFC 7126 отмечал, что распространённая фильтрация уже сделала такие способы практически непригодными, и рекомендовал маршрутизаторам, шлюзам безопасности и межсетевым экранам отбрасывать пакеты с Internet Timestamp.

Источники