3.2.1.8 Опции: RFC 791, параграф 3.2
Для транспортного уровня должен обеспечиваться способ задания опций IP, которые будут включаться во все передаваемые дейтаграммы IP (см. параграф 3.4).
Все опции IP (за исключением NOP и END-OF-LIST) из принимаемых дейтаграмм должны передаваться на транспортный уровень или системе обработки ICMP (если дейтаграмма является сообщением ICMP). Оба уровня (транспортный и уровень IP) должны интерпретировать понятные им опции IP, игнорируя остальные.
Ниже в этом документе рассматриваются вопросы поддержки специфических опций IP, требуемой протоколами ICMP, TCP и UDP.
- Обсуждение:
Передача всех принятых опций IP на транспортный уровень является преднамеренным «нарушением жесткого деления на уровни», которое предназначено для упрощения ввода в будущем новых опций IP, относящихся к транспортному уровню. Каждый уровень должен выбрать все имеющие к нему отношение опции для внутренней обработки и игнорировать остальные опции. Для этого каждая опция IP (кроме NOP и END-OF-LIST) указывает свой размер.
В этом документе не определяется порядок обработки опций каждого заголовка IP. Хосты, использующие множество опций при передаче, должны понимать, что результаты могут зависеть от порядка обработки опций.
- Реализация
Программы IP-уровня должны быть устойчивы к сообщениям с опциями, размер которых выходит за допустимые пределы. Известны примеры реализаций, которые входят в бесконечный цикл при получении пакетов с полем опций некорректного размера.
Ниже перечислены требования к отдельным опциям IP:
Security (безопасность)
Некоторые среды требуют наличия опции Security в каждой дейтаграмме — такие требования выходят за пределы настоящего документа и стандартов IP. Отметим, что опции безопасности, определенные в RFC 791 и RFC 1038, утратили силу. Для приложений DoD разработчикам следует обращаться к документу [RFC1108].
Stream Identifier (идентификатор потока)
Эта опция устарела — ее недопустимо передавать в пакетах, а на приемной стороне она должна игнорироваться.
Source Route (маршрутизация отправителем)
Хост должен поддерживать маршрутизацию отправителем в исходящих дейтаграммах и должен поддерживать себя, как конечного адресата при маршрутизации отправителем.
Если хост получает дейтаграмму, содержащую завершенный маршрут от отправителя (completed source route), это говорит о доставке дейтаграммы конечному адресату. Принятые опции (записанный маршрут) должны передаваться на транспортный уровень (или системе обработки сообщений ICMP). Записанные маршруты будут инвертироваться и использоваться для передачи отклика на дейтаграмму (см. Опции IP в главе 4). Когда маршрут возврата построен, требуется корректно сформировать его даже при использовании записи маршрута от хоста-отправителя (см. пункт (B) ниже).
Заголовки IP, содержащие более одной опции Source Route, передавать недопустимо, поскольку маршрутизация в таких случаях будет зависеть от реализации.
В параграфе 3.3.5 приведены правила для хостов, выступающих в качестве промежуточных (intermediate hop) для source route (т. е. пересылающих дейтаграммы с заданной отправителем маршрутизацией).
- Обсуждение:
При фрагментировании дейтаграмм source-route каждый фрагмент будет содержать копию заданного отправителем маршрута. Поскольку обработка опций IP (включая source route) должна предшествовать сборке фрагментов, исходная дейтаграмма не может быть собрана до тех пор, пока она не будет доставлена конечному адресату.
Предположим, что такая дейтаграмма передается от хоста S на хост D через шлюзы G1, G2, ... Gn. В спецификации IP существуют неоднозначности, позволяющие задавать для опций source route дейтаграмм, передаваемых хостом S, вариант (A) или (B):
- A)
{>>G2, G3, ... Gn, D} <--- корректно - B)
{S, >>G2, G3, ... Gn, D} <---- ошибка
(>> представляет указатель). При использовании варианта (A) дейтаграмма, принятая хостом D, будет содержать опции {G1, G2, ... Gn >>}, с IP-адресами хостов S и D как отправителя и получателя. Если использован вариант (B), принятая хостом D дейтаграмма будет по-прежнему содержать адреса S и D как отправителя и получателя, но опции будут иметь вид {S, G1, ...Gn >>}, т. е; хост-отправитель исходной дейтаграммы оказывается первым в маршруте возврата.
- A)
Record Route (запись маршрута)
Реализация установки и обработки опции Record Route является необязательной.
Timestamp (временная метка)
Реализация установки и обработки опции Timestamp является необязательной. При реализации этой опции должны выполняться следующие правила:
Хост-отправитель должен записывать временную метку в поле Timestamp опций, для которых поле адреса еще не указано или содержит адрес интерфейса данного хоста.
Принимающий хост должен (если это возможно) добавить текущее время в опцию Timestamp перед передачей опции для обработки на транспортный уровень или ICMP.
Значение временной метки должно соответствовать требованиям, приведенным в параграфе 3.2.2.8 для сообщений ICMP Timestamp.