Internet Engineering Task Force (IETF) A. Perez-Mendez, Ed.
Request for Comments: 7499 R. Marin-Lopez
Category: Experimental F. Pereniguez-Garcia
ISSN: 2070-1721 G. Lopez-Millan
University of Murcia
D. Lopez
Telefonica I+D
A. DeKok
Network RADIUS
April 2015
Internet Engineering Task Force (IETF) A. Perez-Mendez, Ed.
Request for Comments: 7499 R. Marin-Lopez
Category: Experimental F. Pereniguez-Garcia
ISSN: 2070-1721 G. Lopez-Millan
University of Murcia
D. Lopez
Telefonica I+D
A. DeKok
Network RADIUS
April 2015
Support of Fragmentation of RADIUS Packets
支持RADIUS数据包的碎片化
Abstract
摘要
The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers.
远程身份验证拨入用户服务（RADIUS）协议的总数据包大小限制为4096字节。存在通过访问质询数据包在多个数据包之间分割大量认证数据的规定。不存在对大量授权数据进行碎片化的类似规定。本文档指定如何利用现有RADIUS机制来提供该功能。这些机制在很大程度上与现有实现兼容，它们被设计为对代理不可见，对遗留RADIUS客户端和服务器“故障安全”。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7499.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7499.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Requirements Language ......................................6
2. Status of This Document .........................................6
3. Scope of This Document ..........................................7
4. Overview .......................................................10
5. Fragmentation of Packets .......................................13
5.1. Pre-Authorization .........................................14
5.2. Post-Authorization ........................................18
6. Chunk Size .....................................................21
7. Allowed Large Packet Size ......................................22
8. Handling Special Attributes ....................................23
8.1. Proxy-State Attribute .....................................23
8.2. State Attribute ...........................................24
8.3. Service-Type Attribute ....................................25
8.4. Rebuilding the Original Large Packet ......................25
9. New T Flag for the Long Extended Type Attribute Definition .....26
10. New Attribute Definition ......................................26
10.1. Frag-Status Attribute ....................................27
10.2. Proxy-State-Length Attribute .............................28
10.3. Table of Attributes ......................................29
11. Operation with Proxies ........................................29
11.1. Legacy Proxies ...........................................29
11.2. Updated Proxies ..........................................29
12. General Considerations ........................................31
12.1. T Flag ...................................................31
12.2. Violation of RFC 2865 ....................................32
12.3. Proxying Based on User-Name ..............................32
12.4. Transport Behavior .......................................33
13. Security Considerations .......................................33
14. IANA Considerations ...........................................34
15. References ....................................................35
15.1. Normative References .....................................35
15.2. Informative References ...................................35
Acknowledgements ..................................................37
Authors' Addresses ................................................37
1. Introduction ....................................................4
1.1. Requirements Language ......................................6
2. Status of This Document .........................................6
3. Scope of This Document ..........................................7
4. Overview .......................................................10
5. Fragmentation of Packets .......................................13
5.1. Pre-Authorization .........................................14
5.2. Post-Authorization ........................................18
6. Chunk Size .....................................................21
7. Allowed Large Packet Size ......................................22
8. Handling Special Attributes ....................................23
8.1. Proxy-State Attribute .....................................23
8.2. State Attribute ...........................................24
8.3. Service-Type Attribute ....................................25
8.4. Rebuilding the Original Large Packet ......................25
9. New T Flag for the Long Extended Type Attribute Definition .....26
10. New Attribute Definition ......................................26
10.1. Frag-Status Attribute ....................................27
10.2. Proxy-State-Length Attribute .............................28
10.3. Table of Attributes ......................................29
11. Operation with Proxies ........................................29
11.1. Legacy Proxies ...........................................29
11.2. Updated Proxies ..........................................29
12. General Considerations ........................................31
12.1. T Flag ...................................................31
12.2. Violation of RFC 2865 ....................................32
12.3. Proxying Based on User-Name ..............................32
12.4. Transport Behavior .......................................33
13. Security Considerations .......................................33
14. IANA Considerations ...........................................34
15. References ....................................................35
15.1. Normative References .....................................35
15.2. Informative References ...................................35
Acknowledgements ..................................................37
Authors' Addresses ................................................37
The RADIUS [RFC2865] protocol carries authentication, authorization, and accounting information between a RADIUS Client and a RADIUS Server. Information is exchanged between them through RADIUS packets. Each RADIUS packet is composed of a header, and zero or more attributes, up to a maximum packet size of 4096 bytes. The protocol is a request/response protocol, as described in the operational model ([RFC6158], Section 3.1).
RADIUS[RFC2865]协议在RADIUS客户端和RADIUS服务器之间传输身份验证、授权和记帐信息。它们之间通过RADIUS数据包交换信息。每个RADIUS数据包由一个报头和零个或多个属性组成，最大数据包大小为4096字节。该协议是一个请求/响应协议，如操作模型（[RFC6158]，第3.1节）所述。
The intention of the above packet size limitation was to avoid UDP fragmentation as much as possible. Back then, a size of 4096 bytes seemed large enough for any purpose. Now, new scenarios are emerging that require the exchange of authorization information exceeding this 4096-byte limit. For instance, the Application Bridging for Federated Access Beyond web (ABFAB) IETF working group defines the transport of Security Assertion Markup Language (SAML) statements from the RADIUS Server to the RADIUS Client [SAML-RADIUS]. This assertion is likely to be larger than 4096 bytes.
上述数据包大小限制的目的是尽可能避免UDP碎片。当时，4096字节的大小似乎足以满足任何用途。现在，新的场景正在出现，需要交换超过4096字节限制的授权信息。例如，web之外的联邦访问应用程序桥接（ABFAB）IETF工作组定义了安全断言标记语言（SAML）语句从RADIUS服务器到RADIUS客户端的传输[SAML-RADIUS]。此断言可能大于4096字节。
This means that peers desiring to send large amounts of data must fragment it across multiple packets. For example, RADIUS-EAP [RFC3579] defines how an Extensible Authentication Protocol (EAP) exchange occurs across multiple Access-Request / Access-Challenge sequences. No such exchange is possible for accounting or authorization data. [RFC6158], Section 3.1 suggests that exchanging large amounts of authorization data is unnecessary in RADIUS. Instead, the data should be referenced by name. This requirement allows large policies to be pre-provisioned and then referenced in an Access-Accept. In some cases, however, the authorization data sent by the RADIUS Server is large and highly dynamic. In other cases, the RADIUS Client needs to send large amounts of authorization data to the RADIUS Server. Neither of these cases is met by the requirements in [RFC6158]. As noted in that document, the practical limit on RADIUS packet sizes is governed by the Path MTU (PMTU), which may be significantly smaller than 4096 bytes. The combination of the two limitations means that there is a pressing need for a method to send large amounts of authorization data between RADIUS Client and Server, with no accompanying solution.
这意味着，希望发送大量数据的对等方必须跨多个数据包对其进行分段。例如，RADIUS-EAP[RFC3579]定义了可扩展身份验证协议（EAP）交换如何跨多址请求/访问质询序列进行。不可能对会计或授权数据进行此类交换。[RFC6158]，第3.1节建议在RADIUS中不需要交换大量授权数据。相反，应该按名称引用数据。此要求允许预先设置大型策略，然后在Access Accept中引用。但是，在某些情况下，RADIUS服务器发送的授权数据很大且高度动态。在其他情况下，RADIUS客户端需要向RADIUS服务器发送大量授权数据。这两种情况都不符合[RFC6158]中的要求。如该文档中所述，RADIUS数据包大小的实际限制由路径MTU（PMTU）控制，该路径MTU（PMTU）可能显著小于4096字节。这两个限制的结合意味着迫切需要一种在RADIUS客户端和服务器之间发送大量授权数据的方法，而不需要相应的解决方案。
[RFC6158], Section 3.1 recommends three approaches for the transmission of large amounts of data within RADIUS. However, they are not applicable to the problem statement of this document for the following reasons:
[RFC6158]，第3.1节建议在RADIUS内传输大量数据的三种方法。但是，由于以下原因，它们不适用于本文件的问题陈述：
o The first approach (utilization of a sequence of packets) does not talk about large amounts of data sent from the RADIUS Client to a RADIUS Server. Leveraging EAP (request/challenge) to send the data is not feasible, as EAP already fills packets to PMTU, and not all authentications use EAP. Moreover, as noted for the NAS-Filter-Rule attribute ([RFC4849]), this approach does not entirely solve the problem of sending large amounts of data from a RADIUS Server to a RADIUS Client, as many current RADIUS attributes are not permitted in Access-Challenge packets.
o 第一种方法（利用一系列数据包）不涉及从RADIUS客户端发送到RADIUS服务器的大量数据。利用EAP（请求/质询）发送数据是不可行的，因为EAP已经将数据包填充到PMTU，并且并非所有身份验证都使用EAP。此外，如NAS筛选规则属性（[RFC4849]）所述，这种方法并不能完全解决从RADIUS服务器向RADIUS客户端发送大量数据的问题，因为在访问质询数据包中不允许使用许多当前RADIUS属性。
o The second approach (utilization of names rather than values) is not usable either, as using names rather than values is difficult when the nature of the data to be sent is highly dynamic (e.g., a SAML statement or NAS-Filter-Rule attributes). URLs could be used as a pointer to the location of the actual data, but their use would require them to be (a) dynamically created and modified, (b) securely accessed, and (c) accessible from remote systems. Satisfying these constraints would require the modification of several networking systems (e.g., firewalls and web servers). Furthermore, the setup of an additional trust infrastructure (e.g., Public Key Infrastructure (PKI)) would be required to allow secure retrieval of the information from the web server.
o 第二种方法（使用名称而不是值）也不可用，因为当要发送的数据的性质是高度动态的（例如，SAML语句或NAS筛选规则属性）时，使用名称而不是值是很困难的。URL可以用作指向实际数据位置的指针，但它们的使用需要（a）动态创建和修改，（b）安全访问，（c）从远程系统访问。要满足这些限制条件，需要修改几个网络系统（例如防火墙和web服务器）。此外，还需要建立一个额外的信任基础设施（例如公钥基础设施（PKI）），以便能够从web服务器安全检索信息。
o PMTU discovery does not solve the problem, as it does not allow the sending of data larger than the minimum of (PMTU or 4096) bytes.
o PMTU发现无法解决此问题，因为它不允许发送大于最小（PMTU或4096）字节的数据。
This document provides a mechanism to allow RADIUS peers to exchange large amounts of authorization data exceeding the 4096-byte limit by fragmenting it across several exchanges. The proposed solution does not impose any additional requirements to the RADIUS system administrators (e.g., need to modify firewall rules, set up web servers, configure routers, or modify any application server). It maintains compatibility with intra-packet fragmentation mechanisms (like those defined in [RFC3579] or [RFC6929]). It is also transparent to existing RADIUS proxies, which do not implement this specification. The only systems needing to implement this RFC are the ones that either generate or consume the fragmented data being transmitted. Intermediate proxies just pass the packets without changes. Nevertheless, if a proxy supports this specification, it may reassemble the data in order to examine and/or modify it.
本文档提供了一种机制，允许RADIUS对等方通过在多个交换中分割授权数据来交换超过4096字节限制的大量授权数据。建议的解决方案不会对RADIUS系统管理员提出任何额外要求（例如，需要修改防火墙规则、设置web服务器、配置路由器或修改任何应用程序服务器）。它保持与包内分段机制（如[RFC3579]或[RFC6929]中定义的机制）的兼容性。它对现有的RADIUS代理也是透明的，这些代理未实现此规范。唯一需要实现此RFC的系统是生成或使用正在传输的碎片数据的系统。中间代理只传递数据包而不做任何更改。然而，如果代理支持此规范，它可以重新组装数据以检查和/或修改它。
A different approach to deal with RADIUS packets above the 4096-byte limit is described in [RADIUS-Larger-Pkts], which proposes to extend RADIUS over TCP by allowing the Length field in the RADIUS header to take values up to 65535 bytes. This provides a simpler operation, but it has the drawback of requiring every RADIUS proxy in the path between the RADIUS Client and the RADIUS Server to implement the extension as well.
[RADIUS Larger Pkts]中描述了一种处理超过4096字节限制的RADIUS数据包的不同方法，该方法建议通过允许RADIUS报头中的长度字段取值高达65535字节来扩展TCP上的RADIUS。这提供了一个更简单的操作，但其缺点是需要RADIUS客户端和RADIUS服务器之间的路径中的每个RADIUS代理也实现扩展。
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 RFC 2119 [RFC2119]. When these words appear in lower case, they have their natural language meaning.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。当这些单词以小写字母出现时，它们就有了自然语言的含义。
This document is an Experimental RFC. It defines a proposal to allow the sending and receiving of data exceeding the 4096-byte limit in RADIUS packets imposed by [RFC2865], without requiring the modification of intermediary proxies.
本文档是一个实验性RFC。它定义了一个方案，允许发送和接收超过[RFC2865]规定的RADIUS数据包4096字节限制的数据，而无需修改中间代理。
The experiment consists of verifying whether the approach is usable in a large-scale environment, by observing the uptake, usability, and operational behavior it shows in large-scale, real-life deployments. In that sense, so far the main use case for this specification is the transportation of large SAML statements defined within the ABFAB architecture [ABFAB-Arch]. Hence, it can be tested wherever an ABFAB deployment is being piloted.
该实验包括通过观察该方法在大规模实际部署中的使用、可用性和操作行为，验证该方法在大规模环境中是否可用。从这个意义上讲，到目前为止，本规范的主要用例是在ABFAB架构[ABFAB Arch]中定义的大型SAML语句的传输。因此，无论ABFAB部署在何处进行试点，都可以对其进行测试。
Besides, this proposal defines some experimental features that will need to be tested and verified before the document can be considered for the Standards Track. The first one of them is the requirement of updating [RFC2865] in order to relax the sentence defined in Section 4.1 of that document that states that "An Access-Request MUST contain either a User-Password or a CHAP-Password or a State." This specification might generate Access-Request packets without any of these attributes. Although all known implementations have chosen the philosophy of "be liberal in what you accept," we need to gain more operational experience to verify that unmodified proxies do not drop these types of packets. More details on this aspect can be found in Section 12.2.
此外，该提案定义了一些实验特性，这些特性需要在考虑将文档用于标准跟踪之前进行测试和验证。其中第一个是更新[RFC2865]的要求，以放宽该文件第4.1节中定义的句子，即“访问请求必须包含用户密码或CHAP密码或状态”。该规范可能生成不包含任何这些属性的访问请求数据包。尽管所有已知的实现都选择了“接受自由”的理念，但我们需要获得更多的操作经验，以验证未修改的代理不会丢弃这些类型的数据包。有关这方面的更多详细信息，请参见第12.2节。
Another experimental feature of this specification is that it requires proxies to base their routing decisions on the value of the RADIUS User-Name attribute. Our experience is that this is the common behavior; thus, no issues are expected. However, it needs to be confirmed after using different implementations of intermediate proxies. More details on this aspect can be found in Section 12.3.
该规范的另一个实验特性是，它要求代理根据RADIUS用户名属性的值来决定路由。我们的经验是，这是常见的行为；因此，预计不会出现任何问题。但是，在使用不同的中间代理实现之后，需要对其进行确认。有关这方面的更多详细信息，请参见第12.3节。
Moreover, this document requires two minor updates to Standards Track documents. First, it modifies the definition of the Reserved field of the Long Extended Type attribute [RFC6929] by allocating an additional flag called the T (Truncation) flag. No issues are expected with this update, although some proxies might drop packets that do not have the Reserved field set to 0. More details on this aspect can be found in Section 12.1.
此外，本文件要求对标准跟踪文件进行两次小的更新。首先，它通过分配一个称为T（截断）标志的附加标志来修改长扩展类型属性[RFC6929]的保留字段的定义。虽然某些代理可能会丢弃保留字段未设置为0的数据包，但此更新不会出现任何问题。有关这方面的更多详细信息，请参见第12.1节。
The other Standards Track document that requires a minor update is [RFC6158]. It states that "attribute designers SHOULD NOT assume that a RADIUS implementation can successfully process RADIUS packets larger than 4096 bytes," something no longer true if this document advances.
需要少量更新的其他标准跟踪文档是[RFC6158]。它指出，“属性设计器不应假设RADIUS实现可以成功处理大于4096字节的RADIUS数据包”，如果本文档继续，这一点不再成立。
A proper "Updates" clause will be included for these modifications when/if the experiment is successful and this document is reissued as a Standards Track document.
当/如果试验成功且本文件作为标准跟踪文件重新发布时，这些修改将包含适当的“更新”条款。
This specification describes how a RADIUS Client and a RADIUS Server can exchange data exceeding the 4096-byte limit imposed by one packet. However, the mechanism described in this specification SHOULD NOT be used to exchange more than 100 kilobytes of data. Any more than this may turn RADIUS into a generic transport protocol, such as TCP or the Stream Control Transmission Protocol (SCTP), which is undesirable. Experience shows that attempts to transport bulk data across the Internet with UDP will inevitably fail, unless these transport attempts reimplement all of the behavior of TCP. The underlying design of RADIUS lacks the proper retransmission policies or congestion control mechanisms that would make it a competitor of TCP.
本规范描述了RADIUS客户端和RADIUS服务器如何交换超过一个数据包施加的4096字节限制的数据。但是，本规范中描述的机制不应用于交换超过100KB的数据。如果超过此值，RADIUS可能会变成通用传输协议，如TCP或流控制传输协议（SCTP），这是不可取的。经验表明，使用UDP在Internet上传输大量数据的尝试将不可避免地失败，除非这些传输尝试重新实现TCP的所有行为。RADIUS的底层设计缺乏适当的重传策略或拥塞控制机制，这将使其成为TCP的竞争对手。
Therefore, RADIUS/UDP transport is by design unable to transport bulk data. It is both undesirable and impossible to change the protocol at this point in time. This specification is intended to allow the transport of more than 4096 bytes of data through existing RADIUS/UDP proxies. Other solutions such as RADIUS/TCP MUST be used when a "green field" deployment requires the transport of bulk data.
因此，RADIUS/UDP传输在设计上无法传输批量数据。此时更改协议既不可取，也不可能。本规范旨在允许通过现有RADIUS/UDP代理传输4096字节以上的数据。当“绿地”部署需要传输大容量数据时，必须使用其他解决方案，如RADIUS/TCP。
Section 7, below, describes in further detail what is considered to be a reasonable amount of data and recommends that administrators adjust limitations on data transfer according to the specific capabilities of their existing systems in terms of memory and processing power.
下文第7节进一步详细说明了合理的数据量，并建议管理员根据其现有系统在内存和处理能力方面的具体能力调整数据传输限制。
Moreover, its scope is limited to the exchange of authorization data, as other exchanges do not require such a mechanism. In particular, authentication exchanges have already been defined to overcome this limitation (e.g., RADIUS-EAP). Moreover, as they represent the most critical part of a RADIUS conversation, it is preferable to not introduce into their operation any modification that may affect existing equipment.
此外，其范围仅限于授权数据的交换，因为其他交换不需要这种机制。特别是，已经定义了身份验证交换以克服此限制（例如RADIUS-EAP）。此外，由于它们是RADIUS对话中最关键的部分，因此最好不要在其操作中引入任何可能影响现有设备的修改。
There is no need to fragment accounting packets either. While the accounting process can send large amounts of data, that data is typically composed of many small updates. That is, there is no demonstrated need to send indivisible blocks of more than 4 kilobytes of data. The need to send large amounts of data per user session often originates from the need for flow-based accounting. In this use case, the RADIUS Client may send accounting data for many thousands of flows, where all those flows are tied to one user session. The existing Acct-Multi-Session-Id attribute defined in [RFC2866], Section 5.11 has been proven to work here.
也不需要分割记帐数据包。虽然记帐过程可以发送大量数据，但这些数据通常由许多小更新组成。也就是说，不需要发送超过4KB数据的不可分割块。每个用户会话发送大量数据的需求通常源于对基于流的记帐的需求。在这个用例中，RADIUS客户端可以发送数千个流的记帐数据，其中所有这些流都绑定到一个用户会话。[RFC2866]第5.11节中定义的现有Acct多会话Id属性已在此处证明有效。
Similarly, there is no need to fragment Change-of-Authorization (CoA) [RFC5176] packets. Instead, according to [RFC5176], the CoA client will send a CoA-Request packet containing session identification attributes, along with Service-Type = Additional-Authorization, and a State attribute. Implementations not supporting fragmentation will respond with a CoA-NAK and an Error-Cause of Unsupported-Service.
类似地，不需要对授权变更（CoA）[RFC5176]数据包进行分段。相反，根据[RFC5176]，CoA客户端将发送包含会话标识属性、服务类型=附加授权和状态属性的CoA请求包。不支持分段的实现将以CoA NAK和不支持服务的错误原因进行响应。
The above requirement does not assume that the CoA client and the RADIUS Server are co-located. They may, in fact, be run on separate parts of the infrastructure, or even by separate administrators. There is, however, a requirement that the two communicate. We can see that the CoA client needs to send session identification attributes in order to send CoA packets. These attributes cannot be known a priori by the CoA client and can only come from the RADIUS Server. Therefore, even when the two systems are not co-located, they must be able to communicate in order to operate in unison. The alternative is for the two systems to have differing views of the users' authorization parameters; such a scenario would be a security disaster.
上述要求并不假设CoA客户端和RADIUS服务器位于同一位置。事实上，它们可以在基础设施的不同部分上运行，甚至可以由不同的管理员运行。然而，有一个要求，即两者之间的沟通。我们可以看到，CoA客户端需要发送会话标识属性才能发送CoA数据包。CoA客户端无法预先知道这些属性，只能从RADIUS服务器获得。因此，即使这两个系统不在同一位置，它们也必须能够通信，以便协调工作。另一种选择是两个系统对用户的授权参数有不同的看法；这种情况将是一场安全灾难。
This specification does not allow for fragmentation of CoA packets. Allowing for fragmented CoA packets would involve changing multiple parts of the RADIUS protocol; such changes introduce the risk of implementation issues, mistakes, etc.
本规范不允许CoA数据包的碎片化。允许分段CoA数据包将涉及更改RADIUS协议的多个部分；此类变更会带来实施问题、错误等风险。
Where CoA clients (i.e., RADIUS Servers) need to send large amounts of authorization data to a CoA server (i.e., RADIUS Client), they need only send a minimal CoA-Request packet containing a Service-Type of Authorize Only, as per [RFC5176], along with session identification attributes. This CoA packet serves as a signal to the RADIUS Client that the users' session requires re-authorization. When the RADIUS Client re-authorizes the user via Access-Request, the RADIUS Server can perform fragmentation and send large amounts of authorization data to the RADIUS Client.
当CoA客户端（即RADIUS服务器）需要向CoA服务器（即RADIUS客户端）发送大量授权数据时，根据[RFC5176]，它们只需发送包含仅授权服务类型的最小CoA请求数据包，以及会话标识属性。此CoA数据包用作向RADIUS客户端发送的用户会话需要重新授权的信号。当RADIUS客户端通过访问请求重新授权用户时，RADIUS服务器可以执行碎片化并向RADIUS客户端发送大量授权数据。
The assumption in the above scenario is that the CoA client and RADIUS Server are co-located, or at least strongly coupled. That is, the path from CoA client to CoA server SHOULD be the exact reverse of the path from RADIUS Client to RADIUS Server. The following diagram will hopefully clarify the roles:
上述场景中的假设是CoA客户端和RADIUS服务器位于同一位置，或者至少是强耦合的。也就是说，从CoA客户端到CoA服务器的路径应该与从RADIUS客户端到RADIUS服务器的路径完全相反。下图有望阐明这些角色：
+----------------+
| RADIUS CoA |
| Client Server |
+----------------+
| ^
Access-Request | | CoA-Request
v |
+----------------+
| RADIUS CoA |
| Server Client |
+----------------+
+----------------+
| RADIUS CoA |
| Client Server |
+----------------+
| ^
Access-Request | | CoA-Request
v |
+----------------+
| RADIUS CoA |
| Server Client |
+----------------+
Where there is a proxy involved:
如果涉及代理：
+----------------+
| RADIUS CoA |
| Client Server |
+----------------+
| ^
Access-Request | | CoA-Request
v |
+----------------+
| RADIUS CoA |
| Proxy Proxy |
+----------------+
| ^
Access-Request | | CoA-Request
v |
+----------------+
| RADIUS CoA |
| Server Client |
+----------------+
+----------------+
| RADIUS CoA |
| Client Server |
+----------------+
| ^
Access-Request | | CoA-Request
v |
+----------------+
| RADIUS CoA |
| Proxy Proxy |
+----------------+
| ^
Access-Request | | CoA-Request
v |
+----------------+
| RADIUS CoA |
| Server Client |
+----------------+
That is, the RADIUS and CoA subsystems at each hop are strongly connected. Where they are not strongly connected, it will be impossible to use CoA-Request packets to transport large amounts of authorization data.
也就是说，每个跃点处的RADIUS和CoA子系统是强连接的。如果它们不是强连接的，则不可能使用CoA请求数据包来传输大量授权数据。
This design is more complicated than allowing for fragmented CoA packets. However, the CoA client and the RADIUS Server must communicate even when not using this specification. We believe that standardizing that communication and using one method for exchange of large data are preferred to unspecified communication methods and multiple ways of achieving the same result. If we were to allow fragmentation of data over CoA packets, the size and complexity of this specification would increase significantly.
这种设计比允许支离破碎的CoA数据包更复杂。但是，即使不使用此规范，CoA客户端和RADIUS服务器也必须通信。我们认为，与未指明的通信方法和实现相同结果的多种方式相比，更倾向于将该通信标准化并使用一种方法交换大数据。如果我们允许CoA数据包上的数据碎片化，那么该规范的大小和复杂性将显著增加。
The above requirement solves a number of issues. It clearly separates session identification from authorization. Without this separation, it is difficult to both identify a session and change its authorization using the same attribute. It also ensures that the authorization process is the same for initial authentication and for CoA.
上述要求解决了许多问题。它清楚地将会话标识与授权分开。如果没有这种分离，就很难使用相同的属性识别会话并更改其授权。它还确保初始身份验证和CoA的授权过程相同。
Authorization exchanges can occur either before or after end-user authentication has been completed. An authorization exchange before authentication allows a RADIUS Client to provide the RADIUS Server with information that MAY modify how the authentication process will
授权交换可以在最终用户身份验证完成之前或之后进行。身份验证前的授权交换允许RADIUS客户端向RADIUS服务器提供可能修改身份验证过程的方式的信息
be performed (e.g., it may affect the selection of the EAP method). An authorization exchange after authentication allows the RADIUS Server to provide the RADIUS Client with information about the end user, the results of the authentication process, and/or obligations to be enforced. In this specification, we refer to "pre-authorization" as the exchange of authorization information before the end-user authentication has started (from the RADIUS Client to the RADIUS Server), whereas the term "post-authorization" is used to refer to an authorization exchange happening after this authentication process (from the RADIUS Server to the RADIUS Client).
执行（例如，可能影响EAP方法的选择）。身份验证后的授权交换允许RADIUS服务器向RADIUS客户端提供有关最终用户、身份验证过程的结果和/或要强制执行的义务的信息。在本规范中，我们将“预授权”称为最终用户身份验证开始之前（从RADIUS客户端到RADIUS服务器）的授权信息交换，而术语“后授权”用于指在该身份验证过程之后发生的授权交换（从RADIUS服务器到RADIUS客户端）。
In this specification, we refer to the "size limit" as the practical limit on RADIUS packet sizes. This limit is the minimum between 4096 bytes and the current PMTU. We define below a method that uses Access-Request and Access-Accept in order to exchange fragmented data. The RADIUS Client and Server exchange a series of Access-Request / Access-Accept packets, until such time as all of the fragmented data has been transported. Each packet contains a Frag-Status attribute, which lets the other party know if fragmentation is desired, ongoing, or finished. Each packet may also contain the fragmented data or may instead be an "ACK" to a previous fragment from the other party. Each Access-Request contains a User-Name attribute, allowing the packet to be proxied if necessary (see Section 11.1). Each Access-Request may also contain a State attribute, which serves to tie it to a previous Access-Accept. Each Access-Accept contains a State attribute, for use by the RADIUS Client in a later Access-Request. Each Access-Accept contains a Service-Type attribute with the "Additional-Authorization" value. This indicates that the service being provided is part of a fragmented exchange and that the Access-Accept should not be interpreted as providing network access to the end user.
在本规范中，我们将“大小限制”称为RADIUS数据包大小的实际限制。此限制是4096字节和当前PMTU之间的最小值。我们在下面定义了一种使用访问请求和访问接受来交换碎片数据的方法。RADIUS客户端和服务器交换一系列访问请求/访问接受数据包，直到所有碎片数据传输完毕。每个数据包都包含一个Frag Status属性，它让另一方知道碎片是需要的、正在进行的还是已完成的。每个分组还可以包含片段数据，或者可以是对来自另一方的先前片段的“ACK”。每个访问请求都包含一个用户名属性，允许在必要时代理数据包（见第11.1节）。每个访问请求还可以包含一个状态属性，该属性用于将其与以前的访问接受绑定。每个访问接受都包含一个状态属性，供RADIUS客户端在以后的访问请求中使用。每个访问接受都包含一个带有“附加授权”值的服务类型属性。这表明所提供的服务是分段交换的一部分，访问接受不应解释为向最终用户提供网络访问。
When a RADIUS Client or RADIUS Server needs to send data that exceeds the size limit, the mechanism proposed in this document is used. Instead of encoding one large RADIUS packet, a series of smaller RADIUS packets of the same type are encoded. Each smaller packet is called a "chunk" in this specification, in order to distinguish it from traditional RADIUS packets. The encoding process is a simple linear walk over the attributes to be encoded. This walk preserves the order of the attributes of the same type, as required by [RFC2865]. The number of attributes encoded in a particular chunk depends on the size limit, the size of each attribute, the number of proxies between the RADIUS Client and RADIUS Server, and the overhead for fragmentation-signaling attributes. Specific details are given in Section 6. A new attribute called Frag-Status (Section 10.1) signals the fragmentation status.
当RADIUS客户端或RADIUS服务器需要发送超过大小限制的数据时，将使用本文档中建议的机制。不是对一个大半径数据包进行编码，而是对一系列相同类型的小半径数据包进行编码。在本规范中，每个较小的数据包称为“块”，以区别于传统的RADIUS数据包。编码过程是对要编码的属性进行简单的线性遍历。按照[RFC2865]的要求，此遍历保留相同类型属性的顺序。在特定区块中编码的属性数量取决于大小限制、每个属性的大小、RADIUS客户端和RADIUS服务器之间的代理数量以及碎片信令属性的开销。具体细节见第6节。称为Frag Status（第10.1节）的新属性表示碎片状态。
After the first chunk is encoded, it is sent to the other party. The packet is identified as a chunk via the Frag-Status attribute. The other party then requests additional chunks, again using the Frag-Status attribute. This process is repeated until all the attributes have been sent from one party to the other. When all the chunks have been received, the original list of attributes is reconstructed and processed as if it had been received in one packet.
对第一个区块进行编码后，将其发送给另一方。通过Frag Status属性将数据包标识为块。然后，另一方再次使用Frag Status属性请求额外的块。重复此过程，直到将所有属性从一方发送到另一方。当所有的区块都被接收时，原始的属性列表被重建和处理，就好像它在一个包中被接收一样。
The reconstruction process is performed by simply appending all of the chunks together. Unlike IPv4 fragmentation, there is no Fragment Offset field. The chunks in this specification are explicitly ordered, as RADIUS is a lock-step protocol, as noted in Section 12.4. That is, chunk N+1 cannot be sent until all of the chunks up to and including N have been received and acknowledged.
重建过程通过简单地将所有块附加在一起来执行。与IPv4碎片不同，没有碎片偏移量字段。本规范中的块是明确排序的，因为RADIUS是一个锁步协议，如第12.4节所述。也就是说，在接收到并确认N之前（包括N）的所有区块之前，无法发送区块N+1。
When multiple chunks are sent, a special situation may occur for Long Extended Type attributes as defined in [RFC6929]. The fragmentation process may split a fragmented attribute across two or more chunks, which is not permitted by that specification. We address this issue by using the newly defined T flag in the Reserved field of the Long Extended Type attribute format (see Section 9 for further details on this flag).
当发送多个块时，[RFC6929]中定义的长扩展类型属性可能会出现特殊情况。碎片化过程可能会将碎片化属性拆分为两个或多个块，这是该规范所不允许的。我们通过在长扩展类型属性格式的保留字段中使用新定义的T标志来解决此问题（有关此标志的更多详细信息，请参见第9节）。
This last situation is expected to be the most common occurrence in chunks. Typically, packet fragmentation will occur as a consequence of a desire to send one or more large (and therefore fragmented) attributes. The large attribute will likely be split into two or more pieces. Where chunking does not split a fragmented attribute, no special treatment is necessary.
这最后一种情况预计将是最常见的块发生。通常，由于希望发送一个或多个大的（因此是碎片化的）属性，会出现数据包碎片。“大”属性可能会被拆分为两个或多个部分。如果分块不会分割碎片属性，则无需特殊处理。
The setting of the T flag is the only case where the chunking process affects the content of an attribute. Even then, the Value fields of all attributes remain unchanged. Any per-packet security attributes, such as Message-Authenticator, are calculated for each chunk independently. Neither integrity checks nor security checks are performed on the "original" packet.
T标志的设置是分块过程影响属性内容的唯一情况。即使如此，所有属性的值字段仍保持不变。每个数据包的任何安全属性（如消息验证器）都是为每个数据块独立计算的。对“原始”数据包既不执行完整性检查，也不执行安全检查。
Each RADIUS packet sent or received as part of the chunking process MUST be a valid packet, subject to all format and security requirements. This requirement ensures that a "transparent" proxy not implementing this specification can receive and send compliant packets. That is, a proxy that simply forwards packets without detailed examination or any modification will be able to proxy "chunks".
作为分块过程的一部分发送或接收的每个RADIUS数据包必须是有效的数据包，符合所有格式和安全要求。此要求确保未实现此规范的“透明”代理可以接收和发送符合要求的数据包。也就是说，只转发数据包而不进行详细检查或任何修改的代理将能够代理“块”。
When the RADIUS Client or the RADIUS Server desires to send a packet that exceeds the size limit, it is split into chunks and sent via multiple client/server exchanges. The exchange is indicated via the Frag-Status attribute, which has value More-Data-Pending for all but the last chunk of the series. The chunks are tied together via the State attribute.
当RADIUS客户端或RADIUS服务器希望发送超过大小限制的数据包时，会将其分为多个数据块，并通过多个客户端/服务器交换发送。交换是通过Frag Status属性来指示的，该属性对系列的最后一个块以外的所有块都有值更多的数据挂起。这些块通过State属性绑定在一起。
The delivery of a large fragmented RADIUS packet with authorization data can happen before or after the end user has been authenticated by the RADIUS Server. We can distinguish two phases, which can be omitted if there is no authorization data to be sent:
带有授权数据的大片段RADIUS数据包的交付可以在RADIUS服务器对最终用户进行身份验证之前或之后进行。我们可以区分两个阶段，如果没有要发送的授权数据，可以省略这两个阶段：
1. Pre-authorization. In this phase, the RADIUS Client MAY send a large packet with authorization information to the RADIUS Server before the end user is authenticated. Only the RADIUS Client is allowed to send authorization data during this phase.
1. 预授权。在此阶段，RADIUS客户端可能会在对最终用户进行身份验证之前向RADIUS服务器发送一个包含授权信息的大数据包。在此阶段，仅允许RADIUS客户端发送授权数据。
2. Post-authorization. In this phase, the RADIUS Server MAY send a large packet with authorization data to the RADIUS Client after the end user has been authenticated. Only the RADIUS Server is allowed to send authorization data during this phase.
2. 后授权。在此阶段中，RADIUS服务器可在最终用户经过身份验证后，向RADIUS客户端发送包含授权数据的大数据包。在此阶段，仅允许RADIUS服务器发送授权数据。
The following subsections describe how to perform fragmentation for packets for these two phases. We give the packet type, along with a RADIUS Identifier, to indicate that requests and responses are connected. We then give a list of attributes. We do not give values for most attributes, as we wish to concentrate on the fragmentation behavior rather than packet contents. Attribute values are given for attributes relevant to the fragmentation process. Where "long extended" attributes are used, we indicate the M (More) and T (Truncation) flags as optional square brackets after the attribute name. As no "long extended" attributes have yet been defined, we use example attributes, named as "Example-Long-1", etc. For the sake of simplicity, the maximum chunk size is established in terms of the number of attributes (11).
以下小节描述了如何对这两个阶段的数据包执行分段。我们给出数据包类型以及RADIUS标识符，以指示请求和响应已连接。然后我们给出一个属性列表。我们不为大多数属性提供值，因为我们希望专注于碎片行为，而不是数据包内容。为与分段过程相关的属性提供属性值。在使用“长扩展”属性的情况下，我们将M（更多）和T（截断）标志指示为属性名称后的可选方括号。由于尚未定义“长扩展”属性，因此我们使用名为“example-long-1”的示例属性。为了简单起见，根据属性的数量确定最大块大小（11）。
When the RADIUS Client needs to send a large amount of data to the RADIUS Server, the data to be sent is split into chunks and sent to the RADIUS Server via multiple Access-Request / Access-Accept exchanges. The example below shows this exchange.
当RADIUS客户端需要向RADIUS服务器发送大量数据时，将要发送的数据分为多个数据块，并通过多访问请求/访问接受交换发送到RADIUS服务器。下面的示例显示了此交换。
The following is an Access-Request that the RADIUS Client intends to send to a RADIUS Server. However, due to a combination of issues (PMTU, large attributes, etc.), the content does not fit into one Access-Request packet.
以下是RADIUS客户端打算发送到RADIUS服务器的访问请求。但是，由于一系列问题（PMTU、大型属性等），内容不适合一个访问请求数据包。
Access-Request
User-Name
NAS-Identifier
Calling-Station-Id
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [M]
Example-Long-2
Access-Request
User-Name
NAS-Identifier
Calling-Station-Id
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [M]
Example-Long-2
Figure 1: Desired Access-Request
图1：所需的访问请求
The RADIUS Client therefore must send the attributes listed above in a series of chunks. The first chunk contains eight (8) attributes from the original Access-Request, and a Frag-Status attribute. Since the last attribute is "Example-Long-1" with the M flag set, the chunking process also sets the T flag in that attribute. The Access-Request is sent with a RADIUS Identifier field having value 23. The Frag-Status attribute has value More-Data-Pending, to indicate that the RADIUS Client wishes to send more data in a subsequent Access-Request. The RADIUS Client also adds a Service-Type attribute, which indicates that it is part of the chunking process. The packet is signed with the Message-Authenticator attribute, completing the maximum number of attributes (11).
因此，RADIUS客户端必须以一系列块的形式发送上面列出的属性。第一个区块包含来自原始访问请求的八（8）个属性和一个Frag Status属性。由于最后一个属性是“Example-Long-1”，并设置了M标志，因此分块过程也在该属性中设置了T标志。访问请求与值为23的RADIUS标识符字段一起发送。Frag Status属性的值为More Data Pending，表示RADIUS客户端希望在后续访问请求中发送更多数据。RADIUS客户端还添加了一个服务类型属性，该属性表示它是分块过程的一部分。使用消息验证器属性对数据包进行签名，完成最大属性数（11）。
Access-Request (ID = 23)
User-Name
NAS-Identifier
Calling-Station-Id
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [MT]
Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization
Message-Authenticator
Access-Request (ID = 23)
User-Name
NAS-Identifier
Calling-Station-Id
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [MT]
Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization
Message-Authenticator
Figure 2: Access-Request (Chunk 1)
图2：访问请求（区块1）
Compliant RADIUS Servers (i.e., servers implementing fragmentation) receiving this packet will see the Frag-Status attribute and will postpone all authorization and authentication handling until all of the chunks have been received. This postponement also applies to the verification that the Access-Request packet contains some kind of authentication attribute (e.g., User-Password, CHAP-Password, State, or other future attribute), as required by [RFC2865] (see Section 12.2 for more information on this).
接收此数据包的兼容RADIUS服务器（即，实现碎片化的服务器）将看到Frag Status属性，并将推迟所有授权和身份验证处理，直到接收到所有数据块。这种延迟也适用于验证访问请求数据包是否包含[RFC2865]所要求的某种身份验证属性（例如，用户密码、CHAP密码、状态或其他未来属性）（有关此方面的更多信息，请参阅第12.2节）。
Non-compliant RADIUS Servers (i.e., servers not implementing fragmentation) should also see the Service-Type requesting provisioning for an unknown service and return Access-Reject. Other non-compliant RADIUS Servers may return an Access-Reject or Access-Challenge, or they may return an Access-Accept with a particular Service-Type other than Additional-Authorization. Compliant RADIUS Client implementations MUST treat these responses as if they had received Access-Reject instead.
不符合要求的RADIUS服务器（即，未实现碎片化的服务器）还应查看请求为未知服务提供的服务类型，并返回访问拒绝。其他不符合要求的RADIUS服务器可能会返回访问拒绝或访问质询，或者它们可能会返回具有特定服务类型（而非附加授权）的访问接受。兼容的RADIUS客户端实现必须将这些响应视为接收到访问拒绝。
Compliant RADIUS Servers who wish to receive all of the chunks will respond with the following packet. The value of the State here is arbitrary and serves only as a unique token for example purposes. We only note that it MUST be temporally unique to the RADIUS Server.
希望接收所有区块的兼容RADIUS服务器将使用以下数据包进行响应。此处的状态值是任意的，仅用作唯一的令牌（例如）。我们只注意到，它必须是RADIUS服务器在时间上唯一的。
Access-Accept (ID = 23) Frag-Status = More-Data-Request Service-Type = Additional-Authorization State = 0xabc00001 Message-Authenticator
访问接受（ID=23）Frag状态=更多数据请求服务类型=附加授权状态=0xabc00001消息验证器
Figure 3: Access-Accept (Chunk 1)
图3：访问接受（区块1）
The RADIUS Client will see this response and use the RADIUS Identifier field to associate it with an ongoing chunking session. Compliant RADIUS Clients will then continue the chunking process. Non-compliant RADIUS Clients will never see a response such as this, as they will never send a Frag-Status attribute. The Service-Type attribute is included in the Access-Accept in order to signal that the response is part of the chunking process. This packet therefore does not provision any network service for the end user.
RADIUS客户端将看到此响应，并使用RADIUS标识符字段将其与正在进行的分块会话相关联。然后，符合要求的RADIUS客户端将继续分块过程。不兼容的RADIUS客户端永远不会看到这样的响应，因为它们永远不会发送Frag Status属性。服务类型属性包含在Access Accept中，以表示响应是分块过程的一部分。因此，该数据包不为最终用户提供任何网络服务。
The RADIUS Client continues the process by sending the next chunk, which includes an additional six (6) attributes from the original packet. It again includes the User-Name attribute, so that non-compliant proxies can process the packet (see Section 11.1). It sets the Frag-Status attribute to More-Data-Pending, as more data is pending. It includes a Service-Type, for the reasons described above. It includes the State attribute from the previous Access-Accept. It signs the packet with Message-Authenticator, as there are no authentication attributes in the packet. It uses a new RADIUS Identifier field.
RADIUS客户端通过发送下一个数据块来继续该过程，该数据块包括来自原始数据包的另外六（6）个属性。它还包括用户名属性，以便不符合要求的代理可以处理数据包（参见第11.1节）。它将Frag Status属性设置为更多数据挂起，因为有更多数据挂起。出于上述原因，它包括一个服务类型。它包括上一次访问的State属性。它使用消息验证器对数据包进行签名，因为数据包中没有身份验证属性。它使用一个新的半径标识符字段。
Access-Request (ID = 181)
User-Name
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [MT]
Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization
State = 0xabc000001
Message-Authenticator
Access-Request (ID = 181)
User-Name
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [MT]
Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization
State = 0xabc000001
Message-Authenticator
Figure 4: Access-Request (Chunk 2)
图4：访问请求（区块2）
Compliant RADIUS Servers receiving this packet will see the Frag-Status attribute and look for a State attribute. Since one exists and it matches a State sent in an Access-Accept, this packet is part of a chunking process. The RADIUS Server will associate the attributes with the previous chunk. Since the Frag-Status attribute has value More-Data-Request, the RADIUS Server will respond with an Access-Accept as before. It MUST include a State attribute, with a value different from the previous Access-Accept. This State MUST again be globally and temporally unique.
接收此数据包的兼容RADIUS服务器将看到Frag Status属性并查找State属性。由于存在一个数据包，并且它与访问接受中发送的状态相匹配，因此该数据包是分块过程的一部分。RADIUS服务器将属性与上一个块相关联。由于Frag Status属性具有value More Data请求，RADIUS服务器将像以前一样使用Access Accept进行响应。它必须包含一个State属性，其值不同于先前的Access Accept。这种状态必须在全球和时间上都是唯一的。
Access-Accept (ID = 181) Frag-Status = More-Data-Request Service-Type = Additional-Authorization State = 0xdef00002 Message-Authenticator
访问接受（ID=181）Frag状态=更多数据请求服务类型=附加授权状态=0xdef00002消息验证器
Figure 5: Access-Accept (Chunk 2)
图5：访问接受（区块2）
The RADIUS Client will see this response and use the RADIUS Identifier field to associate it with an ongoing chunking session. The RADIUS Client continues the chunking process by sending the next chunk, with the final attribute(s) from the original packet, and again includes the original User-Name attribute. The Frag-Status attribute is not included in the next Access-Request, as no more chunks are available for sending. The RADIUS Client includes the State attribute from the previous Access-Accept. It signs the packet with Message-Authenticator, as there are no authentication attributes in the packet. It again uses a new RADIUS Identifier field.
RADIUS客户端将看到此响应，并使用RADIUS标识符字段将其与正在进行的分块会话相关联。RADIUS客户端通过发送下一个数据块（带有原始数据包的最终属性）来继续分块过程，并再次包括原始用户名属性。Frag Status属性不包括在下一个访问请求中，因为没有更多的块可用于发送。RADIUS客户端包含上一个Access Accept中的状态属性。它使用消息验证器对数据包进行签名，因为数据包中没有身份验证属性。它再次使用新的半径标识符字段。
Access-Request (ID = 241) User-Name Example-Long-2 State = 0xdef00002 Message-Authenticator
访问请求（ID=241）用户名示例-Long-2状态=0xdef00002消息验证器
Figure 6: Access-Request (Chunk 3)
图6：访问请求（区块3）
On reception of this last chunk, the RADIUS Server matches it with an ongoing session via the State attribute and sees that there is no Frag-Status attribute present. It then processes the received attributes as if they had been sent in one RADIUS packet. See Section 8.4 for further details on this process. It generates the appropriate response, which can be either Access-Accept or Access-Reject. In this example, we show an Access-Accept. The RADIUS Server MUST send a State attribute, which allows linking the received data with the authentication process.
在接收到最后一个数据块时，RADIUS服务器通过State属性将其与正在进行的会话进行匹配，并发现不存在Frag Status属性。然后，它处理接收到的属性，就好像它们是在一个RADIUS数据包中发送的一样。有关此过程的更多详细信息，请参见第8.4节。它生成适当的响应，可以是访问接受或访问拒绝。在本例中，我们展示了一个Access Accept。RADIUS服务器必须发送一个State属性，该属性允许将接收到的数据与身份验证过程链接起来。
Access-Accept (ID = 241) State = 0x98700003 Message-Authenticator
访问接受（ID=241）状态=0x98700003消息验证器
Figure 7: Access-Accept (Chunk 3)
图7：访问接受（区块3）
The above example shows in practice how the chunking process works. We reiterate the implementation and security requirements here.
上面的例子在实践中展示了分块过程是如何工作的。我们在此重申执行和安全要求。
Each chunk is a valid RADIUS packet (see Section 12.2 for some considerations about this), and all RADIUS format and security requirements MUST be followed before any chunking process is applied.
每个数据块都是一个有效的RADIUS数据包（有关这方面的一些注意事项，请参见第12.2节），在应用任何数据块处理之前，必须遵循所有RADIUS格式和安全要求。
Every chunk except for the last one from a RADIUS Client MUST include a Frag-Status attribute, with value More-Data-Pending. The last chunk MUST NOT contain a Frag-Status attribute. Each chunk except for the last one from a RADIUS Client MUST include a Service-Type attribute, with value Additional-Authorization. Each chunk MUST include a User-Name attribute, which MUST be identical in all chunks. Each chunk except for the first one from a RADIUS Client MUST include a State attribute, which MUST be copied from a previous Access-Accept.
除了来自RADIUS客户机的最后一个区块外，每个区块都必须包含Frag Status属性，并且具有值More Data Pending。最后一个区块不能包含Frag Status属性。除了来自RADIUS客户机的最后一个区块外，每个区块都必须包含一个服务类型属性，并具有附加授权值。每个区块必须包含一个用户名属性，该属性在所有区块中必须相同。除了来自RADIUS客户端的第一个区块外，每个区块都必须包含一个状态属性，该属性必须从以前的Access Accept复制。
Each Access-Accept MUST include a State attribute. The value for this attribute MUST change in every new Access-Accept and MUST be globally and temporally unique.
每个访问接受必须包含一个状态属性。此属性的值必须在每个新的Access Accept中更改，并且必须在全局和时间上唯一。
When the RADIUS Server wants to send a large amount of authorization data to the RADIUS Client after authentication, the operation is very similar to the pre-authorization process. The presence of a Service-Type = Additional-Authorization attribute ensures that a RADIUS Client not supporting this specification will treat that unrecognized Service-Type as though an Access-Reject had been received instead ([RFC2865], Section 5.6). If the original large Access-Accept packet contained a Service-Type attribute, it will be included with its original value in the last transmitted chunk, to avoid confusion with the one used for fragmentation signaling. It is RECOMMENDED that RADIUS Servers include a State attribute in their original Access-Accept packets, even if fragmentation is not taking place, to allow the RADIUS Client to send additional authorization data in subsequent exchanges. This State attribute would be included in the last transmitted chunk, to avoid confusion with the ones used for fragmentation signaling.
当RADIUS服务器想要在身份验证后向RADIUS客户端发送大量授权数据时，操作与预授权过程非常相似。服务类型=附加授权属性的存在可确保不支持此规范的RADIUS客户端将视为接收到访问拒绝而处理该无法识别的服务类型（[RFC2865]，第5.6节）。如果原始大访问接受数据包包含服务类型属性，则它将与其原始值一起包含在最后传输的数据块中，以避免与用于分段信令的数据块混淆。建议RADIUS服务器在其原始访问接受数据包中包含一个状态属性，即使没有发生碎片，也允许RADIUS客户端在后续交换中发送额外的授权数据。该状态属性将包含在最后传输的块中，以避免与用于分段信令的块混淆。
Clients supporting this specification MUST include a Frag-Status = Fragmentation-Supported attribute in the first Access-Request sent to the RADIUS Server, in order to indicate that they would accept fragmented data from the server. This is not required if the pre-authorization process was carried out, as it is implicit.
支持此规范的客户端必须在发送到RADIUS服务器的第一个访问请求中包含Frag Status=FRAMATION SUPPORED属性，以指示它们将接受来自服务器的碎片数据。如果执行了预授权过程，则不需要这样做，因为这是隐含的。
The following is an Access-Accept that the RADIUS Server intends to send to a RADIUS Client. However, due to a combination of issues (PMTU, large attributes, etc.), the content does not fit into one Access-Accept packet.
以下是RADIUS服务器打算发送给RADIUS客户端的访问接受。但是，由于一系列问题（PMTU、大型属性等），内容不适合一个访问-接受数据包。
Access-Accept
User-Name
EAP-Message
Service-Type = Login
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [M]
Example-Long-2
State = 0xcba00003
Access-Accept
User-Name
EAP-Message
Service-Type = Login
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [M]
Example-Long-2
State = 0xcba00003
Figure 8: Desired Access-Accept
图8：所需的访问接受
The RADIUS Server therefore must send the attributes listed above in a series of chunks. The first chunk contains seven (7) attributes from the original Access-Accept, and a Frag-Status attribute. Since the last attribute is "Example-Long-1" with the M flag set, the chunking process also sets the T flag in that attribute. The Access-Accept is sent with a RADIUS Identifier field having value 30, corresponding to a previous Access-Request not depicted. The Frag-Status attribute has value More-Data-Pending, to indicate that the RADIUS Server wishes to send more data in a subsequent Access-Accept. The RADIUS Server also adds a Service-Type attribute with value Additional-Authorization, which indicates that it is part of the chunking process. Note that the original Service-Type is not included in this chunk. Finally, a State attribute is included to allow matching subsequent requests with this conversation, and the packet is signed with the Message-Authenticator attribute, completing the maximum number of attributes (11).
因此，RADIUS服务器必须以一系列块的形式发送上面列出的属性。第一个区块包含来自原始Access Accept的七（7）个属性和一个Frag Status属性。由于最后一个属性是“Example-Long-1”，并设置了M标志，因此分块过程也在该属性中设置了T标志。访问接受与值为30的RADIUS标识符字段一起发送，对应于未描述的先前访问请求。Frag Status属性的值为More Data Pending，表示RADIUS服务器希望在后续访问接受中发送更多数据。RADIUS服务器还添加了一个带有值Additional Authorization的服务类型属性，这表明它是分块过程的一部分。请注意，此区块中不包括原始服务类型。最后，包括一个State属性，以允许将后续请求与该会话相匹配，并使用messageauthenticator属性对数据包进行签名，从而完成最大数量的属性（11）。
Access-Accept (ID = 30)
User-Name
EAP-Message
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [MT]
Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization
State = 0xcba00004
Message-Authenticator
Access-Accept (ID = 30)
User-Name
EAP-Message
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [MT]
Frag-Status = More-Data-Pending
Service-Type = Additional-Authorization
State = 0xcba00004
Message-Authenticator
Figure 9: Access-Accept (Chunk 1)
图9：访问接受（区块1）
Compliant RADIUS Clients receiving this packet will see the Frag-Status attribute and suspend all authorization handling until all of the chunks have been received. Non-compliant RADIUS Clients should also see the Service-Type indicating the provisioning for an unknown service and will treat it as an Access-Reject.
接收此数据包的兼容RADIUS客户端将看到Frag Status属性，并暂停所有授权处理，直到接收到所有数据块。不兼容的RADIUS客户端还应看到指示为未知服务进行配置的服务类型，并将其视为访问拒绝。
RADIUS Clients who wish to receive all of the chunks will respond with the following packet, where the value of the State attribute is taken from the received Access-Accept. They will also include the User-Name attribute so that non-compliant proxies can process the packet (Section 11.1).
希望接收所有数据块的RADIUS客户端将使用以下数据包进行响应，其中State属性的值取自接收的Accept访问。它们还将包括用户名属性，以便不符合要求的代理可以处理数据包（第11.1节）。
Access-Request (ID = 131) User-Name Frag-Status = More-Data-Request Service-Type = Additional-Authorization State = 0xcba00004 Message-Authenticator
访问请求（ID=131）用户名Frag Status=更多数据请求服务类型=附加授权状态=0xcba00004消息验证器
Figure 10: Access-Request (Chunk 1)
图10：访问请求（区块1）
The RADIUS Server receives this request and uses the State attribute to associate it with an ongoing chunking session. Compliant RADIUS Servers will then continue the chunking process. Non-compliant RADIUS Servers will never see a response such as this, as they will never send a Frag-Status attribute.
RADIUS服务器接收此请求并使用State属性将其与正在进行的分块会话相关联。然后，兼容的RADIUS服务器将继续分块过程。不兼容的RADIUS服务器将永远不会看到这样的响应，因为它们永远不会发送Frag Status属性。
The RADIUS Server continues the chunking process by sending the next chunk, with the final attribute(s) from the original packet. The value of the Identifier field is taken from the received Access-Request. A Frag-Status attribute is not included in the next Access-Accept, as no more chunks are available for sending. The
RADIUS服务器通过发送下一个数据块以及原始数据包的最终属性来继续数据块划分过程。标识符字段的值取自收到的访问请求。Frag Status属性不包括在下一次访问接受中，因为没有更多的块可用于发送。这个
RADIUS Server includes the original State attribute to allow the RADIUS Client to send additional authorization data. The original Service-Type attribute is included as well.
RADIUS服务器包含原始状态属性，以允许RADIUS客户端发送其他授权数据。还包括原始服务类型属性。
Access-Accept (ID = 131)
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [M]
Example-Long-2
Service-Type = Login
State = 0xfda000003
Message-Authenticator
Access-Accept (ID = 131)
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1 [M]
Example-Long-1
Example-Long-2 [M]
Example-Long-2 [M]
Example-Long-2
Service-Type = Login
State = 0xfda000003
Message-Authenticator
Figure 11: Access-Accept (Chunk 2)
图11：访问接受（区块2）
On reception of this last chunk, the RADIUS Client matches it with an ongoing session via the Identifier field and sees that there is no Frag-Status attribute present. It then processes the received attributes as if they had been sent in one RADIUS packet. See Section 8.4 for further details on this process.
在接收到最后一个区块时，RADIUS客户端通过标识符字段将其与正在进行的会话进行匹配，并发现不存在Frag Status属性。然后，它处理接收到的属性，就好像它们是在一个RADIUS数据包中发送的一样。有关此过程的更多详细信息，请参见第8.4节。
In an ideal scenario, each intermediate chunk would be exactly the size limit in length. In this way, the number of round trips required to send a large packet would be optimal. However, this is not possible for several reasons.
在理想的情况下，每个中间块的长度正好是大小限制。这样，发送大数据包所需的往返次数将是最佳的。然而，由于几个原因，这是不可能的。
1. RADIUS attributes have a variable length and must be included completely in a chunk. Thus, it is possible that, even if there is some free space in the chunk, it is not enough to include the next attribute. This can generate up to 254 bytes of spare space in every chunk.
1. 半径属性具有可变长度，必须完全包含在块中。因此，即使区块中有一些可用空间，也可能不足以包含下一个属性。这可以在每个块中生成多达254字节的空闲空间。
2. RADIUS fragmentation requires the introduction of some extra attributes for signaling. Specifically, a Frag-Status attribute (7 bytes) is included in every chunk of a packet, except the last one. A RADIUS State attribute (from 3 to 255 bytes) is also included in most chunks, to allow the RADIUS Server to bind an Access-Request with a previous Access-Challenge. User-Name attributes (from 3 to 255 bytes) are included in every chunk the RADIUS Client sends, as they are required by the proxies to route the packet to its destination. Together, these attributes can generate from up to 13 to 517 bytes of signaling data, reducing the amount of payload information that can be sent in each chunk.
2. RADIUS分段需要引入一些额外的信令属性。具体来说，Frag状态属性（7字节）包含在数据包的每个块中，最后一个除外。大多数区块中还包含RADIUS状态属性（从3到255字节），以允许RADIUS服务器将访问请求与以前的访问质询绑定。RADIUS客户端发送的每个数据块中都包含用户名属性（3到255字节），因为代理需要这些属性将数据包路由到其目的地。总之，这些属性可以生成多达13到517字节的信令数据，从而减少每个数据块中可以发送的有效负载信息量。
3. RADIUS packets SHOULD be adjusted to avoid exceeding the network MTU. Otherwise, IP fragmentation may occur, with undesirable consequences. Hence, maximum chunk size would be decreased from 4096 to the actual MTU of the network.
3. 应调整RADIUS数据包，以避免超过网络MTU。否则，可能会出现IP碎片，并产生不良后果。因此，最大块大小将从4096减少到网络的实际MTU。
4. The inclusion of Proxy-State attributes by intermediary proxies can decrease the availability of usable space in the chunk. This is described in further detail in Section 8.1.
4. 中间代理包含代理状态属性会降低块中可用空间的可用性。第8.1节对此进行了详细说明。
There are no provisions for signaling how much data is to be sent via the fragmentation process as a whole. It is difficult to define what is meant by the "length" of any fragmented data. That data can be multiple attributes and can include RADIUS attribute header fields, or it can be one or more "large" attributes (more than 256 bytes in length). Proxies can also filter these attributes, to modify, add, or delete them and their contents. These proxies act on a "packet by packet" basis and cannot know what kind of filtering actions they will take on future packets. As a result, it is impossible to signal any meaningful value for the total amount of additional data.
没有规定通过整个分段过程发送多少数据。很难定义任何碎片数据的“长度”是什么意思。该数据可以是多个属性，可以包括RADIUS属性头字段，也可以是一个或多个“大”属性（长度超过256字节）。代理还可以过滤这些属性，以修改、添加或删除这些属性及其内容。这些代理以“逐包”的方式工作，无法知道它们将对未来的数据包采取何种过滤操作。因此，不可能对附加数据总量发出任何有意义的信号。
Unauthenticated end users are permitted to trigger the exchange of large amounts of fragmented data between the RADIUS Client and the RADIUS Server, having the potential to allow denial-of-service (DoS) attacks. An attacker could initiate a large number of connections, each of which requests the RADIUS Server to store a large amount of data. This data could cause memory exhaustion on the RADIUS Server and result in authentic users being denied access. It is worth noting that authentication mechanisms are already designed to avoid exceeding the size limit.
未经验证的最终用户可以触发RADIUS客户端和RADIUS服务器之间的大量碎片数据交换，这可能会导致拒绝服务（DoS）攻击。攻击者可以启动大量连接，每个连接都会请求RADIUS服务器存储大量数据。此数据可能会导致RADIUS服务器内存耗尽，并导致真实用户被拒绝访问。值得注意的是，身份验证机制已经设计为避免超过大小限制。
Hence, implementations of this specification MUST limit the total amount of data they send and/or receive via this specification. Its default value SHOULD be 100 kilobytes. Any more than this may turn RADIUS into a generic transport protocol, which is undesirable. This limit SHOULD be configurable, so that it can be changed if necessary.
因此，本规范的实现必须限制通过本规范发送和/或接收的数据总量。其默认值应为100 KB。超过此值可能会将RADIUS变成通用传输协议，这是不可取的。此限制应该是可配置的，以便在必要时可以更改。
Implementations of this specification MUST limit the total number of round trips used during the fragmentation process. Its default value SHOULD be 25. Any more than this may indicate an implementation error, misconfiguration, or DoS attack. This limit SHOULD be configurable, so that it can be changed if necessary.
本规范的实现必须限制分段过程中使用的往返总次数。其默认值应为25。超过此值可能表示实现错误、配置错误或DoS攻击。此限制应该是可配置的，以便在必要时可以更改。
For instance, let's imagine that the RADIUS Server wants to transport a SAML assertion that is 15000 bytes long to the RADIUS Client. In this hypothetical scenario, we assume that there are three intermediate proxies, each one inserting a Proxy-State attribute of 20 bytes. Also, we assume that the State attributes generated by the RADIUS Server have a size of 6 bytes and the User-Name attribute takes 50 bytes. Therefore, the amount of free space in a chunk for the transport of the SAML assertion attributes is as follows: Total (4096 bytes) - RADIUS header (20 bytes) - User-Name (50 bytes) - Frag-Status (7 bytes) - Service-Type (6 bytes) - State (6 bytes) - Proxy-State (20 bytes) - Proxy-State (20 bytes) - Proxy-State (20 bytes) - Message-Authenticator (18 bytes), resulting in a total of 3929 bytes. This amount of free space allows the transmission of up to 15 attributes of 255 bytes each.
例如，假设RADIUS服务器想要将一个15000字节长的SAML断言传输到RADIUS客户端。在这个假设的场景中，我们假设有三个中间代理，每个代理插入一个20字节的代理状态属性。此外，我们假设RADIUS服务器生成的状态属性大小为6字节，用户名属性大小为50字节。因此，用于传输SAML断言属性的块中的可用空间量如下：总计（4096字节）-RADIUS头（20字节）-用户名（50字节）-Frag状态（7字节）-服务类型（6字节）-状态（6字节）-代理状态（20字节）-代理状态（20字节）-消息验证器（18字节），总共产生3929字节。此可用空间量允许传输最多15个属性，每个属性255字节。
According to [RFC6929], a Long-Extended-Type provides a payload of 251 bytes. Therefore, the SAML assertion described above would result in 60 attributes, requiring four round trips to be completely transmitted.
根据[RFC6929]，长扩展类型提供251字节的有效负载。因此，上面描述的SAML断言将产生60个属性，需要完全传输四个往返。
RADIUS proxies may introduce Proxy-State attributes into any Access-Request packet they forward. If they are unable to add this information to the packet, they may silently discard it rather than forward it to its destination; this would lead to DoS situations. Moreover, any Proxy-State attribute received by a RADIUS Server in an Access-Request packet MUST be copied into the corresponding reply packet. For these reasons, Proxy-State attributes require special treatment within the packet fragmentation mechanism.
RADIUS代理可以将代理状态属性引入它们转发的任何访问请求包中。如果他们无法将此信息添加到数据包中，他们可以默默地丢弃它，而不是将其转发到目的地；这将导致DoS情况。此外，RADIUS服务器在访问请求数据包中接收到的任何代理状态属性都必须复制到相应的应答数据包中。由于这些原因，代理状态属性需要在数据包分段机制中进行特殊处理。
When the RADIUS Server replies to an Access-Request packet as part of a conversation involving a fragmentation (either a chunk or a request for chunks), it MUST include every Proxy-State attribute received in the reply packet. This means that the RADIUS Server MUST take into account the size of these Proxy-State attributes in order to calculate the size of the next chunk to be sent.
当RADIUS服务器作为涉及碎片（区块或区块请求）的对话的一部分回复访问请求数据包时，它必须包括回复数据包中接收到的每个代理状态属性。这意味着RADIUS服务器必须考虑这些代理状态属性的大小，以便计算要发送的下一个块的大小。
However, while a RADIUS Server will always know how much space MUST be left in each reply packet for Proxy-State attributes (as they are directly included by the RADIUS Server), a RADIUS Client cannot know this information, as Proxy-State attributes are removed from the reply packet by their respective proxies before forwarding them back. Hence, RADIUS Clients need a mechanism to discover the amount of
但是，虽然RADIUS服务器始终知道每个回复数据包中必须为代理状态属性保留多少空间（因为它们直接包含在RADIUS服务器中），但RADIUS客户端无法知道此信息，因为代理状态属性在转发回它们之前已被其各自的代理从回复数据包中删除。因此，RADIUS客户端需要一种机制来发现
space required by proxies to introduce their Proxy-State attributes. In the following paragraphs, we describe a new mechanism to perform such a discovery:
代理引入其代理状态属性所需的空间。在以下段落中，我们描述了执行此类发现的新机制：
1. When a RADIUS Client does not know how much space will be required by intermediate proxies for including their Proxy-State attributes, it SHOULD start using a conservative value (e.g., 1024 bytes) as the chunk size.
1. 当RADIUS客户端不知道中间代理需要多少空间来包含其代理状态属性时，它应该开始使用保守值（例如1024字节）作为块大小。
2. When the RADIUS Server receives a chunk from the RADIUS Client, it can calculate the total size of the Proxy-State attributes that have been introduced by intermediary proxies along the path. This information MUST be returned to the RADIUS Client in the next reply packet, encoded into a new attribute called Proxy-State-Length. The RADIUS Server MAY artificially increase this quantity in order to handle situations where proxies behave inconsistently (e.g., they generate Proxy-State attributes with a different size for each packet) or where intermediary proxies remove Proxy-State attributes generated by other proxies. Increasing this value would make the RADIUS Client leave some free space for these situations.
2. 当RADIUS服务器从RADIUS客户端接收到块时，它可以计算中间代理沿路径引入的代理状态属性的总大小。此信息必须在下一个应答数据包中返回给RADIUS客户端，并编码为一个称为代理状态长度的新属性。RADIUS服务器可以人为地增加该数量，以便处理代理行为不一致的情况（例如，它们为每个分组生成具有不同大小的代理状态属性）或者中间代理移除由其他代理生成的代理状态属性的情况。增加此值将使RADIUS客户端为这些情况留出一些可用空间。
3. The RADIUS Client SHOULD respond to the reception of this attribute by adjusting the maximum size for the next chunk accordingly. However, as the Proxy-State-Length offers just an estimation of the space required by the proxies, the RADIUS Client MAY select a smaller amount in environments known to be problematic.
3. RADIUS客户端应通过相应地调整下一块的最大大小来响应此属性的接收。然而，由于代理状态长度仅提供代理所需空间的估计，因此RADIUS客户端可以在已知有问题的环境中选择较小的量。
This RADIUS fragmentation mechanism makes use of the State attribute to link all the chunks belonging to the same fragmented packet. However, some considerations are required when the RADIUS Server is fragmenting a packet that already contains a State attribute for other purposes not related to the fragmentation. If the procedure described in Section 5 is followed, two different State attributes could be included in a single chunk. This is something explicitly forbidden in [RFC2865].
这种RADIUS分段机制利用State属性链接属于同一分段数据包的所有数据块。但是，当RADIUS服务器将已包含状态属性的数据包进行分段时，需要考虑一些与分段无关的其他目的。如果遵循第5节中描述的过程，那么一个块中可能包含两个不同的状态属性。这是[RFC2865]中明确禁止的内容。
A straightforward solution consists of making the RADIUS Server send the original State attribute in the last chunk of the sequence (attributes can be reordered as specified in [RFC2865]). As the last chunk (when generated by the RADIUS Server) does not contain any State attribute due to the fragmentation mechanism, both situations described above are avoided.
一个简单的解决方案是让RADIUS服务器在序列的最后一块中发送原始状态属性（属性可以按照[RFC2865]中的规定重新排序）。由于碎片机制，最后一个块（由RADIUS服务器生成时）不包含任何状态属性，因此避免了上述两种情况。
Something similar happens when the RADIUS Client has to send a fragmented packet that contains a State attribute in it. The RADIUS Client MUST ensure that this original State is included in the first chunk sent to the RADIUS Server (as this one never contains any State attribute due to fragmentation).
当RADIUS客户端必须发送包含状态属性的碎片数据包时，也会发生类似的情况。RADIUS客户端必须确保此原始状态包含在发送到RADIUS服务器的第一个块中（因为此块由于碎片而从不包含任何状态属性）。
This RADIUS fragmentation mechanism makes use of the Service-Type attribute to indicate that an Access-Accept packet is not granting access to the service yet, since an additional authorization exchange needs to be performed. Similarly to the State attribute, the RADIUS Server has to send the original Service-Type attribute in the last Access-Accept of the RADIUS conversation to avoid ambiguity.
此RADIUS分段机制利用服务类型属性指示访问接受数据包尚未授予对服务的访问权限，因为需要执行额外的授权交换。与状态属性类似，RADIUS服务器必须在RADIUS会话的最后一次访问接受中发送原始服务类型属性，以避免歧义。
The RADIUS Client stores the RADIUS attributes received in each chunk in a list, in order to be able to rebuild the original large packet after receiving the last chunk. However, some of these received attributes MUST NOT be stored in that list, as they have been introduced as part of the fragmentation signaling and hence are not part of the original packet.
RADIUS客户端将在每个区块中接收到的RADIUS属性存储在一个列表中，以便在接收到最后一个区块后能够重建原始大数据包。然而，这些接收到的属性中的一些不能存储在该列表中，因为它们已作为分段信令的一部分引入，因此不是原始分组的一部分。
o State (except the one in the last chunk, if present)
o 状态（除了最后一个块中的一个，如果存在）
o Service-Type = Additional-Authorization
o 服务类型=附加授权
o Frag-Status
o Frag状态
o Proxy-State-Length
o 代理状态长度
Similarly, the RADIUS Server MUST NOT store the following attributes as part of the original large packet:
同样，RADIUS服务器不得将以下属性存储为原始大数据包的一部分：
o State (except the one in the first chunk, if present)
o 状态（第一个块中的状态除外，如果存在）
o Service-Type = Additional-Authorization
o 服务类型=附加授权
o Frag-Status
o Frag状态
o Proxy-State (except the ones in the last chunk)
o 代理状态（最后一个区块中的代理状态除外）
o User-Name (except the one in the first chunk)
o 用户名（第一个区块中的用户名除外）
This document defines a new field in the Long Extended Type attribute format. This field is one bit in size and is called "T" for Truncation. It indicates that the attribute is intentionally truncated in this chunk and is to be continued in the next chunk of the sequence. The combination of the M flag and the T flag indicates that the attribute is fragmented (M flag) but that all the fragments are not available in this chunk (T flag). Proxies implementing [RFC6929] will see these attributes as invalid (they will not be able to reconstruct them), but they will still forward them, as Section 5.2 of [RFC6929] indicates that they SHOULD forward unknown attributes anyway.
本文档以长扩展类型属性格式定义了一个新字段。此字段的大小为一位，称为“T”表示截断。它表示该属性在该块中被有意截断，并将在序列的下一块中继续。M标志和T标志的组合表示该属性是分段的（M标志），但该区块中的所有片段都不可用（T标志）。实现[RFC6929]的代理将这些属性视为无效（它们将无法重建），但它们仍将转发这些属性，因为[RFC6929]第5.2节指出它们无论如何都应该转发未知属性。
As a consequence of this addition, the Reserved field is now 6 bits long (see Section 12.1 for some considerations). The following figure represents the new attribute format:
由于该添加，保留字段现在为6位长（有关某些注意事项，请参阅第12.1节）。下图表示新的属性格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Updated Long Extended Type Attribute Format
图12：更新的长扩展类型属性格式
This document proposes the definition of two new extended type attributes, called Frag-Status and Proxy-State-Length. The format of these attributes follows the indications for an Extended Type attribute defined in [RFC6929].
本文提出了两个新的扩展类型属性的定义，称为Frag Status和代理状态长度。这些属性的格式遵循[RFC6929]中定义的扩展类型属性的指示。
This attribute is used for fragmentation signaling, and its meaning depends on the code value transported within it. The following figure represents the format of the Frag-Status attribute:
此属性用于分段信令，其含义取决于其中传输的代码值。下图表示Frag Status属性的格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Frag-Status Format
图13:Frag状态格式
Type
类型
241
241
Length
长
7
7.
Extended-Type
扩展型
1
1.
Code
密码
4 bytes. Integer indicating the code. The values defined in this specification are:
4字节。表示代码的整数。本规范中定义的值为：
0 - Reserved
0-保留
1 - Fragmentation-Supported
1-支持碎片化
2 - More-Data-Pending
2-更多数据待定
3 - More-Data-Request
3-更多数据请求
This attribute MAY be present in Access-Request, Access-Challenge, and Access-Accept packets. It MUST NOT be included in Access-Reject packets. RADIUS Clients supporting this specification MUST include a Frag-Status = Fragmentation-Supported attribute in the first Access-Request sent to the RADIUS Server, in order to indicate that they would accept fragmented data from the server.
该属性可能存在于访问请求、访问质询和访问接受数据包中。它不能包含在访问拒绝数据包中。支持此规范的RADIUS客户端必须在发送到RADIUS服务器的第一个访问请求中包含Frag Status=FRAMATION SUPPORED属性，以指示它们将接受来自服务器的碎片数据。
This attribute indicates to the RADIUS Client the length of the Proxy-State attributes received by the RADIUS Server. This information is useful for adjusting the length of the chunks sent by the RADIUS Client. The format of this Proxy-State-Length attribute is as follows:
此属性向RADIUS客户端指示RADIUS服务器接收的代理状态属性的长度。此信息对于调整RADIUS客户端发送的块的长度非常有用。此代理状态长度属性的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Proxy-State-Length Format
图14：代理状态长度格式
Type
类型
241
241
Length
长
7
7.
Extended-Type
扩展型
2
2.
Value
价值
4 bytes. Total length (in bytes) of received Proxy-State attributes (including headers). As the RADIUS Length field cannot take values over 4096 bytes, values of Proxy-State-Length MUST be less than that maximum length.
4字节。接收的代理状态属性（包括标头）的总长度（字节）。由于RADIUS长度字段的值不能超过4096字节，代理状态长度的值必须小于该最大长度。
This attribute MAY be present in Access-Challenge and Access-Accept packets. It MUST NOT be included in Access-Request or Access-Reject packets.
此属性可能存在于访问质询和访问接受数据包中。它不能包含在访问请求或访问拒绝数据包中。
The following table shows the different attributes defined in this document, along with the types of RADIUS packets in which they can be present.
下表显示了本文档中定义的不同属性，以及它们可以存在的RADIUS数据包的类型。
| Type of Packet |
+-----+-----+-----+-----+
Attribute Name | Req | Acc | Rej | Cha |
----------------------+-----+-----+-----+-----+
Frag-Status | 0-1 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+
Proxy-State-Length | 0 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+
| Type of Packet |
+-----+-----+-----+-----+
Attribute Name | Req | Acc | Rej | Cha |
----------------------+-----+-----+-----+-----+
Frag-Status | 0-1 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+
Proxy-State-Length | 0 | 0-1 | 0 | 0-1 |
----------------------+-----+-----+-----+-----+
The fragmentation mechanism defined above is designed to be transparent to legacy proxies, as long as they do not want to modify any fragmented attribute. Nevertheless, updated proxies supporting this specification can even modify fragmented attributes.
上面定义的分段机制设计为对遗留代理透明，只要它们不想修改任何分段属性。然而，支持此规范的更新代理甚至可以修改分段属性。
As every chunk is indeed a RADIUS packet, legacy proxies treat them as they would the rest of the packets, routing them to their destination. Proxies can introduce Proxy-State attributes into Access-Request packets, even if they are indeed chunks. This will not affect how fragmentation is managed. The RADIUS Server will include all the received Proxy-State attributes in the generated response, as described in [RFC2865]. Hence, proxies do not distinguish between a regular RADIUS packet and a chunk.
由于每个数据块实际上都是一个RADIUS数据包，传统代理将其视为其他数据包，将其路由到目的地。代理可以将代理状态属性引入访问请求包，即使它们确实是块。这不会影响碎片化的管理方式。RADIUS服务器将在生成的响应中包含所有接收到的代理状态属性，如[RFC2865]中所述。因此，代理不区分常规RADIUS数据包和数据块。
Updated proxies can interact with RADIUS Clients and Servers in order to obtain the complete large packet before starting to forward it. In this way, proxies can manipulate (modify and/or remove) any attribute of the packet or introduce new attributes, without worrying about crossing the boundaries of the chunk size. Once the manipulated packet is ready, it is sent to the original destination using the fragmentation mechanism (if required). The example in Figure 15 shows how an updated proxy interacts with the RADIUS Client to (1) obtain a large Access-Request packet and (2) modify an attribute, resulting in an even larger packet. The proxy then interacts with the RADIUS Server to complete the transmission of the modified packet, as shown in Figure 16.
更新的代理可以与RADIUS客户端和服务器交互，以便在开始转发之前获得完整的大数据包。通过这种方式，代理可以操纵（修改和/或删除）数据包的任何属性或引入新属性，而不用担心跨越数据块大小的边界。一旦被操纵的数据包准备就绪，它将使用分段机制（如果需要）发送到原始目的地。图15中的示例显示了更新后的代理如何与RADIUS客户端交互，以（1）获取一个大的访问请求数据包，以及（2）修改一个属性，从而生成一个更大的数据包。然后，代理与RADIUS服务器交互，以完成修改数据包的传输，如图16所示。
+-+-+-+-+-+ +-+-+-+-+-+
| RADIUS | | RADIUS |
| Client | | Proxy |
+-+-+-+-+-+ +-+-+-+-+-+
| |
| Access-Request(1){User-Name,Calling-Station-Id, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State1} |
|<---------------------------------------------------|
| |
| Access-Request(2){User-Name,State1, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1} |
|--------------------------------------------------->|
+-+-+-+-+-+ +-+-+-+-+-+
| RADIUS | | RADIUS |
| Client | | Proxy |
+-+-+-+-+-+ +-+-+-+-+-+
| |
| Access-Request(1){User-Name,Calling-Station-Id, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State1} |
|<---------------------------------------------------|
| |
| Access-Request(2){User-Name,State1, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1} |
|--------------------------------------------------->|
Proxy Modifies Attribute Data, Increasing Its Size from 9 Fragments to 11 Fragments
代理修改属性数据，将其大小从9个片段增加到11个片段
Figure 15: Updated Proxy Interacts with RADIUS Client
图15：更新的代理与RADIUS客户端交互
+-+-+-+-+-+ +-+-+-+-+-+
| RADIUS | | RADIUS |
| Proxy | | Server |
+-+-+-+-+-+ +-+-+-+-+-+
| |
| Access-Request(3){User-Name,Calling-Station-Id, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State2} |
|<---------------------------------------------------|
| |
| Access-Request(4){User-Name,State2, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State3} |
|<---------------------------------------------------|
| |
| Access-Request(5){User-Name,State3,Example-Long-1} |
|--------------------------------------------------->|
+-+-+-+-+-+ +-+-+-+-+-+
| RADIUS | | RADIUS |
| Proxy | | Server |
+-+-+-+-+-+ +-+-+-+-+-+
| |
| Access-Request(3){User-Name,Calling-Station-Id, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State2} |
|<---------------------------------------------------|
| |
| Access-Request(4){User-Name,State2, |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[M],Example-Long-1[M], |
| Example-Long-1[MT],Frag-Status(MDP)} |
|--------------------------------------------------->|
| |
| Access-Challenge(1){User-Name, |
| Frag-Status(MDR),State3} |
|<---------------------------------------------------|
| |
| Access-Request(5){User-Name,State3,Example-Long-1} |
|--------------------------------------------------->|
Figure 16: Updated Proxy Interacts with RADIUS Server
图16：更新的代理与RADIUS服务器交互
As described in Section 9, this document modifies the definition of the Reserved field of the Long Extended Type attribute [RFC6929] by allocating an additional flag called the T flag. The meaning and position of this flag are defined in this document, and nowhere else. This might cause an issue if subsequent specifications want to allocate a new flag as well, as there would be no direct way for them to know which parts of the Reserved field have already been defined.
如第9节所述，本文档通过分配一个称为T标志的附加标志来修改长扩展类型属性[RFC6929]的保留字段的定义。此标志的含义和位置在本文件中定义，其他任何地方均未定义。如果后续规范也要分配新标志，这可能会导致问题，因为它们无法直接知道保留字段的哪些部分已经定义。
An immediate and reasonable solution for this issue would be declaring that this RFC updates [RFC6929]. In this way, [RFC6929] would include an "Updated by" clause that will point readers to this document. Another alternative would be creating an IANA registry for
对于这个问题，一个直接合理的解决方案是声明此RFC更新[RFC6929]。这样，[RFC6929]将包含一个“Updated by”子句，该子句将向读者指出本文档。另一种选择是为用户创建IANA注册表
the Reserved field. However, the RADIUS Extensions (RADEXT) working group thinks that would be overkill, as a large number of specifications extending that field are not expected.
保留字段。然而，RADIUS Extensions（RADEXT）工作组认为这是一种过分的做法，因为预计不会有大量扩展该领域的规范。
In the end, the proposed solution is that this experimental RFC should not update RFC 6929. Instead, we rely on the collective mind of the working group to remember that this T flag is being used as specified by this Experimental document. If the experiment is successful, the T flag will be properly assigned.
最后，建议的解决方案是，此实验RFC不应更新RFC 6929。相反，我们依靠工作组的集体思维来记住，这个T标志是按照本实验文件的规定使用的。如果实验成功，将正确分配T标志。
Section 5.1 indicates that all authorization and authentication handling will be postponed until all the chunks have been received. This postponement also applies to the verification that the Access-Request packet contains some kind of authentication attribute (e.g., User-Password, CHAP-Password, State, or other future attribute), as required by [RFC2865]. This checking will therefore be delayed until the original large packet has been rebuilt, as some of the chunks may not contain any of them.
第5.1节指出，所有授权和身份验证处理将被推迟，直到收到所有区块。此延迟还适用于验证访问请求数据包是否包含某种身份验证属性（例如，用户密码、CHAP密码、状态或其他未来属性），如[RFC2865]所要求。因此，该检查将被延迟，直到原始的大数据包被重建，因为某些数据块可能不包含任何数据包。
The authors acknowledge that this specification violates the "MUST" requirement of [RFC2865], Section 4.1 that states that "An Access-Request MUST contain either a User-Password or a CHAP-Password or a State." We note that a proxy that enforces that requirement would be unable to support future RADIUS authentication extensions. Extensions to the protocol would therefore be impossible to deploy. All known implementations have chosen the philosophy of "be liberal in what you accept." That is, they accept traffic that violates the requirement of [RFC2865], Section 4.1. We therefore expect to see no operational issues with this specification. After we gain more operational experience with this specification, it can be reissued as a Standards Track document and can update [RFC2865].
作者承认，本规范违反了[RFC2865]第4.1节的“必须”要求，即“访问请求必须包含用户密码或CHAP密码或状态”。我们注意到，执行该要求的代理将无法支持未来的RADIUS身份验证扩展。因此，无法部署对该协议的扩展。所有已知的实现都选择了“接受自由”的理念。也就是说，它们接受违反[RFC2865]第4.1节要求的流量。因此，我们希望本规范不会出现任何操作问题。在我们获得本规范的更多操作经验后，可以将其作为标准跟踪文档重新发布，并可以更新[RFC2865]。
This proposal assumes that legacy proxies base their routing decisions on the value of the User-Name attribute. For this reason, every packet sent from the RADIUS Client to the RADIUS Server (either chunks or requests for more chunks) MUST contain a User-Name attribute.
该方案假设传统代理根据用户名属性的值来决定路由。因此，从RADIUS客户端发送到RADIUS服务器的每个数据包（数据块或请求更多数据块）都必须包含用户名属性。
This proposal does not modify the way RADIUS interacts with the underlying transport (UDP). That is, RADIUS keeps following a lock-step behavior that requires receiving an explicit acknowledgement for each chunk sent. Hence, bursts of traffic that could congest links between peers are not an issue.
此建议不修改RADIUS与基础传输（UDP）交互的方式。也就是说，RADIUS始终遵循一种锁步行为，该行为要求接收对发送的每个区块的显式确认。因此，可能阻塞对等点之间链路的流量突发不是问题。
Another benefit of the lock-step nature of RADIUS is that there are no security issues with overlapping fragments. Each chunk simply has a length, with no Fragment Offset field as with IPv4. The order of the fragments is determined by the order in which they are received. There is no ambiguity about the size or placement of each chunk, and therefore no security issues associated with overlapping chunks.
RADIUS的锁步特性的另一个好处是，重叠片段不存在安全问题。每个区块都有一个长度，与IPv4一样没有片段偏移字段。片段的顺序由接收它们的顺序决定。每个块的大小或位置没有歧义，因此没有与重叠块相关的安全问题。
As noted in many earlier specifications ([RFC5080], [RFC6158], etc.), RADIUS security is problematic. This specification changes nothing related to the security of the RADIUS protocol. It requires that all Access-Request packets associated with fragmentation are authenticated using the existing Message-Authenticator attribute. This signature prevents forging and replay, to the limits of the existing security.
如许多早期规范（[RFC5080]、[RFC6158]等）所述，RADIUS安全性存在问题。本规范对RADIUS协议的安全性没有任何更改。它要求使用现有的消息验证器属性对与碎片相关联的所有访问请求数据包进行身份验证。在现有安全性的限制下，此签名可防止伪造和重播。
The ability to send bulk data from one party to another creates new security considerations. RADIUS Clients and Servers may have to store large amounts of data per session. The amount of this data can be significant, leading to the potential for resource exhaustion. We therefore suggest that implementations limit the amount of bulk data stored per session. The exact method for this limitation is implementation-specific. Section 7 gives some indications of what could be reasonable limits.
从一方向另一方发送批量数据的能力带来了新的安全考虑。RADIUS客户端和服务器可能必须在每个会话中存储大量数据。这些数据的数量可能很大，导致资源耗尽的可能性。因此，我们建议实现限制每个会话存储的批量数据量。此限制的确切方法是特定于实现的。第7节给出了合理限制的一些指示。
The bulk data can often be pushed off to storage methods other than the memory of the RADIUS implementation. For example, it can be stored in an external database or in files. This approach mitigates the resource exhaustion issue, as RADIUS Servers today already store large amounts of accounting data.
大容量数据通常可以推送到RADIUS实现的内存以外的存储方法。例如，它可以存储在外部数据库或文件中。这种方法缓解了资源耗尽问题，因为RADIUS服务器现在已经存储了大量的记帐数据。
The Internet Assigned Numbers Authority (IANA) has registered the Attribute Types and Attribute Values defined in this document in the RADIUS namespaces as described in the "IANA Considerations" section of [RFC3575], in accordance with BCP 26 [RFC5226]. For RADIUS packets, attributes, and registries created by this document, IANA has updated <http://www.iana.org/assignments/radius-types> accordingly.
互联网分配号码管理局（IANA）已根据BCP 26[RFC5226]在[RFC3575]的“IANA注意事项”部分所述的RADIUS名称空间中注册了本文件中定义的属性类型和属性值。对于本文档创建的RADIUS数据包、属性和注册表，IANA已更新<http://www.iana.org/assignments/radius-types>因此。
In particular, this document defines two new RADIUS attributes, entitled "Frag-Status" (value 241.1) and "Proxy-State-Length" (value 241.2), which have been allocated from the short extended space as described in [RFC6929]:
特别是，本文件定义了两个新的RADIUS属性，标题为“Frag状态”（值241.1）和“代理状态长度”（值241.2），它们是从[RFC6929]中所述的短扩展空间中分配的：
Type Name Length Meaning
---- ---- ------ -------
241.1 Frag-Status 7 Signals fragmentation
241.2 Proxy-State-Length 7 Indicates the length of the
received Proxy-State attributes
Type Name Length Meaning
---- ---- ------ -------
241.1 Frag-Status 7 Signals fragmentation
241.2 Proxy-State-Length 7 Indicates the length of the
received Proxy-State attributes
The Frag-Status attribute also defines an 8-bit "Code" field, for which IANA has created and now maintains a new sub-registry entitled "Code Values for RADIUS Attribute 241.1, Frag-Status". Initial values for the RADIUS Frag-Status "Code" registry are given below; future assignments are to be made through "RFC Required" [RFC5226]. Assignments consist of a Frag-Status "Code" name and its associated value.
Frag Status属性还定义了一个8位“代码”字段，IANA已为该字段创建并维护了一个新的子注册表，名为“RADIUS属性241.1的代码值，Frag状态”。RADIUS Frag状态“代码”注册表的初始值如下所示；未来的任务将通过“需要RFC”[RFC5226]完成。分配由Frag状态“代码”名称及其关联值组成。
Value Frag-Status Code Name Definition
---- ------------------------ ----------
0 Reserved See Section 10.1
1 Fragmentation-Supported See Section 10.1
2 More-Data-Pending See Section 10.1
3 More-Data-Request See Section 10.1
4-255 Unassigned
Value Frag-Status Code Name Definition
---- ------------------------ ----------
0 Reserved See Section 10.1
1 Fragmentation-Supported See Section 10.1
2 More-Data-Pending See Section 10.1
3 More-Data-Request See Section 10.1
4-255 Unassigned
Additionally, IANA has allocated a new Service-Type value for "Additional-Authorization".
此外，IANA还为“额外授权”分配了一个新的服务类型值。
Value Service Type Value Definition
---- ------------------------ ----------
19 Additional-Authorization See Section 5.1
Value Service Type Value Definition
---- ------------------------ ----------
19 Additional-Authorization See Section 5.1
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000, <http://www.rfc-editor.org/ info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月<http://www.rfc-editor.org/ 信息/rfc2865>。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003, <http://www.rfc-editor.org/info/rfc3575>.
[RFC3575]Aboba，B.“RADIUS（远程认证拨入用户服务）的IANA注意事项”，RFC 35752003年7月<http://www.rfc-editor.org/info/rfc3575>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011, <http://www.rfc-editor.org/info/rfc6158>.
[RFC6158]DeKok，A.，Ed.，和G.Weber，“半径设计指南”，BCP 158，RFC 6158，2011年3月<http://www.rfc-editor.org/info/rfc6158>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013, <http://www.rfc-editor.org/info/rfc6929>.
[RFC6929]DeKok，A.和A.Lior，“远程身份验证拨入用户服务（RADIUS）协议扩展”，RFC 69292013年4月<http://www.rfc-editor.org/info/rfc6929>.
[ABFAB-Arch] Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Work in Progress, draft-ietf-abfab-arch-13, July 2014.
[ABFAB-Arch]Howlett，J.，Hartman，S.，Tschofenig，H.，Lear，E.，和J.Schaad，“Web之外的联邦访问（ABFAB）体系结构的应用程序桥接”，正在进行的工作，草稿-ietf-ABFAB-Arch-13，2014年7月。
[RADIUS-Larger-Pkts] Hartman, S., "Larger Packets for RADIUS over TCP", Work in Progress, draft-ietf-radext-bigger-packets-03, March 2015.
[RADIUS大数据包]Hartman，S.，“TCP上RADIUS的大数据包”，正在进行的工作，草稿-ietf-radext-BIGER-PACKES-032015年3月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000, <http://www.rfc-editor.org/info/rfc2866>.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月<http://www.rfc-editor.org/info/rfc2866>.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003, <http://www.rfc-editor.org/info/rfc3579>.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月<http://www.rfc-editor.org/info/rfc3579>.
[RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007, <http://www.rfc-editor.org/info/rfc4849>.
[RFC4849]Congdon，P.，Sanchez，M.和B.Aboba，“半径过滤器规则属性”，RFC 48492007年4月<http://www.rfc-editor.org/info/rfc4849>.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007, <http://www.rfc-editor.org/info/rfc5080>.
[RFC5080]Nelson，D.和A.DeKok，“通用远程身份验证拨入用户服务（RADIUS）实施问题和建议修复”，RFC 50802007年12月<http://www.rfc-editor.org/info/rfc5080>.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008, <http://www.rfc-editor.org/info/rfc5176>.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 51762008年1月<http://www.rfc-editor.org/info/rfc5176>.
[SAML-RADIUS] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML", Work in Progress, draft-ietf-abfab-aaa-saml-10, February 2015.
[SAML-RADIUS]Howlett，J.，Hartman，S.，和A.Perez Mendez，编辑，“SAML的RADIUS属性、绑定、配置文件、名称标识符格式和确认方法”，正在进行的工作，草稿-ietf-abfab-aaa-SAML-10，2015年2月。
Acknowledgements
致谢
The authors would like to thank the members of the RADEXT working group who have contributed to the development of this specification by either participating in the discussions on the mailing lists or sending comments about our RFC.
作者要感谢RADEXT工作组的成员，他们通过参与邮件列表的讨论或发送有关我们RFC的评论，为本规范的制定做出了贡献。
The authors also thank David Cuenca (University of Murcia) for implementing a proof-of-concept implementation of this RFC that has been useful to improve the quality of the specification.
作者还感谢David Cuenca（Murcia大学）实施了该RFC的概念验证实施，该实施有助于提高规范的质量。
This work has been partly funded by the GEANT GN3+ SA5 and CLASSe (<http://www.um.es/classe/>) projects.
这项工作的部分资金来自GEANT GN3+SA5和CLASSe(<http://www.um.es/classe/>)项目。
Authors' Addresses
作者地址
Alejandro Perez-Mendez (editor) University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain
Alejandro Perez Mendez（编辑）穆尔西亚大学艾斯皮纳多S/N，计算机科学学院，穆尔西亚，西班牙30100
Phone: +34 868 88 46 44
EMail: alex@um.es
Phone: +34 868 88 46 44
EMail: alex@um.es
Rafa Marin-Lopez University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain
拉法马林洛佩兹大学穆尔西亚分校埃斯皮纳多S/N，计算机科学学院，穆尔西亚，西班牙30100
Phone: +34 868 88 85 01
EMail: rafa@um.es
Phone: +34 868 88 85 01
EMail: rafa@um.es
Fernando Pereniguez-Garcia University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain
费尔南多PrEnErgz加西亚大学穆尔西亚分校埃斯皮纳多S/N，计算机科学学院，穆尔西亚，西班牙30100
Phone: +34 868 88 78 82
EMail: pereniguez@um.es
Phone: +34 868 88 78 82
EMail: pereniguez@um.es
Gabriel Lopez-Millan University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia 30100 Spain
加布里埃尔洛佩兹米兰大学穆尔西亚分校埃斯皮纳多S/N，计算机科学学院，穆尔西亚，西班牙30100
Phone: +34 868 88 85 04
EMail: gabilm@um.es
Phone: +34 868 88 85 04
EMail: gabilm@um.es
Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 84 Madrid 28006 Spain
Diego R.Lopez Telefonica I+D Don Ramon de la Cruz，84马德里28006西班牙
Phone: +34 913 129 041
EMail: diego@tid.es
Phone: +34 913 129 041
EMail: diego@tid.es
Alan DeKok Network RADIUS SARL 57bis Boulevard des Alpes Meylan 38240 France
阿兰·德科克网络半径萨尔57比斯阿尔卑斯-梅兰大道38240法国
EMail: aland@networkradius.com
URI: http://networkradius.com
EMail: aland@networkradius.com
URI: http://networkradius.com