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
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).
本文件放宽了IANA关于承载网络访问认证（PANA）协议的规则。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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:
本文件放宽了IANA关于承载网络访问认证（PANA）协议的规则[RFC5191]。[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规则以允许IEESG批准[RCF5226]，互联网工程指导组（IESG）也有可能考虑分配请求，即使它不履行默认规则。例如，一个实验性协议扩展可能应该从保留位字段中分配，只要仍有足够数量的位用于其他目的，并且PANA社区对这种分配感到满意。
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值相关的注册表，如下所述。所有其他PANA IANA注册保持不变。
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.
消息类型命名空间用于标识PANA消息。值0未使用，且未由IANA分配。从1到65519的值范围适用于IETF审查或IESG批准分配的永久性标准消息类型[RFC5226]。在此之前，该范围的规则仅由IETF Review分配。[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].
从65520到65535（十六进制值0xfff0到0xffff）的值范围保留给实验消息。由于这些代码仅用于实验和测试目的，因此无法保证使用实验命令进行通信的PANA客户端（PaC）和PANA身份验证代理（PAA）之间的互操作性，如[RFC3692]所述。
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.
PANA消息头的标志字段中有16位。[RFC5191]第6.2节分配了位0（'R'）、1（'S'）、2（'C'）、3（'A'）、4（'P'）和5（'I'）。通过标准操作或IESG批准[RFC5226]从PANA标头标志字段中的剩余空闲位进行分配。以前，这些位的规则是仅按标准操作分配。
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.
[RFC5191]第6.3节中定义的AVP报头的AVP标志字段中有16位。该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 Review分配。
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 Review分配。
This specification does not change the security properties of PANA.
本规范不会更改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 51912008年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.
本文档更改IANA规则：消息类型、消息标志、AVP标志、结果代码AVP值和终止原因AVP值。
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
雅丽爱立信芬兰公司02420
EMail: jari.arkko@piuha.net
EMail: jari.arkko@piuha.net
Alper Yegin Samsung Istanbul Turkey
土耳其伊斯坦布尔阿尔珀·耶金酒店
EMail: alper.yegin@yegin.org
EMail: alper.yegin@yegin.org