RFC: 3748
Оригинал: Extensible Authentication Protocol (EAP)
Предыдущие версии: RFC 2284
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Николай Малых

RFC 3748, Страница 26 из 46

5.7. Расширенные типы

Поскольку большинство применений EAP связано с фирменной продукцией, введен отдельный тип, позволяющий произволителям поддерживать свои расширенные типы, не подходящие для общего применения.

Expanded Type также используется для расширения глобального пространства типов методов за пределы исходных 255 значений. Значение Vendor-Id = 0 отображает исходные 255 возможных типов в пространство из 2^32-1 возможных типов (тип 0 используется только в отклике Nak для индикации отсутствия предложений).

Поддерживающие атрибут Expanded реализации должны трактовать типы EAP со значением меньше 256 одинаково, независимо от формы их предствления — один октет или 32-битовое значение Vendor-Type в Expanded Type с Vendor-Id = 0. Партнеры, не поддерживающие Expanded Type, должны передавать отклик Nak, как описано в параграфе 5.3.1, и согласовывать более подходящий метод идентификации.

Формат и описание полей Expanded Type показаны ниже. Поля передаются, начиная с левого.

 0                   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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |               Vendor-Id                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Vendor-Type                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Vendor data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type
  • 254 для Expanded Type
  • Vendor-Id
  • Трехоктетное значение Vendor-Id представляет код SMI Network Management Private Enterprise Code для производителя с использованием сетевого порядка байтов (как выделено IANA). Нулевое значение Vendor-Id зарезервировано для использования IETF с целью расширения глобального пространства типов EAP.
  • Vendor-Type
  • Четырех октетное поле Vendor-Type представляет фирменный тип метода от указанного производителя.

    Если Vendor-Id = 0, поле Vendor-Type является расширением и надмножеством существующего пространства типов EAP. Первые 256 типов зарезервированы для совместимости с однооктетными типами EAP, которые уже определены или могут быть определены в будущем. Таким образом, типы EAP от 0 до 255 семантически одинаковы при их указании у однооктетных полях EAP Type или в полях Vendor-Type при Vendor-Id = 0. Из этого правила есть одно исключение — обычные и расширенные пакеты Nak относятся к одному типу, но должны трактоваться по разному, поскольку имеют различные форматы.

  • Vendor-Data
  • Поле Vendor-Data определяется производителем. При Vendor-Id = 0 поле Vendor-Data будет использоваться для доставки содержимого методов EAP с определенными IETF типами.

5.8. Experimental

Тип Experimental не имеет фиксированного формата и содержимого. Этот тип предназначен для экспериментов с новыми типами EAP. Назначение этого типа — эксперименты и тесты. При использовании этого типа нет никаких гарантий интероперабельности, как отмечено в [RFC3692].

  • Type
  • 255
  • Type-Data
  • Не определено.

Страница 26 из 46

2007 - 2022 © Русские переводы RFC, IETF, ISOC.