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 Payload 0 Резерв 1-32 Security Association SA 33 Key Exchange KE 34 Identification — Initiator IDi 35 Identification — Responder IDr 36 Certificate CERT 37 Certificate Request CERTREQ 38 Authentication AUTH 39 Nonce Ni, Nr 40 Notify N 41 Delete D 42 Vendor ID V 43 Traffic Selector — Initiator TSi 44 Traffic Selector — Responder TSr 45 Encrypted E 46 Configuration CP 47 Extensible Authentication EAP 48 Резерв IANA 49-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 октета) — размер текущего элемента данных в октетах с учетом базового заголовка.