RFC: 4413
Оригинал: TCP/IP Field Behavior
Категория: Информационный
Дата публикации:
Авторы: ,
Перевод: Николай Малых

2.1.2. Поля заголовка IPv4

ПолеРазмер в битахКласс
Version4STATIC
Header Length4STATIC-KNOWN
DSCP6ALTERNATING
Флаг ECT1CHANGING
Флаг CE1CHANGING
Packet Length16INFERRED
Identification16INFERRED
Reserved Flag1CHANGING
Флаг запрета фрагментирования1CHANGING
Флаг наличия дополнительных фрагментов1STATIC-KNOWN
Fragment Offset13STATIC-KNOWN
Time To Live8CHANGING
Protocol8STATIC
Header Checksum16INFERRED
Source Address32STATIC-DEF
Destination Address32STATIC-DEF
Рисунок 3: Поля заголовка IPv4
  • Version — версия
  • Это поле указывает номер версии протокола IP. Пакеты с отличающимися значениями этого поля должны обрабатываться разными стеками IP. Все пакеты одного потока должны, следовательно, иметь одинаковую версию IP. Это позволяет отнести поле к классу STATIC.
  • Packet Length — размер пакета
  • Предполагается, что информация о размере пакета обеспечивается канальным уровнем. Это поле, следовательно, относится к классу INFERRED.
  • Flags — флаги
  • Поле резервного флага (Reserved) должно имет значение 0 в соответствии с RFC 791 [1]. Поэтому в RFC 3095 [31] поле классифицируется как STATIC-KNOWN. Однако предполагается возможность использования зарезервированных полей в будущем. Нежелательно выбирать такое представление, которое будет препятствовать использованию профиля компрессии при изменении заголовка в результате использования резервных полей. По этой причине используется классификация поля как CHANGING. Коммуникационный профиль, естественно, может быть оптимизирован с учетом текущей ситуации, когда значение поля известно заранее (0).

    Флаг наличия дополнительных фрагментов (MF) предполагается нулевым, поскольку фрагментации в идеальном случае не ожидается. Однако следует понимать, что в некоторых сценариях работы (например, в некоторых вариантах архитектуры туннелирования) фрагментация может возникать. В общем случае, тем не менее. предполагается отсутствие фрагментации в Internet (благодаря начальному согласованию MSS и последующему применению механизма path-MTU discovery). RFC 3095 [31] указывает, для протокола RTP только первый фрагмент будет содержать заголовок транспортного уровня и последующие фрагменты будут сжиматься с использованием другого профиля. Это нормальная ситуация для TCP. Если возникает фрагментация, первый фрагмент по определению будет относительно большим для минимизации относительного размера заголовков. Последующие фрагменты будут сжиматься с использованием другого профиля. Следовательно, представляется нежелательной оптимизация фрагментирования при сжатии заголовков. Флаг наличия дополнительных фрагментов в результате классифицируется как STATIC- KNOWN.

  • Fragment Offset — смещение фрагмента
  • В предположении отсутствия фрагментации смещение фрагмента всегда равно нулю. Следовательно, это поле классифицируется как STATIC-KNOWN. Даже если принимать во внимание фрагментацию, только первый фрагмент будет содержать заголовок TCP и смещение фрагмента в этом заголовке будет равно нулю.
  • Protocol — протокол
  • Это поле обычно имеет одинаковое значение во всех пакетах одного потока. Данное поле определяет тип последующего заголовка.

    Это поле меняет свое значение лишь в случае изменения последовательности заголовков (например, вставляется или удаляется расширение заголовка или туннельный заголовок). Следовательно, поле относится к классу STATIC. Будет ли такое изменение приводить к тому, что последовательность пакетов станет трактоваться как новый поток (с точки зрения сжатия заголовков) определяется профилем. Профили ROHC должны обеспечивать возможность работы с расширенными заголовками и туннелями, но выбор стратегии не входит в задачи данного документа.

  • Header Checksum — контрольная сумма заголовка
  • Контрольная сумма заголовка позволяет предотвратить обработку поврежденных пакетов. Когда почти вся информация заголовка IP представлена в сжатом виде, не возникает необходимости в использовании этой дополнительной контрольной суммы. Вместо этого значение контрольной суммы восстанавливается при декомпрессии. Следовательно, поле классифицируется как INFERRED.

    Отметим, что контрольная сумма заголовка TCP защищает не все заголовки TCP/IP, а только псевдо-заголовок TCP (и данные).

    ROHC [31] использует значение CRC для проверки несжатого заголовка. С учетом необходимости проверки корректности всего заголовка TCP/IP, затрат на расчет контрольной суммы TCP с учетом всех данных и известные недостатки контрольных сумм TCP [37] дополнительная проверка является необходимой. Следовательно, весьма желательно использование дополнительной контрольной суммы (такой, как CRC) для проверки корректности декомпрессии.

  • Source Addresses и Destination Addresses — адреса отправителя и получателя
  • Эти поля являются частью определения потока пакетов и, следовательно, являются неизменными для конкретного потока. Таким образом, поля классифицируются как STATIC-DEF.

Общие размеры заголовков разного класса показаны на рисунке 4:

КлассРазмер в октетах
INFERRED4
STATIC1,5
STATIC-DEF8
STATIC-KNOWN2,25
CHANGING4,25
Рисунок 4: Размеры полей
2007 - 2017 © Русские переводы RFC, IETF, ISOC.