インターネット エンジニアリング タスク フォース（IETF）のドラフト標準では、ネットワーク アクセス サーバと RADIUS サーバ間でベンダー固有の属性（VSA）を使用してベンダー固有の情報を伝達する方法が規定されています。VSA を使用すれば、ベンダーは一般的な用途に適さない独自の拡張属性をサポートできます。VSA は XML ファイル内で事前に定義されます。XML ファイルにベンダー固有の属性を追加する必要があり、この XML ファイルがコントローラにダウンロードされます。このサポートを有効にするためにコントローラ上で実施しなければならない設定はありません。ファイルには、XML タグを指定するための XML スキーマで規定されている特定の形式で RADIUS 属性が含まれています。

定義されたベンダー固有の属性を含むXML ファイルは FTP サーバからダウンロードできます。ダウンロードしたファイルはフラッシュ メモリに保存され、複数のリブート プロセスを通して保持されます。ファイルは、ダウンロードが成功したときとコントローラが起動するたびに解析されます。XML ファイルは RADIUS サーバにアップロードして認証とアカウンティングに使用できます。コントローラは、これらの値を解析すると、そのファイルをベンダー固有の属性を保存するための別のデータ構造に保存します。また、指定された使用形式に基づいて、認証パケットとアカウンティング パケットのどちらかまたはその両方でこれらの属性値を使用します。ファイルにエラーが含まれている場合は、コントローラの解析が失敗して、属性が適用されません。ファイル内のエラーを修正するか、ファイルを FTP サーバからコントローラにダウンロードし直す必要があります。

モバイル クライアントが WLAN にアソシエートするときに、RADIUS レルムが認証要求パケット内の EAP-AKA ID 応答要求の一部として受信されます。WLAN のネットワーク アクセス識別子（NAI）形式（EAP-AKA）は、0<IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org として指定できます。NAI 形式のレルムは @ 記号の後ろに示され、wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org のように指定されます。ベンダー固有の属性が MCC については 311、MNC については 480 ～ 489 として追加された場合、その NAI 形式は 0311480999999999@wlan.mnc480.mcc311.3gppnetwork.org のように指定できます。

モバイル加入者の場合、コントローラは、デバイスから受信した NAI 形式のレルムが特定の標準に従っている場合にのみ、AAA サーバに認証要求を送信します。認証とは別に、アカウンティング要求もレルム フィルタリングに基づいて AAA サーバに送信する必要があります。

コントローラ上でレルム フィルタリングをサポートするには、RADIUS 上でレルムを設定する必要があります。ユーザが特定の SSID を使用して接続されている場合、RADIUS サーバ上で設定されたレルムに対して受信された NAI 形式を使用してユーザが認証および認可されます。

WLAN 上のレルム サポート

各 WLAN は NAI レルムをサポートするように設定されます。レルムが特定の SSID に対して有効になっている場合は、RADIUS サーバ上で設定されたレルムに対して EAP ID 応答で受信されたレルムを照合するためのルックアップが実施されます。

RADIUS サーバ上のレルム サポート

（注）	NAI レルムが WLAN 上で有効になっていても、レルムがユーザ名に含まれていない場合は、動作がデフォルトでルックアップなしに設定され、RADIUS サーバの通常の選択が使用されます。

（注）	クライアントが高速再認証識別を使用すると、コントローラで対応する要求を正しいサーバに転送するために、認証サーバからレルム名が要求されます。

EAP-AKA をレルムと組み合わせて使用したとき、eap サーバがユーザ名部分とレルム部分の両方がある AT_NEXT_REAUTH_ID 属性で応答すると、高速再認証がサポートされます。レルムの目的は、受信コントローラが後続の高速再認証要求で正しいサーバをつかまえることです。たとえば EAP-AKA をサポートしているしているホスト apd サーバはレルム部分をサポートしません。したがって Cisco WLC は、この互換性がある eap サーバについてのみ、高速再認証をサポートしています。