RFC: 4675
Оригинал: RADIUS Attributes for Virtual LAN and Priority Support
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Николай Малых

RFC 4675, Страница 2 из 8

1.2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

1.3. Интерпретация атрибутов

Описанные в этом документе атрибуты применяются к одному экземпляру порта NAS (точнее говоря, к одному порту моста IEEE 802.1Q. Стандарты [IEEE-802.1Q], [IEEE-802.1D] и [IEEE-802.1X] не распознают более тонкое разделение, нежели уровень порта. В некоторых случаях (например, в беспроводных ЛВС IEEE 802.11) вместо физических портов используется понятие виртуального порта. Такие виртуальные порты обычно связаны с защищенными соедиениями и представляются как станция или MAC-адрес.

Атрибуты, определенные в этом документе, применяются на уровне отдельного пользователя и предполагается, что на каждый порт приходится один пользователь; однако в некоторых случаях порт может быть виртуальным. Если реализация NAS, соответствующая этому документу, поддерживает виртуальные порты, может оказаться возможным предоставление таким портам уникальных значений описанных здесь атрибутов. Такой подход позволяет множеству пользователей на одном физическом порту использовать уникальные для каждого пользователя наборы параметров аутентификации.

Если соответствующий данной спецификации сервер NAS получает пакет Access-Accept, содержащий определенный в этом документе атрибут, который сервер не может применить, сервер должен действовать как при получении пакета Access-Reject. [RFC3576] требует, чтобы сервер NAS, получивший запрос CoA-Request, отвечал на него пакетом CoA-NAK, если запрос включал неподдерживаемый атрибут. Рекомендуется включать в такой пакет CoA-NAK атрибут Error-Cause со значением Unsupported Attribute (401). Как указано в [RFC3576], смена авторизации является атомарной операцией, поэтому в такой ситуации не происходит к разрыва сеанса и существующая конфигурация остается неизменной. В результате генерировать пакет учета (accounting) не следует.

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