[要約] RFC 5872は、PANAプロトコルのためのIANAルールを定めています。このRFCの目的は、PANAプロトコルの拡張や新しいパラメータの割り当てに関するガイドラインを提供することです。
Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 5872 Ericsson
Updates: 5191 A. Yegin
Category: Standards Track Samsung
ISSN: 2070-1721 May 2010
IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)
ネットワークアクセスのために認証を運ぶためのプロトコルのIANAルール（PANA）
Abstract
概要
This document relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA).
このドキュメントは、ネットワークアクセス（PANA）の認証を運ぶためのプロトコルのIANAルールを緩和します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5872.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5872で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA) [RFC5191]. Rules for the following protocol fields, all defined in [RFC5191], are affected:
このドキュメントは、ネットワークアクセス（PANA）[RFC5191]の認証を運ぶためのプロトコルのIANAルールを緩和します。次のプロトコルフィールドのルールは、すべて[RFC5191]で定義されています。
o Message Types
o メッセージタイプ
o Message Flags
o メッセージフラグ
o Attribute-Value Pair (AVP) Flags
o 属性値ペア（AVP）フラグ
o Result-Code AVP Values
o 結果コードAVP値
o Termination-Cause AVP Values
o 終了原因AVP値
The rationale for this update is that there can be situations in which it makes sense to grant an allocation under special circumstances. At the time of this writing, the IETF is in the process of approving one such allocation. By changing the current IANA rules to allow for IESG Approval [RFC5226] as well, it has become possible for the Internet Engineering Steering Group (IESG) to consider an allocation request, even if it does not fulfill the default rule. For instance, an experimental protocol extension could perhaps deserve an allocation from a field of reserved bits, as long as a sufficient number of bits still remain for other purposes, and the PANA community is happy with such allocation.
この更新の理論的根拠は、特別な状況下で割り当てを付与することが理にかなっている状況がある可能性があるということです。この執筆時点で、IETFはそのような割り当てを承認する過程にあります。現在のIANAルールを変更してIESGの承認[RFC5226]も許可することにより、デフォルトのルールを満たしていなくても、インターネットエンジニアリングステアリンググループ（IESG）が割り当て要求を検討することが可能になりました。たとえば、実験的なプロトコル拡張は、おそらく、十分な数のビットが他の目的のために残っており、パナコミュニティがそのような割り当てに満足している限り、予約済みビットの分野からの割り当てに値する可能性があります。
IANA has updated the registries related to PANA Message Types, Message Flags, AVP Flags, Result-Code AVP Values, and Termination-Cause AVP Values, as specified below. All other PANA IANA registries are to remain unchanged.
IANAは、以下に指定されているように、PANAメッセージタイプ、メッセージフラグ、AVPフラグ、結果コードAVP値、および終端原因AVP値に関連するレジストリを更新しました。他のすべてのパナイアナレジストリは、変更されておくことができます。
The Message Types namespace is used to identify PANA messages. Value 0 is not used and is not assigned by IANA. The range of values from 1 - 65,519 are for permanent, standard Message Types, allocated by IETF Review or IESG Approval [RFC5226]. Previously, the rule for this range was allocation by IETF Review only. [RFC5191] defined the range of values from 1 - 4. The same Message Type is used for both the request and the answer messages, except for type 1. The Request bit distinguishes requests from answers.
メッセージタイプの名前空間は、パナメッセージを識別するために使用されます。値0は使用されず、IANAによって割り当てられていません。1〜65,519の値の範囲は、IETFレビューまたはIESG承認[RFC5226]によって割り当てられた永続的な標準メッセージタイプ用です。以前は、この範囲のルールはIETFレビューのみによる割り当てでした。[RFC5191]は、1〜4から値の範囲を定義しました。タイプ1を除き、要求と回答メッセージの両方に同じメッセージタイプが使用されます。リクエストビットは、リクエストを回答と区別します。
The range of values from 65,520 - 65,535 (hexadecimal values 0xfff0 - 0xffff) is reserved for experimental messages. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between the communicating PANA Client (PaC) and PANA Authentication Agent (PAA) using experimental commands, as outlined in [RFC3692].
65,520〜65,535（ヘキサデシマル値0xfff0-0xffff）の値の範囲は、実験メッセージ用に予約されています。これらのコードは実験目的とテスト目的のみを目的としているため、[RFC3692]で概説されているように、実験コマンドを使用して、通信PANAクライアント（PAC）とPANA認証エージェント（PAA）の間の相互運用性を保証することはできません。
There are 16 bits in the Flags field of the PANA message header. Section 6.2 of [RFC5191] assigned bit 0 ('R'), 1 ('S'), 2 ('C'), 3 ('A'), 4 ('P'), and 5 ('I'). Allocations from the remaining free bits in the PANA header Flag field are made via Standards Action or IESG Approval [RFC5226]. Previously, the rule for these bits was allocation by Standards Action only.
パナメッセージヘッダーのフラグフィールドには16ビットがあります。[RFC5191]のセクション6.2は、ビット0（ 'r'）、1（ 's'）、2（ 'c'）、3（ 'a'）、4（ 'p'）、および5（ 'i'）を割り当てました。。Pana Headerフラグフィールドの残りのフリービットからの割り当ては、標準アクションまたはIESG承認[RFC5226]によって行われます。以前は、これらのビットのルールは、標準訴訟のみによる割り当てのみでした。
There are 16 bits in the AVP Flags field of the AVP header, defined in Section 6.3 of [RFC5191]. That RFC also assigned bit 0 ('V'). The remaining bits are assigned via Standards Action or IESG Approval [RFC5226]. Previously, the rule for these bits was allocation by Standards Action only.
AVPヘッダーのAVPフラグフィールドには16ビットがあり、[RFC5191]のセクション6.3で定義されています。そのRFCはビット0（ 'v'）も割り当てました。残りのビットは、標準アクションまたはIESG承認[RFC5226]によって割り当てられます。以前は、これらのビットのルールは、標準訴訟のみによる割り当てのみでした。
As defined in Section 8.7 of [RFC5191], the Result-Code AVP (AVP Code 7) defines the values from 0 - 2.
[RFC5191]のセクション8.7で定義されているように、結果コードAVP（AVPコード7）は、0〜2の値を定義します。
All remaining values are available for assignment via IETF Review or IESG Approval [RFC5226]. Previously, the rule for these values was allocation by IETF Review only.
すべての残りの値は、IETFレビューまたはIESG承認[RFC5226]を介して割り当てに利用できます。以前は、これらの値のルールは、IETFレビューのみによる割り当てのみでした。
As defined in Section 8.9 of [RFC5191], the Termination-Cause AVP (AVP Code 9) defines the values 1, 4, and 8.
[RFC5191]のセクション8.9で定義されているように、終端原因AVP（AVPコード9）は、値1、4、および8を定義します。
All remaining values are available for assignment via IETF Review or IESG Approval [RFC5226]. Previously, the rule for these values was allocation by IETF Review only.
すべての残りの値は、IETFレビューまたはIESG承認[RFC5226]を介して割り当てに利用できます。以前は、これらの値のルールは、IETFレビューのみによる割り当てのみでした。
This specification does not change the security properties of PANA.
この仕様は、パナのセキュリティプロパティを変更しません。
However, a few words are necessary about the use of the experimental code points defined in Section 2.1. Potentially harmful side effects from the use of the experimental values need to be carefully evaluated before deploying any experiment across networks that the owner of the experiment does not entirely control. Guidance given in [RFC3692] about the use of experimental values needs to be followed.
ただし、セクション2.1で定義されている実験コードポイントの使用については、いくつかの単語が必要です。実験値の使用による潜在的に有害な副作用は、実験の所有者が完全に制御しないネットワーク全体で実験を展開する前に、慎重に評価する必要があります。実験値の使用に関する[RFC3692]で与えられたガイダンスに従う必要があります。
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191] Forsberg、D.、Ohba、Y.、Patil、B.、Tschofenig、H。、およびA. Yegin、「ネットワークアクセスの認証を運ぶためのプロトコル（PANA）」、RFC 5191、2008年5月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、2004年1月。
This document changes the IANA rules for: Message Types, Message Flags, AVP Flags, Result-Code AVP Values, and Termination-Cause AVP Values.
このドキュメントは、メッセージタイプ、メッセージフラグ、AVPフラグ、結果コードAVP値、および終端原因AVP値のIANAルールを変更します。
The authors would like to thank Yoshihiro Ohba, Ralph Droms, Magnus Westerlund, and Alfred Hoenes for reviews and comments on this topic.
著者は、このトピックに関するレビューとコメントについて、ヨシヒロ・オバ、ラルフ・ドロムズ、マグナス・ウェスターランド、アルフレッド・ホーネスに感謝したいと思います。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
Jari Arkko Ericsson Jorvas 02420フィンランド
EMail: jari.arkko@piuha.net
Alper Yegin Samsung Istanbul Turkey
Alper Yegin Samsung Istanbul Turkey
EMail: alper.yegin@yegin.org