[要約] RFC 3575は、RADIUS（Remote Authentication Dial In User Service）のIANA（Internet Assigned Numbers Authority）に関する考慮事項をまとめたものです。このRFCの目的は、RADIUSプロトコルの拡張や新しい属性の割り当てに関するガイドラインを提供することです。
Network Working Group B. Aboba
Request for Comments: 3575 Microsoft
Updates: 2865 July 2003
Category: Standard Track
IANA Considerations for RADIUS (Remote Authentication Dial In User Service)
RADIUSのIANAの考慮事項（ユーザーサービスのリモート認証ダイヤル）
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS).
このドキュメントでは、ユーザーサービス（RADIUS）のリモート認証ダイヤルに関するIANAの考慮事項について説明します。
This document updates RFC 2865.
このドキュメントは、RFC 2865を更新します。
This document provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the Remote Authentication Dial In User Service (RADIUS), defined in [RFC2865], in accordance with BCP 26, [RFC2434]. It also reserves Packet Type Codes that are or have been in use on the Internet.
このドキュメントは、BCP 26、[RFC2434]に従って、[RFC2865]で定義されているユーザーサービス（RADIUS）に関連するリモート認証ダイヤル（RADIUS）に関連する値の登録に関するインターネット割り当てされた番号局（IANA）にガイダンスを提供します。また、インターネットで使用されている、または使用されているパケットタイプコードも予約します。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration".
ここでは、BCP 26で定義されている意味で次の用語を使用しています：「名前スペース」、「割り当てられた値」、「登録」。
The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IESG Approval", "IETF Consensus", "Standards Action".
ここでは、BCP 26で定義されている意味で次のポリシーが使用されています。「私的使用」、「最初の到着」、「エキスパートレビュー」、「必要な仕様」、「IESG承認」、「IETFコンセンサス」、「標準アクション」で使用されます。。
There are three name spaces in RADIUS that require registration: Packet Type Codes, Attribute Types, and Attribute Values (for certain Attributes). This document creates no new IANA registries, since a RADIUS registry was created by [RFC2865].
登録を必要とする半径には、パケットタイプコード、属性タイプ、および属性値（特定の属性）の3つの名前スペースがあります。このドキュメントは、[RFC2865]によって半径レジストリが作成されたため、新しいIANAレジストリを作成しません。
RADIUS is not intended as a general-purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to Authentication, Authorization or Accounting.
RADIUSは汎用プロトコルとして意図されておらず、認証、承認、または会計に関係のない目的のために割り当てを行うべきではありません。
For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. However, the Designated Expert can approve allocations once it seems clear that an RFC will be published, allowing for the allocation of values prior to the document being approved for publication as an RFC. The Designated Expert will post a request to the AAA WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request, publish a notice of the decision to the AAA WG mailing list or its successor, and inform IANA of its decision. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.
指定された専門家に相談する必要がある登録要求のために、責任あるIESGエリアディレクターは指定された専門家を任命する必要があります。意図は、すべての割り当てに公開されたRFCが伴うことです。ただし、指定された専門家は、RFCが公開されていることが明らかになったら、割り当てを承認することができ、ドキュメントがRFCとして公開される前に値の割り当てを許可することができます。指定された専門家は、インターネットドラフトを含むコメントとレビューのために、AAA WGメーリングリスト（またはエリアディレクターが指定した後継者）にリクエストを投稿します。30日間が経過する前に、指定された専門家は登録要求を承認または拒否し、決定の通知をAAA WGメーリングリストまたはその後継者に公開し、IANAの決定を通知します。拒否通知は、説明によって正当化されなければならず、可能な場合は、要求をどのように修正できるかについての具体的な提案を受け入れるようにしなければなりません。
Packet Type Codes have a range from 1 to 253. RADIUS Type Codes 1-5 and 11-13 were allocated in [RFC2865], while Type Codes 40-45, 250-253 are allocated by this document. Type Codes 250-253 are allocated for Experimental Uses, and 254-255 are reserved. Packet Type Codes 6-10, 12-13, 21-34, 50-51 have no meaning defined by an IETF RFC, but are reserved until a specification is provided for them. This is being done to avoid interoperability problems with software that implements non-standard RADIUS extensions that are or have been in use on the Internet. Because a new Packet Type has considerable impact on interoperability, a new Packet Type Code requires IESG Approval. The intention is that any allocation will be accompanied by a published RFC. Type Codes 52-249 should be allocated first; when these are exhausted, Type Codes 14-20, 35-39, 46-49 may be allocated. For a list of Type Codes, see Appendix A.
パケットタイプのコードの範囲は1から253の範囲です。半径タイプコード1-5および11-13は[RFC2865]に割り当てられ、タイプコード40-45、250-253はこのドキュメントによって割り当てられています。タイプコード250-253は実験用途に割り当てられ、254-255は予約されています。パケットタイプコード6-10、12-13、21-34、50-51には、IETF RFCによって定義された意味はありませんが、仕様が提供されるまで予約されています。これは、インターネット上で使用されている、または使用されている非標準半径拡張機能を実装するソフトウェアの相互運用性の問題を回避するために行われています。新しいパケットタイプは相互運用性に大きな影響を与えるため、新しいパケットタイプコードにはIESGの承認が必要です。意図は、すべての割り当てに公開されたRFCが伴うことです。タイプコード52-249を最初に割り当てる必要があります。これらが使い果たされると、タイプコード14-20、35-39、46-49が割り当てられる場合があります。タイプコードのリストについては、付録Aを参照してください。
Attribute Types have a range from 1 to 255, and are the scarcest resource in RADIUS, thus must be allocated with care. Attributes 1-53,55,60-88,90-91,94-100 have been allocated, with 17 and 21 available for re-use. Attributes 17, 21, 54, 56-59, 89, 101-191 may be allocated by IETF Consensus. It is recommended that attributes 17 and 21 be used only after all others are exhausted.
属性タイプの範囲は1〜255であり、半径で最も少ないリソースであるため、注意して割り当てる必要があります。属性1-53,55,60-88,90-91,94-100が割り当てられ、17と21が再利用可能です。属性17、21、54、56-59、89、101-191は、IETFコンセンサスによって割り当てられる可能性があります。属性は、他のすべてが使い果たされた後にのみ使用することをお勧めします。
Note that RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. For functions specific only to one vendor's implementation of RADIUS, the use of that should be encouraged instead of the allocation of global attribute types.
RADIUSは、ベンダー固有の拡張機能（属性26）のメカニズムを定義し、1つのベンダーのRADIUSの実装のみに固有の関数のメカニズムを定義します。1つのベンダーのRADIUSの実装に固有の関数の場合、グローバル属性タイプの割り当てではなく、その使用を奨励する必要があります。
As noted in [RFC2865]:
[RFC2865]に記載されているように：
Attribute Type Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used.
属性タイプの値192-223は実験用に予約され、値224-240は実装固有の使用のために予約され、値241-255は予約されており、使用しないでください。
Therefore Attribute Type values 192-240 are considered Private Use, and values 241-255 require Standards Action.
したがって、属性タイプの値192-240は私的使用と見なされ、値241-255には標準アクションが必要です。
Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Additional values can be allocated by the Designated Expert. The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS. Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus. The intention is that any allocation will be accompanied by a published RFC.
RADIUSの特定の属性（たとえば、NAS-Port-Type）は、さまざまな意味に対応する値のリストを定義します。各属性に40億（2^32）の値があります。指定された専門家によって追加の値を割り当てることができます。このポリシーの例外は、Service-Type属性（6）です。その値は、RADIUSの新しい動作モードを定義しています。サービスタイプの属性の値1〜16が割り当てられています。新しいサービスタイプの値の割り当ては、IETFコンセンサスによるものです。意図は、すべての割り当てに公開されたRFCが伴うことです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B。およびJ. Vollbrecht、「ローミングにおけるプロキシチェーンと政策の実施」、RFC 2607、1999年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867] Zorn、G.、Aboba、B。、およびD. Mitton、「トンネルプロトコルサポートのための半径会計変更」、RFC 2867、2000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。and I. Goyret、「トンネルプロトコルサポートのRadius属性」、RFC 2868、2000年6月。
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W。and P. Calhoun、「Radius Extensions」、RFC 2869、2000年6月。
[RFC2869bis] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", Work in Progress.
[RFC2869BIS] Aboba、B。およびP. Calhoun、「拡張可能な認証プロトコル（EAP）の半径サポート」、進行中の作業。
[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2882] Mitton、D。、「ネットワークアクセスサーバー要件：拡張RADIUSプラクティス」、RFC 2882、2000年7月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。およびD. Mitton、「Radius and IPv6」、RFC 3162、2001年8月。
[DynAuth] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[Dynauth] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D。、およびB. Aboba、「ユーザーサービスのリモート認証ダイヤル（RADIUS）へのダイナミック認証拡張」、2003年7月。
The security considerations detailed in [RFC2434] are generally applicable to this document. Security considerations relating to the RADIUS protocol are discussed in [RFC2607], [RFC2865], [RFC3162], [DynAuth], and [RFC2869bis].
[RFC2434]で詳述されているセキュリティ上の考慮事項は、一般にこのドキュメントに適用されます。半径プロトコルに関連するセキュリティ上の考慮事項については、[RFC2607]、[RFC2865]、[RFC3162]、[Dynauth]、および[RFC2869BIS]で説明しています。
Appendix A - RADIUS Packet Types
付録A-半径パケットタイプ
A list of RADIUS Packet Type Codes is given below. This document instructs IANA to list them in the registry of Packet Type Codes. Note that Type Codes 40-45, defined in [DynAuth], are being formally allocated here. Codes 40-45 were listed in [RFC2882] and have been implemented and used. Given their current widespread usage, these assignments are not reclaimable in practice.
RADIUSパケットタイプコードのリストを以下に示します。このドキュメントは、IANAにパケットタイプコードのレジストリにそれらをリストするように指示します。[dynauth]で定義されているタイプコード40-45は、ここで正式に割り当てられていることに注意してください。コード40-45は[RFC2882]にリストされ、実装および使用されています。現在の広範な使用法を考えると、これらの割り当ては実際には埋め立てできません。
# Message Reference
---- ------------------------- ---------
1 Access-Request [RFC2865]
2 Access-Accept [RFC2865]
3 Access-Reject [RFC2865]
4 Accounting-Request [RFC2865]
5 Accounting-Response [RFC2865]
6 Accounting-Status [RFC2882]
(now Interim Accounting)
7 Password-Request [RFC2882]
8 Password-Ack [RFC2882]
9 Password-Reject [RFC2882]
10 Accounting-Message [RFC2882]
11 Access-Challenge [RFC2865]
12 Status-Server (experimental) [RFC2865]
13 Status-Client (experimental) [RFC2865]
21 Resource-Free-Request [RFC2882]
22 Resource-Free-Response [RFC2882]
23 Resource-Query-Request [RFC2882]
24 Resource-Query-Response [RFC2882]
25 Alternate-Resource-
Reclaim-Request [RFC2882]
26 NAS-Reboot-Request [RFC2882]
27 NAS-Reboot-Response [RFC2882]
28 Reserved
29 Next-Passcode [RFC2882]
# Message Reference
---- ------------------------- ---------
30 New-Pin [RFC2882]
31 Terminate-Session [RFC2882]
32 Password-Expired [RFC2882]
33 Event-Request [RFC2882]
34 Event-Response [RFC2882]
40 Disconnect-Request [DynAuth]
41 Disconnect-ACK [DynAuth]
42 Disconnect-NAK [DynAuth]
43 CoA-Request [DynAuth]
44 CoA-ACK [DynAuth]
45 CoA-NAK [DynAuth]
50 IP-Address-Allocate [RFC2882]
51 IP-Address-Release [RFC2882]
250-253 Experimental Use
254 Reserved
255 Reserved [RFC2865]
Intellectual Property Statement
知的財産声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連の文書における権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
Acknowledgments
謝辞
Thanks to Ignacio Goyret of Lucent, Allison Mankin of Lucent Bell Labs, Thomas Narten of IBM, Glen Zorn and Harald Alvestrand of Cisco for discussions relating to this document.
LucentのIgnacio Goyret、Lucent Bell LabsのAllison Mankin、IBMのThomas Narten、Glen Zorn、およびCiscoのHarald Alvestrandに感謝します。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。