RFC: 4306
Оригинал: Internet Key Exchange (IKEv2) Protocol
Другие версии: RFC 2407, RFC 2408, RFC 2409, RFC 5996
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

3.2. Базовый заголовок элемента данных

Каждый из элементов данных (payload) IKE, определенных в параграфах 3.3 — 3.16, начинается с базового заголовка (Рисунок 5). Рисунки в описании каждого элемента включают базовый заголовок, но описания полей для краткости опущены и приводятся только в этом параграфе

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5: Формат базового заголовка данных
  • Next Payload (1 октет) — идентификатор типа следующего элемента данных в сообщении. Если текущий элемент является последним, это поле имеет значение 0. Это поле позволяет создавать «цепочки», когда дополнительный элемент просто добавляется в конец сообщения и устанавливается значение поля Next Payload в предыдущем элементе для индикации типа нового элемента. Элемент типа Encrypted, который всегда должен быть последним в сообщении, является исключением. Он содержит структуры данных в формате дополнительных элементов. В заголовке элемента Encrypted поле Next Payload устанавливается в соответствии с типом первого вложенного элемента (вместо 0).

    Значения Payload Type показаны на таблице:

    Тип Next PayloadОбозначениеЗначение
    No Next Payload0
    Резерв1-32
    Security AssociationSA33
    Key ExchangeKE34
    Identification — InitiatorIDi35
    Identification — ResponderIDr36
    CertificateCERT37
    Certificate RequestCERTREQ38
    AuthenticationAUTH39
    NonceNi, Nr40
    NotifyN41
    DeleteD42
    Vendor IDV43
    Traffic Selector — InitiatorTSi44
    Traffic Selector — ResponderTSr45
    EncryptedE46
    ConfigurationCP47
    Extensible AuthenticationEAP48
    Резерв IANA49-127
    Для частного применения128-255

    Значения типов 1-32 не следует использовать во избежание перекрытия со значениями, применяемыми в IKEv1. Типы 49-127 зарезервированы IANA для будущего распределения в IKEv2 (см. параграф 6). Типы 128-255 выделены для частного применения по согласованию сторон.

  • Critical (1 бит) — это поле должно иметь значение 0, если отправитель хочет, чтобы получатель пропустил этот элемент, если он не понимает код в поле Next Payload предыдущего элемента. Если получатель понимает тип элемента, он должен игноорировать этот флаг. Это поле должно устанавливаться в 0 для определенных в документе типов элементов данных. Отметим, что флаг критичности относится к текущему элементу данных, а не к следующему, чей тип указывается в первом октете. Причина сбрасывания бита критичности для определенных здесь элементов заключается в том, что все реализации должны поддерживать все типы элементов, определенные в этой спецификации, и, следовательно, должны игнорировать значение флага Critical. Предполагается, что пропускаемые элементы будут иметь корректные значения полей Next Payload и Payload Length.
  • RESERVED (7 битов) — должно иметь нулевое значение при передаче и игнорироваться на приеме.
  • Payload Length (2 октета) — размер текущего элемента данных в октетах с учетом базового заголовка.
2007 - 2017 © Русские переводы RFC, IETF, ISOC.